Posts for nitsuja


Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)
Joined: 12/21/2004
Posts: 2687
Kuwaga wrote:
Yes, I'm quite sure lua can't do it.
Actually, it all sounds doable in Lua to me from what you've described. I'm not 100% sure about the "more easily" part, though.
Kuwaga wrote:
Edit: I have checked the inputs in the cases I got a desync, but they were still perfectly the same for each frame. So, I now think the desyncs are caused by something that has to do with the emulation itself. The only difference in some of those cases were different amounts of lag frames, regardless of them having used the same input. Any ideas on how to fix this? Does input between two frames affect the RNG?
I think it'll hard to be sure what's going on until you have it working with re-recording. I still suspect that, if they had been recording to different movie files, a binary comparison between the movie files would show some difference in the cases that desynced. (It's been quite a while since I've seen Gens ever desync on its own like that, even with massive savestate use.) Input changing in-between frames could screw things up, but if you're only setting the input at the normal time then that shouldn't be happening.
Post subject: Re: Lua in emulators
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)
Joined: 12/21/2004
Posts: 2687
Xkeeper wrote:
I wasn't saying that you shouldn't be able to check movie input at all! Just that it isn't consistant anywhere.
Oh, I know, I was just giving my opinion on what I thought would be best to standardize on.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)
Joined: 12/21/2004
Posts: 2687
What exactly are you trying to do? Are you sure it can't be done more easily with a Lua script? Well, to answer your question directly even though it sounds like you're doing something weird, I think what you did didn't work because Update_Controllers runs right after the code you changed, and it calls SetCurrentInputCondensed which overwrites the effects of any calls you made to SetCurrentInputCondensed on the same frame, so you'd have to edit Update_Controllers instead of Update_Input to make it stick.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)
Joined: 12/21/2004
Posts: 2687
Try watching some S3&K movies with this script. It attempts to detect and eliminate "boring things", such as special stages and zipping and super music... (But don't run it at the same time as that other ghost script I posted earlier. I think there's some bug in Gens I didn't know about until now that causes huge obvious desyncs if those two scripts are both active.)
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)
Joined: 12/21/2004
Posts: 2687
Xkeeper wrote:
nitsuja wrote:
There is an updated binary in the downloads already which has had input.get and a bunch of other additions for a while now. At the moment this is "snes9x-1.43-rerecording-svn-r98.zip" or "snes9x-1.51-rerecording-svn-r67.zip" in the downloads list (depending on whether you want to use 1.43 or 1.51), the same as or only slightly older than the latest trunk version.
That should really be put onthe front page somewhere.
That would be easy to do but I'm guessing gocha has some reasons for not wanting them to be featured downloads quite yet. They were renamed/updated to "snes9x-1.43-rerecording-svn11.zip" and "snes9x-1.51-rerecording-svn11.zip" since my last post, by the way... so just look for the most recently modified ones, I guess.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)
Joined: 12/21/2004
Posts: 2687
Very nice find on Carnival Night 2. This gives at least one substantial thing to change in any further revisions of the other TASes. Oh, maybe you just stopped entering new input before this, but the cannon launch from Carnival Night 2 to Ice Cap 1 should be done faster.
Paused wrote:
...basically a zip a thon like the current run... seeing the tile sets for each stage scroll by...
I don't feel like that's a valid description of anything, because most of these runs are not spent zipping. The zips are over very fast, with the exception of the "going around the level instead of through it" cases (which are more teleports than zips), and this run is omitting those. Sure, they replace a lot of gameplay, but what you see right away after each one is other gameplay... Part of the reason for not including Tails was that Tails is required for a lot of the glitches, therefore it forces showing more of the levels. (And if we're trying to show off Hyper Sonic's capabilities then Tails would probably be dead weight most of the time.) A totally glitchless run would be a separate (and very much longer) run, although I'm not trying to argue against it being attempted.
NrgSpoon wrote:
I feel the need to mention that sometimes in my general playthroughs, I've managed to go super/hyper without it changing the music.
I think it's as simple as going super/hyper right as the "got an extra life" music starts to play. For example, on the exact frame that you get a 100th ring.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)
Joined: 12/21/2004
Posts: 2687
There is an updated binary in the downloads already which has had input.get and a bunch of other additions for a while now. At the moment this is "snes9x-1.43-rerecording-svn-r98.zip" or "snes9x-1.51-rerecording-svn-r67.zip" in the downloads list (depending on whether you want to use 1.43 or 1.51), the same as or only slightly older than the latest trunk version.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)
Joined: 12/21/2004
Posts: 2687
3 (fast). I'm the one that added the option to set the compression level, so I'm pretty sure there's no more speed to be gotten out of tweaking it from what I used. It used to be even slower before that option was added (was hardcoded to 6 IIRC). EDIT: I tried 1 (fastest) and it wasn't measurably faster, and switching it to completely uncompressed made it noticeably slower. EDIT2:
Xkeeper wrote:
- Gens's method is a bit weird (fill first, then outline, so drawing a hollow box is slightly annoying)
I think it's better to have the more important one first, and the fill is probably more important since it makes a bigger visual difference. And I don't think a totally hollow box is a sensible default, there should be at least some partially-opaque fill or else it's too easy to get your boxes confused or overlook them, especially for hitboxes. And gui.text has fill first, outline second, so this order is more consistent with that.
Post subject: Re: Lua in emulators
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)
Joined: 12/21/2004
Posts: 2687
I feel like the biggest problems are more the cases where you realize "oh, I can't do this at all in this emulator". Or cases where it's technically possible but won't work anywhere near as well. For example, savestates in Snes9x are more than 100 times slower than savestates in Gens for some reason, so a lot of scripts that would work well in Gens aren't really practical to run in Snes9x, and nothing can be done about it from the Lua side. (Some numbers from my quick tests: - Gens savestate save: 0.3 milliseconds - Gens savestate load: 0.3 milliseconds - Snes9x savestate save: 21.7 milliseconds - Snes9x savestate load: 41.7 milliseconds) Lack of "print" console functionality in non-Gens emulators is probably the most annoying and debilitating difference I've noticed so far, though. Having to debug with modal popup dialog boxes instead of real logging is painful. It's possible to work around that with enough effort but it's a big waste of time to accomplish something that Lua is supposed to have a working function for already. (And don't say that "print" is only supposed to go to stdout... Lua actually recommends replacing print with a version that instead goes to something like an application-specific console window.)
Xkeeper wrote:
- Change EMULATORNAME.command() to "emu.command()". There's little sense in having 3 (4, 5, etc) variations on the same commands.
That's sensible. Although it's easy to get the same result by adding something like "emu = emu or gens or snes9x" at the top of every script, this would make for one less thing to worry about.
Xkeeper wrote:
- Bump FCEUX up to use full 24-bit color like SNES9x and Gens. This will greatly increase the flexibility with Lua painting, remove the huge speed penalty for drawing (every non-named color is a speed hit because it has to look it up; this is especially noticable if you do a lot of pixel(x, y, "#FF0000") v. using "red").
I'd call it 32-bit color, since 24-bit color would be missing the alpha component, and it's quite useful to have full alpha transparency control in the drawing functions. But that speed comparison you give is a bit weird. I guess FCEUX does some really inefficient color conversion for "#FF0000" to be noticeably slower than "red". Well, the fastest thing even with 32-bit color is to use numbers instead of strings, so for example 0xFF0000FF for 32-bit color red would be fastest since it avoids allocating any memory or going through string tables at all.
Xkeeper wrote:
- Make all the commands actually work the same. Does joypad.read read the user's input, the movie's input, or the input set by joypad.set? Choose one and make it a standard.
I think it's really bad when it's not able to read the movie's input, since then a script that works fine when you're recording will totally fail when you try to play back the same input since it's not getting the button presses anymore. So I'd say joypad.read should always get the same buttons the emulated game is getting (whether they come from the user or from movie playback), and things that need to know what buttons the user is trying to press even when the emulation is normally supposed to ignore that input should use a different function for that special purpose (that's what joypad.peek is for in Gens).
Xkeeper wrote:
(For example you could create a basic hitbox drawer that just took 4 memory addresses and drew them to the screen without having to modify the rest of the code).
Sorry to pick on this particular example, but... 4 memory addresses? I think that having a "drawbox" function already covers most of the cross-game code reuse you could get out of hitbox drawing code, and that there's not much point attempting to generalize something that's so commonly vastly different from game to game, especially when going across platforms.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)
Joined: 12/21/2004
Posts: 2687
marzojr wrote:
How do I go about doing that? So far, I have been using multiple emulator windows, all synchronized to about the same spot in the different runs so I can compare how things are going (and all watching the relevant RAM addresses); but the ghost images of other savestates would definitely be interesting.
Well, try saving this Lua script (download link) and running it in Gens, then TASing like normal. You should notice it working right away for comparing against yourself for any savestates you make going forward, which I think is already pretty useful. Note that you need Gens11a or newer for it to work, it will be kind of broken if you try running it in Gens11 instead of Gens11a. This script can also already handle comparing against other (existing) movies, but that takes a little extra setup since you have to actually provide it with the ghost data for those movies. The comments say how to add in ghost data (start running the script, start playing the other movie and fast-forward until the end, save a state, then rename the newly-created .luasav file in your savestates directory to something in-between "YOURROMNAME - YOURMOVIENAME.gs10.luasav" and "YOURROMNAME - YOURMOVIENAME.gs14.luasav") but I can provide that data later if you want, possibly in a Lua-only format instead of .luasav if that would be easier.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)
Joined: 12/21/2004
Posts: 2687
Warp wrote:
Of course this category would have to get an official status before people will attempt such runs.
That's the part I'm not sure about. Someone could certainly try it, and hopefully there's more that goes into judging the result than whether it fits into a category that has an existing official status. What would an official status guarantee, anyway? That we wouldn't instantly reject a submission without even watching it? But that's probably already the case. The only thing reassuring enough to motivate some people to try it would be precedence, which isn't something we can just suddenly decide. And actually, I can think of at least one example that's precedence suggesting such runs could possibly be accepted... EDIT: What I said above doesn't exactly cover the whole "playaround run" idea, only the "low glitch" idea. But I suspect those would be fine as well, as they already are accepted on a case-by-case basis for fighting games and certain other games.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)
Joined: 12/21/2004
Posts: 2687
arukAdo wrote:
Name it "test.dsm" the answer is in the question actually There is no warning that you dont use .dsm, its a text file anyway, could use txt extension wouldnt change anything Also, when you click replay movie, be sure the dropbox show All Files if you want to be able to play a file without extension and not having the filter DSM Files or else you wont see them
This is an actual bug, and very easy to fix. The Windows save file dialog has a default extension setting (called "lpstrDefExt" in the OPENFILENAME struct at least) that should be set to "dsm" to fix the problem.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)
Joined: 12/21/2004
Posts: 2687
Yeah, a lot of this stuff is surprisingly difficult... I remember the Hydrocity 2 Knuckles bypass trick being more a matter of perfect timing than anything else, but it was a little hard to get it to work so I wouldn't be surprised if subpixels have something to do with it too. Actually, it could be that this trick requires Tails and I'm telling you to do something impossible, but I thought I was able to do it with Sonic alone too (just with more difficulty and a slightly slower setup). The alternate path for skipping Knuckles used in my v1 run should definitely work, but that should be a last resort since it's a lot further out of the way. Also, there's a trick with going through the cross of slides that would start to happen around frame 39500 in your movie that you didn't do, did you decide it wasn't possible somehow due to the route you'd taken? And the zipping near there didn't work well either? One more thing, I know it doesn't matter too much, but I'd try to prevent the drowning countdown from interrupting the music in that act. The Carnival Night 1 wheel glitch is a long shot... I brought it up since we should be sure all the possibilities are covered, but there's a decent chance that just going Super as soon as possible will win out. I think you forgot to keep the camera scrolled down at the end of this act to make the goalpost hit the ground faster. Carnival Night 2 is packed full of hard-to-do-even-in-a-TAS tricks. I wouldn't worry about it too much yet though, in case Act 1 affects something. I think it saves a little time to use the fire shield right before entering Hydrocity 1. If you're not already doing this (my guess is that you aren't), I suggest setting up your emulator to draw ghost images of the other TASes so that you can compete against them more directly and see more precisely where you fall behind or pull ahead, and also so that you can compete against yourself (your other savestates) for general optimization even when the other TASes aren't anywhere near you. By the way, did you make this video? Well, that looks like something to look forward to in Ice Cap 1...
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)
Joined: 12/21/2004
Posts: 2687
I just want to add that even the really glitchy runs aren't as unrecognizably glitchy as some people are saying. For example, in the Sonic+Tails S3&K run, some people make it sound as if you're just watching walls fly by with Sonic nowhere in sight the entire time, when in fact over 80% of the movie length is totally normal (unusually fast, but otherwise normal) play. You might say then that the actual complaint is not that there was so much glitching that nothing recognizable remained, but that so much of the game was simply skipped that people want to see too. But that's been true since the first Mario 3 TAS ("what about the other levels?") and generally it gets answered with a 100% run or some other variation, and usually whatever that variation is doesn't conflict with aiming for speed as one of the top priorities.
Derakon wrote:
But it sets an incredibly high bar for newcomers to try to make low-glitch runs, or indeed any runs at all. In short, I don't feel that "If you want it, then do it yourself" is a fair argument.
Well, I apply that argument to myself, in other words, if I want something done and it seems nobody's doing it, then I'll do it myself, when I have time. And that's probably the best thing a newcomer could do to contribute, really... I don't think it's so unreasonable to ask that of people. And it doesn't matter how high the bar is, anyone who actually tries to meet it will learn how to do it and will probably be offered help as well.
Derakon wrote:
Is there something wrong with indicating an interest in a specific run, so that the people who have the expertise to make such runs know there'd be an audience for them?
There's nothing wrong with expressing interest, but some of it so far has come across more like a condemnation of past actions than a "I'd like to see this run, how can we make it happen?" sort of posting that would've been more productive. Besides that, there's also nothing compelling the rest of us to become interested, so "if you want it, then do it yourself" really is honest and practical advice (somebody has to do it), it's not meant condescendingly.
CtrlAltDestroy wrote:
...
Exactly. Although, actually, I'd say your #1 is a bit too specific. I know this isn't the most objective terminology, but I watch TASes mainly to see games "pushed to their limits", because those limits are often surprising and fun to see, and it just happens that speed is often the best way to get that. I also think that speed is usually necessary but almost never sufficient, that is, there are already a lot of TASes that I think would be considerably worse if their authors had only aimed for the theoretically fastest time and hadn't also tried to show off in other ways.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)
Joined: 12/21/2004
Posts: 2687
marzojr wrote:
nitsuja wrote:
Also, while I went through the left edge of Carnival Night 1, the bug that made that possible was really weird and might be able to save time in other ways too, at least near the start of the level.
I will keep it in mind; but how does that bug work?
If you brush against one of those (ferris?) wheels without actually landing on it (which is relatively easy to do from a balloon pop jump, but maybe it has to do with the item monitors under it), you'll land back on the ground, but the game will apply on-the-wheel physics to you. So you can stick to any surface, and if you walk off an edge you'll fall off of it very quickly even if that means falling sideways or straight up. Sometimes it can push you through things too. It's really tricky to put it to good use, like it's a puzzle, but it could be possible (I didn't fully explore it going up/right). Canceling the effect is easy: just jump, and the game will think you jumped off the wheel and return you to normal wherever you actually are.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)
Joined: 12/21/2004
Posts: 2687
marzojr wrote:
But when you put into categories like that, I'd guess it would be (2). That would mean I could fight Knuckles' boss in Marble Garden 2, which is a plus; and there may be a few other things too. I will go over the run again and see what changes can be done.
In that case, don't forget to take into account the (many) Hydrocity 2 glitches in both my v1 and v2 runs. They were very different from each other and from SprintGod's, and neither of them went through the left edge of the level. If nothing else, skipping the Knuckles cutscene should still be possible, since you have the bubble shield then. Also, while I went through the left edge of Carnival Night 1, the bug that made that possible was really weird and might be able to save time in other ways too, at least near the start of the level. And, I'd say "no deaths" should be a goal too.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)
Joined: 12/21/2004
Posts: 2687
Probably because that run is more like 4 minutes slower, not 6 minutes faster. EDIT: By their timing, this TAS is about 4 minutes and 57 seconds faster than that speedrun on SDA.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)
Joined: 12/21/2004
Posts: 2687
Which glitches exactly are you choosing not to use? I'd be a little worried of it winding up in the same situation as this run. The only "glitch categories" that make sense to me here are: 1: anything goes 2: anything goes except for instantly warping from the start of the act to the end of the act 3: no programming errors are allowed to be abused, even if they're easy to do in real-time Also, those roughly fit in with movie categories we already have.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)
Joined: 12/21/2004
Posts: 2687
I got ISFJ on the first test and ISTP on the second one. Both of those describe me pretty well... I'm probably partway between the two. Oddly enough, the descriptions for ISTJ and ISFP were way off the mark (as were all of the others except maybe INTP, which I did get once earlier).
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)
Joined: 12/21/2004
Posts: 2687
It hasn't. Are you sure you're looking at the current code from SVN? If you downloaded it from here then it's not the latest code. (You have to follow these directions instead.)
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)
Joined: 12/21/2004
Posts: 2687
You're almost arguing that TASes that use new glitches to go faster shouldn't obsolete the old ones... This kind of goes against what movie obsoletion has always been about here. TASes here are almost always about pushing the game to its limits so we can see (and have fun seeing) what those limits are. These runs you give examples of were no-holds-barred from the start and followed a natural progression of becoming both glitchier and more precise over time as new tricks and TASing techniques were discovered. Now that we have a better idea of what the game's limits are, maybe we should make a version that intentionally goes easy on the game. Someone could try making a glitchless version of S3&K, where that's the goal from the start of making the movie. I'd like to see it (or make it if I had the time), although there's always been something unsettlingly arbitrary about "holding back" in a TAS, like, maybe it would be better to add goals that force showing off more of the game instead of adding restrictions. But I don't think it makes sense to repurpose SprintGod's first S3&K run like that. Mostly because, at least to me it looks quite bad compared to his second run even on the straightforward parts... it's just hard to forgive how low the precision is after seeing the later runs.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)
Joined: 12/21/2004
Posts: 2687
If anyone still wants the IPS patch and can't find it (because the link in the submission text doesn't go anywhere useful), there's a working download on romhacking.net (it's right under where it says "Patch Version"). Also, the patch seems to be for "Super Mario Bros. (JU) (PRG0)".
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)
Joined: 12/21/2004
Posts: 2687
I really recommend going with Sonic-only instead of Sonic+Tails for an all emerald run, for the following reasons:
  • It will make the run less similar to the Sonic+Tails one. It's good to try to make a TAS as unique as you possibly can (while staying within your goals), and having a different character choice will make that a lot easier. For a big example, consider Ice Cap zone...
  • You won't be "chained" to the actions of the Sonic+Tails run. Right now, it must be a huge pain to get the input to re-sync all the time, and whenever problems come up you're not as free to try new things to correct them as you would be if you were just controlling Sonic.
The above reasons could also be an argument for doing a Tails-only run, except I think Hyper Sonic wins by a landslide as far as TAS potential goes. You can use the old input however much you want to, but I'm kind of against making TASes that reuse input a lot simply because there's so much lost opportunity for new discoveries or personal touches.
marzojr wrote:
Also, after the first special stage in AI2, I cannot figure out how to go through the floor except after it has finished falling; I would appreciate any pointers.
Sorry I don't remember too much about it besides it being ridiculously difficult to pull off, but I'd suggest checking Sonic's Y subpixel position compared to the movies where it worked, and also the frame difference between when the platform is first touched and when you try passing through it. It could be that the platform is swapped out for something else (or simply forgets to check collision for a frame) when it's preparing to fall, and you have to be at exactly the right Y position at exactly the right time in order to fall through it inside that 1 frame.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)
Joined: 12/21/2004
Posts: 2687
fruitbane wrote:
I think there's a place for the high-speed, jumping is faster run. That's what's done here. I'm not saying we should kill them off or replace them. Rather, this would provide more opportunities for entertaining TASes. This doesn't have to be a case of "A or B". Why not "A and B"?
Well, if "A" and "B" are almost the same as each other (as the "bunny hopping" example makes me think), then what's the point? In that case the audience for "B" will be very small, and probably nobody will have the motivation to make it in the first place. However...
fruitbane wrote:
Perhaps the solution is more of an "Exhibition" category, as someone else mentioned. Some movies like that show up on here, but the bar is high enough that it's daunting.
I would actually like for such a category to exist (or rather, to see more movies like that). But, if it exists on this site, then I think the bar should be very high, just as it is for other types of runs here. If somebody makes a "playaround" run, it could have a place here, but it had better "play around" as impressively as possible and also offer something significantly different from existing TASes. Whatever it does, if the consensus is that it's surprisingly awesome then I'd say it fits in well enough with the goals of this site to be published. I realize that there's no objective way to define "playing around as impressively as possible", but I think all that means in practice is that the TASer has a much harder job to do to make sure it's up to the standards of as many people as possible. For example, the TASer would have to be very careful to not cross over from "spends extra time to be entertaining" to "wastes your time". But for the people viewing and judging it, it really doesn't pose much of a problem, since after all, almost every TAS of a new game or category is judged completely subjectively anyway and we're perfectly capable of dealing with that. Something else I think could have a place somewhere here are "glitchless" runs. Imagine being in an alternate universe where all these bugs didn't exist... for some games, the TASes would still be very entertaining, but we're missing out on them despite being able to produce roughly equivalent TASes. The runner would probably need to make a few semi-arbitrary decisions because "glitchless" can be hard to pin down, but most people probably wouldn't care one way or another as long as the decisions were made and they were followed-through consistently. Again, though, I think the standards for such runs should be very high. I think part of what you meant is that there should be a section of the site where the bar is much lower, so as to encourage more people to make runs like these so we end up with more variety. But I think that's a completely orthogonal issue to accepting runs that don't aim primarily for speed. (And an issue that's likely to encounter more resistance, since currently the only part of this site that caters to runs with low standards is called "gruefood".)
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)
Joined: 12/21/2004
Posts: 2687
fruitbane wrote:
This desire is hard to express, but I guess I've seen so many games where jumping is faster than walking, so what happens? The play features the main character hopping all the way to the finish, avoiding most enemies instead of facing them.
I think stuff like jumping makes it better (if you're going to disallow that then why not also disallow using the run button?), but I would like to see more runs that feature the main character hopping all the way to the finish AND slaughtering all enemies along the way. It's too bad it's hard to define "100% kills" in an objective and non-arbitrary way in most games. For an example, I suspect there's some definition of 100% ("collects all skills" or something like that) that would make for a (more) entertaining River City Ransom run, considering how much stuff that game has that could make the fights more interesting but is completely ignored because of the time it takes to acquire it. I don't think such a run would need to do things like "waiting around to give enemies a chance to do their attacks" in order to be entertaining.