Topic by dekutony

Posted: 4/10/2018 1:30 AM
(Edited: 6/30/2020 6:37 AM)

Post subject: Kirby Tilt 'n' Tumble

Quote

dekutony

Experienced player (630)

Joined: 11/23/2013
Posts: 2208
Location: Guatemala

I didn't see a thread for this game, so I'm making one now.

Kirby's Tilt 'n Tumble TAS by ism in 16'17''65 Part 1 Part2

And the current RTA WR: Link to video Former WR: https://www.speedrun.com/ktnt/run/dy4ekdqm Some blog posts from the author: http://ism140.blog.shinobi.jp/%E3%82%AB%E3%83%BC%E3%83%93%E3%82%A3/?pageNo=3 http://ism140.blog.shinobi.jp/%E3%82%AB%E3%83%BC%E3%83%93%E3%82%A3/?pageNo=2 http://ism140.blog.shinobi.jp/%E3%82%AB%E3%83%BC%E3%83%93%E3%82%A3/?pageNo=1 And commentary on the TAS: http://ism.harisen.jp/zakki/kkirby.html

Here, my YouTube channel: http://www.youtube.com/user/dekutony

Posted: 6/26/2018 11:53 PM

Quote

dekutony

Experienced player (630)

Joined: 11/23/2013
Posts: 2208
Location: Guatemala

After a little while, I can finally TAS this game properly. Currently starting on the first level. It's gonna take me a while to optimize it, and improve the old one. Old thing I did to test the core: http://tasvideos.org/userfiles/info/47518336021050499 Right now I slipped up at the beggining, so I'm redoing that part... :P

Here, my YouTube channel: http://www.youtube.com/user/dekutony

Posted: 8/30/2018 7:15 AM

Quote

dekutony

Experienced player (630)

Joined: 11/23/2013
Posts: 2208
Location: Guatemala

ALLRIGHT! I took a break from TASing but here's the first level: http://tasvideos.org/userfiles/info/49501524548555316 I did not anticipate this TAS would be a big challenge, but it is very satisfying. The movement looks smoother and I land on the clouds earlier than the old TAS. EDIT: Resynced the wip to the newest bizhawk http://tasvideos.org/userfiles/info/64353734171226348

Here, my YouTube channel: http://www.youtube.com/user/dekutony

Posted: 6/30/2020 9:00 AM

Quote

Blazephlozard

He/Him

Banned User

Joined: 2/27/2013
Posts: 175
Location: Ohio

Augh, I can't do much of anything in this game, I don't know what I'm doing wrong or if I need a newer version but I'm desyncing like crazy in tastudio on 2.4.1. I can't even get you any kind of input file. X/Y/Z position are at FFA5/A8/AB. (Two bytes, plus a subpixel byte) X/Y/Z speed at FFD2/D4/D6, but I don't find them very useful, they aren't very accurate to your actual progress especially when your position locks to an object (like a cloud or such) Vertical speed caps at 2px per frame. If you move horizontally more than 6 or -6, your vertical speed will suffer a bit. Here's a Lua script that displays X/Y/Z position and difference from previous frame. I've added a coloring to the Y position that's basically, green if it's faster than it's ever seen before, red if it's slower than it's seen before (and white if it's a new frame or matches). This is really useful for quickly gathering at a glance if the changes you've made (like reducing horizontal movement to increase Y speed) actually are an improvement or not. https://pastebin.com/C3MBTPB4 I think I was able to save 2 frames on the first rightward turn in the first level by reducing the rightward 45s to gain a bit of Y distance. But I clear the greenzone and it desyncs oh well. But here's something interesting too! I was thinking that the initial acceleration to -2 is very slow. Jumping actually has faster acceleration! So start the level with a jump! You do go slower for a bit once you land, but it still saves some pixels. I'd be somewhat interested in collaborating with you, if I could get this desync nonsense sorted out...

Posted: 7/1/2020 4:44 AM

Quote

dekutony

Experienced player (630)

Joined: 11/23/2013
Posts: 2208
Location: Guatemala

Thank you so much for this. This was really useful. I managed to save 8 frames over my previous wip: http://tasvideos.org/userfiles/info/64398659505545337 Yeah, I don't know whats going on with this game and it not syncing or working very well with tas studio, but when it does work it works so thats cool i guess.

Here, my YouTube channel: http://www.youtube.com/user/dekutony

Posted: 7/1/2020 3:24 PM

Quote

Alyosha

He/Him

Editor, Expert player (3522)

Joined: 11/30/2014
Posts: 2728
Location: US

Please report problems with desyncs, and use the current dev build. Make sure you are all using the same version so it's definitely narrowed down to a TAStudio (i.e. savestate) problem and not just an emulation change.

Posted: 7/1/2020 3:28 PM

Quote

Blazephlozard

He/Him

Banned User

Joined: 2/27/2013
Posts: 175
Location: Ohio

Alyosha wrote:

Please report problems with desyncs, and use the current dev build. Make sure you are all using the same version so it's definitely narrowed down to a TAStudio (i.e. savestate) problem and not just an emulation change.

Yeah, I was going to check out his WIP in the dev build and report anything if it was still there, cause I do want this game to work well. If I load his movie into tastudio in dev build, with no pre-existing savestates, and sync to the end of level 1, that would eliminate version diff / emulation change as the issue, right?

Posted: 7/1/2020 3:39 PM

Quote

Alyosha

He/Him

Editor, Expert player (3522)

Joined: 11/30/2014
Posts: 2728
Location: US

Blazephlozard wrote:

Alyosha wrote:
Please report problems with desyncs, and use the current dev build. Make sure you are all using the same version so it's definitely narrowed down to a TAStudio (i.e. savestate) problem and not just an emulation change.
Yeah, I was going to check out his WIP in the dev build and report anything if it was still there, cause I do want this game to work well. If I load his movie into tastudio in dev build, with no pre-existing savestates, and sync to the end of level 1, that would eliminate version diff / emulation change as the issue, right?

Yeah, and I don't think dev will change again in terms of emulation before the next release, so that should give you some stability.

Posted: 7/1/2020 9:27 PM

Quote

dekutony

Experienced player (630)

Joined: 11/23/2013
Posts: 2208
Location: Guatemala

My concern about this is that if that's ok to do when I plan to submit this movie after I finish it. Didn't the rules say something about not using dev builds to make the TAS for submissions? Would it sync on a release build?

Here, my YouTube channel: http://www.youtube.com/user/dekutony

Posted: 7/1/2020 9:48 PM

Quote

Blazephlozard

He/Him

Banned User

Joined: 2/27/2013
Posts: 175
Location: Ohio

Your level 1 appears to have synced perfectly on the dev build, so it's fairly safe to assume anything made in the dev build would also sync on an official version. (Or probably easy to resync if needed. Or wait for the next release if really needed.) Well, I'll see if it has improved tastudio stability when I get home. This is the version I'll be trying: https://ci.appveyor.com/project/zeromus/bizhawk-udexo/builds/33841544/artifacts

Posted: 7/2/2020 4:40 AM

Quote

dekutony

Experienced player (630)

Joined: 11/23/2013
Posts: 2208
Location: Guatemala

http://tasvideos.org/userfiles/info/64420550550599130 Finished the second level on the dev build you just linked. It seems that I can't fall earlier after I grab the balloon, and that 15 second timer doesn't help. I think the old TAS slows kirb down to make it look better?

Here, my YouTube channel: http://www.youtube.com/user/dekutony

Posted: 7/2/2020 7:48 AM

Quote

Blazephlozard

He/Him

Banned User

Joined: 2/27/2013
Posts: 175
Location: Ohio

Small time save in level 1: There is serious lag when jumping onto the cloud at frame 1470ish. Note in the old TAS how he moved the camera with the directional buttons; this was lag reduction. So keep this in mind any time you jump at a position that causes a lot of action (tile/bumper flips and such). As his notes say, this camera control can also be used to begin certain platform cycles earlier. I also noted two lag frames at 1706/1707, caused by the checkpoint. Reducing the earlier lag happened to reduce this one to only one lag frame. Maybe it could be reduced more somehow? Let's see. Clearly I should try to display this fake lag with my Lua script. Like, D-pad input still works during this lag, I wonder if tilt sensor input does too, but, it should still get marked with code. I notice the lag affects the in-game timer; perhaps I could find the frame timer value and check if it changed this frame! Is the JP version being used for a specific reason? I see in the old TAS notes this translated bit:

・After defeating the boss on each side, it automatically goes to the warp star. In the Japanese version, you have to operate it yourself and go to the warp star, but in the overseas version it rolls around. Even if there is a hole along the way, it floats in the air. ・Is the option reversed when warping in 3-1 or 6-1? ・The behavior when touching the Gordo of 8-3 is different. When you touch the Gordo in a normal state, such as by flipping up, the Japanese version makes a big jump that jumps off the screen, but the overseas version does not have such a thing.

Sounds like JP has to move Kirby manually into the warp star; probably better than a slow auto-move. And I am curious about this 8-3 Gordo jump. (And the Whispy warps might default to No or Yes differently?) I haven't ran into desyncs in the dev build like I was, though I did also figure out an issue I was having with the cursor jumping like mad, which may have messed analog sync up in the process (but it happens on any analog inputs, so not Alyosha's problem!): https://github.com/TASVideos/BizHawk/issues/2189 That jumping back to frame 0 nonsense funnily enough led to me checking something that I had stuck in my mind but was perhaps a bit afraid to check; "cruise control"ing the tilt sensor. Setting it to 45 during the sensor check at the start of the game, making 45 equal 0, so theoretically -45 is -90. Normally on something like N64, TASing lets you put any analog values you want, even those normally outside the range of a stick that require cruise control to use on console, so I was a bit shocked to see that yes, this does actually work. Max speed is still -2, but this greatly increased acceleration. However, I have no idea what harm this might do to our ability to move. Cannot move downward anymore! Does this resync automatically between levels? Is there a quick reset for it? I gotta read the manual... But, well, this cruise control might help match the old TAS. This looks like the missing piece of the puzzle, I had these synced at the first roll frame and went forward just a few frames (old WIP vs. youtube TAS). Clear higher acceleration.

The boosted acceleration helps not just at the start but also after any jump, and probably after any diagonal movement too. We just have to figure out how hard we can cruise control, and if levels that require downward movement can be done still with an automatic recalibration. Wew I'm making this game complicated. I haven't even mentioned my plans to try to code a brute forcer to find the best possible horizontal inputs when they're needed.

Posted: 7/2/2020 9:38 AM

Quote

dekutony

Experienced player (630)

Joined: 11/23/2013
Posts: 2208
Location: Guatemala

Woa. That uh... thats a lot to take in. Welp... Anyway, regarding why I'm using the Japanese version, if you saw the RTA WR in the first post, after defeating a boss and as soon as the saving screen shows up, he resets. The Japanese title screen is faster due to the voice clip being shorter than the American version. We also reset due to the Kirby dance and the level select cutscene being slower.

Here, my YouTube channel: http://www.youtube.com/user/dekutony

Posted: 7/2/2020 9:51 AM

Quote

Blazephlozard

He/Him

Banned User

Joined: 2/27/2013
Posts: 175
Location: Ohio

Ah, I haven't watched RTA (or the full old TAS) yet! But I can picture how slow the "kir-by-tilt-n-tum-ble!" voice acting is to wait through. Trying to look into the cruise control. It's seeming like it takes an average of the tilt sensor for the previous 32 frames. So, if you press A on the first possible frame, but tilted for only a few frames before that A press, you'll be less cruise controlled than if you tilted for longer. C454 is a 32 frame timer, that sets C455 to 1 once it loops, and C455 is what lets you press A. The 32 last X results are stored in C456 to C495. Y's are C496 to C4D5. They're two bytes each, though I can't figure out any logical formula for the values you get in there... Though I have to wonder, where did this limit of 45 for the game's tilt sensor analog come from? The calibration settings seem to be stored around FFFA, so we could look there to see if they ever change, but its possible the only way to recalibrate is pressing Select, and it's very slow. But if there's midrun resets then that could help maximize usage during levels where there's no downward movement required. (...Aaaand soft-resetting doesn't go to the calibration screen. Well then.) Anyway here's updated Lua script that shows mid-level lag in tastudio, among other times in between levels (but remember that input could still be getting polled!) https://pastebin.com/Mqxp5S77

Posted: 7/2/2020 9:56 PM

Quote

Alyosha

He/Him

Editor, Expert player (3522)

Joined: 11/30/2014
Posts: 2728
Location: US

I fixed the TAStudio issue, please test to make sure there are no de-syncs or other problems.

dekutony wrote:

My concern about this is that if that's ok to do when I plan to submit this movie after I finish it. Didn't the rules say something about not using dev builds to make the TAS for submissions? Would it sync on a release build?

Given the complexity of this TAS I think it's safe to assume that there will be an official release before it's done. And yes it will sync on the release build since I'm done with emulation changes until next release (currently in testing mode.)

Posted: 7/3/2020 8:56 AM

Quote

Blazephlozard

He/Him

Banned User

Joined: 2/27/2013
Posts: 175
Location: Ohio

Thank you for your help, now analog TASing can be the regular amount of frustrating again. Recalibrating by pressing Select only costs around 127 frames, so definitely much faster than a Hard Reset, if those are the only 2 ways to recalibrate, and if a recalibration is even needed. I watched the real-time run and it seemed like its acceleration is very good, yet I think it is not cruise-controlled. So it got me wondering if this 45 range in Bizhawk is correct. I've been testing on my actual cart, and I happen to have a memory viewer device for Game Boy. Viewing in hex helped me understand the calibration bytes. The two byte pairs during calibration seem to be a main byte, which stays within a very small range centered around a certain number, and a sub byte that always ends in 0 (in hex), so only 16 possibilities for it. In Bizhawk, the values for right/neutral/left are 17/80, 1D/00, 22/90 (so 23.5, 29, 34.5ish) But in my cart, it's around 29/B0, 38/00, 45/70 (with constant slight fluctuation; basically never the same number two frames in a row) It's interesting that the neutral number is very different; is this a per-cart thing maybe? I don't know. And Bizhawk has 5.5 units it can go either way, but my cart seems to be able to go 14 units, but I don't think that means its range is THAT much higher. But, I do think, it has got to be somewhat higher. I have a possibly very smart way to test it, through the Kirby faces on the pause screen: https://imgur.com/a/O4NJIdF This is the maximum up and right values for Bizhawk and for my cart, as shown by how far Kirby peeks his head out. Both were calibrated neutral, of course. If I cruise control in Bizhawk, I can get the whole Kirby sprite that the cart can normally. So, I believe the maximum analog values should be 90 each way, instead of 45...? I am 100% sure that our movement options are not accurate to console at least. And I suspect the VBA TAS wasn't cruise-controlled either to have its acceleration.

Posted: 7/3/2020 9:15 AM

Quote

Blazephlozard

He/Him

Banned User

Joined: 2/27/2013
Posts: 175
Location: Ohio

frick it double post swordsmankirby asked if my acceleration looks like his so I figured hey let's record a video of me starting 1-1 and compare it to the other 3 videos I have of Biz/VBA/WR 1-1 starts (I just compared and yeah, I pretty much match SMK's WR off the starting line of 1-1, which pretty much matches VBA TAS) Link to video kirby goes zoom????????? this could be cartridge tilt, I tried it again and my music cut out shortly after

