Some feedback on the latest features

[PoloniumRain]

trafficstars

Just had a look at the latest changes you've made, and obviously a lot of these new features might not be finished yet and could change before the next release, but...

1. The new 3dfx Voodoo Hardware OpenGL option is huuuuge and massively improves performance :) I assume it works similar to DOSBox-X with glide passthrough enabled? There's also a Hardware OpenGL High Resolution option which seems to double the games native resolution. But i think it would be better if there was a separate resolution option for this, with 2x, 3x, 4x increases and so on. This would also make it clear to the user exactly what the setting does, and this is how other emulators deal with this feature (the DuckStation core is a good example). I can now run any 3dfx supported game and hit the games maximum frame rate with "High Resolution" 2x res enabled, so the performance headroom is there for much higher resolutions.

2. Hardware OpenGL fixes significant visual issues like #316. I need to do more testing but it's looking great so far.

3. The 3dfx Voodoo Gamma Correction option is really useful but by default it has incorrect gamma. There's roughly 30-ish DOS games that support 3dfx Voodoo and i've tried most of them. Every one of them now has incorrect gamma by default, so they look either too bright (most common) or too dark. Previously the gamma was correct in every game. So how about an "Auto" gamma setting that works exactly as things did before? Or have the current None gamma setting function this way. If there's some reason this can no longer be done with Hardware OpenGL, then i can create a list with the correct Gamma settings for every game and DBP could apply them on launch.

4. Software Multi Threaded (default) and Software Multi Threaded, low quality run worse than before. Frame rates are cut in half and i get significant sound stuttering/popping. It's similar to when i tried 1 CPU thread in my testing. But Software Single Threaded runs the same as when i tested with 7 threads... Are these options incorrectly labelled?

5. This only affects Hardware OpenGL - In Screamer 2, Screamer Rally and Carmageddon 2 the menu screens have the same issue as above, but not as severe and only with the menu screens. Seems like a possible threading issue but it's strange how (so far) it only affects the menus and never gameplay.

6. Running a 3dfx accelerated game and switching from any of the Software Multi Threaded or Software Single Threaded options to Hardware OpenGL will show a black screen after restarting the game. To fix this the game needs to be closed and run again.

Anyway, just ignore any of the above problems if it's simply down to the feature being unfinished. Excellent work btw!

[michael-leroy]

Interesting. I wonder if this would fix the graphical issues I see in Diablo 2 in glide mode on iPadOS. Since that platform is so restricted I am guessing I won’t be able to test this for a long while. It would be cool if a dosbox-pure beta (from main/master branch) core was added to Retroarch for such purposes.

Things are sounding promising though!

[schellingb]

@PoloniumRain Thank you so much for the detailed feedback. It isn't enabled by default just yet because it is new. But were it not for feedback like this, it likely would have been released as it is now :-)

1. The reason why we can't have arbitrary multipliers is because this DOSBox core has a fixed maximum resolution of 1280x1024 which is reported to the frontend (RetroArch) at start and we can't go past that. It will need some more under the hood changes to make this more flexible but I can look into it if you're interested. It would be neat to see even higher resolutions :-)
2. I don't know why the texture level-of-detail issues exist in the software renderer, it's code inherited from the original authors of the 3dfx emulation. I've noticed it not reappearing with OpenGL and I'm glad but ideally software rendering would also be fixed but I don't know how...
3. Before games were not gamma corrected at all so they really didn't look like original. In DOS games, the default value of SST_GAMMA is at 1.7. This can be changed in the command line with SET SST_GAMMA 1.0 to disable gamma correction. If you were to do that, and set the core option to "None" it should look like it looked before. The default 1.7 seemed way to bright so I ended up defaulting to -0.2.
4. Oh, you're totally right, the flag check for single threaded and multi threaded was flipped in code by mistake. I fixed it now.
5. The same issue meaning performance issue or texture issues? Rendering 2D in Voodoo with OpenGL is actually very tedious because every drawn pixel is a command that has to be translated to GL. I think full screen 2D screens can be slower on OpenGL than in software rendering due to that. We're already batching all pixel draws into a single OpenGL draw but it still needs a lot of processing to get there.
6. RetroArch should show a little notification popup saying "To enable OpenGL hardware rendering, close and re-open.". This is needed because at startup we tell the frontend if we want hardware accelerated rendering or not. If 3dfx is set to the default (software rendering), we don't request hardware rendering and thus we are limited to 2D functions. For now this is to not break any existing compatibility (it runs on devices that don't have OpenGL). In theory we could always request the 3D context but I'm conflicted a bit. If only a small percentage of users use 3dfx, it seems an unnecessary overhead...

@michael-leroy I really wanted to try Diablo 2 but I couldn't get it to run in DOSBox Pure. The only way I got Diablo 2 running was with software rendering in windowed mode. Can you tell me how I could get it running in glide mode? Any special version or patches? Hopefully new release soon!

[michael-leroy]

@schellingb It took me forever to get D2 working. The key is to use version 1.05b with a no-cd patch. You can get the needed files from this project:

https://github.com/ChaosMarc/D2VersionChanger

I didn't use the .bat file I just installed the game (full install) and copied the classic/1.05b files and then the no-cd game.exe. Software mode does run fine it seems. I didn't have to use window mode. Trying to use later versions makes it explode with an illegal operation usually due to fog.dll.

In glide mode the sprites are missing with white blocks around them, but the game does actually start and run. I can post screen shots/video later if need be. I tried several voodoo driver versions with no luck. At one point messing with some settings in the registry I was able to get the background rendering properly in glide mode, but almost all the sprites were missing.

Here is a video I do have of it running in software mode: https://youtu.be/2s7sPFEUKrQ

This is with an M4 ipad pro.

While on this subject do you know what is going on with mouse grab/lock in iPAD os with dosbox-pure? Having the system cursor and the windows 98/game cursor at the same time is less than ideal. Makes it really hard to play games like D2 and say Quake with a mouse. Seems like a upstream Retroarch problem. A bug has been open for about a year with no progress..

[michael-leroy]

Here is the video of D2 starting and running in glide mode:

https://youtu.be/QShKAzrYmWE?si=j_Q3tRD3MMmu3I2r

Let me know if you want me to file a separate issue/ticket on this. I don’t want to crowd/distract from OP’s report.

[schellingb]

Interesting... I wonder why it's so broken. I wonder if this would run correct in something like PCem.

[PoloniumRain]

but I can look into it if you're interested. It would be neat to see even higher resolutions :-)

Yeah definitely!!

3. Before games were not gamma corrected at all so they really didn't look like original. In DOS games, the default value of SST_GAMMA is at 1.7. This can be changed in the command line with SET SST_GAMMA 1.0 to disable gamma correction. If you were to do that, and set the core option to "None" it should look like it looked before. The default 1.7 seemed way to bright so I ended up defaulting to -0.2.

This is what i'm seeing...

You can see that with DBP 0.9.9 the 3dfx version has gamma that closely resembles software rendering, which has correct gamma. But now it's way too bright and i have to lower gamma to -7 to get it to match DBP 0.9.9. Every 3dfx game is like this to some extent but Blood is one of the more obvious examples. I remember many games were like this on real hardware, where some were too bright/dark and i'd have to adjust my monitor or Windows settings to fix it, which was always a pain, but the great thing about previous DBP versions is that i never had to bother with this. Every game always had correct gamma.

So now with DOS 3dfx games i can at least fix the gamma by adjusting the DBP gamma setting for each game and then save my core options settings with RA. But the biggest problem here is with something like Windows 98 where the DBP gamma setting obviously cannot be configured for individual games running inside Windows.

