Posts for Omnigamer


1 2 3 4
11 12
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
I can never find the user file uploads location! Managed to work it back from Scepheo's link, but I have no idea how to arrive there through normal browsing. In any case, my watch set: http://tasvideos.org/userfiles/info/42118433998608228 Of particular note are a number of addresses that are related to X position, which I just called the sub-positions. They are related to the speed at $56. The X and Y px velocities are useful for finding out where you are losing speed, but the actual "position" is still a mystery. It's between one of two addresses, but has a lot more to do with the subpixels as well. Like I said, I have disassembled the game. If there are any particular addresses that seem especially interesting, I can try to track down interactions with those.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
Good job! Are you doing anything in particular to track horizontal position or speed?
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
I figured out the bug a few nights ago. It is basically reaching into memory and pulling up some other enemy's attack/damage value. The Phoenix plumes are treated the same as enemy projectiles in memory, but do not have an initialized set of values for HP/attack like other enemies do. So when they get assigned an attack ID, it just goes and looks for whatever attack value the attack ID is associated with. In this case, it's ID + 0x7F2016, where I've seen IDs as low as 0x1260 and as high as 0x1CC0 in increments of 0x30. So it relies on the way in which the IDs are assigned for the mega-damage to occur. That region of memory changes on major screen transitions and some boss patterns. Your chance of doing big damage is probabilistic with how full that space is with huge attack values.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
The console switches aren't something that I would particularly need for testing, but in the long run they function just the same as controller inputs as far as the Atari is concerned. Other games might certainly benefit from toggling console switches on certain polls, but until the input state can be changed mid-frame I don't think it will be useful.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
One further question - for the purposes of the oninputpoll event, what counts as an Atari input? Is it just controller inputs, or also system inputs (reset, difficulty select, etc)? Going through the code I see far more direct calls to just the button and the system inputs than there are polls occuring per frame.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
My mistake! You were discussing Grand Prix on TG, and I just swapped the games/times in my head. As far as input polling goes, I set up a basic script to change out inputs on different polls, but there are a couple things I'm not sure of. What is the "start" of a frame for Atari, as far as BizHawk is concerned? I assume it starts in VBlank but the oninputpoll() behavior is kind of strange. That, or the emulator doesn't seem to register input changes until the start of the next frame. It might not be possible to change them mid-frame like that.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
To clarify, I don't think sub-frame is necessary for improving the current TAS, but may be necessary for true optimality later on. I believe Alyosha mentioned he could produce a 32.61, so that's at least an improvement. Sub-frame would be nice, but I understand the difficulty in making that happen from an emulator development perspective. At least, a better understanding of the system would make it possible to reason a theoretical limit, assuming sub-frame inputs were possible.
Post subject: Barnstorming [A2600]
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
Just wanted to post a thread for this game, in case anybody is working on it. I know Alyosha has put in some time with it, but as far as I know hasn't published a WIP or otherwise. This game is interesting in that it has another early-gaming era "legendary time," but also has existing footage of humans beating the currently-published TAS. We should probably fix that. I spent a little bit of time experimenting with the game last night to get a feel for the mechanics, and also started a disassembly of the binary. The basics I think are pretty well understood: you lose some horizontal speed by moving vertically, so minimal movement is optimal. But the actual coordinate system it uses is tricky to track; I found the addresses related to horizontal and vertical pixels per frame, but couldn't find a sensible combination of addresses that could precisely describe the plane's current horizontal position. It's in there, I just haven't nailed it down yet. From the disassembly, though, I noted several other things that will affect optimality: -Frame rules. There are numerous odd/even frame rules spread throughout the code, but also a number of checks that only occur every 8 frames. -Sub-frame inputs. Unfortunately, the game checks the button state at 3 separate logic blocks in the code, which I'm pretty sure are not mutually exclusive. -Birds spawn based on button use. If you start up a race and never press the accelerator again, no birds will spawn. If this is one of the three input checks, then you can absolutely get an optimal pattern (no birds) by precisely toggling sub-frame inputs. -It is possible to go through windmills. I found this entirely by accident my first time going through, but some precise combination of position and v/h speed will cause the plane to bounce "upwards" instead of backwards. It is unlikely that this is faster than simply going around the windmill. Currently unknown, though, is whether you can bounce backwards after passing through a barn in order to pass through it again. Just wanted to document these things in case anybody plans to put more work into this game.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
This is about as entertaining as it can be, given the game. Yes vote.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
I hadn't thought about failure to switch into BCD mode; that would result in garbled digits, but I doubt it would affect the loop operation beyond that. As far as I've seen, there are no further swaps to BCD mode in the entirety of the codebase. So that's a plausible reasoning for an empirical 5.51 to appear on hardware. Again, though, that's assuming some form of hardware failure. The same user that checked solution sets for my optimal in-game time inputs also checked the minimal set I used for P2. Apparently the input sequence I have there is also optimal for all possible values of the frame counter; I thought I had one that finishes two frames sooner, but on checking again I could not reproduce it. So we can likely nix the "sacrifices time for entertainment" tags on this run as well.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
Just as a minor update, a YT user conducted a dynamic programming-based approach to finding optimal input combinations. His results corroborated the set of inputs used in the published TAS (exact results here: https://paste.ee/p/7r7Us). This is supporting evidence that the TAS is optimal, given no further discoveries that violate the assumption of the game model.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
I am not going to release the disassembled code for legal reasons. The best course if you want to work through the code yourself is to obtain a copy and perform the disassembly. The information in the notes and in the thread should be a good headstart in understanding the major game functions. A small bit of inaccuracy is extremely unlikely to be an issue here. There's just a significant mathematical barrier to hitting the next time increment that would require a lot more to change. The simulator is also built off of the code itself, so it shouldn't be affected by any inaccuracies in the Atari emulation core.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
Samsara's movie starts with a frame counter that is equivalent to 0, and also releases the clutch some frames early to just barely cross the finish line with a 5.57. That movie's subdistance going over the finish line is 1. This is fine by itself, but it doesn't meet the secondary goal I described in my notes. There are many combinations of ways to get a 5.57 time. What I optimized for was crossing the finish line with as many additional subdistance units as possible, which is a more challenging problem and represents as close as I can get to the next time increment. If there are improvements found down the line that might enable a 5.54, the strategies available in this movie are of much greater value for future TASers when it is optimized for remaining subdistance. If you're saying for submission purposes that the movie should aim only for the soonest possible 5.57 time in term of gameplay frames, then I would have to re-optimize and re-submit. But overall, I think the movie I have posted is more significant in terms of technical achievement than finding a slightly sooner 5.57.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
Holding clutch before frame 0 has no gameplay impact. You don't shift into first until the clutch is released, and your speed is also locked at 0 for as long as you hold it. The spreadsheet represents the entire prior sequence as the frame 0, so the first actual frame that the shift "activates" is correct as shown in the spreadsheet. On the other hand, if you're asking about cases where you might cheat the "start early" flag, then you can approximate it with custom distance and/or speed at frame 0. Based on some quick n' dirty calculations, you could start at frame 0 with a distance of 8 and a speed value of 32 if you automatically start the countdown in gear 1. This leads to a best time in the neighborhood of 4.77. You could do quite a bit faster if you somehow could advance to 2nd/3rd gear during the countdown as well, but starting in 1st is enough of a stretch as it is.
Post subject: SNES Hardware Revision Differences
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
Is there any documentation related to the implementation differences between revisions of the SNES hardware? I've found all manner of information on various combinations of hardware revisions, but it has all been related to improved video encoders and pipeline. I'm looking for any known details on changes to instructions, including undocumented, or functionality of the PPU. Specifically, I'm trying to figure out the technical reasoning behind this behavior: Link to video While the video itself is not mine, I have a model of SNES that produces the exact same graphical oddities. Stranger yet is that they only occur on the first stage; 2nd and beyond Arthur appears as normal. I don't remember the exact combination of parts in the SNES (it's a full-size 1CHIP, at least), but it doesn't happen on my SNES-mini or older full-size models. I'm curious if: -Whatever causes these anomalies can be leveraged in other games -How much it would take to reproduce the same effect in-emulator
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
I'm not really looking for help so much as just a better understanding of what hardware differences actually cause this. The behavior is awfully specific (incorrect sprite ordering for just 1 stage?), and as far as I know there aren't a whole lot of implementation details for the various SNES hardware revisions. It could be something like Genesis Model 3 where some instructions were fixed when they re-made the CPU, but ironically some games relied on the broken behavior of those instructions. Most of what I've seen for different SNES revisions are just changes to encoders and board layout. The above behavior isn't specific to 1CHIP models either, as I have a mini-SNES that doesn't show this same error. It's confusing, but something I'd really like to understand for TAS purposes.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
While on the topic of "crazy things that haven't been explained," I'm curious if anybody might know technical details related to this bug: Link to video As far as I know, this is SNES-hardware dependent for specific 1CHIP full-size models. I have a model of SNES that shows the same effects. In this case it's just graphical anomalies, but I'm wondering if it could have any subtle effects in this or other games as well.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
You can hold the shift for as long as you want during the countdown, it doesn't actually increment the gear until you release it. This same code path is what checks for whether the countdown is currently at 0, and marks you as early if it isn't and the gear increments. Thus, you can legally complete the shift into first on the first actual frame the countdown is 0.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
I can't test either at this exact moment, but scepheo's movie is circa 2014. I don't know which BizHawk version was used, but there have been numerous Atari accuracy improvements since then. The discrepancy (6.07 instead of 5.57) is likely due to a faster or slower system startup. An adjustment of even one or two frames can throw off the frame rules and drastically change the effect from shifts. Judging from just the time characteristics feos listed in the prior post, the difference between my run and Samsara's is likely just the starting frame counter value. I include an additional delay at the beginning to optimize distance traveled over the finish line. I go for frame_ctr%16 = 12, but I believe a 5.57 is also possible at frame_ctr%16 = 0. That accounts for most of the difference, while the rest may be from further accuracy improvements. I'll check it when I get home.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
I am on vacation presently, so I can't check either of those. If anybody tries to load them up, you can use the finishing subdistance of player 1 ($42) to draw a comparison between their runs and my own. The updated TAS finishes with 98 additional subdistance units.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
The opening strategy is pretty much fixed. Since in gear 1 the frame rule is every frame, you can get to the optimal gear 1 ceiling (32) on the same frame regardless of the frame counter. So long as you start with 15 or greater tach value, you can always hit this point with some selective gas presses and without dropping the speed at all. There is an alternative strategy where you'd shift up in gear 1 when you reach a speed of 28 (corresponding to tach value 28). This lets you start gear 2 with 31 instead of 28 tach. In almost all cases I tested though, this performed worse than letting it get to 32. You can see this strategy used for the gear 2->3, though.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
Based on JSmith's comment, I went back and fiddled with the race end a little to eke out an extra 24 units of distance. Dropping the speed to get an odd speed value in general is never beneficial in terms of your total distance, but once you've reached the speed ceiling you sacrifice much less. Thus I came up with a new addition before going full-clutch that goes to 251 speed for 2 frames, then 253 for the remainder. This led to an additional 24 units of subdistance. I also checked the other 7 frame counter values to be sure this didn't change anything for them; it allowed more of them to hit 5.57 at all, but 12 was still the optimal seed by quite a bit. I updated the movie to reflect this. It's still the same length, and only 4 frames of input were changed. The submission text and temp encoding were updated to reflect the change. New movie file below: https://www.dropbox.com/s/n3ny4bhh5u18ced/Dragster%20%281980%29%20%28Activision%29%20%5B%21%5D.zip?dl=0
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
Update: I've reproduced the entirety of the speed system here. Fool around with it if you'd like. I explain the mechanics in-depth on the rule slide too, but a lot of the finer details are below. First, the order of operations in a frame is as follows... 1. increment timer 2. check if speed = 0, otherwise add to subdist($42) 3. Check upper 3 bits of speed ($40), and with frame counter... 4. Check to see if distance($3A) >0x60, if so mark as finished 5. And frame counter ($01) with table (0,2,6,E) using current gear as index 6A. If result is 0, jump to gear shift [6] 6B. If result is !0, add 1 to bar if not in clutch, otherwise add 3 6C. If result is !0 and you aren't pressing button, same as 5B except subtract 7. Check if gear shifted 8A. If no gear shift, check if in redline. If in redline, rotate carry into tach 8B. Rotate tech left for each gear past 1. Compare with speed 8C. If equal, skip speed increment (go to 9) 8D. If unequal and limit is larger, increment speed by 2 8E. If unequal and limit is smaller, decrement speed 9. Check if $D6 bit 2 is set, if so increment gear unless >4 10. Check if in steering mode... 11. Update Inputs. 12. Repeat Based on that, there are a few bits of strategy to maximizing distance: -Shift as late as possible. Every additional frame later nets you +2 total distance -For 1->2 and 2->3, you can have the speed limit odd. You can abuse this to have the speed temporarily exceed the limit before locking in the speed with a shift. Hitting gear 2 at 32 speed and gear 3 at 64 speed seems to be optimal. -As your gear goes up, there's a growing frame rule that checks your button state. At gear 4, it only checks the gas every 16 frames. Changing the frame counter to one of 8 configurations will net you different overall shifting points in gear 3 and 4, and tend to give fairly different performance. -The "end game" is probably the most tricky, where there are some instances that allowing the tach to decrease or shifting early will get you very good results. I haven't figured out the exact rules for making an optimal choice, but sometimes it can lead to vastly improved finishes. So all that said, I don't think better than 5.57 is possible. The best I've managed is 5.57 with 66 additional subdistance. There's just too much to overcome to get the extra bit more. I've also confirmed in the code that it completely wipes the memory inbetween resets, so there shouldn't be anything possible from trying to get the memory in a funky state before going over. I also compared the original ROM with the PAL and one other version; the differences, when present, are just related to display controls. So all that said, I can't think of any other way that getting below 5.57 is possible. The "simulated" best of 5.54 supposedly from the developers I also think is from a flawed implementation. There just isn't enough input options or otherwise to trigger a bug and allow starting earlier outside of glitching (as in, the actual hardware variety). Even assuming some level of cheating, I've managed a 5.51 only with starting in 1st gear with no shift and starting with 2 speed already stored. I don't have any more ideas on this, and my interest is waning. I might think a bit more on the optimal finish timing, but for now I'm going to call this closed.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
Hello. I have a complete disassembly and graph for this game. There are still some parts that I'm working to understand, but I have a good feel for the general system now. The major takeaway so far that I haven't seen discussed in this thread is the relationship between the tachometer and your speed "limit." It essentially works as a moving window for optimal operation. At each gear level past 1, the game applies a ROL to your current tachometer value, with an initial carry if you happen to be >=0x14. If the resulting value is greater than your current speed, it then checks if the difference between them is greater than 0x10. I don't know what exactly this affects, but my guess is that's the limit it uses for engine lurch, where you are penalized for being in too high of a gear too quickly (which I haven't yet looked into). I haven't watched the files yet, but I imagine that the other TASers so far have utilized this window whether they knew it or not. So far I don't see anything that would allow additional time to come off, but there's some strange things that happen with resets and changing modes that I don't fully understand yet. If you have specific mechanics you'd like me to look into, I'll happily do so. EDIT: I did some theory-crafting today and came to the same general conclusion as others: 5.57 seems to be the limit with the normal assumptions. Going over the information posted by Todd Rogers elsewhere though, I started to play with the assumptions: if you were somehow able to start in 2nd Gear, 5.51 would just barely be possible. I haven't been at my main computer to test anything yet, but I'll see if there's anything special that might happen with well-timed resets or otherwise.
Experienced Forum User, Published Author, Player (33)
Joined: 2/16/2012
Posts: 282
I tested a version of that particular skip via infinite jump cheats some time ago, but in that case the boss would not spawn. I'm curious what the major difference is for what you're doing that allows the boss to spawn. I specifically tested landing immediately on the 2nd raft, but if there's some point at which you can death warp to it instead then it might be workable.
1 2 3 4
11 12