Posts for Deadcode

1 2
Posted: 7/4/2026 7:51 PM
(Edited: 7/5/2026 12:32 AM)
Deadcode
He/Him
Experienced Forum User, Published Author, Player (6)
Joined: 7/27/2016
Posts: 32
Dimon12321 wrote:
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).
Posted: 7/3/2026 12:08 AM
(Edited: 7/3/2026 12:54 AM)
Post subject: Widescreen resolutions like 1280×720 – possible?
Deadcode
He/Him
Experienced Forum User, Published Author, Player (6)
Joined: 7/27/2016
Posts: 32
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).
Posted: 7/2/2026 6:51 PM
(Edited: 7/2/2026 7:00 PM)
Deadcode
He/Him
Experienced Forum User, Published Author, Player (6)
Joined: 7/27/2016
Posts: 32
Dimon12321 wrote:
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.
Posted: 7/2/2026 6:11 PM
Deadcode
He/Him
Experienced Forum User, Published Author, Player (6)
Joined: 7/27/2016
Posts: 32
Dimon12321 wrote:
2) Cycles mode Suggested values:
  1. cycles=max 100% limit 450000
  2. cycles=auto 100000 limit 450000
  3. fixed 450000
Dimon12321 wrote:
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?
Posted: 7/2/2026 8:33 AM
(Edited: 7/5/2026 12:36 AM)
Post subject: Custom video refresh rates
Deadcode
He/Him
Experienced Forum User, Published Author, Player (6)
Joined: 7/27/2016
Posts: 32
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:
  1. 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.
  2. 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.
  3. 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.
  4. 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: 
[cpu]
core = dynamic_x86

[video]
machine = svga_s3vision968
forcerate = 300

[dosbox]
iodelay      = 1000
iodelay16    = 5
iodelay32    = 5
irq delay ns = 5
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.
Posted: 6/12/2026 7:28 AM
(Edited: 6/12/2026 7:36 AM)
Deadcode
He/Him
Experienced Forum User, Published Author, Player (6)
Joined: 7/27/2016
Posts: 32
Dimon12321 wrote:
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.
Posted: 6/12/2026 3:45 AM
(Edited: 6/12/2026 3:47 AM)
Deadcode
He/Him
Experienced Forum User, Published Author, Player (6)
Joined: 7/27/2016
Posts: 32
Dimon12321 wrote:
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.
Posted: 6/3/2026 4:22 PM
(Edited: 6/3/2026 4:44 PM)
Deadcode
He/Him
Experienced Forum User, Published Author, Player (6)
Joined: 7/27/2016
Posts: 32
eien86 wrote:
- If you need to use memory search to look to find anchoring points for LUA, you must set the DOSBox system memory to 16Mb or less, otherwise the search feature is disabled
Not sure if you're replying specifically to my filed issue... You seem to be implying that there's already built-in memory searching in BizHawk Lua, but I couldn't find anything in Bizhawk/LuaFunctions. To what search are you referring? The BizHawk UI? It would take longer to go through the search UI every time a new WA level is started, than just using my current Lua script, which takes about 9 seconds and works with 48 MB of RAM.
Posted: 6/3/2026 3:11 PM
(Edited: 6/3/2026 4:14 PM)
Deadcode
He/Him
Experienced Forum User, Published Author, Player (6)
Joined: 7/27/2016
Posts: 32
h3oCharles wrote:
Can the region be set to United Kingdom in the installation movie for different soundbanks? The English soundbank is much more recognisable to outsiders
Yes, since I expect to be soon using a Lua script to import replays rather than doing it manually, that should be easily sorted. I also want to run GfxUpdate.exe so that WA 3.8.1 looks the way it is supposed to, and supports switching to the alternative (protan colour-blindness) team colour set. Would it be controversial if I used that alternative colour set in my movie? I think it's much more aesthetic, as it not only makes green/yellow and blue/purple more distinct, but makes the colours more saturated. Also I am disappointed that the Windows 98 SE installation movie did not disable the animation options, e.g. "Animate windows when minimizing and maximizing" and "Fade or slide menus into view". These have no effect on the current movie in its submitted form, but they do slow down testing of certain things during the production of the movie. Would including a third installation movie be the best solution for this? Then the .hdd from running eien86's installation movie could still be reused. For people setting all of this up for the first time, they'd have 3 stages of installation movies:
  1. Windows 98 SE (r3gamerz's movie, as included in the Bizhawk/DOSBox guide)
  2. WA (eien86's movie)
  3. WA GfxUpdate.exe and possiblly some settings
Posted: 6/3/2026 12:27 AM
(Edited: 6/3/2026 6:11 PM)
Deadcode
He/Him
Experienced Forum User, Published Author, Player (6)
Joined: 7/27/2016
Posts: 32
ikuyo wrote:
I think we could discuss a delay and coauthorship deal if Deadcode and eien are willing to work together to improve the run, and I think that would be the best possible outcome.
A delay would be nice, yes please. eien86 has already said he's moved on and is not interested in doing anymore WA TASing, so unless something changes, it'll just be me working on the run – which is structured around doing the TASing in the TA build first, and then dubbing the replays into BizHawk. (So far the dubbing has been manual, but my plan is to write a Lua script to do it.) Some replays work as-is (so far #2), some achieve the same time with some adjustments and are essentially the same (so far #1, #3), and due to certain inputs impossible natively, some need to be redone in a way that's a bit slower (so far #4, #5). In the case of #4, I re-ran the Uzi aiming sequence brute-forcer used to previously optimize #4 for round time (and it's continuing to find improvements, by 0.26 seconds so far; using that will require the replay-to-BizHawk dubbing to be redone). The exact uzi aim has a randomness manipulation effect, because it affects the order in which the crates detonate, and also makes holes that flamelets move into (affecting how many flamelets they spawn and the number of RNG calls they make). eien86 will of course be credited, for:
  1. The idea of doing a BizHawk run, and the installation movie
  2. Missions #6 and #18: Saving round time by having the first CPU turn fire a Bazooka instead of Shotgun. (Even though eien86 wasn't the first to do this in a Mission #6 TAS – Wyvern was. But back then, we weren't optimizing for round time.)
  3. Mission #17: Demonstrating that my mine jump technique could be used to plop both enemy worms instead of just the General, which results in shorter round time. In my previous techniques I'd already done this, but didn't know it was possible with this particular (fastest) mine jump. (Funnily enough, the subpixel positioning for this is much easier than it is for killing just the General, so surely this is just the first form of the jump that he got to work.)
  4. Mission #21: Using a 2 (instead of 3) second grenade on the second turn, and having the player's worm come to a stop sooner after being hit by that grenade.
All of the above techniques have already been improved upon, but the first execution of them was his. Edit: Previously spoke of most of those being micro-techniques, and hadn't yet included them in the WKB Method credits. That is now fixed, and upon further thought, I don't think it makes sense to call some micro-techniques and others not, because there's a whole spectrum.
h3oCharles wrote:
Where's the line drawn for crediting someone? If someone found a route/solution, but didn't do a single input to the TAS file, do they still get credit? Does each person credited need to make a TASVideos account to get credited?
Also, was it improper that eien86's submission credited only eien86? Because if it's proper procedure to credit the previous TASers from which methods in the new TAS are derived, shouldn't it have also credited me and Wyvern? And perhaps Mablak too, because Mission #27 is a direct copy of his RTA that beat the previous TAS record. In the case of my BizHawk TAS, it will also credit Syc for a TAS technique in Mission #1 (not used in eien86's run). And credit the RTAers whose methods the TASes are also based on. That will be a long list: Lex, BarmaN, c0o1, Run, M3ntal, Mablak, zippeurfou, Bloopy, and Sprek.
Posted: 6/1/2026 9:45 PM
(Edited: 6/1/2026 10:21 PM)
Deadcode
He/Him
Experienced Forum User, Published Author, Player (6)
Joined: 7/27/2016
Posts: 32
Dimon12321 wrote:
If it helps, in DOS -> Settings... you can adjust "Frame Numenator" to "Frame Denominator" ratio (Num divided by Denom) to equal 50, to have a 50-fps BizHawk movie.
Better to use >=100 fps, so that it's possible to e.g. press Space on two adjacent frames to shoot rope and immediately detach it. Better yet to use 120 fps, so that recorded A/V can be decimated to 60 fps for YouTube, and also because at 50 fps, WA 3.8+'s tweening will get stuck at a particular phase, which might not be zero – e.g. it could get stuck at showing the state 0.01 seconds after every frame. (At 100 fps it'd be alternating between two constant phases, neither of which is likely to be zero.) With 60 or 120 fps, the phase will constantly move, guaranteeing it doesn't get stuck. Link to video This now goes up to Mission #5... using the same technique as the leading TA build replay! It's a little slower, but it still works, and is much faster than the next-slower technique. The WA v3.6.28.0+ feature of holding Shift to move the mouse at 4x speed came in handy for placing that Girder quickly, sacrificing only 3 frames in a row of no Bungee input. BizHawk movie XML settings file (same as before) DOSBox configuration file (same as before) Uses the same .hdd generated by eien86's WA installation movie. The resulting replay files
Posted: 5/29/2026 9:16 PM
(Edited: 5/30/2026 4:03 AM)
Deadcode
He/Him
Experienced Forum User, Published Author, Player (6)
Joined: 7/27/2016
Posts: 32
h3oCharles wrote:
In Operation Market Garden there is an RTA strategy that is frame perfect because of holding down key sets before the turn starts. Is that strategy faster than the current TAS?
That mission #2 RTA strategy is for Silver, not Gold. It only works when the Cluster Bomb crate appears on the leftmost flower on turn 4 (CPU turn 2). Mablak's video does not show enough of the map for that crate to be seen, but you can hear the crate-pop sound effect at 2:53. When done as prescribed by the video, the round time is 1:25.84. With the final grenade shot optimized, it's 1:22.12. It can be turned into a TAS Gold strategy by manipulating RNG, and by streamlining some things, but I still only managed to get it down to 1:20.74. In comparison the current TA record by Lex is 1:17.16, unbeaten since 2007. Edit: Managed to get it down to 1:00.42; now posted. Thanks for coming up with the RTA strategy, Mablak, and for the idea of making a TAS based on it, Charles.
h3oCharles wrote:
I mentioned mission #25, being Mars Star - there's one replay that Deadcode made that is very ridiculous, I wonder if it's replicable in emulation. Lots of precise and well-timed girders are involved here.
I strongly suspect that it's possible, but I'd like to save it as a surprise until a "cycles=4000000" (or similar) run reaches that point (as opposed to copying a premade team into the emulator to jump straight to mission #25).
andypanther wrote:
You have to consider that ILs with the TA tool and a fullgame run with Bizhawk are not comparable. Doing it all in one playthrough is a completely different challenge.
It's not all that different. The initial logic random seed is constant for all missions except for Mission #3 "All Quiet in the Library". So as long as the DOSBox "cycles" setting is sufficient for avoiding frame skips, the missions' input sequences (other than mission #3) are independent of each other. They need to be retimed to make the 50fps input fit into a 60fps BizHawk movie, but in theory a Lua script could be written to automatically dub a replay file into such a BizHawk movie (especially if the replay files are exported from a previous BizHawk run, meaning they're guaranteed to have only inputs that are possible).
Posted: 5/28/2026 7:10 AM
(Edited: 5/28/2026 8:18 AM)
Post subject: Proof-of-concept: BizHawk can match the TA build replay times
Deadcode
He/Him
Experienced Forum User, Published Author, Player (6)
Joined: 7/27/2016
Posts: 32
eien86's movie used "cycles=fixed 600000", and had a huge proportion of lagged/skipped frames – I measured that only about 56% of the game logic frames were rendered (and polled for changed input). With "cycles=fixed 4000000", there's virtually no frame lags or skips, and the TA build replays can in many cases be replicated exactly. In this proof of concept, all of Basic Training and Mission #1 match the TA build round times (with one training stage actually being improved upon when I was forced to depart from the exact TA build replay input sequence). It took 5 hours to make this. (I don't think DOSBox's cycle count setting is a realistic representation of computer speed. It strikes me as being similar to BogoMIPS.) Link to video BizHawk movie XML settings file DOSBox configuration file Uses the same .hdd generated by eien86's WA installation movie. The resulting replay files In Mission #1, the TA build replay suddenly places a girder on the very first frame after a rope attach. To do this with native input in the BizHawk run, I selected the girder ahead of time and moved it into place while the worm was in the Rope Roll state, and then clicked to do a "buffered" placing of it before the rope attached. Then pressed Enter to actually place it, on the first frame after the rope attached, replicating the timing of the TA build replay. I accidentally generated a bunch of Pause and S key pressings in this run, due to assuming that conflicting bindings weren't possible. The Pause presses caused some screenshots to be saved, adding a little lag to the run; so, it could perhaps be even a bit faster than it is in this demonstration. The S key presses also had to be kept in the run (I tried removing them, but even that eventually caused a desync). I've fixed my bindings, but will be posting this run as is. Before trying the increased cycle count, I tried enabling "Timer Workaround" in Advanced Options; it did not help. I also tried the DirectDraw 8-bit hardware renderer, which should in theory be faster, but it caused glitches in BizHawk/DOSBox-X and didn't give a dramatic speed-up, so I stuck with the default DirectDraw 32-bit renderer.
Posted: 5/22/2026 3:41 PM
(Edited: 5/22/2026 4:12 PM)
Post subject: TA build replay protection/flagging
Deadcode
He/Him
Experienced Forum User, Published Author, Player (6)
Joined: 7/27/2016
Posts: 32
ikuyo wrote:
Deadcode wrote:
The fact that WA TASing can now be done with BizHawk will likely result in me releasing the WA TA build publicly very soon. What stopped me from doing this for so many years (which I have regretted enormously) was that I was afraid the tool would be used to fraudulently pass off TAS replays as being RTA.
Have you looked into the ways that other similar tools have attempted to handle this issue? Both Celeste and UFO 50 have mods that function as TAS tools that have implemented their own safeguards. Any modded Celeste run includes an impossible to remove image in the Chapter complete screen to flag the run as done in a modded build. CoffeeTools forces an input viewer on running any UFO 50 game to signal the runqwas done with the tool on.
The problem is, I feel that adding such safeguards is just an invitation for someone to crack the protection, and from there it'd become and arms race. Reverse-engineering is easier these days than ever before. Furthermore, such protection won't mean much unless the replay files are encrypted. And if they're encrypted, there needs to be a layer of compression beneath the encryption, otherwise the files will waste more space than they need to, with no possibility of ever being compressed as much as they should be able to. Such implementations need extensive debugging to make sure they don't break things. And I also feel that there's a conflict of goals with such implementations; if I do it in a clean way that can be easily maintained (which it is my strong inclination to do), it'll be easier to reverse-engineer and crack. That pretty much explains right there why I've delayed releasing the TA build for so long – now 22 years. The impediments to giving it proper protection are too daunting. That is already too long. I would like to release it as soon as possible, to encourage the TAS community to TAS WA in a way that's competitive with previous work. Clearly my previous model of giving a TA build to people who ask (and seem trustworthy, and intend to use it to make TASes for public sharing) has not worked, because for the past several years I've been the only one TASing WA (and even before that, there was virtually no serious competition). It seems pretty clear that the TAS community insists that the tool be public if serious competitive TASing is to occur. It's a Catch 22. I've been feeling very demotivated for the past several years, from many factors. It would help greatly toward motivating me to work on future releases of WA, if it had a competitive TASing scene. But if before even releasing a TA build, I need to implement layers of protection on the replay format strong enough that they won't be easily crackable, and debug that extensively to show it to be sufficiently reliable, then that's work that'd have to be done in a demotivated state. And that's on top of all the other non-TAS-related things I've already determined are necessary to implement before releasing the next normal WA build. In the meantime while working on all that, interest in TASing WA continue to wane, and/or there will be more emulator-TASing of WA (which isn't competitive with TA build TASing), and/or someone else will reverse-engineer WA sufficiently to make a TA module for it. And if TASing can be done with BizHawk anyway, which results in replay files cannot flag that they were TASed, what point is there in even putting all the effort into implementing reliable strong protection, when that time could be more productively spent on other things?
Posted: 5/21/2026 1:02 AM
(Edited: 5/21/2026 2:34 AM)
Deadcode
He/Him
Experienced Forum User, Published Author, Player (6)
Joined: 7/27/2016
Posts: 32
Here is an up-to-date video compilation of mission replays made with the TA build: Link to video And Basic Training: Link to video
Posted: 5/20/2026 1:21 PM
(Edited: 5/20/2026 1:41 PM)
Deadcode
He/Him
Experienced Forum User, Published Author, Player (6)
Joined: 7/27/2016
Posts: 32
Dimon12321 wrote:
In Doom speedrunning community, the mainstream source port (DSDA-Doom) which provides TAS tools, provides header markers to replay files, indicating that TAS tools were used. You can apply something like that to your build, maybe by introducing exclusive compatibility for a clear distinction.
The TA build already does something like that (though the earliest versions didn't). But it would probably not be too hard to forge, especially with the power of today's reverse-engineering tools and AI. But I'm not going to let that fear and caution block a TA build release anymore... I feel it's mostly moot anyway now, with there being ways of TASing WA that do not require a special build and thus cannot put any special markers in the header.
Dimon12321 wrote:
On the other hand, Doom is a much more complex game than WA. The superior results are deeply examined by other people, so the act of cheating is disclosed one way or the other.
What relevance does how complex the game is even have to this? But if you are going to compare their complexity (for whatever reason), isn't WA a hugely more complex game than Doom? I would think it has far more weapons and game mechanics, and schemes result in huge possibilities for playing so many very different types of games. And new glitches, as well as qualitatively new game scenarios, are still being found 25+ years later.
Posted: 5/20/2026 4:42 AM
(Edited: 6/1/2026 10:26 PM)
Deadcode
He/Him
Experienced Forum User, Published Author, Player (6)
Joined: 7/27/2016
Posts: 32
What input is possible
eien86 wrote:
including repeated actions that can't be replicated natively
I'd like to clarify this. The TA build allows the following things that can't yet be replicated natively:
  • Selecting any weapon (including those that would require multiple presses of a function key) and using it in the same frame
    • Note that with native input, you can't select a weapon and use it in the same frame if there is currently no weapon selected (which can only happen if the team's inventory has no default-selected weapons). This happens for example in Mission #4 "Cool as Ice", where with native input, selecting and using the Jet Pack takes two frames, and selecting and using the Uzi also takes two frames.
  • Pressing Tab multiple times in the same frame, followed by any other action (including those in this list) also in the same frame
  • Pressing and releasing Space to detach Ninja Rope and then immediately pressing it again on the next frame to shoot the next rope. I'm pretty sure this is possible in native keyboard input, but BizHawk does not allow it (it requires a key to be released for one full frame before being pressed again) unless the framerate is set to >=100 fps.
  • Pressing Backspace twice in one frame to do a backflip (e.g. with only 1 frame of retreat remaining)
    • Note that this is already possible natively in the current alpha, via adding the backslash key as a second Backspace-equivalent binding
  • Firing a powered-up weapon with zero power, whereas with keyboard input the minimum is currently 1 out of 75 (and the maximum is "76" out of 75).
It was partially Lex's encouragement that resulted in the above features. I plan making all of those things possible natively by making the input handling that's done between frames more flexible. Also in the TA build, the mouse cursor can be moved anywhere instantly. It seems to me that this is a gray area in terms of how possible it is "natively". I doubt use of the above features has much impact on the total time of the tool-assisted Mission replays. I'd estimate that it saved a few seconds at most. For completeness, I should note that there are additionally some things that the TA build allows in "unrestricted control" mode that are not used in any posted tool-assisted replays – unless specifically noted, but I think I've only shared examples of that privately – and in particular, they're not used in any of the posted Mission replays:
  • Moving the worm and moving the cursor for a mouse-aimed weapon simultaneously
  • Moving the cursor for a mouse-aimed weapon outside the normal range. If a girder or teleport is attempted it will fail, but strikes and homing weapons will succeed
Logic version The current set of tool-assisted Mission record replays cannot represent a contiguous run because they aren't all done in the same game logic version. In this regard, eien86's TAS clearly wins, for now. I plan on redoing them all in the same logic version, but not yet... because some past game logic changes significantly altered the behavior of certain missions from how they were in WA v1.0-3.0:
  • The crate drop algorithm was changed, altering the position of the crate drop and wind direction/strength on the first of Missions #18 "Rescue Agent Dennis" and #27 "Bazooka on the Rocks".
  • It used to be possible to press Space to cut the parachute of any crate drop. This would have been an extra avenue of randomness manipulation, which in the above two missions would even allow manipulating the first turn wind.
  • Originally, Double Damage did not increase the explosion crater size of a 100-damage weapon such as Holy Hand Grenade. This significantly alters Mission #15 "Hot Stuff".
  • The number of frames that pass at the start of Sudden Death changed, altering the wind direction/strength on the first turn of Missions #4 "Cool as Ice" and #20 "Rumble in the Farmyard".
  • A bug in the way CPU worms plan their walking/jumping movement was "fixed", but the fix introduced a worse bug, which heavily biases CPU worms to only walk in one direction.
  • The amount of time that passes after the last active object stops moving changed in v3.6.31.1, altering the resulting round time in most missions.
I plan on rectifying this by reverting to the original behavior in Missions. (In the case of the CPU movement bias, that will just be reverted altogether.) To redo all of the runs before then just wouldn't make sense.
eien86's TAS My perspective that while eien86's TAS represents a impressive effort, the emulator used imposes arbitrary restrictions, some of them quite unrealistic. In particular, any modern PC (even systems 20+ years old) should be able to handle input processing at the full 50 fps. The fact that the TAS had to fight against that unrealistic limitation, and that going back to edit an earlier mission would require redoing every subsequent one, and that it couldn't take advantage of TA build features and be truly competitive against previous WA TASing, makes me feel wistful about this TAS. But I like that it brings attention to WA TASing – which I hope will lead to TASing being done with the WA TA build rather than an emulator. With realistic "natively possible input" limitations, and the power of the TA build (trajectory lookahead, info display, etc.), I think a full "native possible" TAS run should come much closer to the TA build total, not falling 4.6+ minutes short of it like this one does. So, I have mixed feelings and biases, and I'll abstain from voting.
eien86 wrote:
and even got three new TAS WR that improved even the TASes produced with Deadcode's tool!
It's nice to have some competition, even if for now it is fleeting. I've beaten all three of those records now (Missions 06, 18, and 21 – see round time records). This brings the total down to 2408.94 seconds (measured as >=v3.6.31.1 equivalent), which is 34.78 seconds less than it was before eien86's TAS. The fact that WA TASing can now be done with BizHawk will likely result in me releasing the WA TA build publicly very soon. What stopped me from doing this for so many years (which I have regretted enormously) was that I was afraid the tool would be used to fraudulently pass off TAS replays as being RTA.
Posted: 4/13/2024 4:36 PM
Post subject: Level 3-9
Deadcode
He/Him
Experienced Forum User, Published Author, Player (6)
Joined: 7/27/2016
Posts: 32
I ran DDD on level 3-9 for a while, this being the only remaining one out of the five even close to being solvable with DDD (at least in its current design). Projecting forward from this, I estimate it would take 2-3 petabytes and 10-20 years to complete. I was hoping it'd surprise me and slow down its growth, but alas, it's shown no sign of doing that. With this estimate done, I'll finally now be using my new disk space for its primary intended purpose instead of DDD. 
Kwirk Level 28 (3-9), Bird's-eye View: 18x16, 1 players
Optimized version
Using 17 WinAPI threads (with 1024 node chunks) with WinAPI sync and compiler TLS
Compressed state is 173 bits (22 bytes data, 23 bytes per closed node, 24 bytes per open node)
Using 34359738368 bytes of RAM for 1431655765 buffer nodes
Using Windows API files with unbuffered disk I/O
Frame-group   0x/390x:            1 nodes,             1 total; Expanding...    2.806 s; Merging...    0.014 s,            2 nodes; Combining...     0.310 s (     3.130 s)
Frame-group   1x/390x:            2 nodes,             3 total; Expanding...    0.015 s; Merging...    0.014 s,            3 nodes; Combining...     0.123 s (     0.152 s)
Frame-group   2x/390x:            3 nodes,             6 total; Expanding...    0.015 s; Merging...    0.013 s,            4 nodes; Combining...     0.129 s (     0.157 s)
Frame-group   3x/390x:            3 nodes,            10 total; Expanding...    0.014 s; Merging...    0.014 s,            7 nodes; Combining...     0.124 s (     0.152 s)
Frame-group   4x/390x:            5 nodes,            17 total; Expanding...    0.015 s; Merging...    0.013 s,           11 nodes; Combining...     0.123 s (     0.151 s)
Frame-group   5x/390x:            2 nodes,            26 total; Expanding...    0.029 s; Merging...    0.013 s,            4 nodes; Combining...     0.126 s (     0.168 s)
Frame-group   6x/390x:            5 nodes,            27 total; Expanding...    0.015 s; Merging...    0.013 s,           16 nodes; Combining...     0.145 s (     0.173 s)
Frame-group   7x/390x:            1 nodes,            39 total; Expanding...    0.015 s; Merging...    0.013 s,            1 nodes; Combining...     0.130 s (     0.158 s)
Frame-group   8x/390x:            4 nodes,            39 total; Expanding...    0.014 s; Merging...    0.013 s,            9 nodes; Combining...     0.131 s (     0.158 s)
Frame-group   9x/390x:            0 nodes,            46 total; Expanding...    0.010 s; Merging...    0.009 s,            0 nodes; Combining...     0.128 s (     0.147 s)
Frame-group  10x/390x:            7 nodes,            46 total; Expanding...    0.015 s; Merging...    0.013 s,           31 nodes; Combining...     0.126 s (     0.154 s)
Frame-group  11x/390x:            4 nodes,            73 total; Expanding...    0.014 s; Merging...    0.014 s,           25 nodes; Combining...     0.126 s (     0.154 s)
Frame-group  12x/390x:           13 nodes,            94 total; Expanding...    0.015 s; Merging...    0.013 s,           41 nodes; Combining...     0.124 s (     0.152 s)
Frame-group  13x/390x:           10 nodes,           126 total; Expanding...    0.015 s; Merging...    0.014 s,           67 nodes; Combining...     0.123 s (     0.152 s)
Frame-group  14x/390x:           20 nodes,           190 total; Expanding...    0.015 s; Merging...    0.013 s,           76 nodes; Combining...     0.123 s (     0.151 s)
Frame-group  15x/390x:           19 nodes,           248 total; Expanding...    0.015 s; Merging...    0.017 s,          141 nodes; Combining...     0.124 s (     0.156 s)
Frame-group  16x/390x:           29 nodes,           362 total; Expanding...    0.015 s; Merging...    0.013 s,          164 nodes; Combining...     0.123 s (     0.151 s)
Frame-group  17x/390x:           43 nodes,           495 total; Expanding...    0.015 s; Merging...    0.013 s,          295 nodes; Combining...     0.130 s (     0.158 s)
Frame-group  18x/390x:           47 nodes,           738 total; Expanding...    0.015 s; Merging...    0.013 s,          390 nodes; Combining...     0.127 s (     0.155 s)
Frame-group  19x/390x:          104 nodes,          1007 total; Expanding...    0.015 s; Merging...    0.013 s,          796 nodes; Combining...     0.124 s (     0.152 s)
Frame-group  20x/390x:          104 nodes,          1601 total; Expanding...    0.015 s; Merging...    0.013 s,          850 nodes; Combining...     0.125 s (     0.153 s)
Frame-group  21x/390x:          179 nodes,          2173 total; Expanding...    0.015 s; Merging...    0.013 s,         1443 nodes; Combining...     0.139 s (     0.167 s)
Frame-group  22x/390x:          273 nodes,          3121 total; Expanding...    0.025 s; Merging...    0.013 s,         2149 nodes; Combining...     0.142 s (     0.180 s)
Frame-group  23x/390x:          365 nodes,          4636 total; Expanding...    0.016 s; Merging...    0.013 s,         3117 nodes; Combining...     0.129 s (     0.158 s)
Frame-group  24x/390x:          589 nodes,          6735 total; Expanding...    0.016 s; Merging...    0.013 s,         4774 nodes; Combining...     0.125 s (     0.154 s)
Frame-group  25x/390x:          786 nodes,          9803 total; Expanding...    0.017 s; Merging...    0.014 s,         6322 nodes; Combining...     0.126 s (     0.157 s)
Frame-group  26x/390x:         1254 nodes,         13789 total; Expanding...    0.017 s; Merging...    0.013 s,         9946 nodes; Combining...     0.125 s (     0.155 s)
Frame-group  27x/390x:         1435 nodes,         19630 total; Expanding...    0.018 s; Merging...    0.013 s,        11370 nodes; Combining...     0.141 s (     0.172 s)
Frame-group  28x/390x:         2474 nodes,         26211 total; Expanding...    0.019 s; Merging...    0.013 s,        19349 nodes; Combining...     0.125 s (     0.157 s)
Frame-group  29x/390x:         2511 nodes,         36423 total; Expanding...    0.018 s; Merging...    0.013 s,        19987 nodes; Combining...     0.127 s (     0.158 s)
Frame-group  30x/390x:         4434 nodes,         47466 total; Expanding...    0.024 s; Merging...    0.013 s,        34042 nodes; Combining...     0.129 s (     0.166 s)
Frame-group  31x/390x:         4147 nodes,         63434 total; Expanding...    0.019 s; Merging...    0.032 s,        33213 nodes; Combining...     0.159 s (     0.210 s)
Frame-group  32x/390x:         7440 nodes,         80403 total; Expanding...    0.030 s; Merging...    0.013 s,        56269 nodes; Combining...     0.130 s (     0.173 s)
Frame-group  33x/390x:         6979 nodes,        105338 total; Expanding...    0.023 s; Merging...    0.014 s,        55825 nodes; Combining...     0.131 s (     0.168 s)
Frame-group  34x/390x:        11549 nodes,        132749 total; Expanding...    0.027 s; Merging...    0.014 s,        87708 nodes; Combining...     0.130 s (     0.171 s)
Frame-group  35x/390x:        11560 nodes,        170265 total; Expanding...    0.061 s; Merging...    0.014 s,        92017 nodes; Combining...     0.142 s (     0.217 s)
Frame-group  36x/390x:        16813 nodes,        213392 total; Expanding...    0.031 s; Merging...    0.014 s,       131246 nodes; Combining...     0.137 s (     0.182 s)
Frame-group  37x/390x:        18482 nodes,        269464 total; Expanding...    0.050 s; Merging...    0.035 s,       149213 nodes; Combining...     0.243 s (     0.328 s)
Frame-group  38x/390x:        23880 nodes,        336096 total; Expanding...    0.037 s; Merging...    0.017 s,       195743 nodes; Combining...     0.177 s (     0.231 s)
Frame-group  39x/390x:        28319 nodes,        421719 total; Expanding...    0.041 s; Merging...    0.014 s,       238891 nodes; Combining...     0.147 s (     0.202 s)
Frame-group  40x/390x:        33548 nodes,        525014 total; Expanding...    0.049 s; Merging...    0.013 s,       281877 nodes; Combining...     0.152 s (     0.214 s)
Frame-group  41x/390x:        43865 nodes,        652389 total; Expanding...    0.059 s; Merging...    0.014 s,       379581 nodes; Combining...     0.159 s (     0.232 s)
Frame-group  42x/390x:        49156 nodes,        816143 total; Expanding...    0.222 s; Merging...    0.087 s,       428576 nodes; Combining...     0.170 s (     0.479 s)
Frame-group  43x/390x:        68365 nodes,       1013387 total; Expanding...    0.148 s; Merging...    0.014 s,       596597 nodes; Combining...     0.181 s (     0.343 s)
Frame-group  44x/390x:        74649 nodes,       1268512 total; Expanding...    0.082 s; Merging...    0.013 s,       656403 nodes; Combining...     0.190 s (     0.285 s)
Frame-group  45x/390x:       106991 nodes,       1564547 total; Expanding...    0.115 s; Merging...    0.013 s,       926067 nodes; Combining...     0.209 s (     0.337 s)
Frame-group  46x/390x:       118626 nodes,       1954191 total; Expanding...    0.140 s; Merging...    0.013 s,      1028838 nodes; Combining...     0.243 s (     0.396 s)
Frame-group  47x/390x:       163693 nodes,       2396752 total; Expanding...    0.192 s; Merging...    0.015 s,      1399435 nodes; Combining...     0.256 s (     0.463 s)
Frame-group  48x/390x:       189104 nodes,       2968785 total; Expanding...    0.193 s; Merging...    0.014 s,      1605785 nodes; Combining...     0.286 s (     0.493 s)
Frame-group  49x/390x:       249037 nodes,       3629038 total; Expanding...    0.267 s; Merging...    0.013 s,      2085323 nodes; Combining...     0.324 s (     0.604 s)
Frame-group  50x/390x:       295125 nodes,       4450571 total; Expanding...    0.291 s; Merging...    0.013 s,      2448364 nodes; Combining...     0.368 s (     0.672 s)
Frame-group  51x/390x:       376052 nodes,       5410702 total; Expanding...    0.369 s; Merging...    0.014 s,      3078504 nodes; Combining...     0.426 s (     0.809 s)
Frame-group  52x/390x:       453227 nodes,       6595596 total; Expanding...    0.474 s; Merging...    0.014 s,      3660428 nodes; Combining...     0.496 s (     0.984 s)
Frame-group  53x/390x:       556995 nodes,       7976472 total; Expanding...    0.515 s; Merging...    0.013 s,      4471662 nodes; Combining...     0.567 s (     1.095 s)
Frame-group  54x/390x:       679211 nodes,       9647319 total; Expanding...    0.580 s; Merging...    0.013 s,      5347543 nodes; Combining...     0.660 s (     1.253 s)
Frame-group  55x/390x:       816162 nodes,      11592442 total; Expanding...    0.734 s; Merging...    0.013 s,      6395086 nodes; Combining...     0.753 s (     1.500 s)
Frame-group  56x/390x:       991381 nodes,      13924977 total; Expanding...    0.870 s; Merging...    0.013 s,      7635053 nodes; Combining...     0.897 s (     1.780 s)
Frame-group  57x/390x:      1175083 nodes,      16614733 total; Expanding...    1.016 s; Merging...    0.013 s,      9043862 nodes; Combining...     1.021 s (     2.050 s)
Frame-group  58x/390x:      1414364 nodes,      19831669 total; Expanding...    1.143 s; Merging...    0.013 s,     10674452 nodes; Combining...     1.294 s (     2.450 s)
Frame-group  59x/390x:      1662887 nodes,      23493445 total; Expanding...    1.360 s; Merging...    0.013 s,     12561742 nodes; Combining...     1.532 s (     2.905 s)
Frame-group  60x/390x:      1975462 nodes,      27864074 total; Expanding...    1.559 s; Merging...    0.013 s,     14719303 nodes; Combining...     1.904 s (     3.476 s)
Frame-group  61x/390x:      2305019 nodes,      32832385 total; Expanding...    1.840 s; Merging...    0.013 s,     17223832 nodes; Combining...     2.201 s (     4.054 s)
Frame-group  62x/390x:      2714325 nodes,      38729755 total; Expanding...    2.228 s; Merging...    0.013 s,     20079196 nodes; Combining...     2.393 s (     4.634 s)
Frame-group  63x/390x:      3142711 nodes,      45483336 total; Expanding...    2.543 s; Merging...    0.014 s,     23358066 nodes; Combining...     2.749 s (     5.306 s)
Frame-group  64x/390x:      3682270 nodes,      53422983 total; Expanding...    3.017 s; Merging...    0.014 s,     27219540 nodes; Combining...     3.395 s (     6.426 s)
Frame-group  65x/390x:      4241682 nodes,      62633418 total; Expanding...    3.497 s; Merging...    0.013 s,     31582147 nodes; Combining...     3.655 s (     7.165 s)
Frame-group  66x/390x:      4952659 nodes,      73400574 total; Expanding...    4.084 s; Merging...    0.013 s,     36846196 nodes; Combining...     4.423 s (     8.520 s)
Frame-group  67x/390x:      5686924 nodes,      86047784 total; Expanding...    4.765 s; Merging...    0.014 s,     42698874 nodes; Combining...     5.111 s (     9.890 s)
Frame-group  68x/390x:      6642636 nodes,     100740885 total; Expanding...    5.596 s; Merging...    0.013 s,     50041449 nodes; Combining...     5.836 s (    11.445 s)
Frame-group  69x/390x:      7613602 nodes,     118156971 total; Expanding...    6.358 s; Merging...    0.014 s,     57981424 nodes; Combining...     6.937 s (    13.309 s)
Frame-group  70x/390x:      8949620 nodes,     138377872 total; Expanding...    7.908 s; Merging...    2.433 s,     68509857 nodes; Combining...     7.939 s (    18.280 s)
Frame-group  71x/390x:     10216659 nodes,     162519710 total; Expanding...    9.415 s; Merging...    2.815 s,     79237500 nodes; Combining...     9.198 s (    21.428 s)
Frame-group  72x/390x:     12143965 nodes,     190467770 total; Expanding...   10.094 s; Merging...    3.302 s,     94678641 nodes; Combining...    11.296 s (    24.692 s)
Frame-group  73x/390x:     13837260 nodes,     224119499 total; Expanding...   11.090 s; Merging...    3.765 s,    109529045 nodes; Combining...    12.692 s (    27.547 s)
Frame-group  74x/390x:     16616082 nodes,     263248470 total; Expanding...   10.345 s; Merging...    4.757 s,    132085512 nodes; Combining...    15.058 s (    30.160 s)
Frame-group  75x/390x:     18925721 nodes,     310319070 total; Expanding...   11.978 s; Merging...    5.401 s,    153170700 nodes; Combining...    17.587 s (    34.966 s)
Frame-group  76x/390x:     22995072 nodes,     365495364 total; Expanding...   15.526 s; Merging...    6.555 s,    186027198 nodes; Combining...    21.906 s (    43.987 s)
Frame-group  77x/390x:     26232525 nodes,     431661533 total; Expanding...   14.099 s; Merging...    7.776 s,    216493271 nodes; Combining...    24.836 s (    46.711 s)
Frame-group  78x/390x:     32123845 nodes,     509861877 total; Expanding...   16.267 s; Merging...    9.284 s,    264015618 nodes; Combining...    29.050 s (    54.601 s)
Frame-group  79x/390x:     36953845 nodes,     603186224 total; Expanding...   22.521 s; Merging...   10.937 s,    308769349 nodes; Combining...    33.576 s (    67.034 s)
Frame-group  80x/390x:     45181464 nodes,     713993125 total; Expanding...   23.270 s; Merging...   13.345 s,    376339666 nodes; Combining...    40.205 s (    76.820 s)
Frame-group  81x/390x:     52690280 nodes,     845637806 total; Expanding...   26.679 s; Merging...   15.728 s,    442552457 nodes; Combining...    47.398 s (    89.805 s)
Frame-group  82x/390x:     64056948 nodes,    1002196322 total; Expanding...   28.810 s; Merging...   19.212 s,    537579676 nodes; Combining...    55.751 s (   103.773 s)
Frame-group  83x/390x:     75706307 nodes,    1188031852 total; Expanding...   39.624 s; Merging...   22.425 s,    634921575 nodes; Combining...    65.483 s (   127.532 s)
Frame-group  84x/390x:     91305059 nodes,    1408315857 total; Expanding...   45.685 s; Merging...   28.107 s,    767436986 nodes; Combining...    79.529 s (   153.321 s)
Frame-group  85x/390x:    108752270 nodes,    1669867830 total; Expanding...   52.687 s; Merging...   33.886 s,    907582438 nodes; Combining...    94.653 s (   181.226 s)
Frame-group  86x/390x:    130303820 nodes,    1977436010 total; Expanding...   59.804 s; Merging...   40.639 s,   1091674334 nodes; Combining...   108.842 s (   209.285 s)
Frame-group  87x/390x:    155609213 nodes,    2343997151 total; Expanding...   74.072 s; Merging...   51.473 s,   1289444971 nodes; Combining...   132.194 s (   257.739 s)
Frame-group  88x/390x:    185103529 nodes,    2770565672 total; Expanding...   81.088 s; Merging...   66.020 s,   1542286300 nodes; Combining...   152.494 s (   299.602 s)
Frame-group  89x/390x:    221046815 nodes,    3279646387 total; Expanding...   93.965 s; Merging...   72.925 s,   1818160959 nodes; Combining...   179.609 s (   346.499 s)
Frame-group  90x/390x:    261121267 nodes,    3866404286 total; Expanding...  104.835 s; Merging...   88.436 s,   2159413493 nodes; Combining...   213.463 s (   406.734 s)
Frame-group  91x/390x:    310614563 nodes,    4565156558 total; Expanding...  139.577 s; Merging...  107.124 s,   2539234721 nodes; Combining...   251.451 s (   498.152 s)
Frame-group  92x/390x:    365341294 nodes,    5365534048 total; Expanding...  137.251 s; Merging...  126.672 s,   2994826918 nodes; Combining...   295.062 s (   558.985 s)
Frame-group  93x/390x:    431768697 nodes,    6313100255 total; Expanding...  156.272 s; Merging...  149.203 s,   3510328294 nodes; Combining...   346.382 s (   651.857 s)
Frame-group  94x/390x:    505982216 nodes,    7395468054 total; Expanding...  177.323 s; Merging...  181.676 s,   4110318854 nodes; Combining...   406.993 s (   765.992 s)
Frame-group  95x/390x:    594656020 nodes,    8666126235 total; Expanding...  210.053 s; Merging...  211.134 s,   4805404207 nodes; Combining...   473.815 s (   895.002 s)
Frame-group  96x/390x:    692719157 nodes,   10117815179 total; Expanding...  240.234 s; Merging...  255.255 s,   5581696336 nodes; Combining...   550.532 s (  1046.021 s)
Frame-group  97x/390x:    811669051 nodes,   11804612828 total; Expanding...  278.662 s; Merging...  303.414 s,   6516511031 nodes; Combining...   643.739 s (  1225.815 s)
Frame-group  98x/390x:    937763711 nodes,   13736803015 total; Expanding...  322.125 s; Merging...  353.665 s,   7505192165 nodes; Combining...   748.059 s (  1423.849 s)
Frame-group  99x/390x:   1096504370 nodes,   15955357298 total; Expanding...  375.055 s; Merging...  417.164 s,   8752253492 nodes; Combining...   864.683 s (  1656.902 s)
Frame-group 100x/390x:   1256930473 nodes,   18505509459 total; Expanding...  425.145 s; Merging...  493.208 s,  10005397768 nodes; Combining...  1002.399 s (  1920.752 s)
Frame-group 101x/390x:   1465907159 nodes,   21400867248 total; Expanding...  494.826 s; Merging...  595.474 s,  11646567277 nodes; Combining...  1158.289 s (  2248.589 s)
Frame-group 102x/390x:   1669333297 nodes,   24738920937 total; Expanding...  566.280 s; Merging...  689.002 s,  13238357841 nodes; Combining...  1335.060 s (  2590.342 s)
Frame-group 103x/390x:   1940809983 nodes,   28493886291 total; Expanding...  654.943 s; Merging...  816.192 s,  15364250078 nodes; Combining...  1534.100 s (  3005.235 s)
Frame-group 104x/390x:   2199153606 nodes,   32825505344 total; Expanding...  741.508 s; Merging...  951.657 s,  17396478700 nodes; Combining...  1756.612 s (  3449.777 s)
Frame-group 105x/390x:   2547393505 nodes,   37668159296 total; Expanding...  859.109 s; Merging... 1134.641 s,  20106256616 nodes; Combining...  2017.083 s (  4010.833 s)
Frame-group 106x/390x:   2877788247 nodes,   43245615340 total; Expanding...  966.767 s; Merging... 1322.379 s,  22720865377 nodes; Combining...  2304.849 s (  4593.995 s)
Frame-group 107x/390x:   3315279347 nodes,   49460414188 total; Expanding... 1109.198 s; Merging... 1554.068 s,  26114865797 nodes; Combining...  2641.495 s (  5304.761 s)
Frame-group 108x/390x:   3745404411 nodes,   56587960314 total; Expanding... 1252.631 s; Merging... 1758.086 s,  29511429274 nodes; Combining...  3001.302 s (  6012.019 s)
Frame-group 109x/390x:   4281744800 nodes,   64529363555 total; Expanding... 1464.633 s; Merging... 1986.069 s,  33694806632 nodes; Combining...  3409.840 s (  6860.542 s)
Frame-group 110x/390x:   4846381467 nodes,   73577376304 total; Expanding... 1720.536 s; Merging... 2277.265 s,  38119507888 nodes; Combining...  3907.706 s (  7905.507 s)
Frame-group 111x/390x:   5493469038 nodes,   83677042559 total; Expanding... 1962.955 s; Merging... 2669.730 s,  43228161480 nodes; Combining...  4506.462 s (  9139.147 s)
Frame-group 112x/390x:   6231785300 nodes,   95096251164 total; Expanding... 2198.831 s; Merging... 3210.123 s,  48961140232 nodes; Combining...  5087.093 s ( 10496.047 s)
Frame-group 113x/390x:   7008184357 nodes,  107871169850 total; Expanding... 2435.979 s; Merging... 3591.886 s,  55175588741 nodes; Combining...  5859.210 s ( 11887.075 s)
Frame-group 114x/390x:   7960570555 nodes,  122204749510 total; Expanding... 2826.776 s; Merging... 4226.398 s,  62520496369 nodes; Combining...  6587.812 s ( 13640.986 s)
Frame-group 115x/390x:   8894248636 nodes,  138270588759 total; Expanding... 3131.842 s; Merging... 4777.853 s,  70089878376 nodes; Combining...  7378.791 s ( 15288.486 s)
Frame-group 116x/390x:  10102676932 nodes,  156173015665 total; Expanding... 3873.200 s; Merging... 5518.660 s,  79363678835 nodes; Combining...  8699.624 s ( 18091.484 s)
Frame-group 117x/390x:  11235223693 nodes,  176247958489 total; Expanding... 4031.843 s; Merging... 6234.608 s,  88617179002 nodes; Combining...  9522.192 s ( 19788.643 s)
Frame-group 118x/390x:  12738734003 nodes,  198501314294 total; Expanding... 4627.959 s; Merging... 7017.669 s, 100152861151 nodes; Combining... 10864.267 s ( 22509.895 s)
Frame-group 119x/390x:  14127271670 nodes,  223430037412 total; Expanding... 5095.612 s; Merging... 7645.382 s, 111512207146 nodes; Combining... 11514.640 s ( 24255.634 s)
Frame-group 120x/390x:  15962958537 nodes,  250961308601 total; Expanding... 5817.040 s; Merging... 8763.013 s, 125662656993 nodes; Combining... 13059.979 s ( 27640.032 s)
Frame-group 121x/390x:  17682679236 nodes,  281732484577 total; Expanding... 6340.959 s; Merging... 9991.756 s, 139653082580 nodes; Combining... 14488.221 s ( 30820.936 s)
Frame-group 122x/390x:  19883346078 nodes,  315637243109 total; Expanding... 6982.472 s; Merging...11621.202 s, 156792441297 nodes; Combining... 17499.531 s ( 36103.205 s)
Frame-group 123x/390x:  22025116364 nodes,  353413516638 total; Expanding... 8379.738 s; Merging...13265.094 s, 174048416128 nodes; Combining... 20064.683 s ( 41709.515 s)
Frame-group 124x/390x:  24626788148 nodes,  394977092950 total; Expanding... 8590.819 s; Merging...16282.970 s, 194598466240 nodes; Combining... 20127.140 s ( 45000.929 s)
Frame-group 125x/390x:  27290551572 nodes,  441113362345 total; Expanding... 9645.251 s; Merging...18647.067 s, 215847664905 nodes; Combining... 22645.580 s ( 50937.898 s)
Frame-group 126x/390x:  30344665941 nodes,  491834006138 total; Expanding...10402.646 s; Merging...18769.779 s, 240328026883 nodes; Combining... 25071.283 s ( 54243.708 s)
Frame-group 127x/390x:  33634835248 nodes,  547915714541 total; Expanding...11892.167 s; Merging...21728.937 s, 266361556373 nodes; Combining... 28574.111 s ( 62195.215 s)
Frame-group 128x/390x:  37213078258 nodes,  609523526760 total; Expanding...13630.992 s; Merging...26420.578 s, 295406183478 nodes; Combining... 30820.923 s ( 57241.501 s)
Frame-group 129x/390x:  41235320243 nodes,  677396738594 total; Expanding...14648.431 s; Merging...26625.417 s, 327114540448 nodes; Combining... 34811.462 s ( 76085.310 s)
Frame-group 130x/390x:  45434945000 nodes,  751897515315 total; Expanding...16266.693 s; Merging...30133.962 s, 361492447796 nodes; Combining... 38746.206 s ( 85146.861 s)
Frame-group 131x/390x:  50302629585 nodes,  833704608754 total; Expanding...18156.917 s; Merging...34170.966 s, 399855968958 nodes; Combining... 43355.886 s ( 95683.769 s)
Frame-group 132x/390x:  55248485831 nodes,  923414768666 total; Expanding...19909.688 s; Merging...38119.612 s, 440512858568 nodes; Combining... 46494.881 s (104524.181 s)
Frame-group 133x/390x:  61074883326 nodes, 1021639333733 total; Expanding...22938.015 s; Merging...42910.274 s, 486579435749 nodes; Combining... 52777.526 s (118625.815 s)
Frame-group 134x/390x:  66925382272 nodes, 1129234460902 total; Expanding...24311.440 s; Merging...47233.939 s, 534706152688 nodes; Combining... 57026.356 s (128571.735 s)
Frame-group 135x/390x:  73826895008 nodes, 1246749013460 total; Expanding...30138.340 s; Merging...52781.700 s, 589590031890 nodes; Combining... 62793.465 s (145713.505 s)
Frame-group 136x/390x:  80777839987 nodes, 1375290336390 total; Expanding...30568.238 s; Merging...56701.390 s, 646601737675 nodes; Combining... 71798.527 s (159068.155 s)
Frame-group 137x/390x:  88874318380 nodes, 1515397945086 total; Expanding...39721.979 s; Merging...68678.272 s, 711488932083 nodes; Combining... 76081.375 s (184481.626 s)
Frame-group 138x/390x:  97141598019 nodes, 1668371311843 total; Expanding...34730.056 s; Merging...74788.322 s, 778998609008 nodes; Combining... 84240.866 s (193759.244 s)
Frame-group 139x/390x: 106579860950 nodes, 1834815097065 total
Posted: 2/26/2024 4:28 PM
(Edited: 2/26/2024 4:54 PM)
Deadcode
He/Him
Experienced Forum User, Published Author, Player (6)
Joined: 7/27/2016
Posts: 32
Deadcode wrote:
Alyosha wrote:
Why do they need to be resolved? Isn't just going back and removing the extra frames at each hole fill sufficient?
Well, probably most of them will end up being the same, but perhaps some solutions can be faster now by filling in extra holes.
I re-solved 24 out of the 25 already-DDD-solved levels (i.e. all except for level 3-6) and as expected, none were more optimal than before by being solved with Bird's-eye View timings. The longest to solve out of those, level 2-2, took 9 days (or 138.8 hours of total run time) in 2010, but just now took only 28.4 hours (one uninterrupted run). It is impossible for level 3-6 to be solved with a shorter solution in Bird's-eye View timings, since at the end of the solution that was optimized using Diagonal View timings, there are only two blocks left over, and neither of them can be pushed into a hole (even from the starting state). Now let's assume that some other solution is possible, in which fewer blocks are pushed into holes. If that were possible, and shorter in Bird's-eye View than the Bird's-eye View port of the Diagonal View optimized solution, then it would also be shorter, when ported to Diagonal View, than the Diagonal View optimized solution, thus it would have been the solution found by DDD using Diagonal View timings. Thus, proof by contradiction, the existing DDD solution is also optimized in Bird's-eye View. So, the 15:12.62 BizHawk 2.9.1 (Gambatte core) replay still stands as my submitted replay.
Alyosha wrote:
Cool, looks good!
Thank you.
Alyosha wrote:
Oh, I was playing around with possible improvements in 3-9, and I ended up with a solution that was a couple steps longer but shorter in frame count. I was doing the moves manually, so I was doing all the moves as fast as possible just holding buttons down, so I figured something had to be wrong with the original file.
Oh, I see. That make sense, thanks.
Posted: 2/26/2024 1:42 AM
(Edited: 3/6/2024 10:01 PM)
Deadcode
He/Him
Experienced Forum User, Published Author, Player (6)
Joined: 7/27/2016
Posts: 32
Saved another 0.72 seconds (primary-submitted replay file for this submission) using the information TAStudio provided, and that truly appears to be the best possible with this set of solutions. (But I still find it a bit of an inconvenient way to do this; a log file would be much better. And then at first I thought, after seeing what TAStudio could do, that it explained how you did this:
Alyosha wrote:
https://tasvideos.org/UserFiles/Info/638443243569823355 I'm not sure what happened, but it seems like all the moves in the last 2 levels are taking too long to move after a block has been placed. Here is a partial improvement of those levels.
But it appears that TAStudio loses the ability to do that magic when the GBHawk core is in use, and the replay file you posted was based on the GBHawk one. So how did you do that? Edit: I've added lag-frame detection to my replay frame logging script. It works even with the GBHawk core, unlike TAStudio: 
  1278:   
  1279:   
  1280:   
  1281:   
  1282:   
  1283:   
  1284:   
  1285:   
  1286:   
  1287:   
  1288:   
  1289: ! 
  1290: ! 
  1291: ! 
  1292: ! P1 Left
  1293:   
  1294:   
  1295:   
  1296:   
  1297:   
  1298:   
  1299:   
  1300: ! 
  1301: ! P1 Left
  1302:   
  1303:   
  1304:   
  1305:   
  1306:   
  1307:   
  1308:   
  1309: ! 
  1310: ! P1 Left
  1311:   
  1312:   
  1313:   
  1314:   
  1315:   
  1316:   
  1317:   
  1318: ! 
  1319: ! P1 Left
  1320:
And then I can just use the regex (! \R[^!\r\n]+){2}! \w to find instances of too-late input. Edit: Or (\] \R[^\]\r\n]+){2}\] \w on the latest version of the script (still linked above) which shows when the input was read in fractions of a frame relative to the current frame.
Posted: 2/25/2024 11:04 PM
(Edited: 2/27/2024 9:43 AM)
Deadcode
He/Him
Experienced Forum User, Published Author, Player (6)
Joined: 7/27/2016
Posts: 32
Alyosha wrote:
Here is the first move in level 1-2, you can see the 'left' button is pressed on the fourth (green) input frame but input is accepted on the second:
Wait, what? How are you interpreting that graph in that way? It shows 4 frames in a row that are all the same color, against a gray* background. Can you actually tell just by looking at it that it accepts input on the 2nd? Why not the 1st? *I guess it's grayish cyan, using a color-picker, but to my protanomalously colorblind eyes it looks gray. That's not the problem though, as all 4 frames in a row from 1313 to 1316 are the same green (I had to check, to make sure there wasn't just some color difference I wasn't seeing)
Posted: 2/25/2024 10:10 PM
(Edited: 2/25/2024 10:42 PM)
Deadcode
He/Him
Experienced Forum User, Published Author, Player (6)
Joined: 7/27/2016
Posts: 32
Alyosha wrote:
TAStudio is really helpful for cases like this since you can (generally) see where input is accepted.
Okay, that's neat in principle, but in practice, it's just plain wrong. According to its graph when I tried it just now, level 1-1's input can start 1 frame earlier, but if I edit the replay file to do that, it doesn't work. Did you try applying any its hints besides the one about first-start being 10 frames earlier? Edit: It appears that there is a grain of truth in what it shows, but it's distorted. It showed me level 2-1's movement could be started up to 5 frames earlier, and that didn't work (and neither did 1 frame earlier, or 3), but 4 frames earlier did work, and so did 2 frames earlier. So the accurate display would show the gaps for what wouldn't actually work, but TAStudio misleadingly shows a continguous list of 5 frames. Still, it can at least provide a hint at what to try. Also, it's annoying that it doesn't show the "comments" that I put in my replay file, e.g.: 
|....S....| Level 1-5
And I made it display some other comments as well, to help with finding delays to reduce. TAStudio doesn't show these.
Posted: 2/25/2024 8:49 PM
(Edited: 2/25/2024 9:49 PM)
Deadcode
He/Him
Experienced Forum User, Published Author, Player (6)
Joined: 7/27/2016
Posts: 32
Alyosha wrote:
Deadcode wrote:
These post-submission improvements have all been incorporated into this BizHawk 2.9.1 (Gambatte core) replay file, along with fully optimizing its UI delays. This is now meant to be the primary file associated with this submission, so please ignore the "15:27.21" one and use this 15:13.34 one instead when judging the submission.
Seems like there are still some script issues. The very first start input can be pressed 10 frames sooner. Also a lot of levels are 2 frames late on the first move, with some even being 4 frames late.
Well, that first-start thing is confusing. I couldn't press start 1 frame earlier, so I assumed I had it as early as possible. Apparently it doesn't poll for that start every frame. What's even worse is that if Start is already being held on that frame, it doesn't work. It has to be pressed from a released state. So a binary search doesn't work to find the optimal frame. How am I supposed to find this? Individually trying every single frame within a range? (I tried that now, and it confirmed your finding of 10 frames, but it's pretty tedious.) And absolutely none of the levels were any frames late; I confirmed that (not only for the first moves of levels, but for all 95 instances of UI delay). Now, if you were testing that in a version of the replay where you already removed 10 frames before the first start, that would likely throw everything off, so I'm guessing that's what you did. Which is rather upsetting, because it took me a lot of time to do that, and now it's apparently wasted, because it was all based on starting the game 10 frames later than optimal. Edit: You seem to have sent me on a wild goose chase, Alyosha. I went through all the delays in the first set of 10 floors, and not a single one could be reduced by 1 frame. Are there parts of the UI beyond the first-start-press that also don't poll every frame? Could you please provide actual exact examples of what you found, or a replay file demonstrating it, instead of the vague information you gave above?
Posted: 2/25/2024 6:31 PM
(Edited: 2/26/2024 1:28 AM)
Post subject: Replay file updated
Deadcode
He/Him
Experienced Forum User, Published Author, Player (6)
Joined: 7/27/2016
Posts: 32
These post-submission improvements have all been incorporated into this BizHawk 2.9.1 (Gambatte core) replay file, along with fully optimizing its UI delays. This is now meant to be the primary file associated with this submission, so please ignore the "15:27.21" one and use this 15:13.34 one instead when judging the submission. Edit: Now fully optimized for real (with some help from TAStudio), bringing it down to 15:12.62: This replay file.
Posted: 2/24/2024 9:22 PM
Deadcode
He/Him
Experienced Forum User, Published Author, Player (6)
Joined: 7/27/2016
Posts: 32
Alyosha wrote:
https://tasvideos.org/UserFiles/Info/638444031574122837 2 steps saved in 3-10, couldn't find anything new in the other non-optimal levels, but that was a fun revisit.
Awesome, thank you! This too saves 18 frames.
1 2