But somehow DBP 0.9.9 and older versions have correct gamma for each Windows 98 game that i've tried so far (only around 8)... Which is weird! Because i've no idea how it could get the gamma correct for 3dfx Windows games when some of these games will need separate gamma adjustments on real hardware. But now the gamma is too bright or dark with the default -2. For example Motorhead and Pod are too bright, but Carmageddon 2 almost looks correct, which is how i'd expect real hardware to work. Anyway all i know is that the previous gamma implementation worked extremely well for me, so can you add that back as an "Auto" setting or something? Btw i'm on Windows 11 with an RTX 3080 and haven't changed any RA or driver display settings that could be affecting my gamma.

5. The same issue meaning performance issue or texture issues? Rendering 2D in Voodoo with OpenGL is actually very tedious because every drawn pixel is a command that has to be translated to GL. I think full screen 2D screens can be slower on OpenGL than in software rendering due to that. We're already batching all pixel draws into a single OpenGL draw but it still needs a lot of processing to get there.

Sorry for not being clear, i meant it's a performance issue. One strange thing is that GTA is 2D but runs totally fine with Hardware OpenGL, and i've just noticed with Screamer 2 on the very first screen that appears where you select your team, it has frame rate issues and sound stuttering due to it running too slow, but this screen only shows four 3D models of the team logo's. It's a very simple scene with low complexity. This same screen runs perfect with DBP 3dfx Software rendering but Hardware OpenGL has better frame rates during gameplay, which has far higher scene complexity. Makes no sense.

Oh and Screamer Rally runs way too fast during gameplay with Hardware OpenGL, but this likely isn't a problem with DBP. Screamer Really has always had issues with the game speed being tied to the frame rate. So now that Hardware OpenGL produces far higher frame rates it seems to have sped up the gameplay. It's best to use DBP 3dfx Software rendering for this game. I'm only mentioning this because i'm sure someone will eventually make a post saying how Screamer Rally isn't working properly...

6. RetroArch should show a little notification popup saying "To enable OpenGL hardware rendering, close and re-open.".

In theory we could always request the 3D context but I'm conflicted a bit. If only a small percentage of users use 3dfx, it seems an unnecessary overhead...

Ah i didn't notice that notification even though it's really obvious! lol. Ignore this one then :)

[schellingb]

Anyway all i know is that the previous gamma implementation worked extremely well for me, so can you add that back as an "Auto" setting or something?

The problem is, previously we had NO gamma implementation. It showed the raw color data as rendered. completely unadjusted. This means things like fade-in/fade-out (for example used by the spinning 3dfx logo on game startup) doesn't work. Games like Quake 3 Arena use a special gamma curve to make fire and stuff pop out which resulted in very flat, dull colors before.

I was close to having 2 options "Gamma Correction in DOS" and "Gamma Correction in Windows 9x" but it seems that wouldn't be enough.

We can have a "disabled" option for gamma correction, but I'm not sure this is really what we want... The issues above are quite severe in my opinion.

Without gamma correction:

With gamma correction:

---

strange thing is that GTA is 2D but runs totally fine with Hardware OpenGL, and i've just noticed with Screamer 2 on the very first screen that appears where you select your team, it has frame rate issues and sound stuttering due to it running too slow, but this screen only shows four 3D models of the team logo's

GTA still draws the world with (rather large) polygons. The problem in screamer isn't the 4 team logos, it's the background (307200 pixels) and text (17737 pixel) which is a full screen drawing where each pixel is processed and converted for OpenGL rendering one-by-one. The Voodoo API isn't set up that the game can prepare a bitmap, it has to send a draw command for each pixel. For us this means drawing 2D on the entire screen (at 640x480) is similar to the game drawing 307200 polygons. There might be means of catching large pixel drawings somewhere in the process and treating it special, but it won't be easy...

Just to be clear, some games draw images like that, some don't. For example Tomb Raider has a full screen image on the title, but it choses to draw it with 12 or so large polygons, which of course is much faster.

[schellingb]

I added a bit of optimization to pixel drawing. It isn't magnitudes faster but hopefully noticeable. @PoloniumRain If you have some more time for testing, can you give the latest commit a shot?

[PoloniumRain]

This means things like fade-in/fade-out (for example used by the spinning 3dfx logo on game startup) doesn't work.

For me i get the opposite result... The 3dfx logo works properly in 0.9.9, but it doesn't fade in with Hardware OpenGL, it's very dark then instantly gets lighter...

https://github.com/user-attachments/assets/e48a15b3-f561-40b1-9e69-75a44f924c76

But with 3dfx Software it still works correctly. It might be a different logo to the one you're talking about though, because there's two different spinning 3dfx logo's. But either way that logo in Motorhead doesn't show the fade-in effect with Hardware OpenGL. The other spinning 3dfx logo looks the same in 0.9.9 or with the latest changes.

Games like Quake 3 Arena use a special gamma curve to make fire and stuff pop out which resulted in very flat, dull colors before.

I also don't have the same issue as in the images you posted. What version of Quake 3 is that because the font is different and the text is green? I have an original Quake 3 that has been updated with the official patch 1.32. It looks like this...

But to get Q3 to even run i had to use a driver file named OpenGL.dll and place it in the game directory. So maybe i'm getting different lighting results because of that, because i can't replicate that flat/dull look in the image you posted no matter what graphics setting i change in the game. This is my current settings...

it's the background (307200 pixels) and text (17737 pixel) which is a full screen drawing

Ohh that explains it! Pretty obvious now that i look at it again...

I added a bit of optimization to pixel drawing. It isn't magnitudes faster but hopefully noticeable. @PoloniumRain If you have some more time for testing, can you give the latest commit a shot?

That was quick! I'll test it tonight...

[michael-leroy]

I recall in the ancient days of yore some 3dfx games were too dark and I had to boost gamma. I think it being wildly inconsistent is fairly accurate to the real hardware?

RE: D2, can you guys reproduce the graphical glitches I see in the latest version with OpenGL enabled? When I get around to it I will try it on a Windows PC instead of iPadOS. What I wonder is if D2 never actually ran correctly on a voodoo 1. That is one thing that is a bummer about emulating a V1, the drivers are much older and are fairly ancient by the time Diablo 2 came out. It would be really nice to instead have Voodoo Banshee emulation. Not as demanding to emulate as a full voodoo 2, but has newer drivers.

[PoloniumRain]

Ok i tested the latest commit but sadly it doesn't seem to make any difference. The frame rates are identical on the menu screens.

@michael-leroy Just gave D2 a go and can't get it to work with 3dfx either, including with the new Hardware OpenGL. Like you say i think the Voodoo is just too old. From what i can find it definitely supports Voodoo 2 and 3, but probably not Voodoo 1. This is how it's looking for me with completely missing sprites....

Your best bet is to use PCem, which supports up to Voodoo 3 (but is only available for Windows and Linux). It has far better Windows support as well because DOSBox was never really intended to run Windows. There's a good chance D2 will work, but PCem focuses heavily on accuracy, so it requires way faster CPU's than DOSBox. To emulate even the minimum required CPU for Diablo 2 (Pentium 233MHz) you'll need a CPU at least equivalent to an AMD Ryzen 3600X.

[PoloniumRain]

Found a fix for the menu performance issue! It happens when Emulated Performance is set to either AUTO or MAX.

For Screamer 2, Screamer Rally and any other games with this problem, if i set the Emulated Performance to 300MHz it will now run the menus perfectly (solid 60fps). If i go up to around 600MHz and beyond i will get frame rate drops and sound stuttering again, exactly the same as with AUTO. So it seems to be caused by the CPU cycles being too high on AUTO when using Hardware OpenGL. How many threads does Hardware OpenGL use?

[schellingb]

OpenGL doesn't use any threads. Well, your graphics card driver might but that is out of our control. What OpenGL does though, unlike software rendering, it makes the main thread (of RetroArch) much busier than ever before. So maybe that causes the emulation thread to have to wait for the main thread which usually never happens. The AUTO/MAX CPU cycle scaling might just not work well with it.

[michael-leroy]

Ok i tested the latest commit but sadly it doesn't seem to make any difference. The frame rates are identical on the menu screens.

@michael-leroy Just gave D2 a go and can't get it to work with 3dfx either, including with the new Hardware OpenGL. Like you say i think the Voodoo is just too old. From what i can find it definitely supports Voodoo 2 and 3, but probably not Voodoo 1. This is how it's looking for me with completely missing sprites....

Your best bet is to use PCem, which supports up to Voodoo 3 (but is only available for Windows and Linux). It has far better Windows support as well because DOSBox was never really intended to run Windows. There's a good chance D2 will work, but PCem focuses heavily on accuracy, so it requires way faster CPU's than DOSBox. To emulate even the minimum required CPU for Diablo 2 (Pentium 233MHz) you'll need a CPU at least equivalent to an AMD Ryzen 3600X.

Your image matches what I got at one point trying different voodoo drivers and registry settings on iPadOS. I do suspect that the game never worked right on a real Voodoo 1 either (EDIT: The game runs fine with a voodoo 1 under PCem). I completely understand this may be out of the scope of the project, but running D2 in glide mode on the iPad would be so rad. Especially if hw openGL actually works on iOS/iPadOS. (One day..)

I know I can just use a PC. Heck I can just play the remastered version of D2, but AFAIK the only way to play D2 on the iPad is via Dosbox-Pure. The novelty is what makes it cool. It’s actually really awesome that the game runs in Direct2d even without JIT!

UTM SE is wayyyyy too slow to even attempt without JIT, even with a M4 CPU. I might try using PCem (on windows) if it has a Voodoo 1 to see if it’s broken in a similar way.

I am not totally familiar with all the dosbox forks, but is emulating a Voodoo Banshee out of the question? This card had much newer 3dfx drivers that are less likely to have bugs in various win 95/98 games. It’s essentially a crippled V2 so perhaps easier to emulate?

[schellingb]

I think emulating a Voodoo Banshee in DOSBox would be quite involved. A lot of its normal VGA rendering very much is built on top of its VGA code which can emulate an S3 card among a few others. Unlike Voodoo 1 and 2 which were separate, 3D only cards, implementing something like a Banshee in DOSBox is probably not an easy endeavor. It feels like Voodoo 2 is the limit for what we have. Voodoo 2 code is mostly in there but disabled in some places because I got crashes in Windows. Perhaps this could be fixed.

Edit: I tried to enable Voodoo 2 support and the code that is there seems just unfinished. Bugs I can maybe work around, but if the emulation in the DOSBox Voodoo emulation is unfinished, there isn't much I can do.

[PoloniumRain]

I did some testing with Quake II and uncapped the frame rate limit, then used the games built-in "timedemo 1" benchmark. This is the most demanding DOS game but performs particularly well with Hardware OpenGL + AUTO (no menu performance issues) and is a good example of just how much performance can be gained even when the res is doubled:

3dfx Software @ 640x480	Hardware OpenGL High Resolution @ 1280x960
28 FPS	98 FPS

There's also no difference AT ALL between 640x480 and 1280x960 when using Hardware OpenGL and Hardware OpenGL High Resolution, not even a 1 FPS change. The bottleneck is 100% CPU. This is on an RTX 3080, but i think if there was higher resolution scaling options then even 6x scaling (slightly over 4K) would run fine on any remotely decent GPU, maybe even some integrated graphics.

[schellingb]

Great numbers! Happy to see :-)

