Posts for nitsuja


Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Atma wrote:
the buttons pressed thingy down the bottom of mupen only shows 2 out of 3 force for the main direction being pushed
BTW, if you get the current emulator version, you'll see a more precise number out of 99 instead of just out of 3. If it shows 99, you know it is definitely pushed 100% of the way in that direction, whereas 3/3 before just tells you it is somewhere between 67% and 100%.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Wow, never mind, you're right. That is a pretty big bug, then (and gives me a much better idea of where it is...). Banjo Kajooie doesn't seem to have that delay problem, though, at least not for normal transitions, but I guess it should be tested more thoroughly.
Atma wrote:
but the flip side is that you'd have to play the whole movie with those settings (dont know about your machine, but that one option drops it to about 10fps on my machine), since changing them at any point would desync the movie for the watcher who would have to change them to keep it in sync (which would be over the top irritating).
If it only affects the pause screens, then you could turn it off in-between (either recording or playback), but you'd have to be very careful about it.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Bag of Magic Food wrote:
What about that menu delay in Legend of Zelda? Doesn't that change when you use that option?
Nope, (maybe unfortunately (but good for synchronization purposes)) you can't change that delay no matter what you do with your plugins.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Of course not. (And his movie didn't desync when I turned it on even though he recorded with it off, so that should work the other way around.) All it does is black out the image put on the puzzle pieces, when it's off. And I don't think video plugins even have the capability of doing anything that could cause a desync or otherwise change the game timing.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Bag of Magic Food wrote:
But if you turn on Copy Framebuffer To RDRAM, does everybody have to turn it on to watch your movie?
If they really want to see the puzzle animation effects in the emulator, then yes. Personally I wouldn't turn it on unless encoding or testing the plugin, since it makes the emulation unwatchably slow (at least for me) and doesn't make any difference at all outside of the occasional transition effects even though it slows things down everywhere.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Phil wrote:
It will be better to have an option to desactivate it. I don't like this feature. I remember telling blip to desactivate it since I didn't love that feature. For subtitles, yes but this is not implemented.
What? You were the one who requested specifically for input display to be recorded into the AVI. EDIT: Oops, apparently I was out of my mind when I read Phil's post that I thought said that. EDIT: it's fixed now
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Maza wrote:
Unfortunately I wasn't able to find a suitable video plugin for Banjo-Kazooie. Each I tried had some sort of problems :( So the one I finally chose to use was Jabo's Direct3D8 1.6.
Actually that plugin handles this game perfectly (from what I've seen). It's a popular enough game that plugin support for it is quite good. If you mean about the puzzle piece transitions showing black, that's because they're off by default because it's really slow to do on a PC compared to on an N64, but you can turn it on to get more accurate graphics by enabling "Copy framebuffer to RDRAM" in the Advanced tab of that plugin's graphics settings. Anyway, I also think that any% would be much better for this game, and that a 100% TAS in addition to it would be unnecessary (because 100% is almost the same, except a little slower and easier to play and easier to plan). And if someone wants to attempt this they should plan that out and hopefully find some interesting strategies before actually starting.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Looks like a big improvement - voted yes. As for the mistakes you mentioned, they obviously aren't enough to outweigh the improvement, and anyway I didn't even notice them, although of course it would be better to not have them.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
FODA wrote:
While leaving from secret aquarium, i change camera from "lakitu - mario" to "lakitu - lakitu (stop)" i think that will be more interesting and wasted 6 frames on that.
Actually I was going to request that you try this, but I wasn't sure if it would be better in more places than the mario cam. And I thought it only took 4 frames to switch it (start, down, right, start), but however long it takes it doesn't bother me if the run looks better afterward.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
OK, those bugs in FCEU are now fixed. - no more manifest file required - "save block 74" bug fixed - compatibility with movies much improved - if an old movie is missing information required to play it deterministically, you can set what those variables are to try to keep it in sync (Note to Genisto: your "full amazing run" is missing this save state info. I found that "acc=8, bc=0" plays it as far as any values I could find (upper world 5 fortress) - something else might work better but I couldn't find it. Regardless, if you clear out your save states and continue recording using the same values each time you continue, you shouldn't run into any more desyncs.) Windows Binaries (FCEU 0.98.13 re-recording r5): http://rapidshare.de/files/8361990/fceu-0.98.13-rerecording.zip.html mirror: http://www.visionsofdoom.us/misc/fceu-0[1].98.13-rerecording.zip (thanks to Andy Olivera) Source Code: http://rapidshare.de/files/8362016/fceu-nitsuja-src.7z.html mirror: http://www.visionsofdoom.us/misc/fceu-0[1].98.13-rerecording-src.7z
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
The character takes a few frames to start running, and sometimes has that delay when landing, so the movement can be optimized a bit more by jumping to cancel that delay whenever it would happen. For instance, if you jump at the very start of the first level you'll save about 7 frames. Anyway, I didn't notice any mistakes besides that, and it was amusing how you avoid being crushed to zoom through the rooms with moving walls (and made fools of the bosses in the rematches).
Bablo wrote:
And what's pre-jump?
Jumping before an edge you need to fall down so you'll be falling faster when you get there.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
There's no way around that that I know of, you just have to rename the .manifest file with it. Actually there should be a way but I couldn't figure out how to do it just with gcc and windres. The manifest file gives it windows XP themes and enables unicode display support. (edit: figured it out, was doing something slightly wrong with the resource file before )
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
FODA wrote:
but what if i don't have a savestate or saved over it?
If you have a savestate a little earlier, you can load that and wait 5-10 seconds. If you don't, then you can use "pause at frame" to get there. That's what I said before. I said "start at frame" doesn't make sense because "pause at frame" is just as good.
GWing_02 wrote:
And what if I just want to BAM skip 20 minutes of playback, and no savestate was provided?
Well, that's impossible unless you get or make a savestate there. Emulators that let you do that (ZSnes, I think) are keeping multiple savestates in the movie for it, but savesates of emulated N64 games are a bit large for that...
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
FODA wrote:
yea but nistuja, it's better to start the playback, choose "pause at frame x" and put max speed and go do other things so when you come back, the game will be paused waiting for you to resume recording. it's boring to pay attention to a long movie waiting for the moment to pause.
It's even better to already have a savestate so you don't even need to wait for it to get there. And that's what I meant about using the "pause at frame x" option, I don't know what you're objecting to...
Pyrolistical wrote:
Is there a way to get around the 4 GB limit on AVIs generated by Mupen64?
It's a limitation of the AVI format, it's nothing Mupen64 is doing. I'm surprised you got as high as 4 GB, I thought the limit was 2 GB before it starts getting corrupted. The way to get around it for now is to pause the movie partway through before the AVI is too big, stop recording the AVI, and start recording a new AVI. The best that can be done to fix it in Mupen64 is to make the emulator do that automatically to split the AVI into multiple files at 2 GB boundaries.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Interesting, it does appear to be exactly the same bug as in Tiny Toons. But as far as I can tell, that glitch movie wasn't published. And I'm not really sure what makes a bug like this lame compared to other bugs... maybe it's because it reduces the difficulty of optimizing for speed, but it also in this case gave enough extra options in each situation that I felt it outweighed that. There were several clearly different things done besides simply moving faster. Anyway, this was basically recorded overnight, those who would most want to see this either already have or still can, and I'm much more interested in certain other games at this point, so I'll go ahead and cancel this. EDIT: My real reason for cancelling this: It seemed that Bisqwit thought it would set a bad precedent, and I recorded it for fun, not to argue with Bisqwit. Also, the few frames lost at times (mainly the final Bowser battle) really should not have been lost in a version that only offers more possibilities than the original (left+right movement, and shooting fireballs with X while running with Y).
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Oh... well that sounds like a not-small problem to me. It's odd, since I was mainly playing old movies for testing and never saw that happen, but I'll check some other ones.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
I also wonder the answer to FODA's question. I think the glitch is pretty similar in concept to the one used in the full aLttP run and nobody had a problem with that glitch on its own. But, either a concept demo or a sidenote link to the smv run (well, or neither, I guess) would be fine with me, maybe preferable... I don't care so much about this run, but I'd still like to see what someone else would be able to do with it.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
I fixed a bunch of bugs in FCEU and added a few minor features:
  • Found what really made the "random desync bug" happen, and hopefully it's gone for good now.
  • Fixed a bug where re-recording from a movie file that had gone through nesmock would corrupt the movie header.
  • Fixed output of some AVI codecs (including uncompressed) to not crash.
  • Optimized AVI output - it should be much faster now.
  • Fixed slow-motion of things below 25% speed
  • Fixed something with fast-forward
  • Frame counter and/or input display now go into AVI recordings. (It won't be legible if the codec's video quality is too low, of course.)
  • Save state and other messages aren't instantly obliterated by a running frame counter / input display anymore.
  • You can replay the currently playing movie from the start (without browsing to it) by choosing to Reset the emulator while a movie is playing (or while it is recording in read-only mode). This also fixes a bug because resetting during a movie used to inject a reset into the still-playing movie (causing certain desync).
  • Made save state files never appear in the movie replay list
  • Made the failure of nesmock to convert a movie (of a format it didn't expect) more likely to be detected.
  • Maybe fixed some bug having to do with loading non-movie save states in a movie or vice-versa or input looping. (Non-movie save states used to contain garbage movie data that was always loaded.)
  • Added XP-style support, which has the side-effect of making unicode characters (in the author info field) now display correctly instead of as ? characters (if you're running XP - otherwise it should be the same as before). Note that the extra manifest file in there (if using Windows XP) is required for fceu.exe to run.
  • Apparently some of the line breaks are inconsistent, which isn't fixed yet.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
dugan wrote:
I can't compile the latest version using any of the 3 compilers available for Ubuntu 5.10. ...
...
mappers/6.c:74: error: ‘apIRQHook’ undeclared (first use in this function)
...
apIRQHook? That file says MapIRQHook on that line. Sounds like your sed ate a character after the line break. Maybe not all of the line breaks are Windows-style and it will take a more complicated replacement (than the one currently listed) to handle it properly.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
nico wrote:
what is the best way to resume recording? the only way i've found is to go through the whole movie until i get to where i want to pick up on. you know how there's a "pause at frame x" feature? maybe a "start at frame x" feature could be helpful.
The best way to resume recording is to (during non-read-only mode playback) load the savestate that you made while recording at the point you want to continue from. The second-best way is to load a savestate sometime before you want to record from in read-only mode, then switch out of read only mode and save-load to resume. "Start at frame x" doesn't really make sense - pausing at the frame is already what you'd do anyway to continue from there if you didn't have a savestate there. If you have the ROM already running, a trick you can do is pause, then playback the movie, then load the state, then unpause, and that way you don't even have to wait for the ROM to load again, it just jumps straight into the save state in the movie.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
FODA wrote:
this frame i'm here: the immediatelly next frame i'm here: yep no frames between those. doing this i got the first star 34 frames faster than spezzafer's. so it is usefull glitch after all hehehe
Are you serious? If you have an .m64 of that I'm really curious to see what you did.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Well, it still count as a vote and it's allowed. Since you hopefully watched your own run and have an opinion on whether it should be published, you meet the same requirements for voting on it as anyone. Anyway, the whole idea of voting is that a single vote shouldn't matter, so if your particular vote makes a difference then something's wrong with the whole system regardless of whether you actually voted, which is why it's generally not forbidden. Plus I think the judges/publishers get a list of who voted, not what they voted for but if you're on the list they could safely assume you voted 'yes' and mentally subtract a vote if so.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
erdamus wrote:
Are the .m64 files altered by the playback of them?
If you play them in non-read-only mode, loading a save state erases everything after it in the movie and starts recording from there, so I'm guessing that's what you (possibly accidentally) did.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Oh, I didn't know it did that, as my savestates aren't in the movie dir. BTW (Andy), optimizing do_video_conversion() is making encoding a heck of a lot faster, that was a good idea to do that.
Emulator Coder, Experienced Forum User, Published Author, Skilled player (1301)
Joined: 12/21/2004
Posts: 2687
Xebra: Calling someone's work shitty like that is crossing the line almost anywhere, not merely a flippant statement of opinion. JXQ was only responding in kind, he would not have said any of that otherwise. Also, you shouldn't continue saying he's copied your run - that's being too possessive considering that he has not literally copied your input. Just rest assured that somebody will eventually obsolete his run if it's really suboptimal. And yeah, it's only a game.