search

libretro / dosbox-svn

GNU General Public License v2.0
6 stars 17 forks source link

Extremely low framerate with high resolution #45

Closed alice-mkh closed 4 years ago

alice-mkh commented 4 years ago

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.

realnc commented 4 years ago

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.

alice-mkh commented 4 years ago

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.

realnc commented 4 years ago

The FPS indicator at the start says 103? Did you forget to enable vsync maybe?

alice-mkh commented 4 years ago

No. The core doesn't output video on each frame, video_cb() is called with NULL framebuffer most of the time, so the FPS indicator lies.

realnc commented 4 years ago

What I'm saying is why is it called 103 times per second? Shouldn't it be either 60 or 70?

alice-mkh commented 4 years ago

Good question. VSync is on. Hard GPU sync was off, but no difference other than the FPS indicator if it's on.

realnc commented 4 years ago

Guess I'll have to install this game and see what's going on there.

alice-mkh commented 4 years ago

You can also use Duke Nukem 3D or Quake, really. Anything with high resolution.

realnc commented 4 years ago

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.

alice-mkh commented 4 years ago

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?

realnc commented 4 years ago

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.

alice-mkh commented 4 years ago

Fair enough :)

alice-mkh commented 4 years ago

Oh, also, any reason why the default value for CPU cycles is so small?

realnc commented 4 years ago

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.

realnc commented 4 years ago

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.

alice-mkh commented 4 years ago

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.

realnc commented 4 years ago

OK. Last time I checked it, it was a pain to build as it required network access in build time to fetch submodules IIRC.

Same with this core though. It also has a mandatory submodule (libretro/deps/common). But submodules are not downloaded during build-time. You fetch them beforehand when you clone the repo by using the --recurse-submodules option when doing git clone, or afterwards with git submodule update --init.

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.

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

alice-mkh commented 4 years ago

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.