Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Derakon wrote:
it seems to me that #4 would probably be your best bet. There's plenty of research done on various schedulers; it seems like you ought to be able to write your own simple deterministic scheduler that will prevent deadlocks, based on that research. I certainly wouldn't recommend trying to reinvent the wheel here, though.
The problem is that I have so little information available: I can't measure the time (all system clocks are off-limits), I can't measure the number of instructions that get executed, and I can't measure the number of cycles spent or number of memory accesses or any other hardware counters or hardware events or OS events that trigger as a direct or indirect result of said hardware events. It's hard to imagine that anyone would have already created any sort of thread scheduler under those constraints that could replace a preemptive scheduler.
Derakon wrote:
I agree that #2 sounds disturbing, if only for the amount of extra work it'd entail for each new game you want to support.
Actually, in the best case it could be quite minimal, such as finding a few program counter addresses that represent good-enough "loop points" for the threads used by the game. I'd still like to avoid it if possible, though. For example, if that's really all that's necessary, maybe it's possible to auto-detect what those loop points should be in a deterministic way.
Derakon wrote:
I'm not sure I understand what extra information you'd use in #3 to get it to work.
Well, anything from saving extra values of some sort per frame that could be used to detect desync so that it could rewind until the desync doesn't happen, to detecting every context switch and storing enough information about them in the movie so that they can be enforced on playback, to saving full memory state delta information per frame. There's probably something in that range that would work. But I'll be avoiding that kind of thing because most of them would introduce verifiability problems or other headaches such as abysmal performance.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Also, there's one really difficult and fundamental problem I've been running into, which is more likely to matter in modern games. The problem is multithreading, or more specifically, how to make a multithreaded game run deterministically when given only a sequence of input. As far as I can tell, these are the only options that have any chance of working:
1: full-blown emulation
2: game-specific options to make them act single-threaded
3: store much more than only the player's input in the movie files and use it somehow on playback
4: only allow one thread to run at a time, and switch between them myself in some deterministic way
5: hope that the other threads don't really matter, and let them run amok
#1, The perfectionist in me likes this one the most. But I assume somebody somewhere is making more progress on this than I ever would and is still far from completion.
#2, I don't like this solution of inventing some hack per multithreaded game engine, but to be honest it sounds the most feasible.
#3, Perhaps this and/or writing their own kernel-level drivers is how Replay Solutions did it, but I really don't want to go there.
#4, Sounds promising, and I've implemented this already, but I haven't been able to find any good-enough criteria for deciding when to switch threads (something always deadlocks). Maybe mixing a bit of solution #2 in is the only way here.
#5, This has been my most successful method so far, but it's obviously not a long-term general solution. Even games that are basically single-threaded tend to multithread their loading screens, which is where I've seen the most problems so far (the actual game itself runs deterministically if I can only get past the loading screen with the same time on the simulated clock). And it would be nice to somehow handle games that do evil things like updating their RNG on a separate thread.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
"...But can it run Crysis?"
Derakon wrote:
Very doubtful. For one reason, Crysis and other modern 3D games probably don't use the same drawing code that this hooks into to get its special code executed.
This would be the easy part. I already have it hooking into many different possible ways of drawing. Adding another might not be trivial but it's definitely possible.
Derakon wrote:
For another, the game state takes up way more memory here, which means that save states would be absolutely painful to deal with unless you have a complete beast of a machine.
This seems like a non-problem. Eventually it won't be much of a problem as hardware improves, and some creative methods of being selective about what to put in the savestates could help too.
That being said, Crysis is not what I would call "simple". It won't happen anytime soon for a huge number of reasons. Certainly not through my efforts, at least.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
It has improved a lot. I think I tried it around the same time and formed a similar opinion of it, but it's one of my favorite emulators now. (And in terms of both compatibility and functionality, it has definitely surpassed No$GBA by now.)
Though, if your computer is pretty old, and if you're trying to actually play games (which I think is not the primary purpose of emulators or games as far as this site is concerned), then you might find DeSmuME still too slow depending on the game. But that's not really a reason to call it barely functional. It can be optimized even more, and people are working on that, but it's a much harder problem than you'd think and the problem is already going away on its own as it becomes less and less likely to find yourself with a computer that's too slow to handle it. And at least now it gives you things like decently-working auto-frameskip options and the ability to turn off one of the screens for a speed boost.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Ferret Warlord wrote:
I don't think it's very open source, but Ikachan is a short, simple game done by the Cave Story guy. Maybe that could help?
The engine is so similar to Cave Story's that there wasn't much left to do to support this too, although it did lead me to fix one bug I'd forgotten about. (I know this wasn't the point of your suggestion, but I guess it's also not a very TAS-worthy game... How not to TAS Ikachan.)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Sorry everyone, I basically haven't even tried to do any work on this project for the longest time (due partly to lack of free time and mostly to a bizarre lack of interest). There are probably only a few weeks of work put into it so far and it could've been ready months ago if I'd stuck to it. But, I'm going to try to make enough time to get back into it now and at least make some sort of progress, even if it has to be slow progress.
mudlord wrote:
Hum the problem here, is that you are editing a game code to make it TASable.
How is hooking APIs via Detours or another library editing a game's code? It does not affect the game itself at all.
I think he was responding to MESHUGGAH's idea. None of those points are real detractors from my (indeed hooking-based) method. (I believe his idea has its own thread now and so doesn't need to be discussed further here.)
Hooking APIs doesn't change the game's code, but it does actually have plenty of potential to affect how the game runs. If done improperly it could cause all sorts of strange behavior, and it's very hard to do it properly in all cases. But that's really no different from the situation with emulators, where perfect emulation is hard to come by and emulator bugs can cause games to do weird things.
ZeXr0 wrote:
SaveState is a problem, because it should be an exact copy of the memory state. Which means you would have to read and write directly to memory the values you want (it will cause conflict at some point)
I was quite surprised with how easy it was to load savestates in running Win32 programs. I didn't really expect it to work, but the first thing I tried was simply overwriting ALL of the program's writable memory (and thread contexts), and actually it tends to work just fine, and quickly. To someone who knows anything about how complicated typical computer software is when you consider everything it's running and how it all interacts, it probably seems outrageous that this method could ever work, but it does. To be fair, there are some refinements required to deal with various things like textures in GPU memory, some of which I'm still working out, and I might yet discover some game that proves impossible to savestate, but all in all it's not bad for a "one size fits all" "instant brain transplant". There are several disadvantages though, so I don't recommend doing savestates this way for anything unless there is no other choice (which there always is if you have either the source code or a real emulator).
scrimpeh wrote:
sticktendo wrote:
Man, if this could work, I'd love to see some more PC game TASes.
Can anyone say "I Wanna Be the Guy?"
IWBTG has the same problems as Kaizohacks. Near perfect play is required to even progress, so any TASing wouldn't be significantly faster than an otherwise perfect non-speedrun and rather dull.
I think the level of play required to merely progress in IWBTG is a lot further from perfection than that. And what little TASing I've done of it so far suggests that there are plenty of little unintended timesavers (things you're unlikely to see outside of a TAS because of how risky they are). Plus, there's enough going on in IWBTG that most viewers probably wouldn't find a quick movie of it dull.
Ferret Warlord wrote:
I was poking around on my hard drive and came across two other games I'd like to see: Seiklus and Legend of Princess.
Thanks, I hadn't heard of Legend of Princess before, I can always use nice little test cases like that.
I am still on the lookout for simple, open-source (and ideally written in C++) games that run on Windows to use for testing. I'm probably looking in the wrong places, but so far the only ones I've looked at have been relatively epic in scope and/or more like a framework than a game. I'd make one myself but it's not something I badly need.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
amaurea wrote:
Kuwaga: The lua scripts never actually make the emulator frameadvance.
This depends on the emulator. It's actually reentrant in Gens and DeSmuME. The Lua script is really calling the emulator's function to advance a frame, there is no outer loop in the emulator that does it while the script is running, there is no "call main lua function" happening every frame, and there's no coroutine yield involved. If two different scripts call emu.frameadvance it in a row, the emulator makes no attempt to somehow merge the two calls into one (they each get what they asked for).
Admittedly, it's a small distinction (each way has different advantages and disadvantages but they behave almost the same most of the time). But I think that frameadvance is not a bad name for describing what it is conceptually doing, either way.
Warp: There is an implicit pause inside the emulator's frame advance function depending on the settings: if not in some fast-forward mode, it will wait enough for the framerate to stay steady, and if the user has paused emulation, it will wait until the user unpauses to return from the frame advance function. Because it's a function call, the Lua script also waits where it was until the frame advance function returns, that's just how function calls work (in the absence of asynchronous madness which is best avoided in cases like this). And frame advance means "run 1 frame" in this context.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Warp wrote:
- Where is the script written to and how do you tell the emulator to use it when running a certain game?
You save it wherever you want and generally browse to it or choose it from a menu after you start the game you want to run it in.
Warp wrote:
- Can you have more than one distinct Lua script running, or is it just one?
It depends on the emulator. In Gens (and possibly some others) you can run more than one at a time.
Warp wrote:
Is there a way to hook scripts to run on certain events instead (eg. keypresses or such)?
You can run a script that hooks various events such as a certain memory location being written to or the beginning of every frame or when a special hotkey is pressed, then the emulator will call the appropriate function your script defined whenever those events happen.
Warp wrote:
- What variables and functions are available for the script to use?
Gens has detailed documentation on what every available function does (it comes with the emulator but gocha is also currently hosting it here). I suggest looking through it because it has some more general information too that might answer many of your questions. Many of those functions are also available in the other Lua-capable emulators, which tend to have their own specific documentation as well.
Warp wrote:
What does "frameadvance()" actually do? (Does it, perhaps, mean "wait until the next frame"? If so, shouldn't it be named like that? As it's named now, it sounds like an instruction for the emulator to advance to the next frame.)
It is precisely an instruction for the emulator to advance to the next frame.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Maybe I was wrong about the position mattering (and I'm sure lag doesn't matter). The requirement seems to be that Sonic must start his skidding animation and then reach a speed of 0 before the skidding animation finishes playing and without turning around. If you're holding down when it happens then he should go straight from skidding to ducking for a few frames and that's your opening.
There's something weird going on, though, because sometimes you can enter a mode where he stands normally on everything and can easily spindash for a while. But this is the trick I did when it would waste too much time to get into that mode.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
I think it has to do with having an X position that exactly lines up with a tile boundary, and also having a small but nonzero X velocity when you duck.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Solon wrote:
I've been trying to watch Waker Boh's Zombies Ate My Neighbors in SNEX9x 1.43+ v17, and it keeps desyncing at the final boss fight. ZAMN is a SlowROM game, but I've noticed that in the movie sync options, the new "Clean FastROM" setting is checked and grayed out (so I can't uncheck it;) is it possible that it's causing the desync, or am I just having random trouble?
If it's not a FastROM game then that setting doesn't apply and doesn't do anything. It's probably something that went out of sync in an even earlier version. It might be worth tracking down what that is... maybe the WIP1 timing option stopped working correctly, or something like that. I've had trouble playing some of my older TASes on these newer versions as well but haven't looked into it yet.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
klmz wrote:
Actually, some games that do run at 60-62 fps don't run smoothly, as if they rushed out 60-62 frames within half a second and then halted until the fps were calculated.
Auto frameskip was dumb enough to do exactly what you are saying in 0.9.4, but that has been fixed in 0.9.5. (Well, let me know if you find a circumstance where it still happens in 0.9.5.) Also, keep in mind that some games don't really run at 60 fps, especially if there are 3d graphics on both screens.
HarryPitfall wrote:
3D games with 3D graphics works, polygons/meshs works amazing, no slowdown.
2D games with 2D graphics works, sprite engine perfect, no slowdown.
2D games using 3D graphics, like castlevanias, the fps slowdown too much.
That's not quite how things are. For example, try Yoshi's Touch & Go. It's 2D with 2D, but it emulates very slowly. There are probably some slow fully-3D games as well.
Basically, CPU-heavy and 3D-heavy games are likely to emulate slowly right now in desmume. Yoshi's Touch & Go emulates so slowly because it uses 100% of the DS's CPU (probably unnecessarily). Order of Ecclesia emulates so slowly because it is extremely 3D-heavy (polygons covering every pixel, and many layers of polygons).
It might be the case that scenes with 3D rendering are likely to draw more layers of polygons per pixel if they have a fixed or 2D viewpoint, which would explain (part of) why things like Order of Ecclesia and NSMB (map screen only) are so slow in desmume.
Anyway, this is not necessarily something worth focusing on. Certain games are heavier than other games, and this will always be true. Currently some games are heavy enough to cross some arbitrary threshold that depends on how fast your computer is. But maybe some general optimizations would be sufficient to push all of these games into "fast enough" territory.
There are various things you can try to make too-slow games run faster, but they will only go so far at the moment.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
arflech wrote:
for some reason most Genesis ROMs use the BIN (undifferentiated binary) extension rather than SMD or GEN
I think BIN and SMD are actually two different formats (the bytes inside an SMD file are shuffled around compared to those in an equivalent BIN file). So it's not just a matter of file associations with those. I don't know whether this same thing applied to SMC vs BIN files, though.
wicked wrote:
i dont know how to change the bios just the directory where the file is located.
It's quite possible that there is no way to change which filename it looks for in the directory, which would mean that the only way to change which bios it uses is to rename the bios you want it to use to "stbios.bin".
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Which visual discrepancy is that? If you mean that the display no longer lags 2 frames behind, that's actually a benefit for TASing (and normal playing for that matter). There's actually an option in the graphics menu to get that same effect without needing a Lua script. But I haven't tried this script with everything else here (especially the jump predictor), so there's probably some other related weirdness I don't know about.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Go into Options > Settings from the menu and choose "BIOS Files" from the dropdown next to Directory, then click Browse and choose a new directory for it.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
I know this is a really minor thing, but on the way to the Wave Cyclone you slide against an edge, which is slower than aiming directly at the corner you're sliding toward. You can get there 1 frame faster by avoiding that.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
SaxxonPike wrote:
One of the sound generators seems to be using a sine wave instead of a square wave - most notably in the Sonic games, using 11a's default settings. Any way to change this back as it was in earlier versions?
I think that's what happens if you have "PSG High Quality" enabled in the Sound menu. I'm not sure how that got to be on by default, it definitely shouldn't be. Perhaps most people haven't noticed it yet if the setting is carried over from a previous version of Gens. It will be off again by default in the next Gens release, whenever that will be.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
I'm not sure if this is the best way to do it either, but here's how to get past the training level a bit faster (timer at 463, or 50 real frames faster due to the ending).
Also, keep in mind that the touch screen might be the fastest way to move Sonic around on the island. I think it's the same speed as holding B (if it's not too close to the center) but with better precision.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Cruizer wrote:
nitsuja wrote:
It might actually be impossible to even get below 1:50:00 without intentionally dying some number of times in order to manipulate luck, and I'm not sure what to do if that's the case.
Well if SDM/mike89 and the rest all get those times, it has to be possible as they are all very trustworthy. Maybe it has something to do with Story Mode vs. Time Attack Mode?
It probably has more to do with the fact that they are able to try over and over until they get the best possible luck, whereas a TAS can't do that without subjecting the viewer to watching all of the "failed attempts" that are used to manipulate luck. And it would be a shame if that were necessary, so I'm trying to avoid it. It seems like nothing else affects the randomness here, since nothing before the boss uses the RNG and it doesn't start in a random state, but I'm not completely certain of that yet. Possibly the only way to be completely certain about it is to understand the code that leads to the boss choosing its actions.
Cruizer wrote:
And if i recall correctly, the last set of rolling is faster than the previous ones. So i think the 1+1+4 is better.
It's still not good enough, though. And one of the times on TSC, not even the fastest one, claims to have been gotten with 1+1+3. And now that I think of it, maybe that 1+1+4 I saw was really a 1+1+4+2 or something equally bad, since I think whenever I change the second set from 2 to 1, the boss tacks on an extra set of rolls to compensate.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Paused wrote:
So... has there been anything worth showing off, of the Blaze run or progress on Sonics run?
The only progress so far is getting 0:26:33 on Leaf Storm 1 and 0:29:43 on Leaf Storm 2. I don't know if it's worth showing off yet.
Cruizer wrote:
Have there been any new developments with the Leaf Storm Boss? (I would love to see what you do while you wait for an attack opportunity too x3)
Well, I'm still trying to figure out how to get anywhere near 1:43:72 (the current record here). It might actually be impossible to even get below 1:50:00 without intentionally dying some number of times in order to manipulate luck, and I'm not sure what to do if that's the case. I've found that the number of time-wasting rolls the boss is about to do gets stored at address 0x20902E8, and that the boss can sometimes "change its mind" about how many rolls to do depending on where you are standing relative to the position the boss last attacked at and how close that is to either edge. (And a value that might be related to which random sequence the boss is currently following is stored at 0x20902DA.) In order to get a good enough time it seems necessary to manipulate the boss to do no more than 5 rolls in total (and preferably fewer) but the best patterns I've ever seen so far are 1+2+3 and 1+1+4. Anyway it seems like it will take some serious analysis of the code to be certain, and... I haven't started doing that yet.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Sonikkustar wrote:
I tried the Backwards Air Dashing in this game and it seems to be much more severe than its prequel.
I think it's exactly the same, actually. (By the way, you can get a slightly higher average speed by letting go of the rush button after 2 frames each time, although this really eats up tension.)
Sonikkustar wrote:
I dont know a lot of info on this game (RAM Addresses, Glitches,etc.). If anybody has some knowledge, can you please tell me?
Here's a Lua script that shows some useful values from RAM:
-- info display script for sonic rush adventure (needs desmume 0.9.5 or newer)
local drawinfo_y = 10
local drawinfo = function(msg,val,xoff,xoff2,color)
gui.text(180+(xoff or 0),drawinfo_y,msg,0xffffff3f)
gui.text(220+(xoff2 or 0),drawinfo_y,val or _G[msg],color)
drawinfo_y = drawinfo_y + 10
end
gui.register(function()
if input.get().capslock then return end -- makes caps lock hide the display
local baseaddr = memory.readlong(0x02133884)
local xvel = math.floor(memory.readlongsigned(baseaddr + 0xBC) / 16 + 0.5)
local yvel = math.floor(memory.readlongsigned(baseaddr + 0xC0) / 16 + 0.5)
local speed = math.floor(memory.readlongsigned(baseaddr + 0xC8) / 16 + 0.5)
local tension = memory.readwordsigned(baseaddr + 0x5f8) * 300 / 4800
local time = memory.readword(0x021338C8)
local xpos = memory.readlongsigned(baseaddr + 0x44) / 4096
local ypos = memory.readlongsigned(baseaddr + 0x48) / 4096
local angle = memory.readlongsigned(baseaddr + 0x34) * 180 / 32768
angle = angle<180 and -angle or 360-angle
if -angle == 0 then angle = 0 end
local topontop = memory.readlong(0x02133AD0) < memory.readlong(0x02133B40)
drawinfo_y = not topontop and 20 or 20-192
drawinfo('speed', speed)
drawinfo('xvel', xvel)
drawinfo('yvel', yvel)
drawinfo('angle', angle)
-- drawinfo('rush', string.format('%.1f%%',tension))
-- drawinfo('time', time)
gui.text(0,not topontop and 46 or 46-192,string.format('%.1f%%',tension))
gui.text(152,not topontop and 17 or 17-192,time)
drawinfo('x', xpos, 0,-30)
drawinfo('y', ypos, 0,-30)
end)
It looks like this while running:
Note that "speed" means "ground speed", not "current speed". It stores a velocity value that will kick in the next time you touch the ground if it exceeds your actual velocity. "angle" is in degrees and represents Sonic's current rotation around the z axis. "x" and "y" are in pixels.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Dromiceius wrote:
Maybe somebody should hack together some unit tests using Lua so that end users don't trip over these kinds of bugs?
for rom in ListOfRomsToTest do
start recording to a movie file
generate random input for N frames, saving and reloading furiously, and checking that the memory state is deterministic...
Provide useful debug info on memory state mismatch
Just a thought.
That has already been done for 0.9.5 (unlike 0.9.4), and every mismatch found in this way has already been eliminated (dozens of them).
I admit the script was not run for a huge list of ROMs, only for maybe 20 of them so far, but the DS isn't like the NES or SNES where there is a wide variety of different hardware on different ROMs, so it's unlikely that very many desyncs remain that would have been found in other games. But if anyone notices desync problems in some particular game, please let us know which game it is so that we can run the script on that game to check it out.
As gocha said here and I said in a different post on this forum, the most likely reason anyone would encounter desyncs now is because of loading the wrong savestate while in read-only mode (recording is bulletproof but playback isn't yet). And that is a problem that is not new to this version, and in fact some other emulators still have the exact same problem.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Hiding the game's HUD without causing desyncs is definitely possible in Gens. Here's a demonstration script that deletes the whole player object in S3&K without causing desyncs (Sonic is invisible but you can play normally or watch movies):
local function dostuff()
-- you can write whatever you want here to cause visible effects.
-- trash all the RAM if you want, it won't cause desyncs.
-- in this demonstration, I'll delete the player object to make Sonic invisible:
memory.writelong(0xffb000,0)
end
local tempstate = savestate.create()
local incallback
gens.registerbefore(function()
-- display a "fake" frame
if incallback then return end
incallback = true
savestate.save(tempstate)
dostuff()
-- run for 2 frames because that's the display latency of this game
local frames,attempts = 2,0
while frames > 0 and attempts < 8 do
gens.emulateframeinvisible()
if gens.lagged() then
attempts = attempts + 1 -- run an extra frame for each lag frame
else
frames = frames - 1
end
end
incallback = false
end)
gens.registerafter(function()
-- advance to the next real frame without drawing it
if incallback then return end
incallback = true
savestate.load(tempstate)
gens.emulateframeinvisible()
incallback = false
end)
gens.registerexit(function()
-- restore the state if we abort while things are messed up
if incallback then savestate.load(tempstate) end
end)
I'm pretty sure that can be modified to hide the HUD instead of the player and to work in Sonic CD instead of S3&K.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Raiscan wrote:
Just out of interest, have you found anything interesting with the boss(es)? Or have you been focusing on Act 1 and 2?
Just the first two acts so far. Well I tried the first boss but it seems it will be a very controlled boss fight that will still be boring even if it's possible to manipulate luck perfectly.
I also tried Blaze a bit. In a TAS her gameplay will be incredibly different from Sonic's. A spindash jump gets her up to higher speeds than rushing, she can't gain speed by jumping and pressing R, and the huge speed on hills trick probably isn't possible (because it relies on that move). She can however user her horizontal R trick to reach 5000 or so speed (in situations where Sonic can't always go that fast), which is only supposed to last for an instant but can be kept by doing it exactly flush with the ground and holding backwards. And of course her up+R tricks shoot her way high up into the air and her R move hovers which makes it possible to take shortcuts everywhere. Maybe the best place for Blaze is as part of a 100% TAS though? Or would it be better to put her in a separate movie, or tack it onto the end of an any%?
Raiscan wrote:
Edit: I suppose I should ask: with this glitch is it possible to underflow sonic's position and wrap around the level (a la sonic 3 & knuckles)?
Nope, it looks like they finally removed that feature. I was able to slam into the left boundary of act 1 with an x velocity of -20000 or so, but nothing much happened.
Note that "speed" means "ground speed", not "current speed". It stores a velocity value that will kick in the next time you touch the ground if it exceeds your actual velocity. "angle" is in degrees and represents Sonic's current rotation around the z axis. "x" and "y" are in pixels.