Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
So I did some quick testing using the current warps run and the comparable portions of the new warpless 1 player run.
Basically from the intruder excluder to game end, 1 player is 750 frames faster.
Level 3 in 650 frames faster in 2 player then in 1 player.
Level 4 can be done faster 1 player then 2 player do to intense lag. I don't know by how much but my very brief testing was already 10 frames ahead. So maybe up to 1 second faster in an optimized case.
So, if level 1 and the snake level can be done fast enough, 1 player warps might be faster then 2 player warps. But I'm not sure if the snake warp can be hit fast enough. It will be very close though.
EDIT: currently 50 frames away from being faster
EDIT2: currently faster by 60 frames. This gets up intruder excluder but doesn't sync to the end (although it should be identical to warpless after this point.)
http://tasvideos.org/userfiles/info/30168575436228154
@feos: are any of the speed improvements you found in 1 player warpless applicable to 2 player warps? I don't think this can be improved too much more, so if you can save 1 second 2 player will still be faster.
EDIT3:
http://tasvideos.org/userfiles/info/30171946756063596http://tasvideos.org/userfiles/info/30172987039226829
Here is a slightly more optimized file that beats the game. So right now 1 player stands as faster then the published 2 player warps run by ~70 frames.
EDIT4: So the entertainment tradeoff feos originally put in his Robo Manus fight in the published run costs about 20 frames. I am at 39931 frames for 2 players right now and 39877 39861 for 1 player. Very close!
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Thanks for posting the WIP Odongdong.
Having something to look at is always way better then starting from scratch, so this is a big head start. It will probably be the next thing I work on after Atari 2600 and Battletoads is sorted out, whenever that may be.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
mklip2001 wrote:
This is great. Finally, this run has an up-to-date Turbo Tunnel skip in level 3. There are some amazing changes elsewhere too.
Of course, this raises the question of how many runs Battletoads should have. The any% and the 2-player warpless, I think, are pretty agreed-upon categories. Is this run valuable enough to be published separately from those other two? (This may just be a case of a legacy category that was more historically interesting, like the Princess SMB2 run.)
One strategy question: why don't you recover your walker stick to fight Big Blag in stage 5? Each time you headbutt him, he pauses the game with his landing. If you took one of his small jumps as time to get the stick back, you can juggle him with the stick and keep him from landing.
This is also something I thought about when working on this. My feeling is that if there is going to be a one player run of this game it should be this one, but as to whether or not 2 player warpless is preferred and obsoletes this one, I guess it depends on how interesting people find it.
2 player warpless also provides a level 5 skip, so the amount of overlap with 2 player warps will be pretty big.
There might not really be enough unique content to have 1 player warpless, 2 player warpless, and 2 player warps. My personal opinion is that if one of them has to go it should be 2 player warpless, but that's just me.
I did some testing with the stick, but yeah Blarg just bounces too high. I also tried to give him a kick with the walker head on the ground, but it seems he is not susceptible to that.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
http://tasvideos.org/userfiles/info/30145763783146691
So I've had this for a while without looking at it, with the 1-p run on the workbench I figured I'd just post it here for anyone interested.
This basically just expands the warps run into a warpless one. Levels 1 and 2 contain decent optimization. Level 3 is just the warps run version. level 4 uses some of what was learned in the warpless run but isn't optimized. Level 5 also uses the level skip similar to level 3.
This only syncs up to the robot boss, but from there on it will identical to the warps run anyway. I made no attempt at entertainment since it's just a rough draft.
Currently I'm not sure when I might come back to this, but here it is for anyone to use.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
With the implementation of PRG write delays, many graphical bugs are now fixed (such as the 'O' in power in H.E.R.O. above. )
This fix also correctly implements PRG delays due to HMOVE, which is what the hacked in original 3-2-1 code was trying to do.
This also fixes the rather annoying house moving bug in River Raid.
At this point pretty much all graphical bugs should be fixed.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I also have to say that this seems like a pretty muddled case. The run's complexity as an optimization problem is definitely higher then other runs in the vault, so it seems rejection for triviality doesn't quite fit. Also this run is at least as complicated as the recent Fighters Destiny runs, which happen to follow the guideline of "in general, these would be games where the user competes against an AI opponent, and/or have a fixed clock time" to the letter. Fighting games get an exception from 'sport' category for some reason though despite being a perfect example according to that definition.
As Warp mentions, this game has all the goals and mechanics of a normal game, and none of a sport (there isn't even an opponent.) So despite the fact that 'golf is a sport', this game is not played as a sporting event.
Maybe this rule needs some attention sooner rather then later.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I did make a fork of Bizhawk (linked in opening post) that has all my current changes, but that is as far as I know how to do. I don't really understand the pull request thing, but sure just tell me what to click on and everything can be integrated.
However I am still waiting for confirmation on the most critical fix which is the ENAM delay in the current FlapPing submission. Aside from just following Stella I have no concrete proof if it is true or not. I asked on AtariAge but have no replies yet. So unless I get something certain there or a console verification, integration into the official BizHawk might have to wait a bit, I wouldn't want a run rejected on uncertain grounds.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
So I have finally fixed the original bug that got me interested in all of this. This implements the same play field delays that Stella uses. While I don't understand why they would be true at a low level, they none the less have high compatibility and I haven't seen any deficiencies in my testing.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
jlun2 wrote:
Wow congrats!
For Stella, I'm not sure why. Given how it was mentioned that it uses a high level approach rather than a lower one, it (may be) the case that the devs simply made a random starfield effect and assumed it looked "close enough". Could be wrong however.
Doing a bit of research it seems that the pattern in Stella was hard coded to match observed behavior. I have no idea why this behavior occurs at this time, but this commercial of the game pretty clearly shows the pattern in Stella as opposed to the uniform one produced by the understood effect:
Link to video
This is what mirco500 was trying to figure out with his work I believe (the basic effect of not resetting movement latches is straight forward and pretty well understood)
Anyway I made some more clean up and commits to my fork. So if anyone wants to compile and play I put the link in the opening post.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Success!
After a bit of sleuthing a discovered what was missing to make the star pattern work correctly.
From the same hardware notes page as above we have:
I mentioned above that HMOVE sends extra clock pulses down
the same clock lines that are usually used during the visible
part of the scanline. In theory this means that performing a
HMOVE during the visible part of the scanline should have no
effect. However, looking at how the various clock signals
interact, I suspect it is possible. I did some preliminary
experiments (on a 2600 Jr) at some point, and I seem to
remember having some success.
So the key is that HMove is only effective during HBlank period. The existing code makes it happen during the entire scanline. Normally this is inconsequential since HMove ends correctly, but during this glitchy case it needs to be taken into account. Doing so gives the correct pattern, as can be seen in the video below.
Link to video
This still isn't quite the end of the story though. It seems there are some analog effects happening with the timer pulses using the same line, I don't think those have been effectively documented anywhere so this might be the as far as things go for a while. On the up side this is a proper implementation and should be correct. It still doesn't look like Stella, but at this point I'm not sure exactly why Stella uses the exact pattern it does.
I have updated my code in the github to reflect all current changes.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Well I have a possible solution that correctly displays cosmic Ark stars.
The problem was that the TIA code was looping the _Hmove counter instead of just resetting it after it reached 15. The effect of this is that the latch that normally would never would be cleared would just be cleared on the next pass of the counter. This prevented the stars from forming.
This 'fix' breaks DK JR though (well, in a different way) so I'll be consulting with micro500 to work out what's happening. I'm pretty sure the overall idea is correct though.
Here is a brief video though:
Link to video
Perhaps we are close to getting the star effect in a real non-hackish way!
EDIT: found the bug the messes up DK JR
if (_hmove.HMoveDelayCnt < 6)
{
_hmove.HMoveDelayCnt++;
}
if (_hmove.HMoveDelayCnt == 6)
{
_hmove.HMoveDelayCnt++;
_hmove.HMoveCnt = 0;
_hmove.DecCntEnabled = true;
Those 6's should be 5's. This 1 extra clock delay is what's breaking DK JR.
The stars still don't display exactly as expected so more research is needed there, but things seem to be shaping up.
EDIT2: I forked all my changes into github here: https://github.com/alyosha-tas/BizHawk
This contains the fixes for pterry, the ENAM fix, the starfield, DK jr fix, 3-2-1 fix.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
So I happened across an emulator bug that might hopefully also shed light on Cosmic Arc stars and properly emulating quirky HMove instructions.
I was browsing other Atari 2600 games that were known to behave badly in BizHawk looking at the list here. I looked at Donkey Kong Jr since it had some weird gameplay bug listed as the error.
The picture below is 4 consecutive movement frames. On frame 3 you can see quite clearly that DK gets pushed to the left rather far before snapping back to the right the next time.
What's happening here is (I think) related to the warning not to change HMove registers until 24 CPU cycles after HMove is executed, here is the relevant code:
So what we have is an HMove immediately following a WSYNC, this is the expected behavior, but then we have only 22 cycles in between that and the following HMP0 instead of the expected 24.
Quoting hardware notes we have:
In theory then the side effects of modifying the HMxx registers
during HMOVE should be quite straight-forward. If the internal
counter has not yet reached the value in HMxx, a new value greater
than this (in 0-15 terms) will work normally. Conversely, if
the counter has already reached the value in HMxx, new values
will have no effect because the latch will have been cleared.
Much more interesting is this: if the counter has not yet
reached the value in HMxx (or has reached it but not yet
commited the comparison) and a value with at least one bit
in common with all remaining internal counter states is
written (zeros or ones), the stopping condition will never be
reached and the object will be moved a full 15 pixels left.
In addition to this, the HMOVE will complete without clearing
the "more movement required" latch, and so will continue to send
an additional clock signal every 4 CLK (during visible and
non-visible parts of the scanline) until another HMOVE operation
clears the latch. The HMCLR command does not reset these latches.
This shove to the left only happens here when HMP0 is 7, the same code is obviously running constantly but only this value makes the big shove to the left happen.
Stella seems to cheat in this case and instantly applies the HMOVE and ignores how long actual execution should take.
This shove to the left doesn't happen on console (and makes the game unwinnable in BizHawk) so sorting this out seems like a good step in understanding this HMove stuff.
Either that or it's a simple bug that I just can't see yet.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
CoolKirby wrote:
I can confirm that the double sized player bug did not affect the sync of the published E.T.: The Extra-Terrestrial run. (The run does not sync on BizHawk 1.7.0 or later as it is though.)
I want to say thank you for fixing all those tough bugs - I was thinking of running Halo 2600 several months ago and now it should finally be possible.
Will your fixes be implemented into the next BizHawk?
Not sure, once micro500 or some other knowledgeable person confirms these findings are correct, it's easy to fix a few of the bugs just by changing some constants. The latch delay type bugs are more difficult though will probably take some time to sort everything out. Halo 2600 should work with the easy fixes though.
Yeah any run like E.T. made before the switch to fixed length frames / inputs will be difficult to reconcile with any new runs made. I thought about making some test runs but currently don't have the time.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
While I'm not an expert, I don't think Mari/o is strong enough to do anything serious like that. It's fine for a sandbox model but you won't get anything particularly impressive out of it for complex games like SMW.
If I were to offer a suggestion that would both seem doable and be impressive, I would suggest SNES Star Fox. The existing run is woefully obsolete just by nature of the emulator used, and the gameplay lends itself more to the Mari/o methodology.
However this would require a great deal of research, I guess it depends how much effort you want to put into it.
Yeah sorry but I won't be able to commit to finishing this for at least the next several months. Normally I hate leaving things open ended so I at least wanted to have that complete WIP out, but beyond that it's up to you! (and possibly Samsara!)
Good Luck!
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
http://tasvideos.org/userfiles/info/29591466236789461
Well it seems I've run a bit short on time so won't be able to commit much more to this. I've created this run that goes to the end of the game (and saves 30 frames on the boss.)
Level 10 and 11 were pretty trivial from TAS perspective so nothing really changed there. Terra Tubes seems pretty well optimized since I couldn't do anything about checkpoints in my testing. The final level seemed really well optimized too so I just synced it up.
@feos: if you plan on working with that trick you found feel free to use this file. If you think it will take too long I might just submit this one by week's end and leave it for future improvements (perhaps including it on the next iteration of the run with a goal to sync on console.)
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Wow you're right! Definitely something that needs further investigation.
EDIT: so far level 3 and 4 have easy improvements related to this trick. Looks like some back tracking needs to be done. This is quite a strange and random trick, I might try putting this in BizHawk and confirming it works the same.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
http://tasvideos.org/userfiles/info/29553178600016834
Alright, so I saved another ~20 frames on the snakes, cleaned up the jets level, and implemented the jump through the current improvements in the tower (as well as fixed the boss fight.) Overall saved about another second.
I think we're ready to start investigating Terra Tubes!
For starters I looked at the fish knocking you into the exit thing, and it seems the exit won't spawn until after the helicopters have already spawned. After that the fish would need to hit you into the spikes to get you through the wall and down into the exit, but this would require scrolling back down a significant ways and probably wouldn't save time since you just fall down anyway.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Nice run.
I played this when I was little and remember being tricked by those cats that hide behind the items, but it was pretty fun for a simple and kind of silly game.
Oh one interesting thing I found out while looking at the code of this one is that the score is actually stored in Decimal and goes up to 99 milliom before rolling over, so anyone wanting to make a max score run would be playing for quite a while!
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I have finally found where the desync happens. Turns out it is very similar in nature to the title screen bug.
What is happening is that the write to Enable Missile for Player 1 (ENAM1) is happening on the same pixel as it is supposed to be drawn. In BizHawk, we get an immediate draw, but in Stella we get a one pixel delay in registering the write. In this case the one pixel delay causes the collision with Pterry 1 frame earlier (since the effect is shifting the missile down one scanline) and this is where the desync happens.
I implemented the delay and indeed lost in BizHawk in exactly the same manner as in Stella, 8-10
For this case I couldn't find any documentation I could quote, so micro500 will need to weigh in here, but this is the cause and effect anyway.
With the implementation of PRG write delays, many graphical bugs are now fixed (such as the 'O' in power in H.E.R.O. above. )
This fix also correctly implements PRG delays due to HMOVE, which is what the hacked in original 3-2-1 code was trying to do.
This also fixes the rather annoying house moving bug in River Raid.
At this point pretty much all graphical bugs should be fixed.
So I have finally fixed the original bug that got me interested in all of this. This implements the same play field delays that Stella uses. While I don't understand why they would be true at a low level, they none the less have high compatibility and I haven't seen any deficiencies in my testing.
What's happening here is (I think) related to the warning not to change HMove registers until 24 CPU cycles after HMove is executed, here is the relevant code: