TASVideos

Posted: 10/30/2005 2:08 AM

Quote

nitsuja

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)

Joined: 12/21/2004
Posts: 2687

Has there been any progress on this? (I can't tell if you noticed my last post/edit.)

Posted: 10/30/2005 1:35 AM

Quote

nitsuja

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)

Joined: 12/21/2004
Posts: 2687

Spacecow wrote:

I just noticed that I don't have the latest version, I think. It's "v3" and not alpha 5. Don't know if that makes any difference, but it's worth mentioning.

Ah, that would explain it. I fixed a bug sometime after v3 which was basically adding a small random number of frames to the start of the movie every time you record or playback.

Posted: 10/30/2005 12:45 AM

Post subject: Re: Mischief Makers

Quote

nitsuja

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)

Joined: 12/21/2004
Posts: 2687

Hmm, when I play this back, it always desyncs at the end of 1-5... I've tried adding/removing frames but you always boost jump into a spike ball and drop the kid. Could someone else see if they're able to watch this? I've been catching various bugs lately but none of them have been related to input synchronization since alpha 5. Besides that, this looks pretty good so far to me, although like you said it can probably be improved and would benefit from knowing or experimenting more with the game.

Posted: 10/29/2005 7:02 PM

Quote

nitsuja

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)

Joined: 12/21/2004
Posts: 2687

Walker Boh wrote:

That door trick by the way, can it be performed on every star door? The one that allowed him to get into the first water world with 0 stars.

The door trick is actually the same thing that's used to go through the big star door near the end and to get into Bowser 3. He does the long-jump-backwards trick on that little staircase, and somehow gains just enough speed to pass through one part of the door. Unless there's something weird about that door in particular, I would guess that this is also possible for getting into Whomp's Fortress, Cool Cool Mountain, and Bob-omb's Battlefield. But it's also closer to being impossible than other other trick I've seen done in this game, and I'm not sure how much time it would actually save.

Walker Boh wrote:

And is it possible to get out of there without the necessary number of stars?

Once you're inside, you can easily get out without enough stars by using pause->exit from inside the level to get to the main castle area.

Posted: 10/29/2005 6:52 PM

Quote

nitsuja

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)

Joined: 12/21/2004
Posts: 2687

Oddly, this is happening for me now too, but only after you pointed out that it happens even though I didn't change anything to purposely make it happen... Maybe it's different, though - it's only happening with certain games, and it works correctly again when I turn off "Hardware Frame Buffer Textures (Experimental)" in the video settings.

Posted: 10/29/2005 9:10 AM

Quote

nitsuja

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)

Joined: 12/21/2004
Posts: 2687

FractalFusion wrote:

I believe your strategy is the fastest. Alternating charged and uncharged is generally the quickest way to beat many bosses with the X-Buster. The same strategy can probably be used to beat Blizzard Buffalo in MMX3.

Keep in mind that uncharged shots only do 80% as much damage to Blizzard Buffalo as they do to this boss, relative to charged shots, and that with the extra damage from uncharged shots here it was only 32 frames faster than not using this strategy. So I don't think it would be faster there, although I'm not completely sure (someone should try it sometime).

Posted: 10/29/2005 8:35 AM

Quote

nitsuja

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)

Joined: 12/21/2004
Posts: 2687

DK64_MASTER wrote:

we still have to open the cannon, so triple jumping has to be faster than the time lost by the cannon opening and flying through the air.

If you have to open the cannon anyway, then how does the time it takes to open the cannon even make a difference?

Posted: 10/29/2005 8:06 AM

Quote

nitsuja

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)

Joined: 12/21/2004
Posts: 2687

DK64_MASTER wrote:

When I reset the ROM, it doesn't show any video input, but plays sound.

What happens if, instead of choosing Reset, you choose Close ROM and then re-open it? Is it still gray then?

Posted: 10/29/2005 6:02 AM

Quote

nitsuja

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)

Joined: 12/21/2004
Posts: 2687

DK64_MASTER wrote:

This grey area also appears when I activate a pull down menu, but if the ROM is being played, it goes away after it refreshes the picture.

Could you explain this more? I thought you said there's always a gray area when the ROM is being played, what does it go away to? (I know you've switched to another plugin but I'd like to know why this one isn't working for you - it can possibly be fixed.)

Bag of Magic Food wrote:

You didn't switch to glN64 for the video, did you? That plugin doesn't work after the first time for me.

What are your settings in the glN64 configuration dialog? I've never seen this happen, and I'm not sure exactly what you mean by "after the first time", but maybe "hardware frame buffer textures" is screwing it up, or maybe your monitor doesn't like the selected texture bit depth or cache size (even if they were the defaults, the defaults could've been bad for your setup).

Posted: 10/28/2005 11:03 PM

Quote

nitsuja

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)

Joined: 12/21/2004
Posts: 2687

Graveworm wrote:

Crap game, it didn't work. :/ But thanks for trying to help me anyway.