Keep in mind though that something like a timedemo or fastforward in the frontend is cheating a bit because it will end up not actually fully rendering all these frames. The emulation will prepare drawing of these frames by queueing up all the draw commands executed on the 3dfx card, but only when the frontend is asking for a new frame will the latest batch of draw commands actually be executed and (3D) rendered to be shown on screen. The software emulation does not have that freedom and will always make sure all 3D rendered images will be finished in the video cards memory at some point. This is actually important for some games that want to read back the rendered image and can lead to issues when using OpenGL where the resulting image is always delayed (an example is Extreme Assault which queries the depth buffer to figure out where to show target markers).

Scaling the output should have a small impact on a powerful desktop GPU. On an Android phone it does have quite an impact because a mobile GPU is very often fill rate limited. Same results on a Raspberry Pi.

[michael-leroy]

I think emulating a Voodoo Banshee in DOSBox would be quite involved. A lot of its normal VGA rendering very much is built on top of its VGA code which can emulate an S3 card among a few others. Unlike Voodoo 1 and 2 which were separate, 3D only cards, implementing something like a Banshee in DOSBox is probably not an easy endeavor. It feels like Voodoo 2 is the limit for what we have. Voodoo 2 code is mostly in there but disabled in some places because I got crashes in Windows. Perhaps this could be fixed.

Edit: I tried to enable Voodoo 2 support and the code that is there seems just unfinished. Bugs I can maybe work around, but if the emulation in the DOSBox Voodoo emulation is unfinished, there isn't much I can do.

Luckily it seems that D2 runs fine on a Voodoo 1. I setup PCem with a 2d card and a Voodoo 1. Using the 3.01.00 drivers, Diablo 2 1.05b runs great in glide mode. So the problem lies in the voodoo emulation on dosbox-pure.

@PoloniumRain Its really cool to see Quake 2 performance improve so much!

[PoloniumRain]

Keep in mind though that something like a timedemo or fastforward in the frontend is cheating a bit because it will end up not actually fully rendering all these frames.

Ah right, but i've found with Q2 that the timedemo is surprisingly representative of gameplay performance. If i start a new game, in the very first room i get almost identical frame rates to the timedemo on the same map. I've now ran through roughly 30% of the game and it's been great, typically around 80 - 130 FPS, sometimes going over 200 FPS! Although of course the Voodoo can't even display that many frames per-second.

With Hardware OpenGL i wonder if there would be some way around the Voodoo refresh rate limitation, so that DBP outputs as many frames as the game is rendering? Like any non-DOSBox game would typically work. Obviously it wouldn't be accurate to real hardware but that could also fix the issue with Variable Refresh Rate not working correctly.

[leilei-]

Somehow I knew the emulation of the clut tables would lead to the gamma shock like it's a new bug. There's a potential "always has been" astronaut meme here.

On real 3dfx hardware, everything was so gamma boosted, this gaslit competitors as being 'too dark' back in the day! The gamma's there likely from the arcade roots, where large CRTs for cabinets then really needed the correction (i.e. Konami's 1987-1993 games). Coincidentally it was also handy for users of S3 video cards which had a forced brightness boost that required monitor adjustment, so the 3dfx gamma boost was well compensated for that. Should also be noted Windows 95+ didn't have color ramps standardized for video drivers in these years.

Later Voodoo hardware (Voodoo2, Banshee/V3) would tone down the default gamma to 1.3.

It's very dark then instantly gets lighter...

that's how it is on the real thing too. The STB-era splash never had an instant appearance.

But to get Q3 to even run i had to use a driver file named OpenGL.dll and place it in the game directory. So maybe i'm getting different lighting results because of that, because i can't replicate that flat/dull look in the image you posted no matter what graphics setting i change in the game. This is my current settings...

The proper procedure is installing the latest drivers (The May 1999 "Quake3 certified" drivers, also available in GLSetup), and having Quake3 use r_gldriver 3dfxvgl. It should see the proper 3dfx gamma extension and send proper color ramps to the card to bring in the intended lighting range. This also overrides the 3dfx gamma setting, so it should look consistent with contemporary 3d hardware. The version in the screenshots is the 1.09 Q3DEMOTEST which shouldn't have any renderer differences from the final game and it's mostly cosmetic, 1-2 weeks behind gold date.

[schellingb]

Thanks for the insight @leilei- ! I'm fine with adding a "Disable Gamma Correction" selection to the "3dfx Voodoo Gamma Correction" core option, it would be a small change and would bring back to what it was before. But the default will probably stay like it is, maybe we go one lower? Not that it would help much...

[PoloniumRain]

So... I've just tested the new resolution scaling options on a RTX 3080...

QUAKE II

Resolution scale	Frame rate
1x (640×480)	98
2x (1280×960)	98
3x (1920×1440)	99
4x (2560×1920)	99
5x (3200×2400)	100
6x (3840×2880)	100
7x (4480×3360)	101
8x (5120×3840)	99

LOL no performance loss even at 5120×3840 .... I've double checked multiple maps and it's the same frame rates with any scaling setting. It's definitely working properly, at least up to 6x (4K) because that's the highest resolution displays which i have to test with, so 8x looks the same as 6x to me. Although the DBP Performance Statistics shows the resolution as 640x480 (it definitely isn't).

Maybe add up to 12x for 8K support? I know that's a little absurd but i doubt the frame rate would change much... I'm sure that even crappy Intel integrated graphics would be fine with 4x or higher, as long as the CPU is fast enough being as that's the real bottleneck here. With this much GPU performance headroom you could implement SSAA (supersampling). DuckStation core has this feature and it will provide the most perfectly anti-aliased image possible, better than any modern AA techniques.

Btw it's great seeing these old games at such high resolutions :) Quake II is looking like the recent remaster.

Oh and Screamer Rally crashes back to the DOS command prompt screen with Hardware OpenGL, typically within 1 minute of racing. So far it's been stable with 3dfx Software rendering, and i know it's stable with 0.9.9 because i completed the Championship mode on that version.

@leilei- Thanks, i'll give Q3 a go with those drivers/files.

[michael-leroy]

Will oGL hardware acceleration work in iPadOS? These performance numbers are pretty rad on PC.

[schellingb]

Found a fix for the menu performance issue! It happens when Emulated Performance is set to either AUTO or MAX.

For Screamer 2, Screamer Rally and any other games with this problem, if i set the Emulated Performance to 300MHz it will now run the menus perfectly (solid 60fps). If i go up to around 600MHz and beyond i will get frame rate drops and sound stuttering again, exactly the same as with AUTO. So it seems to be caused by the CPU cycles being too high on AUTO when using Hardware OpenGL.

Have you noticed any improvement with this since the last commit? It is an attempt that I'm not quite sure is correct but it does seem to help. But it also reduces the emulated CPU's speed a bit while using OpenGL Voodoo rendering (to avoid the stuttering).

[PoloniumRain]

Have you noticed any improvement with this since the last commit? It is an attempt that I'm not quite sure is correct but it does seem to help. But it also reduces the emulated CPU's speed a bit while using OpenGL Voodoo rendering (to avoid the stuttering).

Yeah the last commit definitely helps :) For example the menus in Screamer 2 no longer have any problems until i go up to 5x scaling, where as previously they would have issues with no scaling at all. Other games have similar results to this. But it does have a negative effect with Quake II, where i've lost about 15 FPS. There's some areas in certain maps where it will now dip under 60fps. The frame rate drop isn't visibly noticeable with any other games because they're all far less demanding, so if i uncap their frame rates they're still in the hundreds of FPS. So overall i think it works well.

Maybe DBP could detect Quake II at launch (q2.exe) and not apply the latest commit fix to just this game? It was the one game where it had zero issues with AUTO anyway. I've tried manually adjusting the cycles but nothing works quite as well as AUTO did before this commit.

[PoloniumRain]

Problems i've encountered with Hardware OpenGL so far:

