Blazephlozard
He/Him
Banned User
Joined: 2/27/2013
Posts: 175
Location: Ohio
Hmm, so 0x81D0 turns into the neutral being 1D... where does the 8 go @_@ I used my GBC to attempt to find maximum Y values as opposed to X values, since those are more important. My Y results on GBC are: 29/40 (almost entirely 29/80s and above), 37/00 (approximate neutral), 44/A0 (mostly 44/80s and below, only a few 90/A0 seen in multiple attempts) Decimal: 29 = 41, 37 = 55, 44 = 68 The "flicking" that can happen to produce brief oddities may be responsible for the outliers, I think it's safe to go with 41.5, 55, 68.5 based on how prevalent 80 subvalues were. Or very very slightly more, because I surely wasnt EXACTLY at 90 degrees during these tests. And luckily, 41.5, 55, 68.5 are all 13.5 units apart! I was really hoping for an even spread. So, I believe BizHawk should aim for a 13.5 (or very slightly higher) unit range as well. Currently its range is 7.8125. If 7.8125 = 125 then 13.5 = 216. Perhaps round to 220 range. Neutral value would have to increase, otherwise an underflow with cruise control is quite likely. If 0x8370 makes the average 37, that'd be neat And of course, this is all based on my cart, it is possible other carts are different.
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3826)
Joined: 11/30/2014
Posts: 2834
Location: US
Alright neutral value is changed to 0x8370 and range is increased to 220. I'm working on getting my own cart to test as well.
Blazephlozard
He/Him
Banned User
Joined: 2/27/2013
Posts: 175
Location: Ohio
Alright, the values are quite accurate now for Y. (And cruise control is still going to be a thing... They really didn't put a cap on this acceleration...) As a test I tried max cruise control on emu and console, BizHawk's FFF5/FFF6 = 0D/C0, console = 0E/C0, but of course console wasn't perfectly 90 degrees both ways. And I think the range can be slightly lower. I also thoroughly tested the effect that max Y rotation has on the X coordinate and it seems close enough. Max Y at this point completely nullifies the X value, but that seems to match up quite close with cart, especially if the range is lowered slightly. I'll look more into this with 216 range, as our ability to move horizontally while keeping Y tilt high is very important in the TAS. Looking more into 'flicking' as best I can, I think the outliers in my maximums were definitely due to slight decreases in angle resulting in a one frame increase in the value. I gently wiggled my cart in the -90 area and managed to see a 45/20. BizHawk test: going from -90 to -85 to -90: one frame of 46/10, one frame of 43/60. Going from -90 to 0 to -90: 4F/80, 2C/30 I was hoping if I can re-freeze the game quick enough, I may be able to see the effects that switching from -90 to 0 have on the cart in the 31-frame calibration buffer. Unfortunately, freezing doesn't seem to cause any wild jumps. I have 38 one frame, and 44/80 the next. On Bizhawk I'd have a frame of far lower than 38 before it bounces back. So this is a physical real-world real-time effect the accelerometer has? Well, that makes it impossible to test large changes occurring in only one frame. But I tried a wild rocking back and forth (probably 30 degrees each way?) and I'll just list my values: 38/A0, 3D/80, 45/C0, 4C/50, 4F/10, 48/10, 3B/E0, 34/60, 37/00, 41/B0, 49/F0, 4E/90, 4B/50, 44/90, 3E/90, 3E/A0, 44/50, 45/20, 44/50, and more 44's (stabilization while pressing my freeze button likely) So, the highest seen was 4F/10. And it can dip all the way down to 34 briefly. Tried a similar thing my moving my stick up to up-mid in recording mode: Overall I can't speak to the accuracy of your code, only the range; the range looks to actually be too low. I see 49 max, and 90 -> 0 reaches the 4F that cart can do within 30 degrees. (A higher range would make the 90 -> 0 number get even more extreme, but, it is a superhuman tilt to make in one frame! So maybe that's good that it'd be even more extreme! I don't know!) So tl;dr: I think there are still three things to work on. One is, the range may be better off at the 216 exactly. The outliers above 80 subvalue were almost definitely due to flicking, and shouldn't be consistently obtainable. Currently 44/80 requires -78 angle in Bizhawk, and I'm sure I was holding my cart at higher than -78 to get a 44/80 average. One is the desyncing when flicking from max to neutral and reloading savestates. I am not sure how easy to do, but however many prior inputs are used to calculate new ones, loading a state would have to jump back that many extra frames. And perhaps the flicking code needs to affect the number more...
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3826)
Joined: 11/30/2014
Posts: 2834
Location: US
Ok, range changed to 216. Fixed savestates, I was missing a variable, should be good to go now. The flicking part of the code is wrong, I'll fix it once the static cases are nailed down.
Blazephlozard
He/Him
Banned User
Joined: 2/27/2013
Posts: 175
Location: Ohio
OK, I'll test the affect Y has on X now. I will try 90 degree X/Y pairs at FFF3/FFF5 on console and see how the X/Y pairs on Bizhawk compare, although neither will be exactly at 90 on cart: (no tilt ideally): 38/00, 37/00 for reference (no Y tilt): 45/80, 37/00 attempts to tilt (higher than 38 x desired) 37/40, 44/40 36/70, 44/40 38/30, 44/80 37/C0, 44/70 39/80, 44/60 38/90, 44/60 So, it's really all over the place, some even dipping below neutral despite being at a 90 degree angle. Some of this variance could be due to the flicking mechanic. Currently at max -90 degrees for both in Biz, you get 37/10, 44/80. But, -85 on vertical gives 38/30, 44/80. No loss in vertical, but a comparable X value to what I could see on console. (In fact, an exact match to my third test. Well, except that 38/30 in biz really means 39/30 on my cart) I wanted to test a 45 degree angle for Y, it's hard to say if I'm at 45 degrees exactly, but I'm getting around 40 value at 45 degrees on cart. Biz has 40/90 so that seems pretty spot on as far as the distribution of values from 0-90 goes. Cart high X mid Y tests: 3A/70, 3F/A0 3A/D0, 40/30 38/E0, 41/10 Bizhawk at -90/-45 gives 40/90, 40/90 for both. So, it seems like the X should (sadly) be more reduced by Y. The flicking seems very difficult to code since I don't think it's IN the code (based on it not occurring when freezing the game and resuming at a different tilt). This really is a complicated thing to try to emulate, compared to an analog stick sending its raw values. And unlike flooding controller registers thousands of times a frame, which just works, it's impossible to say the effect that superhuman tilting would actually have on the game. Since it can temporarily give values higher than one can get at a steady angle, it actually has potential use for brief extra acceleration (especially since keeping max accel barely takes any tilt, so like, you could go from -90 to -80 to -70, get frames of higher tilt value to reach 2px faster, then keep the -70 to avoid the frame of lower tilt value). So I want to feel confident in its accuracy as well. What idea do you have in mind for it? I'm thinking it may be a good idea to have a maximum limit in the flicking code, because I wouldn't want to use a -90 to 0 flick, because it's impossible to prove if the effect that'd have on the tilt value in emulator is actually accurate to console; I'd say it falls under abusing emulator inaccuracy. Of course, in the end of all this, it's not like this is for console verification, so it'd be okay regardless. As long as none of this is touched once it's finalized, it's an even playing field. And then dekutony can come out of hiding :P
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3826)
Joined: 11/30/2014
Posts: 2834
Location: US
90 degree per frame is pretty fast, a back of the envelope calculation puts that at about 20 - 40x gravity. But limiting user input would be quite a big departure from standard practice. I think a human could do 1/3 of that (30 degree per frame.) I'm not sure what a robot or something could rotate at, but 90 degree per frame (or 700 RPM or so) doesn't sound impossible. Overall I'm not inclined to limit user input automatically. EDIT: Oh, but Blazephlozard is banned now I see. I'll still be doing physical testing on my own end, maybe starting next week, it would be nice to finalize this for stability.
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3826)
Joined: 11/30/2014
Posts: 2834
Location: US
I updated the control scheme based on my own testing. Barring something demonstrably wrong, this is the last time I'll update it, so anything made now should work with 2.5 when it's released.
Skilled player (1742)
Joined: 9/17/2009
Posts: 4986
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3826)
Joined: 11/30/2014
Posts: 2834
Location: US
Do all the up and right presses do anything? Or are you just button mashing?
Experienced player (691)
Joined: 11/23/2013
Posts: 2238
Location: Guatemala
jlun2 wrote:
Skipping the robot guards during the boss stages.
That's a pretty cool discovery. http://tasvideos.org/userfiles/info/65593981198691761 Here's the lua script for this game. I don't think it was ever uploaded to userfiles.
Here, my YouTube channel: http://www.youtube.com/user/dekutony
Skilled player (1742)
Joined: 9/17/2009
Posts: 4986
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"
Alyosha wrote:
Do all the up and right presses do anything? Or are you just button mashing?
Nope; I just binded both the dpad with the same controls as motion for convenience. I also managed to do this trick once with a single jump (the robots hopped as I land, then I clipped in), so it should be faster than normal for some switches. Om 4-4 I think, I accidentally got this warp star to vanish somehow, but I wasn't recording. Not sure if I would encounter missing objects again tho, so posting it here:
dekutony wrote:
jlun2 wrote:
Skipping the robot guards during the boss stages.
That's a pretty cool discovery. http://tasvideos.org/userfiles/info/65593981198691761 Here's the lua script for this game. I don't think it was ever uploaded to userfiles.
Thanks. Since it's not in the script, for U, 0x0194 in WRAM is stage ID. If anyone wants to attempt 100%, I just tried playing through it; you need to grab all red stars on BOTH normal mode, which unlocks hard mode, then do the same again on hard mode. After the 1st run through, you need to go through the credits for the game to save, so if anyone wants to do a 100% run they might need to time both U & J credits length.
Joined: 9/11/2020
Posts: 2
figure id post my findings here since you gave me the ideas. it seems you can pass directly through the center of the robots. you can also use this same trick to do early keygrabs Link to video Link to video
Skilled player (1742)
Joined: 9/17/2009
Posts: 4986
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"
Nice discovery! If possible, can you please provide input files for that? I found it really hard to reproduce. If you or anyone have an ideas of skips, please post.
Joined: 9/11/2020
Posts: 2
i am an rta runner so this was done on console, sorry. maybe someday ill finally set up emulator for this game. also not really sure about skips aside from those 2, but i think you could get some nice speed boosts if you can use this to get under bumpers and have them push you out the other side