Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Alpha 5 is up - see the first post.
The AVI sound output has been fixed (the sound resampling was screwing it up before, and drift-fixing code also had to be modified).
AVI output of glN64 no longer has a white or garbage pixel at the top of the movie.
Also, Spezzafer's movie plays without desync (alpha 4 was expecting input 1 frame too late).
edit: arg, I think I forgot to "#pragma pack" something, so the plugin info might still be off...
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
I suppose this is relevant here:
http://rapidshare.de/files/6817019/mariotest47.avi.html
It shows a shortcut that I'm sure is possible but couldn't quite get to work (managed to do 2 wall-kicks from it and still couldn't quite land on the platform although there were 3 directions to hit, but then again I was using keyboard controls). It also shows a slightly faster way up the endless stairs to Bowser, (still not perfect since I wasn't lined up straight with it). I made the AVI mainly as a test of audio quality, in case you're wondering why the video isn't the greatest...
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Bisqwit wrote:
Is the "configure" file supposed to be missing? Do the ".o" files belong in that zip?
There are 0 makefiles in that zip.
-confused
It's meant to be copied over the original source:
http://mupen64.emulation64.com/files/0.5/mupen64_src-0.5.tar.bz2
I had a readme file explaining that but apparently it didn't get in the zip... I'm not sure about the .o files, that could also be a mistake.
edit: I fixed the uploaded alpha4 source to not have the .o files, have the readme, and have a 1-line change DeHackEd pointed out to let vcr.c compile.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
DeHackEd wrote:
Can we get source code to version 4? (Or at least a patch against v3).
Sure, it's on the first post now.
Bisqwit wrote:
Also, I think that you shouldn't design the fileformat solely with the rules of this site in mind.
Well, the savestates are typically between 1 and 2 megabytes compressed, so this was a major consideration:
nitsuja wrote:
save states are so large that it might be worth it to figure out how to start multiple movies from the same save state
But I'm reconsidering it anyway; that might not be so important compared to the convenience of other setups. And it's possible to do in addition to other things, as well.
TNSe wrote:
What we can expect when we get things up and running properly
I'm still astonished by the video quality of these, although mostly by the high-res + FSAA the codec manages to keep intact, at least for the Mario 64 one.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Michael Fried wrote:
Oh, I was wondering what those st files were for. Why can't those be combined with the m64 files?
Because they are huge when uncompressed and I wasn't sure how to combine them with the uncompressed movie files. I know it's possible, but since from-snapshot movies aren't submittable and the save states are so large that it might be worth it to figure out how to start multiple movies from the same save state, I didn't bother combining them.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Michael Fried wrote:
I tried recording from snapshot and it played fine. Then I tried changing the name of the m64 file and it failed to load the snapshot at the beginning and desynced right away. Then I changed the name back and it played fine.
Yep, that's supposed to happen. Although maybe an error message would be nicer than a desync. If you rename the movie file you have to also rename the snapshot (.st) file accordingly.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Unfortunately, with the random desyncs of Mupen64 fixed, it turns out that this movie no longer stays synchronized. Luckily, it stays in sync until the very end right before fighting Bowser the third time, probably because the Goomba positions on the final platform were randomized differently. This could probably be fixed by either adding/removing a frame somewhere in the movie or by just redoing the last Bowser fight.
EDIT: or maybe I'm wrong and and TNSe is right and the movie file plays back just fine...
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Alpha 4 of the Windows version is up. Playing from-snapshot movies should be fixed, playing from-start movies should no longer have a high chance of desyncing at the start, AVI output should no longer crash so much, and the music of AVI output should be better.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
The feature doesn't exist in FCEU yet. It annoys me too - the only way to sort-of simulate it for now is to either use slow motion and pause/unpause a lot, or leave it paused and be willing to mash on that frame advance button pretty quickly. (Unless I'm mistaken, FCEU is the first emulator to implement frame advance, and the "repeat" frame advance functionality of other emulators actually happened as a mistake and only later was discovered to be more helpful.)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
OmnipotentEntity wrote:
nitsuja wrote:
A faster way to start 5-9 is to backflip->wall-jump, jump, backflip->wall-jump up to the first switch you activate instead of climbing up 2 ladders to get there. If you can walljump off of a handstand jump then that could be substituted for the first backflip to reach the wall sooner.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Filespace has been dead for the past several days. But I just checked now and it's back up again. (Is anyone who has the file willing to mirror it, btw?)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Phil wrote:
No, because the frame rate is constantly changing like you said earlier. Sometimes, the game is at 20 fps while it can be at 50 other times. So, there will be duplicate frames. Not because of lags but because N64 sucks and can't do ~60 fps like other systems. :P
I didn't say it's constantly changing. In most games, it changes only at certain specific times (like before the game really starts) and stays locked at one speed for most of the game. The FPS number you see in the emulator might be constantly changing, but that's not the FPS of the N64, it's just the FPS the emulator is displaying (which could be lower or higher). Using an external tool will get those extra changes due to your computer speed, whereas exporting the frames from the emulator will get the constant speed it is supposed to run at. (For instance, if you try recording a movie of Legend of the Mystical Ninja with external tools, you will get terrible slowdown in the AVI, but if you get the frames from the emulator and put them together, that extra slowdown will be eliminated.)
Andypro wrote:
Well, it's all good now since nitsuja seems to have fixed the avi output issues.
Sorry, actually I'm still working on it. (Or rather, haven't been able to work on it much yet.) So far I think I've gotten it to not crash, but there are other problems...
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
robot wrote:
I like to use VBA-Record, and very glad to help.
...
Thanks. I wouldn't have thought to use /FORCE, for one thing. Right now I am working on mupen64-rerecording, which currently has higher-priority changes to make, but I will try this when that's in a more stable state.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Phil wrote:
But you will have no choice but to duplicate frames because FPS always change during emulation. So imo, you can use external software since it won't be worst.
Well, the duplicate frames are just like when a NES or SNES game lags, except most N64 games purposely lag almost all the time at a constant rate. An external recorder will also get these duplicate frames, but it might get more or less frames than are actually there for a given graphics frame. Even if you set it to record at 60 FPS, it probably won't record at exactly that rate, and the emulator doesn't always run at quite the same rate of the game it's emulating either. Only getting the frames directly from the emulator will result in completely accurate output, and it's probably faster than using an external software recorder anyway.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
I found what was causing the synchronization problems. There was basically a random chance that the emulation thread would skip over the first frame of input if the ROM-restarting thread took too long. Adding in better messaging between the threads seems to have fixed the problem completely.
(I think the reason I never noticed this problem before is because I never hit Start on the very first possible frame in my tests of Mario 64, in which case it happened to stay synchronized either way.)
I also tried putting the emulation and GUI in the same thread, but then I realized that the emulator core is written in such a way that it would need to be heavily modified for this to work (especially the low-level magic the dynamic recompiler does). Oh well, so much for making the GUI more stable with a simple change.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
DK64_MASTER wrote:
I hope it gets accepted just for a first ever submission's sake!!
Maza wrote:
I know this is just a testrun but I seriously think you should submit this. (I really hope you do.)
I agree (despite that it will probably be improved on), but all that will have to wait until it's possible to correctly output AVI's from Mupen64 movies. Which I wish hadn't turned out to be as tricky as it has been....
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Hmm... on closer inspection, it looks like neither of the functions are implemented by the plugin, and the emulator is substituting its own code to capture the screen in both cases. (And taking a screenshot causes crashes for me with plugins that would also cause the AVI capture to crash.)
Because there's no other interface for it to access the back buffer to get the rendered image, the emulator uses the front buffer instead, which means it will even capture things like the mouse cursor or other windows if you move them over the game screen. I don't think this can easily be fixed inside the emulator. Modifying glN64 is a possibility, however... I've been avoiding getting into that, but maybe it will be easier than whatever alternative hackery I would otherwise try to fix up the AVI capturing (although that should probably be done too to support non-glN64 plugins).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
TNSe wrote:
But the screenshot functionality works perfectly in all cases it seems... could you perhaps use the code behind the screenshot functionality to produce the image output to the AVI?
Ah, good idea. I hadn't noticed before but for some reason there are two completely different functions that the graphics plugin should provide for capturing the screen data, the one that's used for screenshots apparently being better-supported. Possibly it's much slower, but if it always makes a correct AVI without crashing then that's still a big improvement.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
I think I saw a few places where a strategy from the 70-star run would've been faster (especially the whomp's fortress tower top one). And I'm pretty sure there are faster stars that can be used to replace some of these, probably making use of the yet-undiscovered tricks for this game which almost certainly exist. But it was really great to see anyway, especially the bowser levels with so many consecutive high-risk maneuvers.
Gorash wrote:
Since timing by frames seems to be a little difficult on N64:
from Poweron: 17:34
I'm not sure what you mean by this. The number of frames in this movie divided by 60 is 17 minutes and ~32 seconds, which is the length of the movie and what it says in the Play Movie dialog.
Gorash wrote:
And I had slowdowns in the level before second bowser.
Actually, this is accurate emulation of how the real N64 slows down in exactly the same place.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
gbagcn wrote:
I think I remember someone saying something about Visual Boy Advance not being able to correctly emulate this game. The game should work on other GBA emulators but none of them have rerecording support.
Actually, it looks like VBA 1.8 is fixing this bug. Just have to merge some of their fixes in, maybe when 1.8 is no longer still in beta. (In the meantime if you just want to play it on an emulator without recording it, supposedly you just need to get 1.8.0 beta 3.)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
I think this is a multithreading issue, where it only works if your computer happens to switch threads in the right order. So depending on the speed of your computer, various things like other programs or window ordering could change whether it works. I'm going to try merging the Mupen64 GUI and emulation threads, because having them separate is causing way too many problems like this, and I don't really see any benefits to them running in separate threads.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Ferret Warlord wrote:
I had to click the red X in the corner to get it back in shape. Maybe it's because I headed for the "Options" menu too fast; I don't know.
Some of the plugins have extremely buggy options dialogs. (And the Mupen64 GUI itself is also still somewhat unstable.) It's safest to only make changes when a game isn't running and restart between changes, although for most plugins that isn't necessary. (EDIT: and I've seen this exact same bug myself on the original Mupen64 1.5, sometimes this plugin seems to prevent the GUI from loading correctly.)
Ferret Warlord wrote:
And frame advance, assigned to the spacebar, isn't working. It gets out of paused emulation;, beyond that, it's not doing a bloody thing.
I tried this, and the only trouble I encountered was that it's a little tricky to assign Space to a hotkey. Besides that it worked fine. What happens when you press and release it while the game is not paused? That should pause the game if it's working right. (If not... it could be a simple bug somewhere but maybe it's an OS-specific issue as I haven't been able to reproduce it myself.)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
OmnipotentEntity wrote:
If anyone can come up with some faster strategies on 5-9 or 5-10 please let me know.
A faster way to start 5-9 is to backflip->wall-jump, jump, backflip->wall-jump up to the first switch you activate instead of climbing up 2 ladders to get there. If you can walljump off of a handstand jump then that could be substituted for the first backflip to reach the wall sooner. (And 5-6 looks kind of slow for some reason, with the way the hammer was handled.)
Hmm, the music sounds terrible - what sound plugin did you use? (Or maybe it's from the codec? The non-music sound effects sound good.) Also it looks like it's outputting a little extra bar of stuff on the top and bottom, I think that is fixable. The actual graphics in the movie look fine though.
