-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extremely low framerate with high resolution #45
Comments
Try using fixed cycles, and up them to 50.000 or even more. Also make sure the CPU core is set to dynamic. Finally, try other timing sync modes (internal, external.) Also try running it in the DOSBox-core core and see if that helps. |
It is using fixed cycles (30000). 50000 makes it worse really. As said, the game does run at full speed (no sound stuttering), it's only screen redraws, so it's not about CPU cycles. Tried all 3 timing modes, same thing. No difference with DOSBox-core either, except there's no internal mode there (same thing with internal (fixed 60FPS) though) See the recording: https://www.youtube.com/watch?v=5HusT6_FlgY No issues in standalone DOSBox. |
The FPS indicator at the start says 103? Did you forget to enable vsync maybe? |
No. The core doesn't output video on each frame, |
What I'm saying is why is it called 103 times per second? Shouldn't it be either 60 or 70? |
Good question. VSync is on. Hard GPU sync was off, but no difference other than the FPS indicator if it's on. |
Guess I'll have to install this game and see what's going on there. |
You can also use Duke Nukem 3D or Quake, really. Anything with high resolution. |
OK, I just tried Duke 3D in dosbox-core. I upped the cycles to 200.000 and that fixed it. Normally setting cycles to "max" is supposed to up the cycles for you, but it doesn't work reliably on all systems in the libretro cores, only in stand-alone dosbox. So it's best to use a fixed cycle count and set it high enough depending on how many cycles the game needs. |
Oh wow, indeed. I assumed since 50000 didn't help, higher values won't either. Any specific reason why auto/max doesn't work in the core? |
Dosbox's cycles calculation algorithm breaks if the emulation is interrupted every frame. That's how RetroArch and indeed libretro in general works. The emulation runs for 1 frame, then it is interrupted and control is transfered back to Retroarch. I would need to write a new cycle calc algorithm that is able to cope with that. Interestingly, not all systems are affected. For some people, it works fine. I think it has to do with frame time stability, but not sure. |
Fair enough :) |
Oh, also, any reason why the default value for CPU cycles is so small? |
10.000 cycles usually doesn't break older games. With higher, they can outright crash, or completely misbehave. So about 10k is a safe value. Obviously 10k is not enough with late-gen DOS games, but what can you do. You'll just have to up the cycles for those games. |
Oh, btw, DOSBox-core is the core that gets new features: https://github.com/realnc/dosbox-core#dosbox-core DOSBox-svn is in maintenance mode. It only gets bug fixes and is only kept around for platforms that are too old to run DOSBox-core. |
OK. Last time I checked it, it was a pain to build as it required network access in build time to fetch submodules IIRC. Also seems it doesn't run the game you provide, only cds into thar dir, which is a no-go for our purposes. Didn't get to report that yet though. |
Same with this core though. It also has a mandatory submodule (
Oops. That's a bug. I just pushed a fix for it. The libretro buildbot is gonna take a while to offer the new builds in the RA updater, but you can get them right now directly from: https://github.com/realnc/dosbox-core/releases/tag/latest_build |
Indeed. Then it wasn't submodules, I just remember it tried to fetch something and failed. Will migrate to dosbox-core later, but probably expect a PR making fluidsynth and other midi-related deps build options first. :) Context: we're using dosbox-svn in GNOME Games right now (in master only, not in stable yet as there are some blockers, mostly on retro-gtk/Games side). So we won't use fluidsynth etc, and building all of the added deps takes a pretty long time. |
In games like Blood the screen refreshes very slowly in high resolution modes like 800x600. The game still runs at full speed, but the screen refreshes very infrequently, just a couple times per second.
At the same time the game does run smoothly with fast forward, so it seems there's some kind of delay between redraws rather than redraws being slow.
The text was updated successfully, but these errors were encountered: