Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Oh yeah, I remember this place now. It doesn't look like it's possible with Sonic. And it's too bad Tails can't start flying while exiting the wall either, or he might be able to impart all of that zipping velocity to Sonic by catching him.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Nice job... Those extra shortcuts seem so obvious now.
I'd like for the whole thing to be redone at some point, for the same reason that most other TASes don't keep so much input throughout revisions, and at the very least it would be nice to get rid of the ugly-sounding manipulation pauses that have accumulated in-between levels. But this seems like a very valid improvement in the meantime.
marzojr wrote:
I can get Sonic and Tails both onto the wall and I can zip Tails past the left edge of the screen, but Sonic always loses all speed just after he gets out past the left edge of the wall.
I don't know if this will help (maybe you've already considered this), but I think it depends almost entirely on the exact X coordinate that Sonic has when he's first in the wall. If you can get him in there a little more to the side somehow, that might be enough to prevent him from intersecting with the wall edge on the way out. Also, mixing regular zipping with spindashing and/or turning around can sometimes change the coordinates enough.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
There is probably no reason why the games mentioned so far such as Elastomania or Eternal Daughter shouldn't be able to work, it's mostly just a matter of making sure my code is bug-free enough for them to run, and making sure I have all the basic drawing and input methods handled. Generally, the fewer bugs and oversights there are, the more games will naturally work (this is quite similar to the compatibility situation with emulators, come to think of it).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Comicalflop wrote:
Wow. You didn't just beat my time. You BEAT my time.
I'm guessing you used 9.4+? The differences in lag really showed.
Out of curiosity, could you also post the .dsm? So many things happened so fast, I want to see in frame advance what things you did differently and while watching speed.
Not 0.9.4+, a 0.9.5 interim revision. (link removed because it's sync-compatible with the official 0.9.5 release). Here's the dsm. (I recommend turning on "SoftRasterizer" in the 3D settings and "Synchronous" audio ("N" method) in the sound settings, in this version of desmume.)
I also found a place to get high enough speed to glitch out the spiral vine (avi/dsm). I did something close to this in real-time once and was totally confused by what had just happened. With a little tweaking it's possible to exceed speeds of 15000 and keep most of it while jumping, but unfortunately this particular spiral is way off-route and too low for all that speed to be useful.
Cruizer wrote:
Just one that really got me was that you were able to BLJ up to those set of 3 trick rings. What kind of speeds were you getting there?
It was about 8000 speed (slowly decreasing from that peak). (That's 31 or so in the old speed units.) EDIT: I think it's not just because the speed is so high, but because Sonic just passed through a booster. I thought boosters didn't do anything if you're going fast enough already, but it seems they greatly reduce your deceleration for a while.
Cruizer wrote:
Also i think some time could be saved at the vertical jump. You don't really have to hold left that early. In fact I just pulled that jump off with 3 frames holding Left.
I'm not sure yet how the game decides if you're able to turn around. My guess is that it simply depends on your current speed (EDIT: confirmed, speed must be less than 3072 to turn around), and I was going too fast so I had to hold left for much longer to reach a low enough speed that it would let me boost backwards.
N. Harmonik wrote:
I don't suppose you're gonna collect all of the Emeralds (which would mean playing as Blaze as well) and defeat the true final bosses?
I guess I'm not that interested in getting all of the emeralds in a TAS, but I do think Blaze's playing style is different enough to be worth TASing somehow.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
So actually, after seeing that 0:33:15 video, I couldn't resist trying to improve on that. Here's the first attempt, 0:30:35, and there's definitely more than half a second of mistakes. Here's an incredibly lazy encode.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Comicalflop wrote:
Ah, thanks for finding those. I mostly just was trying to find the first address that showed speed so that I could make a test run of the first stage. Out of curiosity, are these addresses the same throughout the entire game? I know that many recent GBA games have the speed address change per level or per room.
I think they stay the same. They also worked for Blaze in a different level, at least.
Comicalflop wrote:
Do you have any interest in doing a run of this game?
Yes. I don't know when I'll get around to it, though, since I have this to work on and several previously-started TAS projects as well.
The sequel to this game might make a good TAS also although the sailing will surely bog things down in-between levels.
Comicalflop wrote:
Also, I haven't checked yet, but desmnume 9.2 made the stage very laggy. Recent versions may have fixed this, but I'm not sure yet.
I would use desmume 0.9.5 for this (when it comes out, which I think should happen soon). Most of the extra lag is gone there and it also fixes lots various graphical problems in this game (at least it does if you switch to the software renderer instead of OpenGL).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
TNSe wrote:
How would this work in conjuction with say DosBox (via D-Fend Reloaded) emulating older DOS games?
This sort of thing could in theory be used to TAS any non-rerecording emulator that runs on Windows. If the emulator starts up in a simple enough way (like, it automatically starts running a game when it opens) then there's a small chance that it's supported already. However, it would probably take a lot of extra effort to make it actually work. Emulators generally fit into the "not really a game" category and there are some major issues that would need to be solved first to allow such programs to work.
Raiscan wrote:
Might I suggest a name for this program?
Hourglass.
Hmm... maybe. Although time is only one of the aspects of this (savestates and movie/AVI support being other major things that are perhaps less common than time alteration). Right now I'm simply calling it "winTASer" which might do but I suppose it's not very creative. Maybe "Hourglass" is better... does anyone have any other suggestions?
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Those aren't quite the right addresses to be watching for speed. It's almost right, but you're losing a lot of precision by only looking at 1 byte of it. You should actually watch these addresses (they are 2-byte signed):
020907E8 : x velocity
020907EA : y velocity
020907F4 : speed
Also, 020907F0 appears to be identical to y velocity except that it becomes 0 when you're not jumping, so that seems kind of useless except maybe for detecting whether you're jumping.
EDIT: Found a couple of others (2 or 4 bytes, unsigned):
02090B10 : tension
02091EBC : time
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
You can actually do it from inside the emulator in Gens. Upthorn would be better able to describe the Input Splice command than me, but I've used it a few times and it's kind of handy, although being able to see the input in a hex editor tends to be better anyway if it isn't a simple thing you're doing.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
CyberShadow wrote:
I have mentioned here why I don't think that a VM is viable for practical TASing.
OK. Those are good points, although I think a VM could be given special modifications to make it more practical for TASing. But it would have its disadvantages anyway... There's a reason I didn't go with that approach either. You're definitely right about the speed advantage of doing it this way: Cave Story playing out at 5000+ frames/second has to be seen to be believed, and you probably can't get that sort of speed any other way. (It might sound useless to be able to go that fast, but believe me, it saves boatloads of time while TASing, albeit partly due to one of the aforementioned limitations of savestates.)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
I guess I might as well admit to being the mystery project lead (before things get too awkward here). And I'll add a few more details for those who are curious (I won't bother withholding very much information, since surprising people later is not really my goal):
It records keyboard input per frame to a movie file. This isn't an AVI-editing based approach.
All of the usual TASing tools are present. This includes pause, frame advance, savestates, (really-)fast-forward, read-only movie toggle, RAM watch, and AVI dumping. There's no Lua support yet but that's surely possible.
Eversion is an SDL game, so hopefully that shows that this isn't limited to only DirectX games.
La-Mulana is working quite well in addition to the games shown in the above demo AVI. Various other games (such as IWBTG and Iji) are getting close.
There's no kernel-level programming involved here. It doesn't run any special drivers or even use any windows hooks. There's also no emulation, it's simply running the game natively.
There is no game-specific hacking or reverse-engineering going on (not even for savestates). The program tries to do the same general-purpose thing for all games (which does not involve changing/transforming the game's code, by the way) and that either works for the game or it doesn't.
It's limited to "simple" windows games at the moment partly because each technology (directx, opengl, etc.) has to be supported separately and it's easiest for me to focus on the technologies used by simple and freely-available games first. But I would say that games definitely become too complex to support at the point where they involve online integration and DRM and cheat-detector agents... I really don't want to deal with that stuff. And things that aren't very game-like probably won't be supported either, so this program isn't going to be able to TAS itself anytime soon. Finally, in the event that I am unable to solve "the multithreading problem" then this approach might be forever limited to games that do not make extensive use of multithreading.
About the complications mentioned, they are hard problems but I think that all of them can be worked around and some games will still be completely TASable even in the worst case that none of them are solved.
My guess is that eventually a true x86 emulator (or some VM-based solution) will surpass this in reliability and TASing utility, and if anyone else is working on a project like that, I hope they will continue so that we can reach that point. I think this is probably a more workable solution for the purpose of at least making some of these windows games TASable in the near-term future, however.
It's a very small and simple project so far (with very few if any library dependencies) compared to just about any emulator out there. I plan to open-source this thing, as soon as I get it presentable and work out whatever kinks I'm currently working on. I won't make any promises about how soon that will happen, though.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Bag of Magic Food wrote:
Well yeah, there's all kinds of stuff you won't do in a speed run when it's "not required"... Kind of an odd condition to put on your answer to this question.
I don't see what's odd about it. Speedruns constantly do things that aren't required to beat the game, because those things allow them to beat the game faster than normal.
I'm saying that, for the set of DS games which can be beaten without closing the lid (which includes almost all DS games), I suspect that TASes of those games will never close the DS lid to save time, despite the potential it technically has to save time.
I think there is a small but nonzero chance that I will be proven wrong by someone who finds a way to take a shortcut by closing the DS lid. I doubt it will really happen. (But it might be a good thing for people TASing DS games to check for, just in case, to make sure they're really taking all of the possibilities into account.)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
gocha wrote:
AVI recorder tries to add samples at every frame. 32 kHz will cause audio desync since 32000 cannot be divided by 60.
That sounds like just a bug though. One can add any amount of audio samples per frame to an AVI. It does not need to divide evenly into anything in order to add up to the correct amount.
(Not to emphasize this too much... it's not all that important.)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Closing the DS lid in a game at a moment where doing so is not required to advance.
The game receives what is basically an input signal and runs some extra code as a result before entering a sleep mode. If it receives the signal at an unexpected moment, this might potentially cause it to decide to run some buggy code, or skip a cutscene or something. But it seems so unlikely to actually be useful, considering that most games choose to immediately go to sleep or do something really simple like play a voice clip.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
gocha wrote:
Also, a new sync flag is added to SMV. Most SMV editors might not care about the new flag byte. Be careful, or you might experience a desync.
This doesn't apply to 1.51. The flag is now logically there at that location, but it is unused and should be 0, and that's the same value that used to be there before, so I think there is no change here.
gocha wrote:
[*] Windows: Do not set frequency to 32 kHz, before you start writing a video to AVI. That will cause a audio desync. Use 48 kHz instead.
Is this just a bug in Snes9x? I think the real SNES uses 32 kHz, so that sample rate should sound more accurate, and I don't remember having audio sync trouble with changing the AVI output sampling rate in other programs.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Another reason to use 1.51 is that several games can't really be TASed in 1.43, and 1.51 makes it possible (by adding support for recording peripherals and/or fixing bugs that would obscure gameplay). I'm not sure why people haven't been TASing those games, though. Maybe it's because they don't realize that it's possible because they're still using 1.43.
I'm a little pessimistic about people completely switching over for all TASes though. A lot of games lag more, so the version switch really gets in the way of comparing to previous TASes. Even if you don't need an exact comparison, people are still reluctant to work on a TAS where at the end all they will have to say for themselves is "This should have been X seconds faster, but because I also switched to Snes9x 1.51, it's actually Y seconds slower than the previous version instead... but please accept it anyway."
AngerFist wrote:
But then, a hero entered the arena, his name was gocha! A sneaky little japanese fellow who actually fixed (!) the desync issues.
Hey, I fixed a whole bunch of desync issues in Snes9x 1.51 too (in gocha's branch). Sorry this happened later than it should have, but I didn't have a good technique for fixing them at the time 1.51 first came out. Not to downplay all the great work gocha has done (and is doing (and, understandably, would not like to have to keep doing for 1.43)) to maintain and add so many features to both versions, of course.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Another hint is that you can quickly narrow things down with a search on the "number of changes". This is especially useful if you don't have any clue what kind of value you're looking for or which direction it might be changing, but you have some idea of when or how frequently it changes.
For example, suppose you want to find out how many hit points your character has in a game that keeps it hidden. What you could do is bring up the search dialog, then switch to the game and let yourself get hit 5 times, then switch back to the search dialog and click on "equal to", "number of changes", and type 5 in the box and click "search". You will be left with a list of numbers that have changed exactly 5 times in that duration, which will probably be a small list, and you can watch them change a bit more and then pick out the ones that look useful and add them to the RAM watch for future use.
You're not guaranteed to find the value you're searching for because you might have made a wrong assumption (for instance, maybe the character regenerates hitpoints gradually, which will increase the change count above 5 if it kicks in), but then you can always alter your search parameters to take into account some uncertainty.
This method also works for continuously-changing things like your character's current speed. For example, you could make your character stand perfectly still for a while and do a search for "equal to 0 changes", then walk around for a while and do a search for "greater than 60 changes". If the character's speed changes smoothly and you walked back and forth for a few seconds, then it's a safe bet that the speed value changed on more than 60 of those frames at the very least. Usually you won't know exactly how many times it changed but you can be sure that it's within a certain range. You might still have a lot of results left at this point but then you can switch to more traditional methods like eliminating values that are zero while you're moving or nonzero while you're standing still, and you'll have fewer useless results to wade through.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Heisanevilgenius wrote:
For those in the know of exactly what the underflow glitch is, maybe this is an important distinction, but it seems pretty odd to avoid it and still use other glitches that have the same basic function.
...
I just don't see why it should have some zip glitches and not others.
They aren't both "zip glitches". Zipping gives you high speed, whereas horizontal overflow doesn't change your speed at all and it simply teleports you to the far right side of the entire level. (I'm just clarifying that, not bringing up an argument to your main point.)
I guess I was the one that suggested making the distinction in the first place, and to not bring Tails along, both of which people are complaining about here. I suggested those mainly because they would force this run to be different from the existing Sonic+Tails run, not because I thought it would please people that wanted a glitch-free run. TASes that are largely identical to other TASes (that they are not attempting to obsolete) tend to be poorly received, after all. And I was curious as to what a run that has Hyper Sonic going all-out through the levels would be like.
By the way, I was somewhat joking about that script to "remove boring things". Certainly I don't think that all parts where Sonic is even slightly offscreen should be excised, and you'd probably miss out on significant parts of the run by watching through it with the script as I posted it.
EDIT: I checked at an arbitrary place and found 6 frames were lost at the end of FBZ and another 30 or so at the start of Sandopolis Zone. It's quite possible that neither of those adds up to any overall time lost (due to "frame rules" from timed objects) but I get the feeling that this run could've been more precise. On the other hand, I was impressed by several things in it and it does improve on certain things from the existing Sonic+Tails run. I don't know what to think about how it turned out as far as being entertaining. There were some unique moments (like skiing Super Sonic) and Hyper Sonic was indeed very fast in the last 1/3 of the movie.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
To start with, I would suggest not using such an old development environment as Visual C++ 6. Try getting Visual Studio 2005 or maybe 2008 and using that instead. (Microsoft provides free versions of them per language, and the C++ ones are actually pretty fully-featured.)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
marzojr wrote:
* That first timed object -- is its position determined by luck, a frame rule or something else? Fo far, I have been trying to manipulate it but not having much success.
I believe it's simply a function of a timer that starts when act 1 starts and keeps running until the end of act 2. In my run, I could have started act 2 earlier, but I purposely delayed entering the door long enough for the first timed object to not be in an inconvenient position. (I think SprintGod did that too but I can't remember.) If you get there at a really bad time then it might be necessary to do something more extreme like spindashing in the wrong direction from the door in order to delay the timer long enough.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
It's hard to judge developer intention sometimes. Maybe the developers wanted it to be that fast, but the people marketing the game handed down a requirement that the game must be X hours long, so the developers were forced to slow it down artificially, and they put the way they really wanted the game to be played in a hidden menu. Not that I know anything about this specific case or have even seen this code in action, but I bet that sort of thing has happened before...
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Since the cheat is provided by the game (it's not out-of-game manipulation), and it doesn't even change the gameplay, then why should it be considered a cheat at all (as opposed to an "option" or "secret option")? And what if the same option was directly on the main menu? Why should the name or location of an option change how acceptable it is to use it, as opposed to what it actually does? Also, if it did change the gameplay, it would easily be accepted if you could make an argument that it makes the game more difficult in any way, so it seems odd that something that changes even less than that would not be considered.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
upthorn wrote:
That is correct. Frame advancing doesn't utilize a window message. Neither does the fast forward key.
The reason for this is because it has to be continuous if the key remains held down, and hotkeyed window messages are only sent on first press.
Well, actually Windows does key repeat for those which are the reason some of the the very first implementations of frame advance in emulators had the continuous advance functionality... I think the actual reason is that now it's possible to assign hotkeys to things that aren't even keys such as mouse clicks or joypad button presses (basically any checks that have to go through DirectInput and bypass Window messages), and we wanted consistent repeat behavior even for those things, at least in the case of frame advance. That, and it's nice to be able to control the key repeat separately from the system global key repeat, since it doesn't make that much sense for your system key repeat setting to affect TASing advance speed.
EDIT: I would think it'd be better to not try to synchronize things like which hotkeys are being pressed, and instead only synchronize the movie file and the current frame count. With the exception of saving and loading savestates, which has to be synchronized more directly.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Kuwaga wrote:
Can lua handle mutexes and memory mapped files? That would make it more powerful than I had thought. I can't imagine this working at all without mutexes or mapped events. (I only use mutexes atm, which might be inefficient, but atm my primary goal is to get it to work at all)
It has a basic "fopen" style interface in its very minimal default library, which actually should be enough for this (I'm not saying it would be pretty or as fast as could be), but it's also easy to call C code from Lua, so you could either find or make a DLL that wraps mutexes or sockets or whatever and call functions from that, or you could make a small edit to the Gens source that defines a few short functions for those, then do the rest in Lua. I'm not recommending doing this particular thing in it especially since you're so far along already without it, just asserting that it's certainly possible.
