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.
Embedding of compressed savestates is already being used in snes9x.
Also, I think that you shouldn't design the fileformat solely with the rules of this site in mind.
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.
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.
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...
After Alpha 3, I was unable to playback any movie file in Windows XP. I haven't touched any of the plug in settings, and any old movie files that I have tried to play don't work.
The movie has sound, but there is no video. It just displays a grey area.
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.
Anyone else having this problem?
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).
I mean that glN64 will show the picture the first time I load a ROM after starting Mupen 64, but if I play a movie, reset the ROM, or load a ROM again, it'll only show gray. I don't think any of the video settings have anything to do with it...
put yourself in my rocketpack if that poochie is one outrageous dude
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).
I think BOMF is experiencing the exact same thing as I am.
I'll describe the characteristics as best as I can (it's late here, and I'm sleepy).
1. The Mario 64 ROM plays fine using glN64 when I first load it.
2a) When I reset the ROM, it doesn't show any video input, but plays sound. Basically the windows stays the same size, but is filled with grey. The frame counter still moves.
I'll take a screencap, but printscreen doesn't work, and I forgot how to change my hardware acceleration/overlay options in order to make it so I can screencap... I don't think it's necessary.
EDIT: Got a screencap:
I think the fact that I was able to get a screencap without any problems, means there is no video playback whatsoever!!! And this occurs after a rest.
2b) Playing a movie file results in the same as 2a (probably because it resets the ROM), however sound still plays.
3) Running Windows XP, on a Dell Inspiron 700m, 1.8Ghz, 60gb HD, 768 RAM (16MB shared, w/intel accelerated graphics).
4) I haven't tested all the plugins, but a few others don't work because my video card doesn't support some its features (integrated video). Could that be behind the cause of this "reset" glitch? Could it be my graphics card? It was working before.
5) I'm currently using: Jabo's Direct 3DC 1.5.2 plugin. Everything else works, except for Glide64 V0.7 ME SP8 (and glN64), since "My video card doesn't support GL_ARB_TEXTURED_MIRRORED_REPEAT" extension.
Hope that helps. :)
EDIT2: Is it possible for you to post the Alpha3 binary again, so I can verify it works for glN64? Or is that not necessary?
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.
It would seem (to me) that avi recording is still somewhat bugged in alpha5.
When recording, the mupen window stays ontop of all others, and if minimised it doesn't capture the video, while still capturing sound (a reasonable annoyance given the size of the window). More importantly, when recording (using jabo's direct3d8 1.6), it gets to frame 9920 of spezzafer's movie (or at least thats where the counter stops, it'd be within 10 frames of that i'd think) and then craps out in terms of video recording.
It still records the audio, but the video no longer gets recorded and thus the last image you see when watching the avi file is mario holding up a star to open a door. when that happens, the playback speed goes from recording slow (about 5-10fps for me) to normal playback speed, and causes some weird stuff to happen with the emulator until its closed.
Is this just me or is this happening to others who try recording avi with alpha5?
It's probably not just you. (Edit: Yep, it happened exactly like that for me too. It's fixed now.)
(About not being able to minimize, that's because video plugins were never designed with the thought in mind that it might be necessary to draw the graphics somewhere else than inside the emulator window, so the only way to capture the video is to read it off of your screen.)
New version (v6) is up.
- Fixed the bug Atma pointed out where after about 9900 frames of AVI recording the GUI would get totally corrupted and stop updating the video (the read_screen code was leaking device context handles).
- Changed the input display to actually be readable. (" {>>^} ZAB C^ " = analog is a fair amount to the right and a little bit up, and Z, A, B, and C Up are held.)
- Changed the movie format to store author/description in UTF-8, and the dialog fully support displaying it, so now you can describe your movies in Japanese or Hebrew or whatever, and it should actually show up. (Note that if you don't have the right character sets or if you're using Win98/ME and don't have unicode support set up, you'll find many characters display as '?' marks. Let me know if it crashes instead - I'm not entirely sure it won't.)
- Fixed movie version storage and added some code to recover corrupted plugin info stored in some previous movies.
- "Fixed" the gray-screen thing... by changing it to black. I still have no idea what could be doing this. It doesn't happen for me, and the fact that it still happens when closing and restarting normally implies that it is not a problem with the game restarting code I added.
- Made it so you can play a movie if you have too many controllers enabled (it just gives you a "possible desync" warning instead of refusing to play).
- If a playback snapshot isn't found, I think it should do something less confusing now.
- Added more extensive error checking to various things (AVI output and recording).
- Fixed a problem where using an input plugin with mouse control permanently locked out the menu - now Alt will still work to open the menu in that case
nitsuja, I have a request, I really liked the hex (or rather I really liked being able to read exactly where the analog stick is), can you leave an option to convert the entire thing back to hex or just the analog stick?
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
v6 start to yapping about bmglib.dll error thing but emulator/playback works fine, could you it shut up about bmglib.dll error? =/
Oops, yes, I just forgot to include that file.
OmnipotentEntity wrote:
nitsuja, I have a request, I really liked the hex (or rather I really liked being able to read exactly where the analog stick is), can you leave an option to convert the entire thing back to hex or just the analog stick?
Sure - I would've found it useful but I can't convert from hex to signed 1-byte integer in my head so easily... I can see it being useful at least for hex editing, though.
I think the fact that I was able to get a screencap without any problems, means there is no video playback whatsoever!!! And this occurs after a rest.
2b) Playing a movie file results in the same as 2a (probably because it resets the ROM), however sound still plays.
3) Running Windows XP, on a Dell Inspiron 700m, 1.8Ghz, 60gb HD, 768 RAM (16MB shared, w/intel accelerated graphics).
4) I haven't tested all the plugins, but a few others don't work because my video card doesn't support some its features (integrated video). Could that be behind the cause of this "reset" glitch? Could it be my graphics card? It was working before.
5) I'm currently using: Jabo's Direct 3DC 1.5.2 plugin. Everything else works, except for Glide64 V0.7 ME SP8 (and glN64), since "My video card doesn't support GL_ARB_TEXTURED_MIRRORED_REPEAT" extension.
Hope that helps. :)
EDIT2: Is it possible for you to post the Alpha3 binary again, so I can verify it works for glN64? Or is that not necessary?
