1 2 3
6 7
Joined: 10/11/2009
Posts: 52
Location: Sydney, Australia
Also something i'm curious about, after this any% run is done, is anything going to be done to get the best time when all wisps are unlocked for the first 3 zones? Because i'm curious to see how good things can get with each of these levels.
Active player (462)
Joined: 12/24/2010
Posts: 297
Location: CT, USA
I was thinking the same thing lol. I wasn't sure, but if you want to see it too then that settles it. Once it's over, I'll do a couple choice levels and do time attacks :D I'm kind of swamped with work from school at the moment, and so there hasn't been any progress :(. I'm going to finish my two essays and try to crank out TR1 in my new WIP today.
Active player (462)
Joined: 12/24/2010
Posts: 297
Location: CT, USA
Saved 41 frames and I'm only a quarter of the way through TR1. Not going to get close to breaking the record due to no boosting, but I think I can shave off 5 seconds overall. Looking forward to TR2 however :D
Skilled player (1326)
Joined: 9/7/2007
Posts: 1354
Location: U.S.
I just want to say that you are doing an excelent job at optimizing this! Keep it up!
Active player (462)
Joined: 12/24/2010
Posts: 297
Location: CT, USA
Thank you very much :D I finished TR1 and it's now 103 frames faster than my previous run. A bunch of minor little improvements through-out the level resulted in a lot of time being saved in total. Boost pads contributed the most and let me make some minor route adjustments I even broke 61440 speed without boosting :) I believe TR2 is going to see a big improvement too. I don't have any predictions for SM1 or 2. Speed and x-velocity addresses do not work for SM1 or 2. The problem fixed itself last time around when I got to SC1. Since I don't want to heavily rely on save state -> x-coordinate comparisons like last time (too lazy to find them, but yet added 10k+ rerecords from optimizing "blindly"), I'll figure out where they get temporarily moved to this time around.
Emulator Coder, Skilled player (1310)
Joined: 12/21/2004
Posts: 2687
Here's the Lua script. I did a bit more than necessary on it so it actually supports all versions of Sonic Rush engine games that I know of: Sonic Rush (U/E/J), Sonic Rush Adventure (U/E/J/K), Sonic Colo[ u ]rs (U/E/J), and New Super Mario Bros (U). I know that last one isn't exactly using the Sonic Rush engine but it was close enough and, uh, it seemed like a good idea at the time. In addition to showing some basic info (current velocity, etc., should work in all levels) it's also a "ghost script", which in this case means that it automatically saves some number of your previous re-record attempts and displays them as "ghosts" for you to race against, as a way of automating the comparison between attempts or at least presenting it in a way that takes better advantage of your human visual processing abilities. It also displays a "velocity trail" behind your character, which makes it easier to see where you came from, acts as a second speed/velocity indicator that stays onscreen longer, and takes into account non-velocity-value-based movement (if any). At the very start of the script are some configuration variables for you to change if you want to configure the keys used by the script or disable certain features. This also tells you what the controls are, but I'll explain the defaults anyway:
  • Turn on caps lock if you want to temporarily hide everything the script draws.
  • Mouse over a ghost's box and left-click on it to protect it from deletion and mark it as "important". Protected ghost tracks show up with a red tint, and won't normally get recycled. Remember to get rid of it eventually if you don't need it anymore or it will unnecessarily reduce the number of normal ghosts you have available.
  • Mouse over a ghost's box and right-click on it to delete it. Be careful, there is no undo (besides re-playing that part of the movie to regenerate the ghost). If the ghost is marked as protected, it will get downgraded first instead of outright deleted.
  • Mouse over a ghost's box and press [ or ] to nudge it backward or forward (respectively) through time, for cases where you want to manually resync a previous attempt with your current location so that you can compare against the rest of it. You can also hold [ and ] at the same time while pointing at a ghost as a shortcut for clearing its adjustment (setting it back to zero).