I just tried it by hex editing 1 frame of jump into your movie before the door and it resulted in the shot you fired later not bouncing off... guess I'll upload that movie, too. BTW, you are being much more thorough than I was. I was 32 frames faster (than my submitted run) by the end of the intro boss, but you were still 19 frames faster than that (edit: but I think you could've gained 2 more frames when you first gain control of Zero by jumping more). If you finish this and it ends up being entertaining (and I don't see why it wouldn't), then I think you should submit it. EDIT: here are the movie files: http://www.filespace.org/nitsuja/mmx3wips.zip (There was 1 frame of delay between firing shots in your movie after the shot had already bounced off, so I redid the firing to fix that.)

Posted: 10/28/2005 9:32 PM

Quote

nitsuja

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)

Joined: 12/21/2004
Posts: 2687

Graveworm wrote:

One of the shots just bumps off it, (the third shot in the second jump) and I've got no idea of why this happens.

It suddenly occurred to me why this might be happening: Your even/odd frames must be reversed from mine. When you enter the room with the drill boss with the dash that goes to the door, try jumping during the dash right before hitting the door to purposely delay 1 frame, and you should find that the shot no longer bounces off.

Posted: 10/28/2005 7:54 PM

Quote

nitsuja

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)

Joined: 12/21/2004
Posts: 2687

Bag of Magic Food wrote:

Yeah, I think the too-dark colors are from glN64.

Not really - here is the difference I am seeing:

The colors and highlight positions look pretty different there... It's not really that bad though (it's still totally recognizable), I was just pointing it out in case it's something that isn't too hard to change.

Posted: 10/28/2005 2:46 PM

Quote

nitsuja

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)

Joined: 12/21/2004
Posts: 2687

Bisqwit wrote:

No, I wasn't thinking of that. I was thinking of ways to decrease the search space.

Oh, it sounded like you were saying that there are too many assumptions like that that have to be made for a practical solving method to really be "brute force" or general-purpose. But maybe general-purpose isn't what the discussion was focusing on...

Posted: 10/28/2005 2:11 PM

Quote

nitsuja

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)

Joined: 12/21/2004
Posts: 2687

(I don't think it matters much for a dungeon room when Zelda changes facing...) Do you think it's possible for a brute-forcing or random search algorithm to be modified so that it infers the answers to these questions you asked from the results it gets?

Posted: 10/28/2005 2:00 PM

Quote

nitsuja

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)

Joined: 12/21/2004
Posts: 2687

Yes, I saw the movie, that's what I was referring to when I said "It might have thought that shot collided with his drill arm which is (will be) at the same height, either that or it's bad detection of collision with the lower spike". It could also be related to your horizontal position, maybe you were 1 pixel too close/far away. Or, it could be related to the timing of that enemy's animations, i.e. if a shot hits on the frame it's preparing to move its arm, it will bounce off. The only other possibility I can think of is that it's somehow random, and could maybe be manipulated. I remember encountering this exact same problem, but I can't remember exactly what I did to avoid it, and comparing the two movies I can't tell what's different there. edit responding to your edit: If you mean about going down a ladder, it has to do with landing in exactly the right position from a jump. I've redone the intro stage (and several others) since the 39:51 movie (and am several seconds faster), progress on the remake is stalled but sometime soon I can post here what I have so far, since it seems like it could help.

Graveworm wrote:

I think I'm as fast as he/she? (sorry, I don't have any idea)

It's he.

Posted: 10/28/2005 1:24 PM

Quote

nitsuja

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)

Joined: 12/21/2004
Posts: 2687

DeHackEd wrote:

I could try switching video plugins, but this one works perfectly and doesn't seem to glitchout 2d objects.

Video plugins won't glitch out 2D objects unless they are set to force filter all textures. You just have to make sure that option is off. (In glN64 it is called "Force Bilinear Filtering", for instance.) And that video filter definitely didn't work perfectly - disappearing bowser, incorrect image fading, incorrect lighting...

Bisqwit wrote:

But I can't move the AVI talk to a separate thread, because it's too entangled with the talk about Mario64

It doesn't look too unseparable to me... most of these posts are clearly about one or the other, or they are mostly about AVI's and mention Mario 64 AVI's as an example.

Posted: 10/28/2005 1:14 PM

Post subject: Re: Requirements for handling N64 games on this site

Quote

nitsuja

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)

Joined: 12/21/2004
Posts: 2687

Bisqwit wrote:

X The file must be one piece (no separate required savestate files)

Separate savestate files are not required for from-start movies. Currently they are required for from-snapshot movies, which should change although that also shouldn't affect submissions.

Bisqwit wrote:

There seems to be an issue with leftover SRAM files (file extension ".eep"). If I watch the Mario64 movie close to its end, and attempt to restart it, it's not going through the Princess and Lakitu intro scene, but instead Mario immediately starts outside the castle outside. It would be nice if a movie could just be loaded and it works, just like that.

This is already being handled in the Windows version - it goes through and clears out .eep (and .sram and mempak) files on playback or recording "from start" movies. I think DeHackEd said he is not handling this in his version yet, although the code I have for it is platform independent so it should be not hard to add in a call to that code... (the function is called VCR_clearAllSaveData(), implemented in vcr.c)

Posted: 10/28/2005 10:32 AM
(Edited: 10/28/2005 10:35 AM)

