Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Baxter wrote:
In the list of selectable movies, when you press "replay movie", you can select all the movies that have the same rom checksum AND all the savestates you made from that game.
Actually, I still don't understand what you mean by this. Do you mean it used to do that and now it doesn't, or do you mean that it does it now but it shouldn't? I have never seen any savestates in the replay menu in any version of FCEU, and savestates are not even looked at at all when populating the movie list. Did you mean the "record movie" dialog instead of the "replay movie" one? That one does have save states listed, but they appear to be working for me.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
FODA wrote:
i found a trick it may be usefull on some levels i hope, its the backwards longjumping but on a upwards moving plataform. doesn't have much ground to gain speed there, but if i go diagonally i can get some good speed i think. we'll see.
That sounds interesting. You get to keep the speed gained for quite a while if you get going fast enough, so it could make a big difference somewhere, if I understand what you mean by this. This is probably crazy, but does that moving platform by the chain chomp have a long enough diagonal to use that to zoom over to the gate and glitch through it? Too bad there aren't very many stairs in levels, though, there's only that short one in WF that I can remember.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
I just saw the SDA run of this, actually. The game is fairly long, doesn't seem to have many bugs at all, and I think it forces you to get pretty close to 100% just to beat it anyway. But, normally you have to play cautiously to survive, and it would be fun to see what sorts of tricks are possible with high precision, especially in the more dangerous levels like Rusty Bucket Bay.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Just make sure to test that it stays in sync by playing from a savestate made right before the start of the level after every 10 seconds or so, and you won't have a chance of losing much work. That's what you'd do anyway, right? (OK, maybe not but it's a good idea at least for this game and DKC2.)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Maybe a general user-based rating system would work better for that.
EDIT: Also for what it's worth, I don't think this awards thing is worth reviving either.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Dacicus wrote:
What do the numbers by the input display of the arrows mean?
It's a measure of how much it was pushed in that direction, scaled to between 1 and 99 so that it's never more than 2 digits. (^99 >5) means it was pushed 100% up and about 5% right. I thought of making it hex but that seemed unnecessarily confusing when games don't even make use of most of the accuracy of the analog data anyway.
FODA wrote:
Nitsuja, i think mupen64 can use savestate slot 0 as well, but i can't find a way to config that on your patched #8 version.
It was called the "default" savestate, which I got rid of partly for being confusing and mostly for lack of space in the config dialog. But I can add a state 0 whenever I do another release of mupen64-rerecording.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
TNSe wrote:
The CRC matched up for me, and no desync in playback with wildly different plugins.
I meant, I had the hacked ROM, and the CRC also matched up for me, which means it's probably displaying the CRC stored in the ROM instead of the CRC the emulator calculates. I should change it to use what the emulator calculates because it's not much help if it can't even differentiate between a good and a hacked ROM.
Anyway, yeah I think a run of this game should be more entertaining than this. I think it should be made with these rules:
- hardest difficulty
- must complete all bonus stages
- choose whichever character is best for doing entertaining and varied moves as that character's optimal means of attacking, which is not necessarily the fastest or most powerful character
- aim for fastest time given the above restrictions
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Note that, while they apparently did not fix any bugs at all from SMB3 (and just added one more), they did fix bugs from the earlier games, for instance up+down no longer works on SMB2 ladders, and maybe I'm wrong about this but it seems the physics or collision detection of SMB1/SMB2j were changed a bit. A 4/5-game run could be neat though. (Imagine if all those were done 100% instead, that would be the longest Mario run ever.)
(BTW, I think the duck-through-corner glitch was intentional in some cases, for instance there's a secret room I go into in the fortress before Bowser's castle that has no other way to enter it... well I didn't check if a P-switch door opens up there, but that invisible coin block was way too conveniently placed.)
About this run, I don't know. A warpless run of this would probably be better and at this point (until JXQ or someone does it, at least) less confusing/controversial as to whether it should be published, but I still think this is interesting to see.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Baxter wrote:
In the list of selectable movies, when you press "replay movie", you can select all the movies that have the same rom checksum AND all the savestates you made from that game.
Oh, so selecting those savestates isn't working. It probably broke from making any change to the items in that menu because it used to be hardcoded which items are the savestate ones.
Baxter wrote:
I was talking about 1 movie... Angerfist and Dehacked made it, it's the megaman 4 movie that's just been submitted (you can download it at the submitted movies).
Oh, OK, just found it. Uh, that movie file doesn't have any author info or ROM info or MD5 info in it at all. They must have converted it back to FCM with nesmock or something and then not bothered to use the --set options to restore those things, and not entered any author info in the first place. (I'll take a look at this other, more serious problem you mentioned about it, though.. edit: ok, I know what the problem is, this is a major bug but shouldn't be too hard to fix.)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Baxter wrote:
At replay movie it also links to all the savestates now.
I don't understand what you mean by this.
Baxter wrote:
Like Phil already mentioned... the 1% speed (and 3 and 6) don't work properly anymore, which is, to me, one of the most importent options.
To fix it, activate Sound options->Use old update code. (Until the new update code is fixed for the < 25% case.)
Baxter wrote:
I also noticed I couldn't see the author info for Angerfists, and Dehackeds run, and when I tried to make a rerecords in the movie, to change something, stopped the movie, and tried to watch it again, the movie wouldn't play.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Andy Olivera wrote:
nitsuja wrote:
AVI audio/video sync fixed
Awesome! So what turned out to be the ultimate cause of the desync?
I don't know. The number of sound samples generated didn't quite match the number of video frames. I looked at the Linux AVI recording patch and found no differences to timing in there that I had not already tried, so I'm not sure how it works with that...
Andy Olivera wrote:
The spontaneous exit when choosing "Full Frames (Uncompressed)" might be caused by a bad setting in FCEUI_AviBegin():
bi.biSizeImage = 4 * bi.biWidth * bi.biHeight;
That 4 should be a 3, since we switched from 32-bit to 24-bit RGB.
Ah, this seems likely. Apparently every other codec, including ffdshow set to Full Frames (Uncompressed), corrects for it somehow, while that doesn't.
Andy Olivera wrote:
Out of curiosity, as a possible (major) optimization, how hard would it be to change the convert_buffer variable in the avi_file struct to a three dimensional array? I ask because do_video_conversion(), given how often it's called, sucks up a ridiculous amount of operations finding the proper byte in a one-dimensional array. I estimate about 20 wasted operations in a loop that runs over three million times per second. Just a thought...
This is easy to do, but mainly because there's an easier way to optimize out the repeated calculations than making it into a 3D array (which would either slow it down from extra indirection and memory alignment changes, or be exactly the same as a 1D array and only conceptually 3D).
Actually, any decent optimizing compiler should perform this optimization on that loop automatically, and then some, but I wouldn't know if that's true of gcc.
Phil wrote:
When using frame advance and show inputs is on, we don't see them.
I take it that means this is a feature you'd like. OK...
Phil wrote:
Edit: CorePNG codec isn't working well. In fact, FCEU either crashes when stopping recording or the AVI is 0 byte.
Maybe it's the same thing that's making uncompressed not work.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
FODA wrote:
Maybe you didn't have enough speed going towards the stairs? after you go up one stair mario needs to have enough speed to get to the next stair in at least 3 frames, or else he jumps out of it. As it is not a slope i'm 99% sure it will work.
Well, what I was worried about is that it is possible that those stair steps were made unusually large or wide to compensate for the camera angle (to make them appear the same size as the other steps), enough so that it's not quite possible to reach the next step in time. It was at a strange angle so perhaps full analog precision would make it work fine, but I think it's worth testing just in case it is actually impossible to do the trick there to avoid having to redo the route later when you get there.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Xebra: Oh. Well generally when the goal is to minimize the in-game clock time, there is implicitly also the goal to minimize the real-time but only when it does not result in a worse in-game time (making exceptions for that only when it looks exceedingly ugly such as the murder beam glitch). So waiting more than necessary after a level would probably be considered a mistake although minor compared with losing time inside the levels.
Anyway, it was a mistake (and wrong) to call his run "shitty" like that; if something he did really bothers you then you could have made it clearer why you didn't like it or even just restated that you really thought it was a problem, without resorting to insulting the movie and author. Getting other people pissed at you doesn't help anything; if you think he might improve those parts of the run then it doesn't make it any more likely to happen, and if you've already accepted that the run is beyond all hope of meeting your standards then insulting him/the run still won't make things better. I mean, not even going into the ethics of why it's wrong, it just wasn't a logical or helpful thing to do.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Well, it couldn't be on the game screen, I would have to pop up a new window separate from the Mupen64 one, and use I-don't-know-what to actually draw the controller graphics in the window, which would probably reduce the emulation speed without either a low update rate or a lot of work on the update timing.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Foda: Well, be sure to actually test that the backward stair jump really works on the basement stairs. It is an actual staircase, not a slope, so the trick should work, but when I tested it briefly I couldn't get it to work for some reason (then again I couldn't get the glitching into JRB to work either and you figured it out).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Bisqwit wrote:
Edit: Now it desyncs around here:
If you have the speed limiter off, that would cause the problem - it needs to run at 100% speed to stay in sync (possibly because this game needs "fake mute" to work more reliably but this movie wasn't recorded with that option on). Otherwise, I'm not sure - the way others have fixed it is by playing the movie, then if it desyncs, restarting the movie in the same emulation session to get a different result (but I don't know if that's something you can do this case).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
I think the compression makes a big difference, because movie files of input are extremely compressable. For instance, it will reduce an 800 kb movie to probably 4 kb. (Maybe it doesn't seem like it, but that's a big difference when it's added up across many downloads.)
There was a problem with how the site stored or retrieved the zips recently, but it's at least worked around / not breaking the downloads anymore.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
OK, I found a change to the sound buffering code that fixed it. I updated the links in the post above with the fixed version. EDIT: Uh, actually wait a sec, I think that slowed it down, now it really is slower than 1600%. EDIT2: OK, now it's really fixed.
Phil wrote:
Since turbo and 1600% are the same speed, why not using 1600% for turbo?
Because they're not the same speed; if your computer is fast enough, turbo should be even faster than 1600%. The problem is fixed now anyway.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
OK, it's only between about 0.1 and 0.5 seconds of a delay for me, which seems fine for going out of a mode like fast-forward, but I'll look into it. I was probably wrong that it's just the frame skip, though, I think what's happening is that fast-forward neglects the sound buffer somewhat so on resuming it waits until the sound is ready.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Phil wrote:
And about that delay?
I said: Turbo skips a lot of frames, the delay is only apparent in the video and it is the frame skip catching up to the next frame after slowing back down.
(it's not intentional but it's not a major problem either)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Turbo skips a lot of frames, the delay is only apparent in the video and it is the frame skip catching up to the next frame after slowing back down. Also, turbo turns off all limitations and skips all waiting so it runs as fast as possible. Turbo and 1600% both run at the same speed for me, except turbo skips many more frames than 1600% does so each graphical update is slower to happen even though it's emulating the same speed or faster.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
OmnipotentEntity wrote:
I'm pretty sure that the 70 star run gets the Blue Cap Star without the Blue Cap,
So, you don't mean this one?
LeCoureur103 wrote:
I also tried to take into account the time spent moving through the castle, which meant that I wasn't able to get the Vanishing Cap or its star since they're so far off the beaten path.
BTW, Foda, maybe you should test if it's possible to do the backwards stair jumping from the stairs that go down into the basement, if it's possible it would probably save time in reaching the ghost house down that hallway.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
TNSe wrote:
In games like these, with such incredibly accurate ingame clock, doing a speedrun against the CLOCK, and not TOTAL FRAMECOUNT is a very good goal. I believe this is what Quietust aimed for in his Sonic 2 run.
Note that this is not the point of contention at all; this is also what Xebra was aiming for (if I'm not hugely mistaken).
