![]() ![]() 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. ![]() Why is the latest SVN build dropping these? As a result, even though I save a new config, when I launch with my batch file, it doesn't load properly because the pertinent lines regarding viewport position and the overlay itself were omitted.Thanks for testing on your side rules out something wonky with my Xorg and direct-rendering configuration. This is what the latest Dosbox-SVN saves my config as if I start with a pre-configured CFG, then re-enable the overlay: Input_overlay = "./overlays/PC Amiga/1084x_night_wall_wood.cfg" It gets worse, it drops stuff from my config. Only after manually re-selecting the overlay, will it display. It starts up, obeys all my viewport parameters, but won't load the overlay. The newest Dosbox-SVN is doing something odd. cfg files located in the /config subfolder tree. With further testing I have found that overlays do indeed still work with Dosbox-SVN, however, the newest build is incompatible with custom config. This is strange, because I am on the 64-bit version of Windows 10, but that is how I have to do things so they work. ![]() I use the full CM-32L romset, plus I like to modify reverb, etc., and in order to do this I must run the 32-bit version of Retroarch to maintain compatibility with the Windows MUNT device driver. :(įYI I am using the 32-bit version of Retroarch for Dosbox, as there were issues with MUNT that prevented the 64-bit version as being an option. Now all I get is the dosbox output with no overlay. Now it is gone and will not display, despite being toggled on. I used to be able to have a nice PC monitor overlay in Doxbox until today, when i updated. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |