Posts for Blazephlozard

1 2
6 7
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
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...
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.
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...
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)
Blazephlozard
He/Him
Banned User
Joined: 2/27/2013
Posts: 175
Location: Ohio
I'm not actively interested in improving it right now and dart's said he's busy for a few months. I suppose delayed is better than having a new submission later. It's definitely on my shortlist and it's only a 12 level game, though it'd likely take a good week or two working on it to try to squeeze as many pixels out as possible.
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.
Blazephlozard
He/Him
Banned User
Joined: 2/27/2013
Posts: 175
Location: Ohio
I double-checked the Dark Link fight to make sure there's nothing more to be saved there. The improvement is actually as simple as deleting two blank inputs between the movement and the first sword slash. And then resyncing the rest of the fight of course. Not sure if those two frames were missed before, or if they were unable to get a good 2nd hit and beyond with it. I don't see any way to possibly reach Dark Link faster than this for dealing the first hit, and all subsequent hits are done 56 frames apart, which is Dark Link's invulnerability time, so they should be maxed out. The last sword slash is the end of input, and Dark Link gets hit by the last frame of the slash, so I believe early input end is maxed out as well. As far as the rest of the game goes, assessing this kind of insane movement is beyond my capabilities.
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...?
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
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.
Blazephlozard
He/Him
Banned User
Joined: 2/27/2013
Posts: 175
Location: Ohio
I may be wrong but it sounds like the Header cycle count does represent the whole movie. emu.totalexecutedcycles() is what doesn't.
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
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.
Blazephlozard
He/Him
Banned User
Joined: 2/27/2013
Posts: 175
Location: Ohio
I misread, I thought it was all on Azrael. The spider wait is gone, wow! That was the only wait left that was gross. It's a little thing but it makes things that much cleaner looking!
Blazephlozard
He/Him
Banned User
Joined: 2/27/2013
Posts: 175
Location: Ohio
Very cool! I was thinking a weakness of the cat boss might be the poor rightward position we're at on the last hit, was that where the improvement came from?
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
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?
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...
Blazephlozard
He/Him
Banned User
Joined: 2/27/2013
Posts: 175
Location: Ohio
Looking into the fastest way to drop pieces for trees, on Level 18 (drop speed = 3 frames), holding Down (which increases drop speed to 2 frames) is equal to doing 3 Down, 1 blank (which alternates 3 frames and 1 frame). Though you want to start that Down hold one frame after you gain control of the piece, to save 1 frame. Since 3 on 1 off is equal speed to holding Down, horizontal movement can be done in the off frame (as well as the very first frame) without losing time. But 5th-8th knee will be getting cleared on Level 19, right? So if you want maximum potential frames, they have more limited hole options. (In reality, the extreme difficulty of manipulating the I-pieces would almost definitely lead to RNG delay frames, during which you can do horizontal movement freely, but I figure I should bring it up) Bottom-most hole is column 5/6/7 for early input end (probably 6 for most options) Next highest hole I believe has to be 3-9. And above that, it'd have to be 4-8. Hmm, yeah, it'd have to be two J's... but what about this? I wonder if you could look into some larger 5-line options like this... (Just realized I didn't test that its actually possible to get the pieces there, especially that T on the far right, but I'm sure there's some similar shapes possible) (If we get too into this, using Discord for real-time chatting could be more useful than swapping replies on the forum here)
Blazephlozard
He/Him
Banned User
Joined: 2/27/2013
Posts: 175
Location: Ohio
Hmm, alright, perhaps I'll make a copy of the hole 10 R+0 that either adds an I at the start, or if first piece is I, replace that with two L's. (Automatically through code) Taking the I-spin into consideration (as well as L-1's that begin with an I on column 5), I think I'd just want to include the 5th line in L-1 too.
Blazephlozard
He/Him
Banned User
Joined: 2/27/2013
Posts: 175
Location: Ohio
Hmm, I think I'm a bit confused about the start, at least as far as your "L-1" builds go. If we're filling in 5 lines instead of 4 then, do they all require two additional I pieces in the fifth line? Other than that, after a thorough reread of your strategy, I think I finally get all of it, so that's good. (There is a bit of a language barrier sometimes) Where the old TAS hits Level 19 with 4 Tetrises ready to go and then does them all, you want to only do 1 of those 4 Tetrises, keeping the other 3 as the finale, to save vertical piece travel.
Blazephlozard
He/Him
Banned User
Joined: 2/27/2013
Posts: 175
Location: Ohio
It's a good point that there will be duplicates. I could keep a table of attempted piece sequences, though I'm not sure if the memory overhead to keep that table and check it would be worth it compared to just, doing the sequence again. I'm sure there's many many ways to try to speed up the program if it turns out to be too unruly, but I think it'll be decent enough. I think I should open your input file up finally, and see about getting the "very first 3-tetris" builds in, do input manually for now, and see how the program goes searching for them. Do we want to try to brute force the initial stack building at all? That part seems ok to do by hand but theoretically I could also test a list of usable piece orders for it too.
Blazephlozard
He/Him
Banned User
Joined: 2/27/2013
Posts: 175
Location: Ohio
I should have no problems with combining every possible sequence of L0 and R1 lists, and L1 and R0, for each hole, once they're made. Though corner cases might be tricky to deal with. (I'm not sure I fully understand what your one "R+1b" fits into.) And I do not know just how lengthy the process will be when there's that many permutations. But since this method isn't an in-game simulation (isn't bound by advancing frames), I don't think it will take too long. This current one-permutation test takes less than a second.
Archanfel wrote:
To have inputs automatically it can be very useful. In this case we be able to apply even deeper optimisation methods. Recurrent multi-tetris optimisation: It would be possible to try minimize average delay for several tetrises by better conjunction between them. For example if for one tetris delay is small 10 frames, but delay for next one is long 37 frames. 10+37=47. We can check second best option 26 delay for first tetris and look what delay for next tetris it can be like 13. So 26+13=39 summay delay is lower = better. And so on for each tetris conjunction. Or even minimize delay for several tetrises D_min(D1+D2+D3+Dn). Well of course we try to do the same without inputs automatically too, but to do such recurrent multi-tetris optimisation by hands many many times in row be very tedious.
Well, since the piece RNG is generally sequential, I'm not if such a major frame difference will be possible. The only factor that can really change the sequence is if it has to do a reroll, which depends on what the current next piece is. The piece selection is made like this: Step 1. Add the piece total to the top byte of the RNG. Modulo 8 (so a number from 0 to 7). If result equals the current next piece or 7, reroll in step 2. Otherwise, that's the new piece Step 2. Advance RNG once. Add piece total and modulo 8 again. Add the current next piece's ID (this is a bit odd because those IDs are 02, 07, 08, 0A, 0B, 0E, or 12, not 0-6). Modulo 7. That's the new piece So if it has to do the reroll, RNG would advance an extra time besides the once per frame, which could save frames. And also the last piece and first piece of sequences will have an effect on the piece-picking process. (Also note that the game does make you far less likely to get the same piece twice in a row.) Well, we'll see how quickly the whole brute force process ends up being when all the data is there. If it's quick, and I can figure out a way to automatically place a given piece sequence, then sure, we can try to go crazy and try some '2nd place' branching paths. Especially if we run into a terrible '1st place' like 37. The 4-frame-rule on line clear animations, and the fact that the previous sequence has to RNG manip for the first piece of the next sequence (which we don't know at the time), is going to make full automation difficult. I'm trying to think of how to handle these things.
Blazephlozard
He/Him
Banned User
Joined: 2/27/2013
Posts: 175
Location: Ohio
Alright, I did some great work towards the brute forcer today. Put simply, I've been doing testing using a specific sequence from the old TAS, and I was able to successfully output this:
{"I","L","Z","L","L","O","O","Z","T","J"}: 28 ({7,2,0,0,5,3,0,5,4,2})
{"I","L","Z","L","L","O","Z","O","T","J"}: 26 ({7,2,0,0,5,3,3,0,2,4})
{"I","L","Z","L","L","O","Z","T","O","J"}: 25 ({7,2,0,0,5,3,3,1,3,1})
{"I","L","Z","L","L","Z","O","O","T","J"}: 35 ({7,2,0,0,5,2,1,14,3,1})
{"I","L","Z","L","L","Z","O","T","O","J"}: 25 ({7,2,0,0,5,2,1,6,1,1})
{"I","L","Z","L","Z","L","O","T","O","J"}: 26 ({7,2,0,0,0,5,2,8,1,1})
{"L","I","L","L","O","Z","O","Z","T","J"}: 35 ({0,5,1,12,11,2,0,1,2,1})
{"L","I","L","L","O","Z","Z","O","T","J"}: 43 ({0,5,1,12,11,2,1,8,0,3})
{"L","I","L","L","O","Z","Z","T","O","J"}: 38 ({0,5,1,12,11,2,1,0,2,4})
{"L","I","L","L","Z","Z","O","O","T","J"}: 45 ({0,5,1,12,2,11,6,6,1,1})
{"L","I","L","L","Z","Z","O","T","O","J"}: 41 ({0,5,1,12,2,11,6,0,4,0})
{"L","I","L","L","Z","Z","T","O","O","J"}: 59 ({0,5,1,12,2,11,9,1,13,5})
{"L","I","L","Z","L","O","O","Z","T","J"}: 29 ({0,5,1,2,3,7,0,5,4,2})
{"L","I","L","Z","L","O","Z","O","T","J"}: 27 ({0,5,1,2,3,7,3,0,2,4})
{"L","I","L","Z","L","O","Z","T","O","J"}: 26 ({0,5,1,2,3,7,3,1,3,1})
{"L","I","L","Z","L","Z","O","O","T","J"}: 36 ({0,5,1,2,3,6,1,14,3,1})
{"L","I","L","Z","L","Z","O","T","O","J"}: 26 ({0,5,1,2,3,6,1,6,1,1})
{"L","I","Z","L","L","O","O","Z","T","J"}: 27 ({0,5,3,0,5,3,0,5,4,2})
{"L","I","Z","L","L","O","Z","O","T","J"}: 25 ({0,5,3,0,5,3,3,0,2,4})
{"L","I","Z","L","L","O","Z","T","O","J"}: 24 ({0,5,3,0,5,3,3,1,3,1})
{"L","I","Z","L","L","Z","O","O","T","J"}: 34 ({0,5,3,0,5,2,1,14,3,1})
{"L","I","Z","L","L","Z","O","T","O","J"}: 24 ({0,5,3,0,5,2,1,6,1,1})
{"L","I","Z","L","Z","L","O","T","O","J"}: 25 ({0,5,3,0,0,5,2,8,1,1})
{"L","Z","I","Z","L","L","O","O","T","J"}: 36 ({0,0,2,0,2,14,3,11,3,1})
{"L","Z","I","Z","L","L","O","T","O","J"}: 26 ({0,0,2,0,2,14,3,3,1,1})
{"L","Z","I","Z","L","T","L","O","O","J"}: 10 ({0,0,2,0,2,0,1,1,2,2})
I had an upper limit of max 15 frames wait, which is why not every permutation is here. That last piece order, with only 10 frames of delay, is indeed the one used in the old TAS, and the delay numbers seem mostly accurate (the last 2 should be a 1? I'll have to look into that...) (edit: I gave that O a 23 frame count instead of 24. it's perfect now!) So, I have very high hopes for the future. I'm worried there's something more to the RNG than I have, since the old TAS ends up desyncing on today's BizHawk? But we'll see. Right now turning your incredible work into proper data form will be a big timesink. And I'm still unsure if I should try to code a way to do the inputs automatically. It'd probably save time in the long run...
1 2
6 7