Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
pirate_sephiroth wrote:
It might be a problem with the current emu...
It can't play SMA4:SMB3 without a hacked SRAM, but the 1.8 can.
Besides a warning message at the start, it plays SMA4:SMB3 just fine.
Mario & Luigi does have some occasional flickering in it, but it's pretty ignorable compared to, say, the flickering in Paper Mario.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
mwl wrote:
You have a point about the deathwarping, though. Screw Mupen64 for STILL not being able to record hard resets.
I don't understand what the problem is. Can't you just record it in segments, since you're not intending to submit it? By the way, I can't get this movie to play back past the tunnel after the Kokiri sword (Link re-enters the tunnel, leaves it again, and slashes around aimlessly).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
You should probably start over rather than going on to world 3 already, since your first world is still as unoptimized as it was before and even the second world has some mistakes. The biggest mistakes I see remaining even to the end of your world 2 are (1) not always jumping out of a hair attack before it slows you down, (2) not constantly jumping everywhere instead of running on the ground, and (3) not jumping or whatever other action on the earliest possible frame that it would work. Also, it seems like there should be some way to eliminate the long delay Dixie has when throwing something at the bosses, such as being partly inside the boss when you're throwing it, or maybe switching to Diddy.
EDIT: VBA is doing something wrong with the frame counting for this game... That means the game time in the emulator will be shorter than it should be, by a second or two per level.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Well, I meant, you could kill every enemy that spawns. It would take more time overall but would probably force things to be less monotonous. Or maybe I'm overestimating how boring it is to fire/fire burst over everything, and/or rock/ice might turn out to be better than fire/fire in most levels.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
OK, let's see...
It will help if you can play mainly with frame advance, for maximum precision (read everything here if you haven't already). And, basically, don't assume you know anything about how the game works or what's fastest until you've tested multiple ways of doing it and compared frame counts to see what's really the faster thing to do. Look for optimizations in even the smallest and simplest actions, they'll add up, and try to do things that seem impossible if they would also save a lot of time (shortcuts especially) until you're convinced they absolutely can't be done even with perfect input.
For some examples/help specific to this game: I think you move slightly faster when in the air (or maybe cartwheeling) than on the ground, which means you want to maximize the amount of time you spend jumping/cartwheeling because every frame that you're running on the ground wastes a little time. Also, the most obvious mistake I see is that you climb up the ropes instead of jumping up them. I didn't time it but jumping looks much faster to me. And I think hitting enemies from the side speeds you up a lot, making it faster to cartwheel through them than jump over them. (And landing on top of them slows you down.)
Oh, and you don't need to bother with supplying AVI's unless you really want to or someone requests it.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
IdeaMagnate wrote:
Does anyone else use this or have thoughts on it?
Yes and yes. See this thread, for example. It might be a little less random than what you're talking about, but it seems to be the same concept. Your "configurable fuzzer" sounds interesting and useful, depending on how configurable it is...
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
pirate_sephiroth wrote:
But... about the emu thing... wouldn't it be better if you could disable the "screen speed limiter"? That hack really abuses cpu power...
I can't tell what you're asking. If you mean hacking the game itself or enabling a cheat code to get rid of it, and redoing the run with that, then no, I doubt that would be acceptable.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
The camhack VBA (along with the changed source) is here. It's disabled by default. To enable it, go to Tools->Customize All Commands and you'll see a command called "SonicAdvance" in the list. Assign some key to it (I used Backspace) and then press it once after the movie has started playing to toggle the "sonic cam" on/off.
You can record an AVI with it on, the only problem being that it will screw up the audio, so you'd have to combine the audio with a separate audio track that was recorded without the camhack enabled (it's not too big of an inconvenience, considering that the audio would need to be compressed anyway).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
moozooh wrote:
Has Mega Man run just lost his crown of being the fastest wall-zipper on the site? :D
Actually, wall-zipping isn't Sonic's fastest form of movement, which is why I don't use it when it's possible to go over in a straight shot.
Zurreco wrote:
Can you explain exactly how that super-dash works?
Do a spin dash where you press the A button exactly 11 times within 21 or 22 frames, and it gives a huge speed boost (20-30 times faster than normal).
Zurreco wrote:
Also, what is with that annoying cartwheel/roundoff that Sonic does from time to time?
The cartwheel move (press B twice) is a good way to bring Sonic to a complete halt in preparation for a spindash. It's often a bit slower than stopping manually with perfect precision, but it moves you forward a good amount in addition to stopping you (which is often advantageous). If you mean Sonic's "space jump" move, that's what happens when you try to jump while doing that cartwheel move. The only good thing about it is that it can jump from midair or up a slope.
moozooh wrote:
Well, I think, technically it's possible to capture the camhack output to AVI, but VBM file will show the same anyways.
AVI would be much preferable because the camhack is very computationally intensive; it maxes out the CPU at well below 100% speed for me, so you'd need either an AVI or a very fast computer to watch it at full speed. I could supply the hacked VBA or try encoding the rest of it.
Mr. Pwnage wrote:
Is it possible to spend any less time onscreen in Secret Base? I don't know what allows for those big spindashes, but looking at a map it seems like there could be more cuts to take and less interacting with the "normal" stage.
Walls that have any object next to them (spring, spikes, etc.) are impossible to glitch through unless you're far offscreen at the time, which ruled out some routes. There's usually no way to gain height when in a wall, so glitching to over or underneath the goal does no good (either freezes the game or kills you, in fact), and same for glitching through a wall that leads to a pit. Also, loops are bad because they count as two solid walls when they're offscreen, and those glide wire things in the Secret Base levels will often freeze the game if you hit them too fast.
You could be right, of course, but this is the fastest route I found.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
DK64_MASTER wrote:
It doesn't make senes, I don't understand how something done in the future would affect the past. That's not causal!
Is that really what's happening? Does it affect prior backups as well? The only good explanation for that would be an external file changing the emulation. The only ones I know of that can do that are "save/Legend of Zelda, The - Ocarina of Time (U) (V1.0) [!].sra" (delete it before opening the ROM) and "mupen64.ini" (replace it from the original install before opening the emulator).
Note that if doing this doesn't fix playback, that doesn't necessarily mean it wouldn't have prevented the problem had it been done before every recording session. On the other hand, it looks from the code like these really should not make any difference.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
mwl wrote:
The subscreen delay, for one, is nonexistent in Proj64.
Do you know how long ago (emulator version number) they fixed it? I think I read somewhere that they simply detected the ROM and hard-coded that cheat code to always be on for it. That might be the most viable solution...
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
mwl wrote:
if raw data is unchecked, the movie desynchs at the player name input. So that can't be it.
Andypro wrote:
But yes, aside from that we can rule out the other possibilities as we're all using the proper plugin / raw data / read only settings and the same rom version.
Bag of Magic Food wrote:
Couldn't you put RawData into the dialog box for loading movies where it compares the settings so we wouldn't have to keep asking the movie author whether to check it?
As far as I can tell, the "raw data" option inherently causes some instability in the recording. I'm not sure why, which means the behavior is undefined/unsupported when it is checked, so it never should be checked. Future versions may refuse to record or playback when that option is on, or at least will issue a warning.
Andypro wrote:
In fact so much so that I'm almost considering trying to join the development team on mupen so we can get some of this crap fixed (recordable resets, desyncs, etc).
Recordable resets and from-SRAM recording have basically been done for a while. (But not posted because of other issues.)
I believe the official development team is Hacktarux, who hasn't released any updates or news of progress in quite a while. The official Mupen64 message board is here.
As for the subscreen delay, I've looked into it several times and am giving up on it for now, again. There's not enough of a debugging framework in Mupen64 to effectively test anything or isolate the changes made by the video plugin when the "copy framebuffer to RDRAM" option is on. Nothing useful came from comparing RDRAM dumps or simulating the changes in it when bringing up the pause screen. Other emulators appear to have the same problem (subscreen delay), except when using an emulator- and ROM-version-dependent cheat code to skip the delay.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Maza wrote:
It looks very fast but I'm having some trouble with the plugins :(. The best quality I was able to get looks like this and I used Jabo's Direct3D6 1.5.2 with it. Every other I tried were much worse.
Use Jabo's Direct3D8 1.6, and after the game starts up, go to the "Rom Settings" tab of the graphics plugin settings, and change "Emulated Width" to 320 and "Emulated Height" to 240. That should make it look something like this.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
First download the source code for the emulators you want to edit, and they will each come with some sort of readme or howto compile text file that tells you which compiler you should use.
I can't get any more specific than that since you didn't say what you know how to do already or which emulators you want to edit or what sorts of changes you're thinking of making.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
mwl wrote:
There is a MAJOR problem with desynchronizations in the production of the OoT TAS.
I know, but I can only assume it's because he's using the "raw input" option which I said beforehand not to use because it could cause desyncs, and he for some reason didn't change when starting over. Also, there might be an actual desync in the movie file caused by loading savestates incorrectly or changing video plugins, or confusion over the ROM version or video plugin settings or other input settings.
The subscreen delay is the biggest problem right now that I'd been hoping to find a fix for, for the next version. It doesn't help that I can't get the source for the only video plugin that produces the desired behavior, and that Mupen64 has had a minor bugfix update since 0.5 without the source for that update being made available.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
nfq wrote:
But why would lag affect -your- speed? Why would Bond "lag" more than the rest of the game.
I don't think he meant that. You're part of the game, and lag affects the entire game's speed, therefore it affects your speed. It's unlikely that the lag would selectively affect only your character and not the enemies.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Thaurlom wrote:
The henchman throwing movement can be a huge timesaver sometimes. Should we consider it as "taking damage" for the second player?
In Pocky & Rocky, if both players dash into each other they rebound all over the place while invincible, which can save a good amount of time, but they also lose a little health. I would consider it not taking damage because it is spending health to perform an action rather than losing health from getting hit by an enemy (and it doesn't do the "getting hurt" noise or animation). I think that also applies to this situation in Pocky & Rocky 2, unless you think it actually makes the movie less interesting to use this throwing move.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Updated to v19.2:
- fixed a large memory leak with the shared memory code introduced in v12 (this addresses pirate_sephiroth's concern)
- fixed a problem with the shared memory code that prevented multiple instances of VBA from working correctly (they would corrupt each other's memory before because the memory was shared; now only the first instance to open shares its memory by name)
- fixed a very old bug with enabling/disabling sound channels of GB and GBC games not taking effect immediately (this addresses CtrlAltDestroy's concern)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
FractalFusion wrote:
I suggest not bringing it up again. Anyone can call it whichever way they feel.
I was only asking if it had been (and already edited my post). I was mainly thinking that the TASvideos forum image is possibly confusing if the S is not meant to stand for "superplay".
FractalFusion wrote:
The disclaimers probably would be more noticeable if they were either longer, overlapped significant playing time, or were more descriptive
I would just want them to be readable... I don't know if overlapping significant playing time is really necessary. Also, not that this is a terrible thing, but making them more descriptive further increases the amount of time they would have to be displayed for to be read, assuming they are meant to be read without requiring the movie to be paused.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
I did notice on some TAS AVIs that the disclaimer and other info was displayed for far too short a duration. I know there's no need to insult the viewer's intelligence with long intros, but I can't read 6 lines of text in 1 second. Anything that is only displayed for 1 or 2 seconds near the start of the movie is likely to not even be noticed.
Besides that... has "tool-assisted speedrun" vs. "tool-assisted superplay" already been discussed? The image at the top of this very forum suggests that TAS stands for the latter. EDIT: Hmm, apparently it has. Something about it being a backronym is in the other thread.