Issues: The timer used by the script restarts per level so you might see some non-applicable ghosts when you switch levels or if you switch games (delete such ghosts if you want), you can disable the use_in_game_time option to fix this but that has other disadvantages such as increased memory usage. Ideally the ghosts would be tied directly to savestate slots, but DeSmuME doesn't currently support savestate.registerload or savestate.registersave so I couldn't do that. The velocity trails aren't as accurate (or as precise) as they could be, and the ghosts could be nicer looking and more accurately shaped, but it seems to work well enough for now. The ghost and trail positions are calculated in simple 2D and won't really match up with the game screen if the game does any zooming or other 3D effects. And I haven't tried the script during boss fights yet so it probably doesn't display anything helpful there. That being said, I don't know of any significant bugs at the moment, but let me know if you find any.
Active player (462)
Joined: 12/24/2010
Posts: 297
Location: CT, USA
Wow! I'm going to try this out right now! I made a ghost of my old TR1 run and compared it against my new one. That's really awesome stuff! This is going to help cut down on rerecords a LOT. Thanks for scaling down all of the values in the addresses so they're easier to look at. I really appreciate all the hard work you put into making this script (the trails are so fucking cool LOL) and I'm going to put it to good use! Thank you nitsuja! EDIT So far I've saved 12 frames in TR2. 2 were saved by better skill at the beginning enemies, and 10 from a ramp trick (learned it on SC2 before restarting my run) to hit 63000+ speed briefly (which is much better than the 49000ish speed cap when jumping). I'm calling it a night for now. TR2 is about 20% complete after about 5 hours today (which is actually a lot faster than last time lmao). I'm currently optimizing two seperate routes to test which one is faster. The potential new route would stay on top of the water and skip going upward. Then after the loop I'll use the slope before the zip line to jump up to the breakable ground section. I think it'll be faster due to there only being two slowdowns (loop and slope) compared to four in the original route (slope, enemies, giant loop, spring). So far it seems a heck of a lot faster, but I've got to optimize the original route to be sure. Thanks again for the lua script nitsuja. It makes things a lot more convenient by having ghosts, and looking in the corner for coordinates, speed and x-velocity are way more practical than looking at the Ram Watch window for the same thing. I didn't even notice the boost percentage at first, and it's going to come in handy already due to there not being as many enemies killed in the route change. Even the trails have been helpful as a loose speed identifier due to color coordination (the box used for position identifying/ghosts even had a blueish-green outline when going really fast a couple times, which made me laugh). Great stuff here, thank you. 2/1/2011 Taking today off to focus on my workload this week. I'm trying to finish two classes worth today, then the other two tomorrow. Then I'll have four days to work on the run :D. I'm more inspired than ever to work on it due to the improvements I've been able to make so far. I'll post my WIP once Globotron is finished (friday or saturday).
Joined: 10/11/2009
Posts: 52
Location: Sydney, Australia
VanillaCoke wrote:
The potential new route would stay on top of the water and skip going upward. Then after the loop I'll use the slope before the zip line to jump up to the breakable ground section.
Apparently, that's the difference in the route that me and SkyLights have made in our separate runs, and from what i've seen, it does seem to be less consistant to humans, however it does return faster runs. Your testing should've found the same results hopefully.
Active player (462)
Joined: 12/24/2010
Posts: 297
Location: CT, USA
Unfortunately I've been swamped with assignments and haven't made any progress yet =/. I figure I'll be able to finish TR2 on Sunday. After TR2, Globotron should be finished relatively fast. I'll more or less just be copying the exact same thing from before, just making minor edits to the fight. Also I'm going to convert my run over to 0.9.7 before making any progress. Sonikkustar said something about adding 4 frames and it synced in 0.9.7 soooooo, I'll figure it out. If you read this Sonikkustar, can you post the dsm you edited that synced? I could avoid figuring it out if you would :D.
Skilled player (1326)
Joined: 9/7/2007
Posts: 1354
Location: U.S.
Emulator Coder, Skilled player (1310)
Joined: 12/21/2004
Posts: 2687
DeSmuME 0.9.7 introduced a bug in Lua that basically makes all the GUI drawing functions read color values incorrectly, which breaks the script I posted earlier. So I updated the script to work around the problem. You can either redownload it from the link in my earlier post, or add this to the top or bottom of the previous version of the script:
-- hack fix for new bug in desmume 0.9.7 with integers > 0x7FFFFFFF getting mangled when read in by the emulator
local function fixcolor(c) return type(c)=='number' and OR(c,0) or c end
local origdrawtext,origdrawline,origdrawbox = gui.text,gui.drawline,gui.drawbox
gui.text = function(x,y,s,c1,c2) return origdrawtext(x,y,s,fixcolor(c1),fixcolor(c2)) end
gui.drawline = function(x1,y1,x2,y2,c1,s) return origdrawline(x1,y1,x2,y2,fixcolor(c1),s) end
gui.drawbox = function(x1,y1,x2,y2,c1,c2) return origdrawbox(x1,y1,x2,y2,fixcolor(c1),fixcolor(c2)) end
Active player (462)
Joined: 12/24/2010
Posts: 297
Location: CT, USA
I haven't even had time to find out it was broken -_-. Thanks nitsuja! I forgot to mention that I found out Speed and X-Velocity work in a weird way when it comes to running on water (which means boost is required). If Sonic jumps, speed's value is ignored when Sonic lands. Instead x-velo is the only relevant address when landing on water. I've already passed the water section, but I forgot to include it in my last update post.
Active player (462)
Joined: 12/24/2010
Posts: 297
Location: CT, USA
Finally working on my run when I wake up ^_^. Edit Holding backwards when getting off a rail onto the ground allows higher than max ground speed (61440) temporarily. Sliding the first frame possible slows down the decay, prolonging the speed. There's a spot this may or may not be useful in TR1. I believe the boost pad right after the rail was more useful to take advantage of. If anything it would result in an 1 frame improvement. I can see if being useful later in the run. However there aren't long enough rails to build up enough speed to make it very useful so far. It was barely useful in TR2 when I discovered it and then optimized for it.
Active player (462)
Joined: 12/24/2010
Posts: 297
Location: CT, USA
I'm going to finish my current run of TR2 and post the dsm just to show some progress. However, I'm going to restart TR2 afterward due to a new method I found to keep a higher average speed during long jumps. Hopefully this is it for big discoveries lol. http://dehacked.2y.net/microstorage.php/info/900195966/Sonic%20Colors.dsm Remember, it's for DeSmuME 0.9.7. It won't sync in 0.9.6 correctly. The discovery is that backwards boosting in mid-air can "reset" decay. The x-velocity value stays the same when the boost is intiated, but the value decreases much slower (ie;, decay). It's mostly useful during big jumps, but it's also useful for a different method of backwards boosting airdash. Edit Calling it a night. Gotta get some work done for class. I'm 30 frames ahead of the WIP I posted six hours ago (in this same post lol) and I'm about 3/4's of the way done with TR2 (going pretty fast being it's my 4th TAS of TR2 lol). Everything up until the first ramp is the same (ie; the whole ferris wheel chase) due to the lag that was present making it not worth redo-ing. At the very best there could be a 1-2 frame improvement by manipulating lag so that jumps/airdash inputs aren't dropped. Finishing TR2 and Globotron tomorrow :D.
Emulator Coder, Skilled player (1310)
Joined: 12/21/2004
Posts: 2687
VanillaCoke wrote:
Sliding the first frame possible slows down the decay, prolonging the speed.
You can also go into a roll while holding backward, then after the roll starts you can hold forward to cut down on the speed loss even more. It's more effective than sliding, at least in some cases. I've used it a bit in Sonic Rush, although going at 8 times max ground speed is typical so I can only touch the ground for a few frames at a time anyway and it doesn't make much of a difference whether I roll or skid. Speaking of which, in case they didn't fix that bug, be on the lookout for any instances where you can land on a flat shallow downhill slope while you have a very high x velocity (the higher the better, but slightly below max ground speed is the minimum). In Sonic Rush, those are the conditions where jumping gives you an uncapped speed boost and causes you to immediately land again.
Active player (462)
Joined: 12/24/2010
Posts: 297
Location: CT, USA
nitsuja wrote:
be on the lookout for any instances where you can land on a flat shallow downhill slope while you have a very high x velocity (the higher the better, but slightly below max ground speed is the minimum). In Sonic Rush, those are the conditions where jumping gives you an uncapped speed boost and causes you to immediately land again.
Whoa! You don't happen to have a .dsm demonstrating it being used do you? If not, could tell me what level(s) that it works on in Rush? I'd like to test it out and know how to replicate it in Rush, and then worry about Colours. A couple general questions So, it requires landing on the slope? It can't be in transition from running from flat to slope?
Emulator Coder, Skilled player (1310)
Joined: 12/21/2004
Posts: 2687
VanillaCoke wrote:
So, it requires landing on the slope? It can't be in transition from running from flat to slope?
I think all that matters is that you have a high enough speed (say, 5000+ at the scale shown by the Lua script). But, landing on a slope itself gives you a pretty big speed boost for 1 frame (which you can keep for longer if you jump on that frame), and that boost tends to be the most practical way of getting enough speed to perform the trick. Although in Sonic Colors, so far I've only seen that 1 frame boost happen on rails.
VanillaCoke wrote:
You don't happen to have a .dsm demonstrating it being used do you?
Try this (in DeSmuME 0.9.7, with advanced bus timing enabled, sonic rush (U)). Frame numbers where interesting things happen: 1025, 3537, 3815, 4557 (landing on a slope as described) 3592 (shows that landing with high speed works as well as with high xvel) 3619 (speed and velocity magically becomes negative) 4118 (going fast enough to get a boost from running down a curve and jumping) 4149 (boost from a sloped rail) It's probably a lot harder to do this stuff in Sonic Colors because they removed airdash-boosting and might have added more speed caps and fixed various bugs, but maybe there are some situations where it's possible anyway.
Active player (462)
Joined: 12/24/2010
Posts: 297
Location: CT, USA
Awesome. I watched (I've never even seen purple trails before LOL) it and even replicated the landing boost and the jumping boost on my own in Rush. I'm going to have to do some more research into it, but unfortunately I have a lot of class work to do that's preventing me from doing it right now. From what I've learned in the half hour of messing around (on the first slope it's used in your dsm), the slope drops x-velocity down to 3471 (55536) when speed is 3840 (61440) and y-velocity is 1641 (26256). I was able to replicate the boost using Sonic Colours' method of Boost + Jump frame 1 -> Airdash -> hold backwards. Hopefully this will work in Colours. edit Couldn't help myself. I tried it out on TR1 on a slope that was very similar (changed x-velocity to 3472) but it didn't work. I did find out that either spinning or sliding will increase x-velocity when jumping from a slope though. I still believe there's a chance for it to be replicated. It might require having a higher speed than 3766 when hitting the slope, which I can do with boost. Managed to hit 4469 in TR2, however it capped to 3840 next frame. Holding backwards didn't make a difference, nor did sliding or spinning. Even jumping capped it. But while it looks identical to the TR1 slope, the x-velocity was a lot different (forgot off the top of my head). So I'm attributing it to the slope being too steep. If it's going to work on any slope, it'll be the slope in TR1. I'll try it out later with boost. Hopefully it's just a matter of speed and not being "fixed". edit Definitely been fixed. I edited the speed value to 122800 (real value, not lua) to the frame before landing from a jump, then disabled it while on a slope. X-velocity was a little under the value, but it was also over 100k. So I tested to see if the speed and x-velo would keep their values all the way down the slope and they indeed did. So the next test was to jump for a frame while holding backwards. I did and x-velocity went higher than speed, which is normal. I landed the second frame, normal. However speed and velocity dropped down to 61440 and 56760. Just to make sure it's not a case of a cheat messing things up, I decided to see if the speed would carry over when jumping from a flat surface to another flat. Worked just like in Rush (have to hold backwards right before landing). So I guess there's a check for slopes. Since slopes are needed to get the speed, it's a no go all around. =( It's also fixed in the US version as well. Figured it'd be worth checking out.
Emulator Coder, Skilled player (1310)
Joined: 12/21/2004
Posts: 2687
Now I'm wondering if they fixed it as early as Sonic Rush Adventure... What about on sloped rails? I suspect they have some totally different programming from regular slopes. Certain rails seem not to allow falling through them either, although even on ones that do, maybe landing near the bottom of a rail and immediately jumping again while holding backwards would give a respectable speedup.
Active player (462)
Joined: 12/24/2010
Posts: 297
Location: CT, USA
nitsuja wrote:
Certain rails seem not to allow falling through them either, although even on ones that do, maybe landing near the bottom of a rail and immediately jumping again while holding backwards would give a respectable speedup.
Off the top of my head, I don't believe I've come across a rail that is impassable. However I haven't specifically tested to see if I could jump on every rail in my last run, again, either. You were right about the speed boost on the rail. I tested it out on a sloped rail and I got a speed burst (4926 lua, 78816 real) when jumping the same frame as landing. Now the key is finding a) places to utilize it and b) rails that are either impassable or slopes are treated as separate rails. Edit (all values are lua) Curved rails work too, forcing me to optimize a part of TR2 :D. I'm never going to get to Sweet Mountain ;_;. I'm currently testing to see what the highest speed I can get off the rail is. So far I've hit 5395. I'm trying to find an optimal angle to have x-velo left over when hitting the surface. Sliding (Pressing R while on the ground) and spinning (pressing down) keep additional speed at exactly the same rate of decay. Sliding backwards looks cooler imo. For some reason I had a really hard time breaking through the wall and not having my x-velocity drop down to 0. The faster I went, the more likely it was to happen. The weird part was that the two fastest speeds were the only ones that broke through, and took longer to get there. The fastest (5675) ended up running into the regular wall, so it wouldn't work. I had to settle on the second fastest speed (5672) in the end. I land and begin my slide with 4578 (73250 regular) speed, which is a hell of a lot better than normal and is the fastest ground speed I've hit since running Colours.
Active player (462)
Joined: 12/24/2010
Posts: 297
Location: CT, USA
Finally done whoring frames on TR2. http://dehacked.2y.net/microstorage.php/info/1403292672/Sonic%20Colors%202.dsm Possible improvements would come from a loop trick I found on the last loop being used on the other two loops in the earlier. I don't believe it would result in a significant improvement, so I didn't go back and optimize for it. Link to video I'm not sure if TR1 could be improved with the loop trick. It's pretty boring since there's no boost. Link to video
Active player (462)
Joined: 12/24/2010
Posts: 297
Location: CT, USA
Sorry there hasn't been any progress in a few days. I'm trying to get caught up on class work so that I can spend most of next week working on this run (and practicing for a smash bros. tournament next weekend). I'm debating redoing TR2. It would be a really small improvement (2-3 frames atb) for my current ability and the improvements wouldn't be noticeable.
Joined: 5/14/2007
Posts: 525
Location: Pisces-Cetus filament
You are at the beginning of the TAS, so I think that you shouldn't ignore known improvements no matter how minor they are.
VanillaCoke wrote:
I'm not sure if TR1 could be improved with the loop trick.
Have you looked into it yet?
AzumaK wrote: I swear my 1 year old daughter's favorite TASVideo is your R4MI run :3 xxNKxx wrote: ok thanks handsome feos :D Help improving TASVideos!
Active player (462)
Joined: 12/24/2010
Posts: 297
Location: CT, USA
I did. The extra x-velocity disappears too fast. Boosting is needed to make it last. Top ground speed is also sacrificed and so the trade off isn't worth it.
Active player (462)
Joined: 12/24/2010
Posts: 297
Location: CT, USA
I've tested two different optimizations so far, and going slower is faster >_>. First one was using the very first ramp in a different way. Instead of boosting asap and backwards airdashing right before hitting the ground, I found a faster method. By using the boost a few frames later for a single frame and then holding backwards, I was able to land with 60544 speed and x-velocity. However when it came to jumping from the loop down to the slope, the slower run landed a point and a half (lua based value) further ahead due to being further up the slope. I tried delaying sliding (in both the test and the WIP) for a frame to get "higher" before the jump and it was worse. First loop that's encountered also can't be optimized with the loop trick. The trick is kind of hard to explain, but basically it's getting as close to 58880 x-velocity while having 61440 speed without going over [58880 x-velocity] and then jumping while holding forward. This sets x-velocity to 64448 temporarily and it can be extended by midair boosting backwards for one frame. The velocity can be further prolonged by jumping when hitting the ground and mid-air boosting backwards for another single frame. For some reason, the speed can't be carried on the ground by spinning or sliding. It'll reset the speed+x-velo to 61440 the next frame. I'm doing it correctly (how I did it after the curved rail) by holding backwards and pressing R and backwards for a frame before holding forward. Even holding backwards the whole time resets the speed. I think the x-velocity is too low to preserve. Like some has to be sacrificed in order for it to be preserved. I'm not positive though. Back to my original point, this isn't better on the first loop due to A) the trick being slower due to the "setup" and B) Jumping and doing another midair boost upon landing would be need to be faster than the WIP (which isn't possible due to hitting the wall). I'll try out the second loop tomorrow. My biggest fear is that I'll be unable to get the same kind of run when it comes to the section with the boost pad (Starting at Frame 9523 or time 0'33"27). I think if I can get that section to work just as well with the optimization (or better), I may be able to finish one frame faster due to barely being off a frame in my WIP. EDIT Tested the second loop and it was indeed faster. There was also some luck at the 9523 section as there wasn't any dropped inputs and that lead to a new strategy. New finish time is 0'42"57 (3 ms faster). Technically it's only one frame faster than the WIP but there was a lag frame so it's really two. Got home about 3 hours ago. Globotron was beaten in 0'12"93 again >_>. I'm going to retry it tomorrow.
1 2 3
6 7