Quote

nitsuja

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)

Joined: 12/21/2004
Posts: 2687

Keep in mind also that 320x240 is not the maximum resolution of the N64. Some games (Turok) go as high as 480x360, I think there might be a few 640x240 or 320x480, and some other games (GoldenEye) change the resolution during the game. 640x480 is the maximum the N64 could technically support.

Posted: 10/28/2005 9:48 AM

Post subject: Re: My contribution

Quote

nitsuja

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)

Joined: 12/21/2004
Posts: 2687

Have you tried turning off the hardware antialiasing when doing this? Because you are basically doing software antialiasing on top of the hardware antialiasing, so maybe better quality and/or speed would result from turning it off, or turning it off and reducing from 1280x960. Besides that... Triangle filter is obviously not the correct choice, too blurry, although it does make for the smallest filesize. Lanczos results in noticeably better looking and a smaller AVI than unscaled, so I think of your 3 test AVIs lanczos definitely wins even though it took considerably longer to encode. (Are you certain that this implementation of lanczos scaling cannot be further optimized?) (edit: BTW, I'm surprised that the resulting lanczos-scaled image did not show the extra pixellation and/or blurriness in the HUD elements that normally shows up when rendering at 640x480. But most people are probably going to watch these AVI's at double the resolution, at least, which makes me wonder if it wouldn't be better to just render at 640x480 (with antialiasing, if it helps) and encode to 640x480 at a somewhat lower codec quality setting. Also, is it just me, or is the shading on Mario way too dark in all of these?)

Posted: 10/28/2005 9:24 AM

Quote

nitsuja

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)

Joined: 12/21/2004
Posts: 2687

Graveworm wrote:

No one has any idea of what causes the Drill bot to block one of my shots in the video posted above or did you just not see it?

That miniboss blocks things a little oddly, but it's mostly based on the height of the shot. It might have thought that shot collided with his drill arm which is (will be) at the same height, either that or it's bad detection of collision with the lower spike. Did you try firing or starting the jump one frame earlier/later, or just delaying that shot by 1 frame? I think I may have altered the first jump somehow in order to make the second one not have a shot get blocked. Also, note that that miniboss has 32 health, and charged shots do it 2 damage, so if you have to fire more than 30 regular shots then somehow one of them didn't count.

Posted: 10/28/2005 8:44 AM

Quote

nitsuja

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)

Joined: 12/21/2004
Posts: 2687

Weatherton wrote:

What version of the emulator did you use to capture the avi and how?

See the Mupen64 re-recording thread where I've been updating the first post with each new release. I made this AVI with alpha version 5, using the glN64 plugin (although other graphics plugins should no longer crash either).

Weatherton wrote:

How do you continue recording a movie (talking about button inputs now) after having stopped recording and turned the emulator off? Is there a way to do it without rewatching everything?

See UsingEmulatorTools where it explains how to resume recording. The general case mentioned that applies to all those other emulators also applies to this one.

Posted: 10/28/2005 12:28 AM
(Edited: 10/28/2005 11:49 PM)

Quote

nitsuja

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)

Joined: 12/21/2004
Posts: 2687

Don't forget about the run+Z+B move, I think it might save time in some places because it doesn't require nearly as much of a running start as a dive and can be canceled early enough to cover short distances quickly (unlike long jumping). edit: Spezzafer, what version of the emulator are you using? edit2: don't update to alpha 5 yet, if you haven't already. I think there are still some issues to work out with it...

Posted: 10/27/2005 9:59 PM

Quote

nitsuja

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)

Joined: 12/21/2004
Posts: 2687

I don't see what would be the problem with just making 1 long movie from the start for something with unlockables, splitting the AVI at reset-button boundaries, and including a save state for people that want to watch on an emulator and skip the first part. (Well, recording reset isn't implemented yet in Mupen64, but it would work for vba and fceu already.)

Posted: 10/27/2005 8:06 PM

Quote

nitsuja

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)

Joined: 12/21/2004
Posts: 2687

DK64_MASTER wrote:

Ok, thanks for the info. So is this run going to be published? Always nice to have something to start off with :).

To be published, it first has to be submitted. To be submitted, the .m64 format first has to be approved. I'm working on addressing some complaints about the format, at the moment.... (Although these changes will not affect the first 32 bytes, which are the only important ones for playing the movie, so this will remain a valid movie file either way). EDIT: Just watched DeHackEd's encoding, parts of it at least. This game should definitely not be encoded with that graphics plugin if it adds so many graphical glitches - glN64 handles it much better (and is supported on both Windows and Linux). Besides the graphics plugin, it looks/sounds good.

Posted: 10/27/2005 6:54 PM

Quote

nitsuja

Emulator Coder, Experienced Forum User, Published Author, Skilled player (1300)

Joined: 12/21/2004
Posts: 2687

Weatherton wrote:

Nitsuja, nice video! What program did you use to record it? (I hate the one I used).

It was outputted directly from the emulator's AVI output. I didn't compress the raw audio of the AVI afterward, though, so it should really be considerably smaller for the amount of quality it has, if I had bothered to do that.

Posts for nitsuja