Unlike the other areas, this one was a lot of fun to make, with few surprises or bugs. I was very satisfied that all my decisions (e.g., exhausting the ammo of several weapons to enable this version's jump glitch) were spot on to later achieve each of the skips used by Molotok. I was also able to exploit police/swat pushing during chases, and was always able to get a fast get-away car after each mission. In a nutshell, even though larger, this movie was a breeze to work on.
Comparison Movie
Here's a comparison video between this run and the current "all missions" RTA WR by Molotok.
The amazing GTA speedrunning community for their continuous support and encouragement. In particular Tarakan3000, Molotok, Tezur0, WordOfWind, hipp0cat, and Stowka
Dimon12321 for his research on DOSBox configurations (also MUGG) and help with sync
Highly entertaining once again. I enjoyed a lot of the smaller strategies, like using a Molly to push an NPC towards you or the Tanks-A-Lot Vehicle Mines strat.
It's so weird to see those kinds of lag hiccups in a recorded TAS. Do they show up as lag frames in the emulator? Could you avoid them with a different system config?
Either way, once again very good work. Yes vote.
Thanks scrimpeh for following these series, happy to hear you had fun watching them.
The lag freezes are unfortunately coming from the emulator. Maybe some I/O or memory buffering that doesn't happen fast enough. Also it's important to notice I reduced the emulated machine RAM size to a minimum to reduce state size in my host machine. Maybe that creates triggers some re-loading from disk, as it loads new sections. Who knows.
The lag freezes are unfortunately coming from the emulator. Maybe some I/O or memory buffering that doesn't happen fast enough. Also it's important to notice I reduced the emulated machine RAM size to a minimum to reduce state size in my host machine. Maybe that creates triggers some re-loading from disk, as it loads new sections. Who knows.
I looked at this weirdness a while back. Savestate size doesn't relate to how much RAM you set in the config. Besides input rolls, a savestate consists mostly of waterbox's diff between point A and point B in time. When there is not enough RAM available, Windows has to access the HDD to swap a piece of RAM content with a similar piece of content from the .swp file to refresh it. The HDD content is also waterboxed, so its diff is also included into a savestate. Despite DOSBox-X providing hacks to read/write to HDD much faster than it would be in a real life, it still may cause lag freezes because of swapping.
The solution is to set more RAM. The unused RAM chunks are not included into a savestate, yet it prevents swapping and, hence, lag freezes. The only downside is, the unused RAM will occupy your host RAM while DOSBox-X is running, but I don't think it will cause RAM scarcity. Like, close one tab in your browser and the problem is solved. I think memsize=96 is enough for Windows 98 + GTA2.
If RAM efficiency is a problem, I think it makes sense to implement the functionality in BizHawk to save the content of an .hdd to a new .hdd of a different size, which should offer a wider choice, not just 512MB or 2GB. Look at how much free space there still is on your HDD with Windows 98 and a game! It can be freed up and less host RAM will be occupied. It will not affect the speed of storing a new savestate, but here's the idea.
TASing is like making a film: only the best takes are shown in the premier.
https://xkcd.com/3246/
So these would be possible to merge to one another now?
Basically not. Each of these movies start from bootup -- it's practically impossible to stitch their inputs together without an immediate (CPU timing-induced) desync upon starting the second episode
