Experienced Forum User, Published Author, Expert player
(3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
MESHUGGAH wrote:
So the game really changes the Y subposition every frame? I don't understand the logic behind doing this.
Yup, the value increases by 51 every frame which is the minimum y-speed when falling of a platform. For more details, read the subpixel paragraph in my Chip 'n' Dale submission. Replace 85 with 51 and 171 with 205. Thus, in this game, 205 is the best y-subpixel value to jump from if you're looking for the highest jump height.
Experienced Forum User, Published Author, Expert player
(3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
MESHUGGAH wrote:
I can verify that jumping at different times (on the same position for the same length) can make a different maximum jumping height. Jumping height also changes depending on previous jumping. This is shown in my demonstration.
Also note that the lua script doesn't shows the "correct" Y pos nor the Y sub position. This is because I can't calculate it. Since the only thing I found is the subroutine I added to the post, I can't really understand how would your description should match the debugged information even if I take away the Y sub 2 from the calculation (I mean that I'm not really sure about my theory either).
edit: the memory values again:
0x07C0 - the vertical boost, jumping makes it 4...3..2...
0x07B0 - Y sub 1, changes only when you jump. Values like -120, 35, 84...
0x0660 - Y sub 2 at least what I think. Changes everytime during the in-game frames. -102, 68, -17...
0x0640 - Y position. 180, 175, 171...
0x07B0 and 0x660 starts the very same pattern similar but in different direction. 660 starts with 51, -103, 50 while 7B0 starts with -51, -102, 103.
Well just as Ans pointed out, one Y sub is for position (0x0660) and the other is for speed (0x07B0), which explains the misunderstanding. Think about that the position should be unsigned to make it easier to read.
Experienced Forum User, Published Author, Expert player
(3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
The reason why it desyncs is this:
In your run at frame 7346 (the frame before you jump) your y-subpixel value is 108. If you do a jump at frame 7327 before this your y-subpixel value at frame 7346 will be 88. In your run this will result in a y peak position of 167.7 while the peak position in the other case naturally is 166.243, your position thus gets pushed to 167.51 while in the other it get pushed to 166.51 meaning that you'll reach position 180 (the one required for you to land) 1 frame earlier and thus it desyncs. Still can't see where those extra subpixels show up, other than if you simply look at this in a completely different way. I'm quite a lot more old-school than you for example :)
Experienced Forum User, Published Author, Expert player
(3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
MESHUGGAH wrote:
It exists as the debugged information shows. You can easily verify this by doing 2 little jumps in a row. If you remove the 1st jump, the 2nd jump's vertical boost (and it's total height depending on the delay between the 2 jumps) will be changed.
If Y sub 1 wouldn't change all the (in-game) time, every jump on the same platform would be equally high and would have the same boost. Currently I'm sticking to brute forcing all jump possibilities whenever I need to be higher or lower.
Still seems very consistent to me after testing. Jumping twice makes the peak of jumps to be only the difference between the y-subpixel values before each jump. You probably know what you're talking about though, just that the two of us most likely have very different ways to analyse a situation like this :)
Something new to me while testing this was that when not doing a full jump, the y-position is set to the start of the pixel where you released the "a" button plus 51 subpixels.
Experienced Forum User, Published Author, Expert player
(3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
I also started an improvement of this myself long ago, but put it aside and never got back into. Here it is, though I doubt it's better than yours. Feel free to finish the project.
The constant y-subpixel change on ground is basically the same as in Chip 'n' Dale, with the difference of increasing 51 every frame instead of 85. I don't think there exist such things as a second set of subpixels though. as far as I recall the y-subpixels in air can only be changed by having different y-subpixels before jumping/falling.
Experienced Forum User, Published Author, Expert player
(3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
feeuzz22 wrote:
Aglar wrote:
WST wrote:
By the way, here is my last job.
So feeuzz didn't show you my short take on this act that I sent to him, like 2 months ago, to help you?
You prefer we just copy your input? ^^
I prefer if you take some learnings from the runs I send you, and apply it to your own runs. If a certain situation ends up not being any faster it's not much of a big deal as long as you've put some effort in trying do it as fast as you can and understand the reason for why it's as fast as possible (something which I doubt is the case in the run I sent).
Experienced Forum User, Published Author, Expert player
(3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
The description says the previous run was improved by 1:23.06, while it should be 1:39.84 due to PAL timing.
Ferret Warlord wrote:
I'm sure it's been discussed and tried already, but is it at all possible to pick up Shades' weapon without Shades? If the weapon switching trick works with any weapon, I'd think that would save loads of time since you wouldn't have to get Gil's.
The only problem is that after you've destroyed a set of blocks and go to the selection screen to change back to Shades the blocks that were destroyed will come back, thus making it impossible to break the lower of 2 vertically connectiong set of blocks.
Experienced Forum User, Published Author, Expert player
(3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
WST wrote:
Well, then I got another question. This game was TASed by nitsuja, you, Sonikkustar and many others very experienced TASers, why didn’t anyone try so obvious thing before?
We're all humans who occasionally overlook things.
Experienced Forum User, Published Author, Expert player
(3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
So the journey towards a new TAS has started...
WST wrote:
How you aligned yourself perfectly? And how the hell you tricked the air speed cap?
He performs a so called double jump (only possible with Sonic or Knuckles here I'm quite sure) where he lands immediately after the first one and then directly jumps again and thereby get two boosts, where the second one is very powerful. He kept the speed in air simply by hitting the ceiling.
Experienced Forum User, Published Author, Expert player
(3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
feos wrote:
Aglar, any plans to improve Batman?
Of course not, he's Batman!
Well, not now at least - don't really feel ready to move to another global timer game right away. I plan to continue on a speedy sega game anyway.
Experienced Forum User, Published Author, Expert player
(3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
Oops, I forgot to put all rerecord counts together as they are spread out over many files. I'll link to a run with the right amount of rerecords later for a moderator to replace it.
Experienced Forum User, Published Author, Expert player
(3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
I'm certainly not surprised you were able to take the game to such an incredible level. Your IL TAS of MZ2 already showed it as it was certainly something that not anybody would come up with. Biggest surprise was the creative way using the wheels in SBZ2, LBZ3 shouldv'e been even bigger but I looked at the time before watching the run and expected the zip to be there. I'm definitely not sure I would've matched this time if I'd given it another go - deeply impressed about your precision work!
For the acts where you didn't gain any time I suppose you at least tried to - except for maybe MZ1 and SLZ1? In that case I guess you gained some pixels/subpixels but it wasn't enough to save any frame?
This also makes the no-zip run even more worthwhile, hope you'll take on that as well - you'll have a fun time with it:) Though one might have to change the rules for it slighty as one can now level-wrap in SBZ2 without using zips so banning level wraps would pretty much be a must as it's supposed to be a kind of low-glitch run.
Great job once again, and hope this is only the start of an awesome TASing career.
Experienced Forum User, Published Author, Expert player
(3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
HDL wrote:
Keep in mind that jump and flight timing will always vary in real time.
Yeah, that's why I suggested that particular way as it leaves quite some margin for different inputs to occur while still being able to work. A test showed that there's at least 70 y-pixel positions that Tails can be at when the trick succeeds (y-positions 915-975 if you watch it using the lua HUD, then then there's some pixels in the range of about 906-914 that won't work if your y-speed downwards is too low, then the pixels 888-905 will also work). Remember that holding 'right' just as you have shifted to the boss room is a must. Try performing it on emulator with frameadvance and use the lua HUD to watch your position.
I could give some more info about how it works exactly, but it wouldn't really be that relevant for RTA:s. If you really want it I can ask marzojr to do some deeper research though.
Experienced Forum User, Published Author, Expert player
(3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
HDL wrote:
I want to know if anything can be done to consistently manipulate it.
I had a discussion with you about this before, where I proposed a strategy where you stand on the flat ground to the left of the tube in the loop-back area and wait for the camera to get to a certain position, then start mashing the jump buttons while holding right. I retried this strat now and it works basically every time, though I don't remember if the position of the camera for when to jump is same as I said back then. So you should jump and mash the buttons and hold right when the camera reaches somewhere inside the blue rectangle here: http://i.imgur.com/9N3lelw.jpg
So quite some margin actually. You can try to see which position that works best for you, though aiming for the middle part should be the safest.
And for you who don't know what level-wrap HDL was talking about:
Link to video
Experienced Forum User, Published Author, Expert player
(3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
andrewg wrote:
Curious how I did this slow throw. I tried to mimic it, and couldn't. I have an idea for a possible improvement if this could be duplicated (or done with any object/enemy).
What happens is an instance of the invisible enemy glitch (the one we never found out exactly how it worked). You pick up the veggy and throw it while crouching which makes it hit the invisible shyguy.
Experienced Forum User, Published Author, Expert player
(3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
Mr_Sweed wrote:
Hello. Another route. Maybe it's faster or maybe it's slower. I I used the previously run by MarzoJr to add in this. Enjoy this wip & demo!
YouTube link: https://www.youtube.com/watch?v=TuuSwjYQ1C8
//Regards DMTM aka Mr_Sweed
Looks like I was expecting. In order for us to use it in the run, 20 seconds need to be saved from this which is rather doubtful. Though, the big thing about this is that it can be done at all.
Experienced Forum User, Published Author, Expert player
(3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
Mr_Sweed wrote:
I found the route to skip the boss fight...
Nice work. It would save some real time, but not any in-game time unless one could come up with a faster method to set it up. Could be worth looking further into.
Yes it works, nice find Hotarubi! It saves 38 frames if inserted at the end of my run. I don't think I'll submit right away though as I can just as well take this opportunity to look for other minor improvements.
Experienced Forum User, Published Author, Expert player
(3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
WST wrote:
Friends, I got a question (usually used to ask marzojr such questions, but now cannot contact him for some reason).
Is there a bit in memory, indicating if Sonic is staying or ducking?
When Sonic ducks, the counter at address $FFF66D starts to increment (from zero) by 1 every frame until it reaches 120 - that's when the screen starts to scroll down. So in some way if this adress has a value > 0 then Sonic ducks as the counter resets to 0 if you stand up again; however if you spindash the counter doesn't reset right away and instead waits until Sonic is in a non-rolling/non-ducking state. Depending on what you will use this for there should be ways to work around it though. Or just try to find a better indicator yourself, as this isn't my expertise. :)
Experienced Forum User, Published Author, Expert player
(3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
andrewg wrote:
He said he holds "right" the entire time he does this. I find it odd because I've never done this. I know that holding "left" right when you reach a wall usually sucks you into it, however, I've never seen someone go any distance into the wall while holding "right."
This is a bit interesting. I always thought that walljumps were always a 1 frame trick. But I guess if you position right, you can have 2 frames to get it? I'm testing on emulator, and I can't seem to mimic Kosmic's 8-4 walljump.
Really, I'm just curious how he could have gotten into the wall if he was holding "right" the entire time. Maybe the positioning has to be perfect?
In order to perform a wall jump you must, aside from being at the same y-pixel as the wall block you're landing on, be at least 1 pixel inside the wall.
In this case it means having an x-pixel position of at least 115 to have frame to do it, or 116 to have 2 frames to do the wall jump. The wall collision detection routine is called when you reach at least that 115 x-pos and pushes you back 1 pixel / frame - starting immediately, meaning that if you get to x-pos 115 you won't be able to wall jump at all since you're directly pulled back to 114. You move at a speed of 2.5 pixels / frame so in order to reach that 116 x-pos you must, on the frame before hitting the wall, have an x-pos of at least 114 pixels and 128 subpixels (which would for a fraction of a frame put you at x-pos 117 but later at the same frame pull you back to 116).
Here's an fm2 of it:
http://dehacked.2y.net/microstorage.php/info/934806167/Super%20Mario%20Bros%20%28JU%29%20%28PRG%200%29walljump.fm2
Experienced Forum User, Published Author, Expert player
(3588)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
andrewg wrote:
http://www.youtube.com/watch?v=EIXIXk6oq4A
How can he be facing backwards, but walljump facing to the right? Ive never seen this happen, but he says it happens frequently.
Apparently, walljumping the first frame you "land on the wall" will still make you face backwards, but if you jump one frame later than that (requires that you get quite a bit inside the wall) you'll turn direction to whichever you're pressing at the moment.