• Decent 2 - Runs too fast and some HUD elements do not show (including the FPS counter which can be enabled by typing frametime).
• Screamer Rally - As mentioned previously, it runs too fast likely due to the insanely high frame rate with Hardware OpenGL, and then the game crashes back to the DOS command prompt.
• Incoming on Windows 98 - Runs too fast. Can be somewhat fixed by setting Emulated Performance to around 12000 cycles.
• POD on Windows 98 - Runs too fast. Can be completely fixed by setting Emulated Performance to Pentium 100MHz.
• Windows 98 - Edit: I've narrowed down this issue. Windows shows a black screen instead of the desktop when the scaling is set too high. The scaling seems to break when it exceeds a resolution that's roughly around 2560x1920. So if the desktop is set to 1024x768 then 3x scaling will show a black screen because the resolution has now gone over 2560x1920. The same thing happens for any Windows games that i've tried so far.

Since my last post i've now tried many more 3dfx supported games on both DOS and Windows. So far with the latest commit i can't find a single game that has menu performance issues with 1x - 4x scaling. Some encounter emulation slowdown with 5x on the menu screens (audio stuttering), while others are fine at 8x. It's made a big improvement! Again the ONE exception being Quake II which ran better previously.

[PoloniumRain]

The latest commit from a few hours ago works great. One example, Screamer 2 can now be scaled to 8x resolution without any audio stuttering on the menus! It's fixed stuttering for all the games i've tried, with any level of scaling. It's come a long way :)

Btw some games will show graphical corruption at the bottom of the screen after changing the scaling to 3x or higher when the game is running. This happened with every commit i've tried but forgot to mention it.

Some examples...

Pyl:

QDOS (DOS Quake with 3dfx Voodoo support and extra features):

Ignition shows a similar problem:

Going back down to 1x scaling wont fix it, but sometimes it will go away by exiting the level and loading it again. Or closing the game and running it again will always fix it.

[PoloniumRain]

The graphics corruption with scaling is a bigger problem than i first thought. It also happens with many games that don't have 3dfx Voodoo support as long as Hardware OpenGL + scaling is enabled. Closing and running the game again will not fix it in these cases. Hardware OpenGL needs to be disabled or scaling set to around 3x or lower. Obviously scaling wont work on these games anyway.

Edit: I wonder if this has anything to do with the issue that causes the Windows 98 desktop to not appear when the resolution exceeds roughly around 2560x1920. Some games, whether they have 3dfx support or not, will have issues when going too high, while others are fine at 8x.

Here's Destruction Derby, Screamer and Wipeout with 8x scaling:

[schellingb]

~~Can you provide more information how to reproduce this? Does this require first running a game with OpenGL and then without closing the content switch to another game? Is this just in Windows 9x? Does this require switching the scale factor while the core is running or does it happen when it is at > 3x from the start?~~

~~Can you enable the statistics in RetroArch via Settings -> User Interface -> On-Screen Notifications -> Notification Visibility -> Display Statistics and tell me what is shown for "Size:" and "Max Size:" when things are weird?~~

Edit: I think I figured it out :-)

[PoloniumRain]

Edit: I think I figured it out :-)

Commit 6975ea7 completely fixes the problem with all games that use a software render engine :)

But one small issue is the graphical corruption persists with some DOS games that support 3dfx Voodoo acceleration (i've only found 2 games so far, so it's not a big problem). Both Pyl and QDOS are DOS based games that will show graphical corruption at the very bottom of the screen.

To reproduce this:

1. Run Pyl or QDOS with 3dfx Voodoo acceleration with OpenGL enabled in DBP. Make sure scaling is set to 1x.
2. Start playing either game (get off the menu screens and into actual gameplay).
3. While the game is running increase the scaling to 8x.
4. You should now see graphical corruption at the bottom of the screen.
5. Press the escape key to bring up either games in-game menu screen.
6. The graphical corruption will now disappear (anything that updates the affected area of the screen will fix the issue).