Posts for nitsuja


Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
For a while I've thought that hacks/patches would be a neat way around the issue of wanting to make something like a "glitchless" run but not being able to define what that means without it being just an arbitrary set of restrictions. With a fixed version of the game, you wouldn't have to "hold back" while TASing and it could simply be a regular TAS of that version without needing weird goals and rules. As for calculator vs. non-calculator run of this (unpatched) game, I did some really rough timings and calculations and it looks like a non-calculator run would need to maintain an average time of at most somewhere around 90 seconds per battle in order to have any chance of beating a calculator run. (That's timed from when any player or enemy character's status stuff appears at the bottom of the screen to when the status display last goes away at the end of the battle.) That sounds really hard, but considering that almost half of the required battles can be beaten by killing a single enemy, and that criticals and misses can be manipulated, and that the JP scroll glitch can still be used, I wonder if that isn't as crazy as it sounds.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Here are some faster Tornado times: 2"61 on Siamang and 4"83 on Wong. Are we sure about starting from SRAM being okay for this game? I don't know of any published TASes that start from SRAM out of convenience instead of necessity.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
It only syncs for me if I set Config > Save Type to EEPROM 4kbit. Otherwise saving the game before the wave cyclone takes 1 frame longer and throws the movie out of sync. Sonikkustar, if you have that set to 4kbit, maybe you should change it back to AutoDetect to reduce desync problems other people get. If you insert 1 frame in the movie where it's saving (like this) the movie should sync with more normal settings.
Post subject: Re: LUA 6 Buttons in Gens 11b
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
BetaTester wrote:
You need some code to enable a 6 buttons? Even changing the configuration of the controls in Gens11b, but not work my 6 buttons LUA macro
I made a fix for this, so see if it works for you in this version of Gens: Gens11svn296
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
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.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
The only problem with using that 2-byte value is a lack of precision. It's not that important, but I've found it useful for various reasons to have exactly (or at least almost) as much precision available as the game really has internally, although I usually scale it to something more convenient to look at. On the European version, 0219B2E0 is X velocity (which is what you should usually be maximizing, of course), 0219B2EC is the speed, and 0219B264 is the X position (all of which are 4-byte values). I watched your WIP and... well, the gradient of being slow near the start of the run and faster later on is pretty noticeable to me, but I'm not familiar enough with the game to suggest route changes or new strategies that you're not already doing near the end of what you had recorded. I guess you're not using any Lua scripts? They tend to help more than you would expect. I can probably get my Sonic Rush scripts to work for this game easily enough, since all I need to do is find where a few memory addresses have moved to.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Yes, I'm already using that trick in Sonic Rush and I believe so are some of the speedrunners. It's actually not limited to boosters, it's something you should take into account almost everywhere in a TAS (and it applies to all 3 games), and it's a logical consequence of how the engine works if you understand it well enough and you know what boosters really do... uh, this is something I know way too much about, and it makes properly TASing Sonic Rush games more complicated than you would expect, so let me write a little essay here (even if you might know some of this already) and maybe this will make more sense: First of all, if you're seeing speed values like 275, you're not watching the right values. You should see something more like 49152 at normal boost speed. Assuming these aren't dynamically allocated addresses, Sonic's speed is at 0219B30C, his X velocity is at 0219B300, and his Y velocity is at 0219B304. They're 4-byte signed values. (In Sonic Rush these values are elsewhere and are smaller by some factor but otherwise behave in the same way.) To make sense of what's going on, you'll need to pay attention to both speed and (mainly x) velocity... it might seem like they are basically the same thing, but the game treats them quite differently, and another way of labeling them is "potential speed" and "actual velocity". When you're on the ground, they are tied together directly and act as you would expect. (But keep in mind that what I call the "speed" can be negative to indicate leftward motion, so while you're on the ground it's actually (sqrt(xvelocity^2 + yvelocity^2) * sign(xvelocity)).) When you jump, the velocity and speed values continue updating, but the speed value now updates in a weird way (though the speed value has no observable effect while you're in the air, only the velocity values do, so you can't notice how weird this is normally): What the speed value does in the air is, it doesn't change at all if you're holding forward (left/right), it decays toward 0 if you're not holding forward (it decays at the same rate as your velocity normally would, even if some external force is holding your actual velocity steady), and if you're holding backward it decays towards 0 even faster (but not as fast as your actual velocity normally changes in this case). Also, the velocity value gets a modification, it's not quite as weird but it's the whole reason the trick works: When you're in the air, if you are not holding backwards, and if the x velocity value exceeds +/- 40960, it gets capped to +/- 40960. So you can avoid the cap by holding backwards, but the speed and velocity values still decay toward 0 when you do that (if you keep holding it, the velocity will decay down to +/- 40960 anyway in only a few frames and then later cross 0 when you fully reverse directions, and then the speed will hit 0 a few frames after that and stay locked at 0). Oh, and if you're boosting in the air then the velocity can still get capped if you're not holding backwards, but it uses 49152 as the cap instead of 40960 in that case. If you hit an obstruction while in the air, both speed and X velocity get cleared to 0, and hitting various level object probably messes with them too, but besides that they stay independent from each other while you're in the air. One more piece of information about how the speed and velocity values interact is what happens when you land. You can probably guess from the above that those two values get easily out of sync from each other while you're in the air (even the sign of the two values can become different), but they are always the same when you're on the ground, so the game has to do something to combine them back into effectively one value when you hit the ground. What it does is it chooses the larger (in magnitude) of the two values and makes that your new speed and velocity. (I left out some unimportant details of slope calculations, but that's the gist of it.) This explains why sometimes you can start running at full speed the instant you hit the ground even if you were barely moving in the air: when that happens, it means your velocity value is low but your speed value is much higher, so the (hidden while in the air) speed value suddenly takes over when you land and you magically "hit the ground running". I believe that this (and most of the above weirdness) is a deliberate quality of the Sonic Rush engine that exists for the purpose of fixing the problem seen in earlier Sonic games where you grind to a halt if you "hit the ground at a bad angle". So what do boosters have to do with this? Well, I think you said as much already, but after hitting a booster, your inair velocity update is temporarily modified such that letting go of the d-pad doesn't cause you to slow down at all, and holding backwards does still make you slow down but with a drastically reduced deceleration rate (I'm not sure whether this is a bug or an intentional feature that it applies in the air). Thus, after hitting a booster, you can hold backwards for a long time without losing much of your velocity, whereas without a booster your deceleration is much faster so you can only hold backwards for a few frames before dropping below the speed cap (unless you are going really ridiculously fast, as is possible in Sonic Rush). What this means is that it's often good to jump and hold backwards after hitting a booster, and even after a regular airdash or when jumping on a regular downslope without a booster, you can get ahead a little by holding backwards for a few frames and then holding forwards as soon as the velocity is about to drop below the cap. But, you have to keep in mind that this is almost always a trade-off, due to the "speed" value behavior I described above: When you hold backwards to exceed the inair velocity cap, the speed value is still decreasing at a normal rate, which means you are gaining (short term) speed in the air but you are quickly losing (long term) potential speed that you could otherwise get the next time you hit the ground. So you have to constantly balance those two things if you want to be as fast as possible overall.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Note that Wong's mech has a weak point at the very bottom, you'll see it as an orange rectangle if you have the Lua script running. It's extremely hard to hit because of the wall, but a treble shot there with Falcon will take off 55.5% of his health and also expose the triple cannon weak point. Also, maybe you've noticed this before, but whenever he raises his shields up while he's facing you, there's a tiny (1 or 2 pixel wide) area of his shoulder joint exposed on each side.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Ehrgeiz - God Bless the RNG?
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
About Garam; oops, I didn't realize uncharged shots worked to manipulate him to jump earlier than normal. Is that what you're doing, or did you find a way to manipulate his behavior before the fight even starts so that he decides to jump immediately? Also, I guess I'm more sure that the time of 5"50 on Wong (with Falcon, without bombs) will be harder to beat, since there was no waiting for Wong to do anything, though maybe it's possible to go a few frames lower. I've seen lower Falcon times posted for Wong, but they used strategies that don't work on Hard mode because he holds the shield differently on Hard which hides the shoulder joint weakness while he's moving sideways. Then again, I did once see him turn the shield the wrong way for a split second, so maybe it's still possible to hit it early somehow. As for "Adjust Aim" abuse, doesn't Griffin always start out by dropping way below the screen? If the aim is adjusted before the fight, you can hit him with bombs or charged shots during that time. I don't know if it will end up speeding up that fight, since you might want to charge during that whole time anyway, but it opens up more possibilities to try.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Try using a different version of the emulator. I suggest using the newest version of Snes9x 1.51 that can be found here, such as (currently) this. The mouse-based input should automatically work in that version. (I know there is a 1.52, but I don't recommend using that for TASing, at least not yet. Also, in versions such as 1.52 that are missing the "automatically work" feature, I think you have to press 7 twice for it to work.) I don't know if you saw this, but here is a Lua script you can use (and should use if you're serious about making this TAS, unless you have or can make something better), and be sure to beat Garam2 in 4"06 or faster (Falcon, hard mode).
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
There are a few cases where cheat codes are acceptable. I think there has been a precedent for all of the following: If there's a bug that changes the effects of a cheat code, then it should be treated as a separate code (i.e. usable only with sufficient approval for it in particular). If there's a bug that simply makes it possible to enter a cheat code faster that you were already going to enter anyway, then of course it should be used.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
There was already a topic on these forums about this game, which might also be worth reading: http://tasvideos.org/forum/viewtopic.php?p=197860 Of note are at least the times I listed and the Lua script (I just posted it there but it's been available for a while). That SDA discussion probably has more specifics than anything that's been posted here so far, as far as strategy goes. I think it's better to not start from SRAM though, because it's always a little controversial to start from SRAM, and you don't need it to enable hard mode, and the training mode isn't that long and it also contains a fight at the end that I think is worth being part of a TAS of the game.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Kuwaga wrote:
Interesting. Is it just my impression or could pretty much anyone get a good score on that test just by applying common sense and lying? (even without that sheet)
It seems that way, which means they are selecting for good lying skills at least as much as anything else. Although some of these are quite counter-intuitive, for example, you lose points unless you say you "strongly agree" that you are a "thrill-seeker", which I would normally expect a company to interpret as "I enjoy getting myself into trouble". Also, I would have expected feeling "strongly" about everything to be a bad thing on these tests instead of a requirement, because anyone who feels strongly about absolutely everything is probably either a habitual liar or so opinionated that it would get in the way of their job. One more thing: "When people make mistakes, you correct them" + "When someone treats you badly, you ignore it" = "It is correct for people to treat you badly"?
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
boct1584 wrote:
The in-game timer shows an improvement of only about 0.13 seconds (8 or so frames); where did the remaining improvements come from?
I think the rest of it came only from choosing a different game mode ("match race" instead of "time attack"), which skips displaying the results screens. (It also adds some item things but apparently those didn't make a difference to this TAS.) Unfortunately this means that we can't easily see what the per-lap times are (though it's probably possible to extract them from memory or change the mode back and resync it). It can be useful to know what these are because inconsistent per-lap times are a good indicator that a level is still improvable, and also some people compete on single-lap times and it would be nice to know whether this beats those records as well.
ALAKTORN wrote:
"manipulates luck"? where?
There is no luck to manipulate that I know of in the tracks themselves, but maybe in switching to "match race" mode it was necessary to manipulate luck slightly in order to prevent the new elements of that mode from causing desyncs with the old input.
mklip2001 wrote:
I can't get this movie to sync past the title screen in Gens v11a. (I know you used v11b, but I was hoping the versions were close enough to still work.) I'd be curious to see if anyone else got v11a to work... I don't like to keep too many versions of emulators around if possible.
I tried it in Gens9g, Gens11a, and Gens11c(dev) and it worked in all of them. Make sure you're using the correct ROM instead of "Sonic and Knuckles & Sonic 3".
mklip2001 wrote:
Are the previous times Nitsuja's or yours?
The previous times appear to be the same as my old ones except for the last level, which I never attempted. So it looks like only Balloon Park was improved (by 1 frame) out of the levels I did, although I had thought that maybe some of the others could be improved.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
henke37 wrote:
Both of those are variants of classical Christmas tunes. The Bloxonious track is based on "Little Drummer Boy" I believe. I am not sure what the first one is based on, silent night?
"Carol of the Bells".
Post subject: Re: A way to get emulator state pause/unpause?
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
BadPotato wrote:
If there no way, I think that could manage the hotkey by myself for frame advance or pause to keep know what are the emulator state, but this method is somewhat brutal.
I don't know how much other emulators would support this, but here's a (somewhat lame) attempt at doing this that works in Gens as it is now, showing gui.register code running while the game is paused, assuming for this example that you use P and F for pause and frame advance and that they aren't configured as your real hotkeys for anything:
pauseKey = 'P'
frameAdvanceKey = 'F'

function handlePauseAndFrameAdvance()
  local newPaused = paused
  local pauseButtonHeldNow = input.get()[pauseKey]
  if pauseButtonHeldNow ~= pauseButtonHeld then
    if pauseButtonHeldNow then newPaused = not paused end
    pauseButtonHeld = pauseButtonHeldNow
  end
  local frameAdvanceButtonHeldNow = input.get()[frameAdvanceKey]
  if frameAdvanceButtonHeldNow ~= frameAdvanceButtonHeld then
    newPaused = not frameAdvanceButtonHeldNow
    frameAdvanceButtonHeld = frameAdvanceButtonHeldNow
    frameAdvanceButtonHeldCount = 0
  elseif frameAdvanceButtonHeld then
    frameAdvanceButtonHeldCount = frameAdvanceButtonHeldCount + 1
    newPaused = frameAdvanceButtonHeldCount < 60 or (frameAdvanceButtonHeldCount % 8 ~= 0)
  end
  if paused ~= newPaused then
    paused = newPaused
    if paused then sound.clear() end
  end
end

gui.register(function()
  testcounter = (testcounter or 0) + 1
  gui.drawtext(50,50, string.format("%s -- %d", paused and "paused" or "unpaused", testcounter))
end)

while true do
  handlePauseAndFrameAdvance()
  if paused then
    gens.redraw()
    gens.wait()
  else
    gens.frameadvance()
  end
end
But really, there should be some sort of emu.registeridle() function, since this example is quite a hacky way of doing it, and updating things in the GUI drawing like some emulators let you do is just a hack as well.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
I was mostly hoping to get across the point that copying input is something that requires some sort of justification (especially when the input is from a predecessor to the movie being created), not something to be encouraged, when you take into account the quality implications. Lack of time and whatever else may be acceptable excuses (excuses I've used before too), but excuses of any kind are something we should be at least vaguely dissatisfied with if the excuses are for the contents of a TAS. So I wouldn't want to start seeing lots of runs where the author only tries to improve one part of the run, for example. But, maybe I'm thinking of this in too short-term a way...
Scepheo wrote:
It just seems silly to, rather than copy someones work, do it all yourself and then end up with exactly the same input file.
While I agree in principle, the thing is, how do you know you would end up with exactly the same input file? My experience has been that we're very bad judges of that, e.g. I don't think I can improve a movie at all, but if I actually try to do so then I am much more likely to succeed than I originally suspected. So encouraging people to try to make "full" improvements seems like a good thing to me, since they so often have the potential to do it. (Not to suggest that I think we need to make some new rule for that purpose.) As for the original topic, I would be in favor of codifying something compatible with the status quo (about input copying) in the form of a license or rule or guideline, purely for the purpose of more openly communicating what's considered acceptable practice.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Scepheo wrote:
Nitsuja, you're only using "copy" as in literally using the copy-paste function. However, when talking about copyright...
Which I explicitly wasn't. And you already said we don't need rules for this so I'm not sure why you're bringing that up.
Post subject: Other issues with copying input
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
It's probably not worth caring about legal implications of copying movie input, although I agree with the idea that they can be considered as a form of artwork. And I won't talk about the ethical implications right now. However, I think there are some issues as far as this site's guidelines go. As far as I can tell, the goal of creating movies for this site is to make them as perfect as you can make them (e.g. whatever the particular movie's goals are, entertainment or whatever, you have to meet them as well as you can, not sloppily). Now, everyone has their own personal standards and methods of doing things. Suppose I make a movie for submission here to obsolete a previous movie, and I copy a lot of its input from that other movie. Consider these three possibilities or categories I could fit into:
  1. If I am capable of improving the input that I copied, I would be submitting a movie that contains sloppy input compared to what I could accomplish. Therefore I clearly shouldn't copy the input.
  2. If I am capable of exactly matching the level of perfection of the input that I copied, then it makes sense to not duplicate the effort and simply reuse the input. But, how could I know I fall into this category without trying it first? And if I try it first then I will have no need to reuse the existing input since I will already have my own, unless mine is actually worse in which case I'm really in category 3 below and not this one. Therefore I have no reason to copy the input if I want to be as sure as I can be that I've created the movie as well as I can.
  3. If I am not capable of even matching the level of perfection of the input that I copied, then it's likely that I'm not qualified to meet the community's standards in creating a successor to a movie of whatever game it is. Therefore I probably shouldn't make the movie at all, or I should try harder until I fit into category 1 or 2 above.
Now, I realize that things aren't quite so black and white, our standards don't all exist on one axis and we don't have infinite time at our disposal, so copying input can be justified and I'm not saying that the cases where it's happened in the past shouldn't have happened. But I think the above conclusions still apply in most cases, which suggest that it's usually a bad idea to copy input, no matter whether the original author would want you to or not, when the input is intended to be submitted to a site that has standards like this one.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
I think everything except the last level (Endless Mine) is my input. I'm pretty sure my input could be improved by a few frames, especially in Desert Palace where some laps are faster than others. I have no idea how optimally Endless Mine was done (yet). EDIT: it can definitely be improved, I got a 0"35 faster first lap with Knuckles without much iteration.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
boct1584 wrote:
I'm also having sound glitches (staticky) but it only occurs when I'm using the EPX+ renderer without a movie playing. If I'm not using the EPX+ renderer, or a movie is playing, it's fine.
That's probably your computer being too slow to handle all of the options you have enabled at once, combined with the sound playing code being un-robust enough that you can hear sound glitches when it's having trouble keeping up. If you really want to use EPX+ without sound glitches on your computer, try setting "Graphics > Latency Compensation" to 0, but note that the controls will feel more unresponsive if you do this, so unless you're playing something like an RPG where the responsiveness doesn't matter, it might be better to simply not use EPX+ instead.
Post subject: Re: Sonic Advance 2 Zipping!
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Sonikkustar wrote:
So in a feeble attempt to improve the current pub., This happened. Sonic Advance 2 Zip ...I just dont know anymore.
I've seen that happen a few times before. Some of them involved going so fast that the collision check failed to stop me from going through a wall, others were at a slope like that. It was always useless the times I found it (couldn't escape from the zipping or could only fall to my death or it was simply slower). But it's definitely something to look out for. That was a pre-memory-watch movie so maybe with the extra precision it's possible to get going fast enough to glitch into more places.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
DrJones wrote:
The Chrome Gadget time seems better than what Nitsuja achieved in the thread linked by sgrunt.
It's because I was in time attack mode (which is possibly the only mode that people should use for time comparisons) and thus couldn't make one of the "competing" players stand around in order to speed up the other player's laps.
mmarks wrote:
nothing but my opinion is a bit impossible to improve or do the same time with the of nitsuja
I posted my GMV next to those times, btw. I'm sure they're improvable.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Nice improvement. And now I guess someone else knows how weird it is to TAS this game glitched. My one complaint is that it seems like a lot less effort was put into making the periods of waiting entertaining... Sonic and Tails have all sorts of moves they can do but you mostly just stood there waiting (before and after each boss fight). It's all very minimal. Also, why didn't the graphics glitch out at the end of Egg Rocket? That's another waiting period that became less interesting (although I can't remember at the moment whether that glitch is something you'd be able to manipulate without losing time). It's not a big deal, though. EDIT: I voted yes, by the way, and I'm looking forward to seeing the without-spindash-glitch run you said you were working on.