Posted: 7/3/2020 1:54 PM

Quote

Alyosha

He/Him

Editor, Expert player (3522)

Joined: 11/30/2014
Posts: 2728
Location: US

About how many degrees do you have to tilt your cart to get that acceleration? I can increase the range to 90, but I assumed that the game devs didn't want people to have to tilt the gameboy 90 degrees down and away from them to get the fastest speed. I can also increase the sensitivity.

Posted: 7/3/2020 5:28 PM

Quote

Blazephlozard

He/Him

Banned User

Joined: 2/27/2013
Posts: 175
Location: Ohio

When I was checking the memory by placing the Gamecube flat at horizontal 0, 90, 180, and 270 (much easier than vertical due to cart's protrusion), I found that 180 was the same as 0, and rotating horizontally slightly more than 90 degrees starts to go back to the neutral value. So I believe that's good proof that 90 degrees is the maximum a real cart recognizes. If it's as simple as doubling two numbers in code and that doesn't break anything, that'd be fantastic. Using cruise control as a test, I need at least a 40 cruise control to have acceleration that matches 45 cruise control. So theoretically that means acceleration maxes out at 85 degrees tilt. Did the devs intend that? I dunno, I guess so. Crazy. By sensitivity do you mean, like, being able to hit all of those subvalues with specific values? It looks like at the moment, one tick = 2 subvalues (38 = 18/40, 39 = 18/20, 40 = 18/00). Of course, one tick also = 1 degree. I think? I can't confirm whether or not the cart's sensor can actually go one value at a time, because there's a lot of averaging of recently polled values going on with the tilt mechanic. But if the cart does have 1/16th precision, I doubt 1/16th precision instead of 1/8th precision is worth it at the cost of readability (the analog unit couldn't represent degrees if its precision was increased, right?) Perhaps it could be a separate digital input column...?

Posted: 7/3/2020 11:25 PM

Quote

Alyosha

He/Him

Editor, Expert player (3522)

Joined: 11/30/2014
Posts: 2728
Location: US

Seems pretty definitive to me. I'll increase the range to 90. I also realized my acceleration calculation contain an error, so unfortunately I'll have to break sync after all. EDIT: for now I just increased the range to 90 for further evaluation. I think I'll have to do some physical testing to nail down the other error.

Posted: 7/4/2020 12:51 AM

Quote

Blazephlozard

He/Him

Banned User

Joined: 2/27/2013
Posts: 175
Location: Ohio

Well, obviously there's no input to desync right now :P If there's anything I can help with physical-wise since I have the memory viewer, let me know For now, I'll have to test cruise-controlling to 90+ and see if it seems to do anything.

Posted: 7/4/2020 1:15 AM

Quote

Alyosha

He/Him

Editor, Expert player (3522)

Joined: 11/30/2014
Posts: 2728
Location: US

Roughly speaking, there should be a point where if you rotate fast enough to the left, kirby will still go to the right. (Or maybe it's the opposite.) I need to get an idea of how fast that is. It's important know how fast it is compared to realistic player movements.

Posted: 7/4/2020 3:58 AM

Quote

Blazephlozard

He/Him

Banned User

Joined: 2/27/2013
Posts: 175
Location: Ohio

Hmm, I think I kind of know what you mean when I was playing with the pause screen on console. Flicking the tilt makes the pause Kirby appear on the opposite side of where you're tilting for a brief moment, and I think I've got that happening in gameplay here too, on emu. I do it using a 360 Controller's analog sticks bound to the tilt, so it's a realistic speed. Though, unfortunately, I think I also see a possible desync issue. The size of that rightward flick isn't being very deterministic... https://www.youtube.com/watch?v=Sk05Aq_yVhM&feature=youtu.be Is this all the code for sending the tilt data to... RAM, I guess? I've never thought too much about how emulators actually give their input to a ROM to read. https://github.com/TASVideos/BizHawk/blob/3dba6857bc3b32bee6cefdb8a0340bd093fd55b8/src/BizHawk.Emulation.Cores/Consoles/Nintendo/GBHawk/GBHawkControllers.cs#L169 Do you know a memory address I should be looking at on console to know what the current tilt sensor values are? (I could see if that location is being copied directly to that 31 frame calibration buffer, since that buffer is easier to time)

Posted: 7/4/2020 8:05 AM

Quote

Blazephlozard

He/Him

Banned User

Joined: 2/27/2013
Posts: 175
Location: Ohio

I commented on the 'big cursor jumps' issue, clicking is fine but it's still doing it when you edit the value now. Acceleration can be even higher with cruise control now... new max values during calibration are 15/30, 1D/00, 24/D0 I looked at VBA and it isn't even analog? It's only up/down/left/right. It seems to not jump straight from 0 to max as you hold the key. But at the start of a level you can be holding Up already and reach the maximum value that way. Maximum values on VBA: 76/90, 7F F0, 89/50 VBA's y speed acceleration if holding up goes 00 00, FF 78, FE F0, FE D4, FE B8, FE 9C, FE 80, FE 64, FE 48, FE 2C, FE 10, FE 08 In BizHawk, this acceleration matches 90 cruise control + -10 tilt, so VBA's "up" would probably match 100 tilt in BizHawk? Oddly, despite a faster initial couple frames, VBA's -100 comes out slower than BizHawk's -90 in reaching top speed of FE 08: 00 00, FF 88, FF 10, FE 98, FE 80, FE 68, FE 50, FE 38, FE 20, FE 08 And BizHawk's -180: 00 00, FF 08, FE 10, FE 08 Is faster than VBA's -200: 00 00, FE D8, FE 94, FE 50, FE 0C, FE 08 FFF3 = adjusted X? FFF5 = adjusted Y? FFF7 = X calibration FFF9 = Y calibration === This has been a lot of information to try to wrap my head around, so I've put together another comparison just looking at Kirby's position shortly after starting a level after reaching max speed. Due to annoying framerate differences I decided to sync these screenshots by looking at the "200" in the corner and syncing it at a certain position. That should be consistent across all 3. https://imgur.com/a/LEfs6Bc To me this shows a clear win for the Gamecube, so perhaps the goal should be to reach that (approximately) "29/B0, 38/00, 45/70" range of motion, which is larger than Biz or VBA. (By the way, where does the initial main number (1D in Biz, 38 on my cart, ~80 on VBA) for that byte pair come from in the Bizhawk code?) My hope is that by the end of all this, we aren't stuck at a huge cruise control the entire game...

Posted: 7/4/2020 1:04 PM

Quote

Alyosha

He/Him

Editor, Expert player (3522)

Joined: 11/30/2014
Posts: 2728
Location: US

The game reads raw accelerometer values from the cart like this:

			else if ((addr & 0xA0F0) == 0xA020)
			{
				return acc_x_low;
			}
			else if ((addr & 0xA0F0) == 0xA030)
			{
				return acc_x_high;
			}
			else if ((addr & 0xA0F0) == 0xA040)
			{
				return acc_y_low;
			}
			else if ((addr & 0xA0F0) == 0xA050)
			{
				return acc_y_high;
			}

The accelerometer values are short (16 bit values) The neutral values and ranges are hard coded into BizHawk in GBHawk's controller definitions. Neutral value is 0x81D0 and range is 125 (so at 90 tilt the accelerometer would read 0x81D0 - 125) Neutral value is probably variable between carts, I can change it without much issue. Range can also be changed, seems like right now it's not high enough, maybe it should be around 135?