Koh1fds is right. It's impossible to get the same result with external capture software. Screen capture programs record "what they see" so if you experience lag/hiccups or the like, that will be recorded as well. Built-in .avi record on other hand gives you a perfect frame-by-frame video dump.
I agree with him that .avi record feature is essential and should be a staple for any good emulator.
You both make some good points.
I'll try and take a look at lsnes' code sometime in the next few days and see how easy/hard it would be to adapt it.
And on an unrelated sidenote, the issues you had with overclocking are (supposed to be) fixed in 0.6.1.
I just finished adding AVI recording to Mesen.
I ended up looking at DOSBox's code and implementing the same solution.
The video can be either recorded raw with no compression, or using the ZMBV codec. The audio is always recorded as uncompressed WAV data.
The ZMBV codec gives a pretty nice compression ratio (except with the NTSC filters) and I can record up to 4x native resolution at 60fps, with my 7-year-old i5 CPU.
All filters and sound effects, etc. are recorded as is. The only thing that is ignored is the "scale" field - the video is always recorded as if scale was set to 1x. e.g: xBRZ 2x will always record in 512x480 (assuming overscan settings are all set to 0).
If you want to record a larger video but without any filter, you can use the "Prescale" filters (which enlarge the picture with nearest neighbor resampling)
The feature will be available in the next version - let me know what you think once you get a chance to try it.
The avi recording feature is available in Mesen 0.7.0 (just released it).
It's fairly bare-bones at the moment - but I can add options/features as needed (assuming they are relatively easy to implement)
Thanks, Sour. Really nice to see it was implemented! :)
As for features to be added, I'd recommend compatibility with at least three codecs: Lagarith, Camstudio and x264. The first two are lossless, x264 is lossy by default, but you can activate "Single pass - lossless" under configuration.
Those are among the most popular and better codecs out there.
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Camsudio codec is just gzip so it's easy and compatible. Lagarith encoded stuff was reported by Ilari as not working on linux. x264 is a huge can of worms, I haven't heard of an emu that's embedded that, unlike ffmpeg, which was added to Dolphin and PPSSPP by Fog, yet it's still not the easiest thing to use.
I'd advice picking just gzip from that list, if necessary.
Another aspect: not all users have ZMBV installed, so it's required to download dosbox and install it from there.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Thanks for the feedback!
I'll take a look at the Camstudio codec - looks like something I could get working in a few minutes based on lsnes' code. Although I'd assume that much like ZMBV, some users might not have it.
Lagarith's source code is rather huge (though I'm sure a lot of it is unrelated to the compression process) - roughly 25% of the size of Mesen itself, so I don't feel like it'd be the best idea. I did not take a close look, but x264 looks to be at the very minimum 4 times the size of Lagarith.
If Camstudio+ZMBV are not good enough for redistribution, it would probably best to use tools like ffmpeg to convert them to whatever format works best for you. ffmpeg is pretty simple to use, and will always support far more codecs than I can ever hope to add support for :)
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Camstudio codec comes with standard codec packs, it's quite popular. Bonus points for compression levels.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
For what it's worth, the ZMBV codec was also included in the codec pack I've been using (K-Lite Codec Pack).
I added Camstudio (CSCD) compression support, along with a compression level slider (1 to 9, which is what zlib supports) which is used for both ZMBV and CSCD. CSCD sometimes has faster compression (not always), but almost always results in bigger files than ZMBV from what I can tell.
Also, the record options window now saves the options used on the last recording (codec & compression level), too.
Thank you so much for avi recording! Can you also improve movie recording feature, please? I test it in version 0.60 a little bit and right now i can't test it at all. Sorry
1. Please make so it saves more events and not only gamepads input:
FDS events (eject/insert disk, changing disk sides). In 0.60 it's impossible to record movie for fds games, because it doesn't save those events.
Console reset (i don't test this)
Insert coin (if mesen supports vs system)
Famicom microphone (i don't test this)
2. Please make so some emulator's settings (that can cause desync) saves in movie and loads when you replay movie.
Overclocking. It would be cool if number of extra scanlines that you add saves in movie and you don't have to remember this.
Region settings (i don't test this). Like if you record movie in "dendy" mode it automatically sets it when you replay it.
Starting ram values (i don't test this)
Input settings
Dip switches
3. Please fix "start movie recording" and "play movie" routines.
When you opens rom from archive with a lot of roms and then starts movie recording "from start" - mesen sometimes loads different rom from that archive for some reasons.
In version 0.60 you can record movie with overclock, but when you replays it - mesen for some reasons ignores overclock settings even if you put correct numbers before start of movie replay. So it's impossible to record movie with overclock in 0.60 and then replays it.
Can you make so when you start movie recording "from start" - mesen doesn't change input settings. Like if you choose arkanoid paddle it didn't automatically change input and ignores that. I don't think that automatically input changes depending on rom you loads is good. It's actually pretty annoying even if you didn't record movies.
4. It would be cool if mesen allows you to record input from more devices. At least Zapper (i don't test this) and arkanoid paddle.
5. Movie status icons would be also cool.
Please, if you can add more tas tools. At least pretty basic one. Like frame advance button (can't find this in 0.60), movie rerecording, frame counter, memory watch window.
It would be cool if dip switches works like in Nestopia plus. Like when you opens roms like Nintendo World Championship you get window where you can sets dip switches as you want. And not like crazy fceux way where you have to resets many times without knowing what's actually changes. And then if you start movie recording it saves in movie what you choose. It would be so cool.
Sorry for all
This is on my todo list - I need to rethink the file format for movies to support these.
Overclock settings, input and region are all already saved in the movie files. Ram init is forced to all 0s when recording & playing movies (because there would be no way to support the "random" init setting in movies)
The movie recording feature predates the ability to select a specific rom within a zip/7z file, so it's likely they don't work well together. I'll keep note of it to fix eventually.
This is already an option that you can disable - "Automatically configure controllers when loading a game" in the input options.
I'm fairly certain all the input devices can be recorded at the moment.
Not too sure what you mean - any example?
TAS tools haven't really been my focus - I understand people on this site want these things though, and I do want to add more of them eventually. A memory watch and other memory tools already exist in the debugger though, if you haven't checked it out.
This is also on my list of things to do.
Thanks for the feedback!
Because it ignores even correct overclock settings when you replay movie i was thinking that it didn't saves any settings at all.
Because it resets input settings and i didn't find that option - i didn't actually test it. Sorry
Like in fceux. When you start recording there is red circle and you know that you recording right now. When you play movie there is red triangle. It's pretty handy actually.
I checked them, but i didn't find handy memory watch tool. Like you put in it 3-5 addresses and can watch them in real time.
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
I don't know the current movie format of Mesen, but the best approach is to have a movie as an archive, where you put each element of the movie as a separate file: input log, header, subtitles, savestate anchor, you name it. And the best way to store input is as text. After archiving, it doesn't waste too much space.
http://tasvideos.org/Bizhawk/BK2Format.html
And when it's paused, you show ||. Also, can please pausing emulator not put a shadow over the image? Or the shadow density be configurable?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
It's a binary format that tries to compress the input info down as much as possible. It's something I came up with around the start of Mesen in 2014 and it hasn't changed since, but really needs a rewrite.
The only concern I have with a format that contains per-frame input is that a game that reads the input 2x in a frame may end up out of sync if the input had changed between both reads when recording (Mesen checks input state every time a rom requests it, not just once per frame). Games that use the DMC's DMA all read the input state at least 2x per frame, so there is a real chance of this happening. I guess I could make it so Mesen only polls input once per frame, at the moment the game first requests it, then returns the same input subsequently until the next frame starts - it would allow per-frame input to stay in sync, wouldn't really increase input lag, and should have relatively minimal impact on players.
feos wrote:
Also, can please pausing emulator not put a shadow over the image? Or the shadow density be configurable?
I'll add an option to disable the overlay when pausing. Would it be best to remove the overlay+the word "Paused"?
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
If you replace it with the movie status mark (also removable), it'd be best.
Poll based input is a good feature, don't remove it. You could simplify it though. This is what I'm planning to do with fceux someday:
https://sourceforge.net/p/fceultra/bugs/741/#168a
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
I guess I could make it so Mesen only polls input once per frame, at the moment the game first requests it, then returns the same input subsequently until the next frame starts - it would allow per-frame input to stay in sync, wouldn't really increase input lag, and should have relatively minimal impact on players.
Please don't do this. This results in more problems than it solves and is not accurate.
Either store inputs on every latch, or have an option to do this or per-frame input.
Really bad FDS sound emulation in Bio Miracle Bokutte Upa
edit: you play nsf file. You pause the emulator. You choose track that you want. You press "Record Wav". You unpause the emulator. Nothing is recording (without any notification, ofc). You have to press "Record Wav" only while track is playing. You can't pause, unpause, change tracks. You can't do anything! If you press something Wav recording immediately stops. It seems to impossible to start recording wav from beginning of the nsf track
There's been a few updates since the last time I posted.
Changes related to things that were posted here:
-I added an option to display a play/record icon when playing/recording movies
-Also added option to disable the gray overlay when the game is paused
-Changed the sound recorder so that it keeps recording after a game is reset - this should let you record a NSF track from the start (changing tracks in the NSF player resets the NES, which is why the recording stopped)
Beyond that, some interesting additions in the last few releases:
-Improved overall emulation performance by 15-35% (depending on the game) - Mesen should be pretty much on par with FCEUX's "New PPU" at this point.
-Added an equalizer to the sound options
-Added a bunch of model-specific emulation options
-Added command line options for most settings
-Improved emulation accuracy in general
-A lot of new debugger features (hex editor, graphic editor, code editor/assembler, etc.)
-UPS/BPS patch files support
Not too much progress from a TAS standpoint - reworking the movie file format to be more flexible is still on my list of things to do.
As for the Bio Miracle sound problem - I spent a bit of time looking at it, but haven't figured out what's wrong just yet. Thanks for letting me know though!
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Woah! How did you speed up the emulation so much?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Nothing too specific, really.
I rearranged a lot of if statements in the PPU's code to try and bring to a minimum the number of comparisons the CPU has to execute overall. Also reworked a few things to get rid of virtual functions when I could.
A lot of it was just trial & error - profile with VS' profiler, try to find something that felt like I could improve a bit, change the code, recompile & see if it helped at all.
I ended up trying a lot of stuff that I was convinced would help, which ended up having no effect whatsoever, though!
As for the Bio Miracle sound problem - I spent a bit of time looking at it, but haven't figured out what's wrong just yet. Thanks for letting me know though!
I also post it on git hub. Sorry! I didn't saw your answer here when i post it. Also thank you for nsf improvement! Now i can record some glorious mesen sound
Oh that's cool, thanks for linking that spikestuff, a lot of new test cases there.
Looks like there is more apu work to do in NESHawk then I thought.
Also @Sour nice work with Mesen! I look forward to being able to do some TAS type testing with it in the future!
EDIT: what is your criteria for passing count_errors, count_errors_fast, and read2004? It seems like they all have variable results from hardware testing, and I'm pretty sure NESHawk is at least emulating the related mechanics correctly.