I keep running into random unhandled exception errors with Bizhawk, particularly when I was running Mystic House (on Windows 3.1, using Win32s), and now while trying to play back and modify the Windows 95 installation movie.
This happens when using TAStudio. I have not had exceptions occur when just playing back bk2.
I managed to play back the Windows 95 installation movie bk2 without any error, but when I load it in TAStudio, it starts occuring a lot at around frame 8000+.
Since it takes ages to load a 2 GB hdd with Windows 95, I was thinking about modifying the installation movie to only use 500 MB, but since the bk2 desynced halfway through, I wanted to modify it in TAStudio but kept running into the aforementioned errors.
It is possible this is due to my old hardware, Windows 7 and only 8 GB RAM. Perhaps it is soon time to migrate to a newer system.
What's odd is I wasn't running into these kind of errors when I did TASes of other games. Perhaps it is due to the high RAM usage, whereas previous games didn't require that much RAM.
I keep running into random unhandled exception errors with Bizhawk, particularly when I was running Mystic House (on Windows 3.1, using Win32s), and now while trying to play back and modify the Windows 95 installation movie.
This happens when using TAStudio. I have not had exceptions occur when just playing back bk2.
I managed to play back the Windows 95 installation movie bk2 without any error, but when I load it in TAStudio, it starts occuring a lot at around frame 8000+.
Since it takes ages to load a 2 GB hdd with Windows 95, I was thinking about modifying the installation movie to only use 500 MB, but since the bk2 desynced halfway through, I wanted to modify it in TAStudio but kept running into the aforementioned errors.
How do these exceptions look like? InvalidOperationException?
If I remember correctly, since BizHawk 2.11.1, TAStudio buffers are already increased. Not to mention, it uses new savestate manager by default. Also, enabled Rewinds can be the root cause. Windows 7 sends a notification when you're low on memory. At worst, it would kill BizHawk process with no exceptions.
I don't think it's a compatibility issue. It would be if BizHawk threw an exception on a specific action. DOSBox-X is also compatible with Windows 7.
TASing is like making a film: only the best takes are shown in the premier.
https://xkcd.com/3246/
@Dimon12321
Yes, InvalidOperationException.
Google AI suggested I try switching to Display method OpenGL, disable Rewinds, minimize the TAStudio window during playback, check Config -> Customize -> Advanced -> Store movie working data on disk instead of RAM, set TAStudio -> Metadata -> Savestate History Settings -> Gaps Buffer Size to a higher value.
None of this fixed the issue.
The only way I can advance in TAStudio is to load the tasproj file, advance by 200 frames, save a branch, then advance another few frames to hopefully advance more and save another branch but usually it crashes at this point already. I can only advance in steps of 200~300 frames.
I haven't tried Bizhawk 2.11.1 yet.
For TASing on Windows 95, any quirks or things that I should be aware of, to boot into Windows and start the game as soon as possible?
I can't seem to find Windows 95 publications that used Bizhawk that I could use for reference.
Should I just make sure the game icon is on the desktop, press the first letter and Enter? And make sure the first letter isn't occupied by one of the existing icons?
For TASing on Windows 95, any quirks or things that I should be aware of, to boot into Windows and start the game as soon as possible?
Windows TASes are concentrated around the game-related part. Milking out every last frame possible from everything coming beforehand is not mandatory. For example, GTA 2 TASes use Start menu to reach the game, which is not the fastest method, although it's covered up by the lasting Windows arrangements after booting.
From my experience, the double-click on a shortcut is the fastest method on both W95/W98, but the fastest operation may result in time loses because Windows may not prioritise it high enough.
An inserted CD with autorun.inf pointing to an exe or a shortcut isn't the fastest launch method because of low priority. On Windows XP, however, a native autorun of an .exe is probably the fastest method.
TASing is like making a film: only the best takes are shown in the premier.
https://xkcd.com/3246/
@Dimon12321
Alright.
I found that you can insert the directory to the game .exe in the Win.ini file to start the game automatically when booting into Windows.
1. Run... -> "notepad c:/windows/win.ini"
2. Behind "run=", enter the game .exe file's directory ( e.g. "c:/game/game.exe")
3. Press ALT+F4 and then confirm to save
4. When Windows loads up the next time, the game starts automatically.
Just to be more clear, those crashes I mentioned happen only when using TAStudio and rewinding at least once.
For example, I encountered them after rewinding to edit input while installing a game or while installing Windows 95 itself.
For some reason, this never happened when I was working on Windows 3.1 projects.
For Windows 95 games, perhaps I will have to restrict myself to not using TAStudio depending if I encounter crashes...
Although I don't know how I will do perfect mouse movement if that happens...
Looks like Bizhawk 2.11.1 actually fixes the mentioned crashes.
Sorry to disturb this topic with several posts, I should have tried switching to the newer Bizhawk earlier even when I didn't expect any change.
At the very least, I have been TASing Ultimate Soccer Manager 98 in TAStudio for hours and have reached halfway through the game without a single crash, whereas on Bizhawk 2.11 I get a crash every 2 minutes.
Perhaps this being the responsible fix:
I'm trying to get Live Wire! to look better on Windows 95. After a fresh install, the game is all horizontally striped, likely because it relies on its Fast Software Renderer, which is the only selectable device when starting the game.
Whereas in this video (1:15), it shows Microsoft Direct3D Hardware acceleration through Direct3D HAL as the selected device and the game is displayed correctly.
How can I get Windows 95 to support Direct3D? Google AI told me to install voodoo graphics drivers (July 2000) from here, among other things. Although it installed correctly, it didn't change anything as Fast Software Renderer is still the only selectable option.
In dxdiag → Display, DirectDraw is enabled, but Direct3D is greyed out.
--------------------------------
Fast Food Tycoon 2 aka. Pizza Connection 2 crashes within seconds on Windows 95 when entering a game and the city is shown.
Using the installer .exe with MD5 a1df3f3d6df489305b9b40e4f1e32951, I always get the Direct3D option in the dropdown menu after installation, on W95 with either S3 Trio64 or Vision 968, and in W98. Can you check if you're using that installer? What else would be different?
MUGG wrote:
In dxdiag → Display, DirectDraw is enabled, but Direct3D is greyed out.
This is normal for the main video card the DOSBox-x core uses (Display 1). The Display 2 tab, as well as Control Panel>Display>3dfx Voodoo Graphics, list Direct3D acceleration enabled for that card. Maybe this is where the hardware acceleration comes from.
MUGG wrote:
Fast Food Tycoon 2 aka. Pizza Connection 2 crashes within seconds on Windows 95 when entering a game and the city is shown.
I couldn't reproduce this either. Due to its later rerelease, I could only find a Russian image of the original Pizza Connection 2. When I opened the game on W95, clicked the second menu option (green pepper icon), and loaded the city, I waited until 00:50 on the clock and it didn't crash for me with S3 Trio64. Here was the .conf I used with both Live Wire! and PC2:
[cpu]
cputype=auto
cycles=fixed 250000
core=dynamic_x86
[sblaster]
sbtype=sb16vibra
[video]
vmemsize=16
vesa modelist width limit=0
vesa modelist height limit=0
Using the installer .exe with MD5 a1df3f3d6df489305b9b40e4f1e32951, I always get the Direct3D option in the dropdown menu after installation, on W95 with either S3 Trio64 or Vision 968, and in W98. Can you check if you're using that installer? What else would be different?
It turns out, for some reason I hadn't installed all of the utilities for windows 95 in my standalone DOSBox-X.
I now installed the voodoo drivers from the utilities ISO and the new setting now does show up in the launch settings for Live Wire!.
However, the game looks very wrong in-game, many visible problems can be seen at the main menu... I'm trying to find out what's causing this. Do you see the same issue?
I don't see it on BizHawk 2.11.1. I should've mentioned I'm using that, haven't tested 2.11. Here's how my launcher looks:
And the level select you posted has all the 2D graphics that are missing (titles, face textures, etc.):
Good to see it works on Bizhawk. I guess it works right after the windows 95 installation movie.
I did another 1-2 hours of trying around and didn't get it to work on standalone.
Tried changing some settings in DOSBox-x and related to [voodoo], also tried re-installing voodoo drivers.
Sometimes I noticed it would say 3dfx Interactive DirectX 5 Driver instead of 3dfx DirectX Driver, but there was no difference as I faced the same problems in-game.
Higher cycles might not always be better! Some Windows games, like Worms Armageddon, follow the old DOS principle of timing loops, which makes the performance worse on fast CPUs.
By "timing loops", I assume you mean measuring the speed of the CPU and using that as calibration for how many iterations of a busy-loop to do, as a way of implementing delays.
Some games do this, but Worms Armageddon is definitely not one of them. It uses the GetTickCount and QueryPerformanceCounter clocks for timing. Increasing DOSBox-X cycles benefits WA.
Higher cycles might not always be better! Some Windows games, like Worms Armageddon, follow the old DOS principle of timing loops, which makes the performance worse on fast CPUs.
By "timing loops", I assume you mean measuring the speed of the CPU and using that as calibration for how many iterations of a busy-loop to do, as a way of implementing delays.
Some games do this, but Worms Armageddon is definitely not one of them. It uses the GetTickCount and QueryPerformanceCounter clocks for timing. Increasing DOSBox-X cycles benefits WA.
I don't know what happens at the low level. The internet, including AI, provide some vague descriptions of this process, and I don't know which one to use and summarise. I just want players to be aware of this kind of outcome, that a faster CPU doesn't always mean higher framerate. If you would like to help, please, provide your rephrase of that warning!
By "benefits", I don't know what to assume, because you decreased the cycles for WA and got a fairly stable framerate. Maybe having them increased benefits the game itself, but not the TASer.
TASing is like making a film: only the best takes are shown in the premier.
https://xkcd.com/3246/
I don't know what happens at the low level. The internet, including AI, provide some vague descriptions of this process, and I don't know which one to use and summarise. I just want players to be aware of this kind of outcome, that a faster CPU doesn't always mean higher framerate. If you would like to help, please, provide your rephrase of that warning!
Well, please remove the use of Worms Armageddon as an example :-) It is incorrect. I don't know offhand an example of a Windows game that does this, but in the meantime until we come up with a real example, it would still be better not to give an incorrect example.
Dimon12321 wrote:
By "benefits", I don't know what to assume, because you decreased the cycles for WA and got a fairly stable framerate. Maybe having them increased benefits the game itself, but not the TASer.
No, I increased the cycles; eien86's movie (which skipped about 45% of WA's game engine frames) used 600000, and I increased them to 4000000, which is 6.667 times bigger... a very big increase. I had also tried 3000000 and it wasn't enough to get rid of all frame skips.
And I think this even reflects realistically what a PC of the time would do with WA v3.8.1. I did some tests in 2019 with the PC I used from 1998-2001, and they suggest it would easily do 60 fps at 1024×768. Unfortunately that motherboard no longer works now so I can't do a more focused test.
[2019.08.07 09:10:00] <Deadcode> Well I set up the system I ran W:A on originally :) Pentium II 333 MHz with Gigabyte GA-686DLX motherboard and 256 MB of PC100 SDRAM (well, back then it was 128 MB) and GeForce2 MX 32MB AGP video card (although for the first few months I played W:A, it was an ATI All-in-wonder Pro AGP - not sure if 8MB or 4MB - I'll try that next)
[2019.08.07 09:10:24] <Deadcode> The motherboard+CPU has been in a static bag since 2002. This is the first time since then it's been powered on.
[2019.08.07 09:11:14] <Deadcode> So W:A v3.0 didn't run very well. At its max res of 1024x768, it only looked to be running at 30 fps or less.
[2019.08.07 09:15:45] <Deadcode> W:A latest alpha runs much better. At 1440x900 it can do 60 fps if the viewport is not too full. Otherwise it drops down to 30 fps if vsync is on, or just slightly below 60 fps if not (but then there's tearing of course).
[2019.08.07 09:15:51] <Deadcode> Oh yeah, and this is under Windows 98 SE.
By "benefits", I don't know what to assume, because you decreased the cycles for WA and got a fairly stable framerate. Maybe having them increased benefits the game itself, but not the TASer.
No, I increased the cycles; eien86's movie (which skipped about 45% of WA's game engine frames) used 600000, and I increased them to 4000000, which is 6.667 times bigger... a very big increase. I had also tried 3000000 and it wasn't enough to get rid of all frame skips.
Oh, thank you for your clarification! I missed one zero in the cycles you provided in your initial PoC post. 4 million cycles is indeed higher than 600 thousand cycles eien86 used
TASing is like making a film: only the best takes are shown in the premier.
https://xkcd.com/3246/
I've been experimenting with [video] forcerate on Worms Armageddon with high refresh rates (using its DirectDraw 8-bit hardware renderer, for much better emulation speed).
At first, I was trying to make it work well only by increasing [cpu] cycles. This did not work very well; at 120 fps, there was always lag no matter how high I pushed the cycles. There were three main kinds of lag:
A lag spike during the fade-in at the beginning of a level, in which many game engine frames were skipped. Not only is this unaesthetic, but it breaks level TASes in which the player's worm's turn starts very early, because some of the needed input would've been on the skipped frames.
A game engine frame only got 1 emulator frame, making it impossible to release and press the same key that had been pressed on the previous game frame.
A game engine frame seemed to get 2 emulator frames, but the second one had the same timestamp as the first, and input was only polled on the first and ignored on the second.
A game engine frame would be dropped entirely.
In WA these can be patched over by pressing Escape to pause time, then pressing Escape again later, swallowing up the lag harmlessly — but this makes the TAS longer, especially for type #1. (The replay files saved by the emulated WA onto its .hdd image will still be just as optimal using this method.)
The test at 300 fps went better; lag types #2, #3, and #4 were eliminated entirely (presumably because 300 is a perfect multiple of the engine framerate of 50 fps), leaving only type #1, and only in some levels. But that was still annoying. Worse, though, there were some occasional double-buffering flicker glitches, and cycles had to be set so high that it made the loading screens be emulated very slowly (paradoxically – though in the movie itself the loading would be faster due to the increased cycles).
In both of these tests, increasing cycles didn't make the in-game emulation (i.e. the levels themselves) slower, seemingly due to Vsync letting the emulated CPU idle for most of the time.
But now I've found that DOSBox-X actually does not detect Vsync-waiting loops and give them an idleness bonus. The only reason this actually happens is [dosbox] iodelay having a value of about 1000 ns by default. Thus a Vsync-waiting loop will spend most of its time sleeping that 1000 ns every time it polls port 0x3DA.
I've found a fairly good solution to make high refresh rate work well: decreasing some of the I/O delays. It's not practical to decrease iodelay, because then emulation will be much slower as it will be spending less of its time sleeping during port 0x3DA polls. (The produced movie would be faster though.) But the 16-bit and 32-bit delays can be decreased way down harmlessly, making loading screens go by faster and getting rid of the double-buffering flicker artifacts.
(Oh, and [video] vesa set display vsync = 1 had no effect when I tried it.)
Here's what is now working quite well in my tests, with all types of lag and flicker eliminated. Showing just the relevant portions:
Edit: Lowering it to iodelay = 300 isn't too bad... I still get about 1/14 realtime speed that way, relative to getting about 1/11 realtime speed with iodelay = 1000.
I've also added a couple of other things to my .conf to try to further improve speed, though I'm not sure how much of an effect (if any) they have – I haven't tried isolating them yet, since each test with WA takes a lot of time:
[cpu]
interruptible rep string op = 0
[dos]
unmask timer on disk io = false
And hard drive data rate limit = 0 didn't need to be added, since it's already in BizHawk's machine preset.
But it seems impossible to make 300 fps perfect. Sometimes it really does render smooth 300 fps, but a lot of the time its frames are doubled, providing something effectively more like 150 fps. I tried setting [cpu] rdtsc rate, but it didn't help at all.
Also note that before I tried changing these iodelay settings, I found that just increasing "cycles" alone had severely diminishing returns on improving loading/booting times. The total time spent emulating a loading screen would keep increasing dramatically, only to provide small benefits in terms of reduction of total emulated-machine time taken by the loading screen. This didn't make sense to me, as I expected the total time spent emulating a loading screen should be fairly constant, and increasing "cycles" should just change how many emulator frames it should take. But now with the iodelays decreased way down, it is much closer to making sense in that way, and the total time spent emulating the loading screens is dramatically reduced.
It's also worth noting that I tried setting BizHawk's FPS numerator and denominator to zero to make them automatic, and it did not set them to be the same as the forcerate value; in that test the input FPS just came out being 60 fps. So it seems that both values must always be set explictly.
I'm pretty sure that BizHawk's Machine Presets would probably be much more realistic if they incorporated changes to the I/O delays. Though again, it's not practical to decrease the 8-bit one if Vsync loop idling efficiency is important.
It would be nice if DOSBox-X added an iodelay setting just for port 0x3DA.
It's not clear how DOSBox-X picks the range of cycles for max/auto, but it's certainly depends on your host CPU. DOSBox-X refuses to keep cycles around the limit value if your host CPU isn't "capable" of emulating it. This may result in a demanding game performing not good enough. In such situation, use fixed format.
Why does the guide include anything but "fixed" in its suggestions for what to use? Since "max" and "auto" are documented to depend on the host CPU, won't they result in movies that desync when played on a different machine? Has anyone tested to see if this is the case?
It's not clear how DOSBox-X picks the range of cycles for max/auto, but it's certainly depends on your host CPU. DOSBox-X refuses to keep cycles around the limit value if your host CPU isn't "capable" of emulating it. This may result in a demanding game performing not good enough. In such situation, use fixed format.
Why does the guide include anything but "fixed" in its suggestions for what to use? Since "max" and "auto" are documented to depend on the host CPU, won't they result in movies that desync when played on a different machine? Has anyone tested to see if this is the case?
I can't explain this phenomenon, but it doesn't desync on a different machine. I have verified several different games already. My only assumption is that the instant cycles value is waterboxed, like the rest of the core's state.
TASing is like making a film: only the best takes are shown in the premier.
https://xkcd.com/3246/
I can't explain this phenomenon, but it doesn't desync on a different machine. I have verified several different games already. My only assumption is that the instant cycles value is waterboxed, like the rest of the core's state.
But for that to work, it would have to record the instantaneous cycles values in the input roll. Have you looked at the resulting "Input Log.txt" files to see if this is the case?
If it's not there, where else could it be? Does it record the host's CPU speed somewhere in the movie settings and provide this data somehow to the DOSBox-X core so that it uses that number to calculate its instantaneous cycles values deterministically?
Or maybe "auto"/'"max" don't actually adapt to the host CPU at all, contrarily to how they're documented to work? Or do so in such a way that any extra host CPU speed beyond a certain maximum is just ignored?
BTW, I'm not sure I fully understand what "waterboxed" means. It's hard to find an actual definition of it.
Is there any way to use resolutions other than 640×480, 800×600, 1024×768, 1280×1024, and 1600×1200 in Windows 98 SE under DOSBox-X?
Like 1280×720, 1920×1080, or, dare I dream, maybe even 1366×768?
I tried adding this to my .conf:
[video]
vesa modelist width limit = 0
vesa modelist height limit = 0
allow high definition vesa modes = true
allow unusual vesa modes = true
and then installing SciTech Display Doctor... and it did not augment the list of usable modes in any way.
But 1280×720 is definitely in the DOSBox-X source code.
Edit: I tried editing HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\Display\0000\Modes and C:\WINDOWS\INF\dxs3.inf, and nothing changed. It looks like editing C:\WINDOWS\SYSTEM\S3.DRV may work, as it does have what appears to be a table of resolutions in binary... but it seems likely that just editing the resolutions themselves won't be enough (probably editing its equivalent of modelines will be necessary too).
I can't explain this phenomenon, but it doesn't desync on a different machine. I have verified several different games already. My only assumption is that the instant cycles value is waterboxed, like the rest of the core's state.
But for that to work, it would have to record the instantaneous cycles values in the input roll. Have you looked at the resulting "Input Log.txt" files to see if this is the case?
If it's not there, where else could it be? Does it record the host's CPU speed somewhere in the movie settings and provide this data somehow to the DOSBox-X core so that it uses that number to calculate its instantaneous cycles values deterministically?
Or maybe "auto"/'"max" don't actually adapt to the host CPU at all, contrarily to how they're documented to work? Or do so in such a way that any extra host CPU speed beyond a certain maximum is just ignored?
BTW, I'm not sure I fully understand what "waterboxed" means. It's hard to find an actual definition of it.
"Input Log.txt" stores just input. Here is the github issue where I provided its whereabouts, considering my poor C++ knowledge.
That's a part of the mystery because I didn't find any documentation on how "auto"/"max" work and none of DOSBox-X devs answered this question. Somewhere, when I was doing this whole investigation, I stepped upon a comment assuming "max/auto %d\% limit %d" picks the range of values by somehow determining how fast the host CPU is. I can say for sure that the "limit" in this declaration just the upper limit of the cycles it can't exceed.
Why "max"/"auto" performance stops growing after a certain point? I don't know. It's my assumption that the host CPU stops satisfying some internal calculation formulas within DOSBox-X, and the only option to circumvent it is to use "fixed".
"waterboxed" means "determinsticated, or kept under control so your TAS doesn't desync".
Deadcode wrote:
Is there any way to use resolutions other than 640×480, 800×600, 1024×768, 1280×1024, and 1600×1200 in Windows 98 SE under DOSBox-X?
Like 1280×720, 1920×1080, or, dare I dream, maybe even 1366×768?
The driver is the problem. Nobody was thinking about widescreen resolutions back then.
Try VBEMP driver. I left a link on it on the first page. It adds a variety of resolutions, but it messes the hardware up, resulting in a major performance penalty. Some games just crash when it's installed.
TASing is like making a film: only the best takes are shown in the premier.
https://xkcd.com/3246/
But now I've found that DOSBox-X actually does not detect Vsync-waiting loops and give them an idleness bonus. The only reason this actually happens is [dosbox] iodelay having a value of about 1000 ns by default. Thus a Vsync-waiting loop will spend most of its time sleeping that 1000 ns every time it polls port 0x3DA.
I've found a fairly good solution to make high refresh rate work well: decreasing some of the I/O delays. It's not practical to decrease iodelay, because then emulation will be much slower as it will be spending less of its time sleeping during port 0x3DA polls. (The produced movie would be faster though.) But the 16-bit and 32-bit delays can be decreased way down harmlessly, making loading screens go by faster and getting rid of the double-buffering flicker artifacts.
...
...
Also note that before I tried changing these iodelay settings, I found that just increasing "cycles" alone had severely diminishing returns on improving loading/booting times. The total time spent emulating a loading screen would keep increasing dramatically, only to provide small benefits in terms of reduction of total emulated-machine time taken by the loading screen.
...
I'm pretty sure that BizHawk's Machine Presets would probably be much more realistic if they incorporated changes to the I/O delays. Though again, it's not practical to decrease the 8-bit one if Vsync loop idling efficiency is important.
Thanks for this tip! I finally got loading screens down to a reasonable length in a 3D 2002 game I've been testing, though it only needs 60 or 70 FPS. Like you said, the I/O delay seemed way too slow whether I ran the game from the loaded disc or a Virtual CloneDrive 5.4.5 .iso from within Windows - still 14-second loads between small areas at 600,000 cycles.
Increasing to 2,000,000 cycles gave a minor improvement: 10.142 seconds.
600,000 with your above .conf values gave 8.356, with setting iodelay to 5 as well improving it by ~0.3 second.
Finally, 2,000,000 cycles with the adjusted .conf was down to 3.199 second, and 4,000,000 gave 2.157. Either of these will be acceptable and close to what RTA experiences on modern computers. This is important because a timesaver involves loading an earlier-created quicksave to return to the origin point and save a few seconds, which would be useless if the loading screen itself took 10+ seconds.
Also, Dimon12321, I keep forgetting to post here and say thanks for helping everyone with all your OP guide and replies in the thread! My game would still be crashing on S3 Trio 64 or freezing up at 200,000 cycles if not for you.
Some recently accepted runs confirm that the following methods you suggested are fair game:
Can't think of any others at the moment. If the eventual judge of Soccer Manager doesn't have an issue with modifying win.ini, I'll look forward to doing that in my 9x runs as well.
Here is the github issue where I provided its whereabouts, considering my poor C++ knowledge.
That's a part of the mystery because I didn't find any documentation on how "auto"/"max" work and none of DOSBox-X devs answered this question.
Well, now that I can see from that issue's discussion thread that cycles max/auto has at least been properly waterboxed, I've given it a try. With WA at least, it didn't work at all for reducing host CPU usage in-game. Whereas "cycles = fixed 8000000" with "iodelay=1000" results in about 1/10 realtime speed in-game, "cycles = max limit 8000000" with "iodelay=25" results in about 1/45 realtime speed in-game, which is pretty much the same as I remember getting with "cycles = fixed 8000000" and "iodelay=25".
And this is the kind of result I'd expect. Auto cycles is tantamount to idle detection, and DOSBox-X already has "dos idle api". What is even the point of using auto/max limit cycles if you can just used fixed cycles with "dos idle api" detecting idle time properly? And on the other hand, how could auto/max possibly work in situations where "dos idle api" doesn't work?
Dimon12321 wrote:
Try VBEMP driver. I left a link on it on the first page. It adds a variety of resolutions, but it messes the hardware up, resulting in a major performance penalty. Some games just crash when it's installed.
Well that's not exactly a shining endorsement, so it doesn't make me too excited to try it. I'm more optimistic about hex-editing S3.DRV.
CoolKirby wrote:
Thanks for this tip! I finally got loading screens down to a reasonable length in a 3D 2002 game I've been testing, though it only needs 60 or 70 FPS. Like you said, the I/O delay seemed way too slow
Awesome, I'm glad this helped!
It could of course be even better if we could reduce "iodelay" without an emulation performance penalty, and to that end here's the DOSBox-X issue where I've requested that feature.
CoolKirby wrote:
Some recently accepted runs confirm that the following methods you suggested are fair game:
Oh wow. If I once knew you could start Windows programs from DOS like that, I'd long forgotten. I guess I should use that for my WA TAS, but it'll make me a bit sad, as I enjoyed TASing modifying the WA shortcut to add the "/nointro" command-line parameter and then launching that modified shortcut. I'd decided to intentionally not put that into the installation movie.
Edit: I tried it, and I get
Cannot load a device file that is specified in SYSTEM.INI.
The performance of Windows should not be affected without this file.
C:\WINDOWS\SYSTEM\VMM32\IOS.VXD
Press a key to continue
And then if I press a key, emulation proceeds at about 0.07 fps, and in 24 frames, I still haven't seen any change (it's still in text mode with that message visible).
What is even the point of using auto/max limit cycles if you can just used fixed cycles with "dos idle api" detecting idle time properly? And on the other hand, how could auto/max possibly work in situations where "dos idle api" doesn't work?
To make some games work stable. With all other configs being equal, some game just crash at some point if fixed cycles are used, but they don't do so with max/auto cycles. I'm not a retro hardware expert, but the internet says it has something to do with CPU and SoundBlaster interaction. Fixed cycles do something wrong with hardware sound handling, while software processing stays fine.
TASing is like making a film: only the best takes are shown in the premier.
https://xkcd.com/3246/
And the level select you posted has all the 2D graphics that are missing (titles, face textures, etc.):
