![]() ![]() ![]() Could it be a problem with how DOSBox rasterizes image? (Just thinking out loud.) Makes me wonder, how exactly vsync works in our case. Same could be said for other apps and games though (Quake). Superscape Benchmark, while able to output hundreds of frames, crawls down to mere 40FPS with vsync on. Is there any overlap with these that also cause degraded behavior with SVN? If so, perhaps some of the issue lies outside of SDL and in pure-DOSBox code. Wow nice testing! You've found a bunch of corner cases. Crusader shows slow down in the very beginning of intro cinematic: it's fading from black per-line. Moving cursor lightning fast in Master of Orion 2 still affects performance. Pixel dissolve in Catacomb 3-D doesn't slow down anymore nevermind, it is still slow seems I've missed something while testing. That's just me guessing though I'm not sure how to diagnose this though. Yes it's as if the video mode plays a role in exasperating vsync and HH's menu-mode feels like one of those fast demo-scene modes compared to the in-game-mode, which feels more "normal". Menu (and also after-play DOS screen) in HH95 is still affected. are DRI2 and 3 still enabled? From what I can see DRI1 always had issues with vsync and tearing.Īlso, does disabling DRI simply mean that SDL2 is forced to use a software (non-hardware accelerated) backend, in which case we're simply using software rendering again which we know isn't affected by this bug? Another question I have is regarding DRI. This area of driver/software interaction appears to be quite a mess after reading It's my hope that we simply use the most bullet-proof SDL2 calls in some "best practices" way, and get the best cross-section of compatibility.įully agree global settings are far worse than per-application, and I appreciate seeing your suggestions that we can control it locally (as a temporary work-around?). I hope the latter is true and we can entirely solve it in DOSBox. We still don't know if the problem exists in SDL2 itself or how the new DOSBox SDL2 code is configuring SDL2. just that it's interesting that tweaking the intel driver alone is sufficient to result in smooth tear-free play (without any adjustment to SDL2 or DOSBox's rendering settings). I'm not saying it's a solution or a good one. Whether it makes sense or not, the configuration eliminates the stuttering. In the meantime, I'll tidy up the coverage branch for a PR I'd like steadily add many tests that hit most of DOSBox's functionality. Demos are probably the best option I need to start combing through those too. Alternatives are cracktros (where usually only small objects or text are scrolling - also hard to see tiny tears). I'm reluctant to drop a bug in SF at this point in case the change was deliberate and QuickView is merely a non-game casualty.īut yes that video works great for seeing tearing! Much easier than trying to watch the scrolling horizontal background while simultaneously not dying in a platformer game. I eventually turned it into a testcase (on the in-progress kc/coverage-1 branch) and used bisect run until it landed on SVN commit 4301 you'll see a PM in vogons to yourself, QBix, and jmarsh. I ripped that video to AVI and found our master branch wasn't compatible with QuickView (throws a codec initialization error, but older DOSBox binaries work fine). Whoa - SDL2 supports wayland without X11 amazing! When I read the SDL guide for moving from 1.2 to 2.0, some of the patterns (ie: blitting and the sequence of new 2.0 function calls) don't jive with our code, some of which seems to still use the 1.2 approach and function calls (will write more details in the next day or so) so I'm hoping once we try these "standard" 2.0 call patterns, we might fix vsync too. If someone out there owns an Apple OS X machine, please chime in if you can. I need to dig more into SVN now too!)Īt least vsync is good on the Windows side. Jazz Jackrabbit doesn't use aspect correction hmm (maybe DOSBox auto-disables aspect correct for these custom VGA modes? Or maybe this is a bug in DOSBox and the custom mode or resolution is throwing off that aspect calculation? interesting stuff. Jazz Jackrabbit is unique in that it deliberately drops to a custom resolution (320x199 instead of 200) so it can run the display at 60hz instead of 70hz. Very interesting that aspect correction isn't performed. Thanks for testing on your side rules out something wonky with my Xorg and direct-rendering configuration. ![]()
0 Comments
Leave a Reply. |