Some feedback on the latest features #519
Comments
|
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! |
|
@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 :-)
@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! |
|
@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: 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.. |
|
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. |
|
Interesting... I wonder why it's so broken. I wonder if this would run correct in something like PCem. |
Yeah definitely!!
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.
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...
Ah i didn't notice that notification even though it's really obvious! lol. Ignore this one then :) |
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:
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. |
|
I added a bit of optimization to pixel drawing. It isn't magnitudes faster but hopefully noticeable. |
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... 3dfx.logo.mp4But 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.
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...
Ohh that explains it! Pretty obvious now that i look at it again...
That was quick! I'll test it tonight... |
|
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. |
|
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. |
|
Found a fix for the menu performance issue! It happens when Emulated Performance is set to either 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? |
|
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. |
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? |
|
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. 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. |
|
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:
There's also no difference AT ALL between 640x480 and 1280x960 when using |
|
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. 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. |
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! |
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. |
|
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. Later Voodoo hardware (Voodoo2, Banshee/V3) would tone down the default gamma to 1.3.
that's how it is on the real thing too. The STB-era splash never had an instant appearance.
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. |
|
Thanks for the insight @leilei- ! |
|
So... I've just tested the new resolution scaling options on a RTX 3080... QUAKE II
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. |
|
Will oGL hardware acceleration work in iPadOS? These performance numbers are pretty rad on PC. |
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. |
|
Problems i've encountered with Hardware OpenGL 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. |
You do mean restart with the "Restart" button in the Quick Menu in RetroArch, not restarting by quitting the game into DOS and starting it again, right? It does work for me with QDOS, not sure what is different. It works fine for you in games other than Redneck Rampage or QDOS?
Here's a little guide how to compile and run the core on Android, only one thing needs to be downloaded and nothing needs to be installed system wide:
If you compile another version, name the file "dosbox_pure_libretro_android.so.20290101T0000000000.0000000002.0.lcbk" because somehow RetroArch remembers the old file name and doesn't want to install it? I'm not sure, this works for me. I have a batch file which builds the core, appends the actual date and time and copies it to the phone. But I still use 2029 so hopefully RetroArch thinks it's new. If RetroArch thinks it isn't new it will say "Core restoration failed" and you will need to try a different filename. |
Yeah, restarting from the Quick Menu. Here's exactly what i'm doing: SkipConsole.mp4That's using RA 1.19.1 (happens with a clean RA install as well) and the exact same thing happens with Redneck Rampage. Other games are working fine, but i've only tried roughly 15 so far. Thanks for the guide! I'll give it a go :) |
|
Think i've found the problem. The above issue only happens when a game is not run from a .ZIP file. I had both games unzipped and was running them from a folder, like So when QDOS and Redneck Rampage are run from .ZIP files, and i then set |
…executable as content path (#519)
|
Gotcha, when running an EXE file as content, it will always run it and it ignores any previous auto start/auto skip setting. But I changed it now that it will respect the auto start. This means you can start something like |
|
Yeah this way makes more sense. I just tested the change and it's working well. Problem solved! |
|
Alright i've finally tested Android (had some trouble, more on that later). This one's going to be long.... Device 1: Device 2: Test setup: Abbreviation meanings in the charts below: I'm using the SoC (System on a Chip) name instead of the phone name. This makes more sense because there's many other devices which use the same SoC's and should perform similar to these Samsung phones. The S8G2 in the S23 Ultra will have a clock speed advantage over other S8G2's, but it's minor. Q2DOS (QUAKE II) (640x480). Frames per-second:
Q2DOS: OpenGL resolution scaling:
Just from the Q2DOS results there's already a few interesting things here...
For the following benchmarks "Software" = QDOS (QUAKE) (640x480). Frames per-second:
QDOS: OpenGL resolution scaling:
Screamer Rally (640x480). Frames per-second:
Screamer 2 and Screamer Rally: OpenGL resolution scaling:
The Screamer 2/Rally track results (not the scaling results) are from when the car is sitting at the starting line. When actually racing the FPS drops from 60 to roughly 45 on the S845. The scaling results are an average of racing AI opponents. The S8G2 is always 60 FPS until 6x scaling is used.
Tomb Raider: OpenGL resolution scaling:
Fatal Racing / Whiplash: OpenGL resolution scaling:
Descent II: OpenGL resolution scaling:
Battle Arena Toshinden: OpenGL resolution scaling:
Grand Theft Auto: OpenGL resolution scaling:
GTA is another game where
Windows scaling with an Nvidia RTX 3080 and AMD Radeon RX 7900 XTX: It's been many years since i last used RA on a phone. Here's some problems with it and other random stuff:
So the reason Android testing took so effing long is because i ran into a VERY annoying issue. For example with Q2DOS, when i wasn't even moving the frame rate could jump up and down from ~80 FPS down to ~20 FPS on the S8G2. This is in an empty room with nothing happening. Most of the time it wasn't that severe though. Some times it might just be going up/down by 10 FPS or less. After a while the constantly jumping frame rate would occasionally settle down, but remain low, sometimes losing well over 50% of the FPS. This happened with I know what you're thinking... But it's not thermal throttling. Each phone only got slightly warm, and it's just a WAY too severe drop in FPS. It can instantly happen after starting a game after the phone has been idle for ages. I also tried The way to temporarily fix this issue is to either: Restart the game from the Quick Menu, close/re-open the game, close/re-open RA, open/close the Quick Menu, or just reloading the games map/track/area could fix it, like typing It mostly happens with QDOS and Q2DOS. Maybe it's just these games. Also, the faster the hardware, the more noticeable this issue becomes. So if you test this on something that only gets like 10 FPS, then it will be far harder to notice the problem with such a low FPS to begin with. I couldn't find the cause after changing loads of core settings on both phones. It doesn't happen on Windows. I also tried extracting the games from the .ZIP files and directly running from the .EXE's, but that had no effect. But ignoring this bizarre problem, DBP works well overall on a phone/Android. Apart from the keyboard! :) |
…witching from glPointSize to gl_PointSize (#519)
|
@PoloniumRain Ok, you have done some amazing posts around here but this one has to take the cake! Amazing work, thank you so much for the dedication! It took me a while but I finally have time to properly respond. I have only done a minimum amount of testing on my Android phone, which by 2024 is a low-end device and I've had similar experience to what you had on your lower end device. The rendering is very fill rate limited so scaling up beyond 1x is really hurting performance. Glad to see that higher end devices are quite a bit better in that aspect. With the OpenGL implementation my biggest hope was for the many lower spec devices RetroArch runs on (phones, handhelds, raspberry pi, ...) and at first it wasn't the holy grail I was hoping for but some of these numbers do look very good. It won't suddenly make complex Win98 3D games run amazing everywhere but quite a few titles will be much more playable which is super cool :-) Let's get to the feedback:
One thing you maybe didn't try is the alternative mouse modes. Touchscreen based phones really should switch the All your suggestion for a split layout or better scaling are great, if only it wasn't so much busywork to implement it :-) I'll try to keep them in mind.
Yeah it really isn't a frame rate but actually it counts how many of the frames had new 3dfx render commands executed. I now committed 3e4fcbb as an improvement to the detection and it seems accurate. Hooray :-)
What you're seeing is that the phone version of OpenGL (OpenGLES) doesn't support drawing points larger than 1 pixel, which is what we rely on for drawing 2D images with upscaling enabled. But turns out there are 2 ways to do that, one called
This is all RetroArch doing, but you're in luck, under Settings -> On-Screen Display -> On-Screen Notifications there is "Graphics Widget Scale Override" which will also scale those performance statistics. It will also scale other popups so not a perfect solution but for my testing I just keep that low while still having the menu be readable.
Yeah that would be on RetroArch to add support for VRR on Android. There are very few cores that have refresh rates above 60 FPS, so I'm not sure if that's a high priority.
Yeah, not much an emulator can do, it emulates a monitor with a software selected refresh rate, but then how often the software draws to that is up to the software. Because the core needs to tell the frontend in advance what the refresh rate is (and submit audio at that rate) it can't be modified to just stall submitting the next frame to the frontend until an actual new image is available. I almost feel like that is something a non-libretro based DOSBox variant might be able to do, but not sure how well it would work out in practice.
That is interesting, maybe it would be worth switching out the OGG decoder library we use, maybe others are faster.
I don't really know why this would be the case... Mobile CPU schedulers are just a mystery box, sometimes they do the most arbitrary things in the name of battery life :-) I wonder if RetroArch could introduce something like gamemode on Linux but for Android, where it somehow forces or tricks the OS into being nicer for the performance needs of games. Though I have no idea if that's a possibility at all, I try to stay away from mobile development as far as I can :-) Again thanks for the in-depth testing, got some good data out of that, and now some small but good fixes, too! |
Well, at least this is now possible with OpenGL😎 Just a short vid, but you can get an idea of how good the performance is. It looks like CPU performance needs to be decent enough to begin with for OpenGL to really start pulling ahead. Which is similar to how many 3D accelerated games performed back in the 90's, where they still relied far more heavily on the CPU compared to modern games. Quite a few 3dfx Win9x games are also playable on my 6 year old Galaxy S9+ but probably not anything shown in that vid where i'm using the Galaxy S23 Ultra. Over the last few days i've found some problems specific to Android:
Problems that affect both Android and Windows:
Typing is still slow but it helps a little...
Nice! I just tested it out with GTA, i'm pretty sure that it's now giving accurate readings, so i've added GTA benchmarks to my post above!
In case you didn't know, 70 FPS already works, at least on Windows :) For example, with DOS games like DOOM that output at 70Hz, my 120Hz TV with VRR will drop down to match this refresh of 70. So being as DOOM runs at 35 FPS, exactly half of 70, it then produces a perfectly smooth looking frame rate with no stuttering. But on a 60Hz display DOOM has obvious stutter. My TV can show the current refresh rate/VRR info, so i can see that it switches to 70Hz when i make the RA window fullscreen.
LOL that underscore has fixed all the affected games :)
Hope this post also helps! |
…nux file systems (#519) This fixes a crash during boot of an installed operating system on Android which expects these entries to exist.
…k cache the first time by showing a loading message (#519) Caching can take a minute or longer on a low end device, now the frontend stays responsive throughout the process.
…erating system for a split second that there is no media inserted (#519) Otherwise Windows 9x might not realize that the CD-ROM has been changed.
This sadly is a general problem with DOSBox. After all it was never meant to emulate Win9x, it's hardware accelerated CPU emulation (the dynamic core) takes some shortcuts to get more performance, which means a multi-threaded OS like Win9x can somewhat easily get confused by the minute differences when running on an ARM CPU as opposed to an Intel CPU. For now it is what it is.
I wish this was reliably reproducible. I get the huge error message on Unreal engine games but no crash. I'd like to not crash the core but if it crashes randomly it's hard to fix... The big Unreal error seems to be about some CPU calculation being off which matches my assumption above. You can change the emulation to not use dynamic recompiling (either by setting
Commit f6294f3 fixed this. Thanks for reporting!
Commit b6310d3 added a fancy message that pops up after a second or so while it is building the seek cache of the ZIP. I always thought there's no way around the freezing but it turned out to be not that complicated to show something on screen and keep the frontend responsive. Though hopefully it doesn't cause any issues because now it shows frame updates when it really shouldn't.
I tried the Acclaim demo from https://re-volt.io/downloads/demos and it shows the loading screen fine. But it might be related to other 2D rendering issues like the Descent 2 menu that still has some artifacts with OpenGL rendering...
Not 100% confident but I think commit f160e1b will improve that.
Commit c7bbbf3 now adds a 'Disable Gamma Correction' to the '3dfx Voodoo Gamma Correction' core option that should make things look like how they were in 0.9.9. Maybe another option with a different but still fixed 2.2 gamma curve? @PoloniumRain I was wondering, we're slowly creeping towards a release of all of this stuff, I might ask for a mention of the new version on the RetroArch blog once it is out and I was wondering if you'd be OK if I'd have them show off your YouTube videos? I was thinking of the two latest ones, Half-Life on the phone and Forsaken in 4K, they make it look very impressive :-) |
I think this actually fixed two issues lol... Because i forgot to mention it before, but on the Start Menu where you choose a HDD size when installing an OS, it would crash RA immediately after the .IMG file had been created. But now this no longer happens. Previously i got around this issue by just copying a Win98 .IMG from my PC to my phone.
So happy to see this!
Yeah, it would be the ideal setting if it works...
This works 100% of the time on Windows 10/11... But oddly enough it never works on Android... To make Win9x recognise a disc change on Android i need to open the Quick Menu, eject the disc, then close the Quick Menu, wait for around 3+ seconds on the Win9x desktop, then re-open the Quick Menu and insert a disc. Or i can do:
Yeah i think it is. Same thing with the black 3DMark 99 loading screen that i mentioned before. But speaking of 3DMark, i tried it again on Android, and the black loading screen doesn't always appear (it does on Windows). Instead, Android will display the very last frame from the previous 3DMark test. But the 3DMark loading/progress bar appears on top of it. So with the Decesnt 2 menu on Windows, if you press the F key to switch RA between windowed and fullscreen mode, it will turn the entire screen black. This might happen because the screen turns black for a split second when resizing the RA window like this, so it's just displaying the last frame again. But if you then press the Up/Down arrow keys, the Descent 2 menu will appear again because pressing these keys will highlight another menu item. Any kind of visual change like this will fix the problem. That's probably why animated bitmaps never seem to be affected, like the progress bar in 3DMark. But the Decent 2 menu is entirely static, and so are most loading screens. It's only completely static bitmaps that are affected.
Hmm there seems to be two freezing issues... There's the one you've just fixed, where for example, with the game Ripper if i run
The image above is what happens after i've selected 'Load Archive' for the eXoDOS versions of GTA and Harvester. On the first attempt, both games will cause the above RA menu screen to freeze for 3+ minutes on the Galaxy S9+, and after roughly 30 seconds Android will ask if i want to close the app because it's unresponsive. If i choose 'Wait' then eventually these games will start. Although this happens with such a small amount of games that it isn't a huge problem or anything (but it might happen with more games on very old/slow hardware). The size of a .ZIP file appears to partially be the cause of this, but not the main reason, because far larger games like Ripper, which is 4.15GB, will get past that frozen screen in under 5 seconds. GTA is 1.2GB and Harvester is 1.3GB, but most larger games from 1.5 - 4GB in size will only freeze for just 1 - 8 seconds. Anyway i'd be surprised if there's anything you can do here! It's more of an RA problem.
Yeah course :) I was actually planning on making a longer compilation video that shows way more games running with OpenGL. I'll probably get round to it some time next week... |
And it does not happen if the file extension is changed from .ZIP to .DOSZ. So yes, this seems to be a RetroArch issue... It somehow does something with the ZIP even though "Load Archive" should just pass the path to the ZIP to the core and leave it at that. But instead it seems to do some big operation on it... Does it extract it? Or calculate a checksum of the content? Or just waste time reading the file for nothing? I wonder... |
|
I don't mean to spam another long post with benchmark tables... But lol.... I was messing around with I'm not even remotely familiar with C++, i've no idea what i'm doing, but this line looked interesting. So i changed this:
To this...
And it showed a slight FPS improvement. So then i made multiple builds for both Windows and Android, where i changed it from 150 to 600 in increments of 50. After tons of testing i narrowed it down and found that Abbreviation meanings in the tables below:
Because the difference to the frame rate is small i've ran the above tests 10 times for each demo, just to be completely sure, because there's always some small variation for each run. So these results are the average FPS for each of those 10 runs. Overall Android testing is such a pain that i didn't bother testing it as thoroughly for each game below, so all of the following games will just have the results for Windows/Threadripper, but basically these games on Android/S8G2 performed similar to the results above, where the FPS increase was typically slightly better than on Windows with the Threadripper.
Ah yeah you're right, that's weird. When using .DOSZ all games will now get past that screen almost instantly, with a 1 second freeze at most, no matter how large the game is. If it's extracting the .ZIP then i can't find where it's being extracted to... But it looks like i'll be changing all my games to .DOSZ then. And @schellingb this is unrelated but do you know why DBP has some different looking text characters to DOSBox Staging on the command line screen, like below? Which one is accurate? Some characters like the 0 and M look squished on DBP, but then the Y, W and T all have different character designs. I'm just asking because i'm making a DOS font so i'm looking for a very accurate example to base it on. I know these characters were stored in ROM, so maybe there's some variation between ROMs, in which case i'll just have to find a nice looking character set which was also common. BTW i haven't had time to do that vid i mentioned! |
Oh, that's a lovely improvement there. The number there is basically the threshold required for how many pixels a triangle must fill on the screen for it to use the threaded rendering. So 200 pixels would be something like a triangle covering a 20 by 20 pixel area. 350 is like a 26 by 27 pixel large triangle. Generally the more modern of a game is being emulated, the smaller the polygons become and thus it will more often forego the threaded rendering. I haven't really done any testing on what other factors affect this but your tests seem quite conclusive.
Yeah, I should look into this, it seems a bug in RetroArch and it's quite peculiar this isn't happening on Windows.
No idea... DOSBox Pure should look like original DOSBox. But I tried two more things, VMWare with MS-DOS 6.22 and PCjs.
You could maybe also try real MS-DOS in PCem to see how it looks there by emulating various types of PCs and video cards. |
Improves 3dfx Voodoo frame rates by 3 - 8% (sometimes slightly less or more) depending on the game. This applies to the core options 'Software Multi Threaded (default)' and 'Software Multi Threaded, low quality'. Many game test results can be viewed [here.](schellingb#519 (comment))
|
Alright i've just created a pull request and it's the first time i've created one, so let me know if i've messed something up...
Yeah i roughly guessed that from the code comment "Don't wake up threads for just a few pixels". If that wasn't there then i'd be lost and never would have stumbled upon this performance improvement. It's all just a total fluke. Don't expect me to do anything else like this lol... I'm only used to simple web development languages.
Totally forgot that i already have PCem. Thanks for those other suggestions! |
|
I was thinking, could MSAA options for OpenGL be added? I'd imagine that this is now a possibility... So for example, within Core Options > Video there could be Speaking of 86Box, i was recently trying it out and it has this extremely useful feature:
It lets you mount a folder as the disc drive. This is SO much easier for getting drivers/games/software on to Win9x. Meanwhile with DBP, there's a few awkward ways to transfer files:
Being as RA doesn't allow for folders to be selected in Quick Menu > Disc Control, maybe a similar feature to 86Box could be added in the Core Options? But instead of also adding an "Eject" option for the disc (folder), it could instead work where you'd only need to select a different folder, which would then automatically "eject" and change the current disc (folder) in Win9x. Or if there's a reason why this can't be done, then having a Core Option to select a folder as a drive would be just as good. It doesn't have to be the D drive either. There could be an option that allows a folder to be mounted as any drive letter. The downside to this is that it couldn't be ejected/changed while the OS is running. But the positives are that it would obviously allow for writes, instead of just reads like with the disc, and it would get around the D drives 8GB size limit. Having both options would be ideal, but either would be hugely helpful, especially to new users. I think that since OpenGL was added, DBP is now easily one of the best ways to play Win9x games, at least for games that only support the Voodoo 1 and don't require MMX (and unlike PCem/86Box, DBP doesn't have severe input latency, plus the overall frame rates are now better than DOSBox X). So having helpful Win9x features like these would be really nice. |
Yeah, that seems like a good next step. SSAA is basically what we already do with the upscaling, but the core would then bilinearly scale it down before passing it to the frontend. MSAA needs some work with how the framebuffers are set up. Put it's probably something for a next version of the core :-)
This seems like a neat feature. Certainly not trivial, to real-time emulate a CD-ROM filesystem. For DOSBox Pure I did the emulation of a FAT file system for emulating the D: drive with any DOSBox drive (mounted directory or ZIP, etc.). CD-ROM emulation could be implemented but even more than that I would like a FAT file system emulation that writes modifications done on the D: drive into a regular DOSBox Pure save zip instead of the opaque hard disk delta files we have now.
A core option can't be something like a directory selection, it is always a selection from one list of items. But... very recently I have contributed this change to RetroArch: This now allows directories to be loaded as the content for DOSBox Pure directly via the Load Content. It also allows that for discs, but for now this only works in DOS, not in Win9x (again, due to there not being something like a CD-ROM filesystem emulator).
There is no way to simply make a transparent folder mounting like you describe. Win9x running inside DOSBox means that all drivers of Win9x run. This includes hard disk and file systems drivers. This means the emulator itself really can just present the OS a block of bytes that makes up an emulated hard drive. So on that level there is no concept of files. One way to achieve this would be if the emulator were somehow able to emulate a full Windows server that offers a network drive to be mapped via Windows file sharing. This is feasible, but will include a lot of work and research. Of course the open source project samba is out there but nowadays that is huge because it supports all kinds of versions of Windows, all kinds of protocols, all kinds of security standards and encryptions. We would basically need none of that. Even if that was figured out, then implementing a fake network server that responds to network packets sent by the emulated OS will still be quite a task. Another option would be to develop a custom Win9x file system driver that somehow does the passthrough, but.... that seems even more complicated and also would mean anyone who would want to use this would need to install this custom driver in their Win9x installation. |
|
There is also VBSF - DOS shared folders support for Virtualbox. Maybe you can implement the Vbox interface in Pure... |
|
DOSBox emulates DOS, it has no problem providing real drives to the emulated application based on anything (mounted directory, zip, filesystem). VirtualBox just like VMWare has something called "Guest Additions" for many operating systems which is what I described above with "custom Win9x file system driver that somehow does the passthrough". The Virtual Box Windows Guest Additions only support Windows NT/2000/XP and up, so none for Windows 9x which is what we'd need. |
I'd love to see SSAA on Win9x games :) Although even higher scaling options would be needed for SSAA, maybe up to 16x. I know that sounds stupidly high but the Voodoo's lowest resolution is 512x384 (although most games only go down to 640x480), so being as the current maximum 8x scaling would produce 4096x3072, that wouldn't be high enough for SSAA to show any meaningful difference on a 4K display. For comparison the Flycast and DuckStation cores have up to 20x and 32x scaling, although these are overkill unless you have an 8K display! But it would be amusing to test these kind of ludicrous resolutions with DBP...
Excellent! |
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...
The new 3dfx Voodoo
Hardware OpenGLoption is huuuuge and massively improves performance :) I assume it works similar to DOSBox-X with glide passthrough enabled? There's also aHardware OpenGL High Resolutionoption 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.Hardware OpenGL fixes significant visual issues like Texture rendering issues in most 3dfx games #316. I need to do more testing but it's looking great so far.
The
3dfx Voodoo Gamma Correctionoption 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 currentNonegamma 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.Software Multi Threaded (default)andSoftware Multi Threaded, low qualityrun 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. ButSoftware Single Threadedruns the same as when i tested with 7 threads... Are these options incorrectly labelled?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.
Running a 3dfx accelerated game and switching from any of the
Software Multi ThreadedorSoftware Single Threadedoptions toHardware OpenGLwill 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!
The text was updated successfully, but these errors were encountered: