Hi Bock,
I agree, 2 bytes per frame is not enough for every peripheral. However I designed the format for dega, which doesn't support any peripheral apart from the joypad. If more peripheral support were added it would be trivial to add it to the format because it is extensible (simply by increasing the input packet size).
I did have a look at the meka code while I was choosing an emulator and I believe it would be relatively simple for someone familiar with the code to be able to add universal recording support. For the input data I can think of 3 ways to do this:
1. An input packet consists of all the data required to determine the values received from the I/O ports used for user input (0xDC, 0xDD, 0xDE). This means the current choice of input device, joypad buttons held down, position of light gun etc. An input packet is stored every scanline (since meka samples input every scanline).
Advantages:
- very easy to determine original user input, e.g. for an input display
Disadvantages:
- large amount of data storage (about 3KB per frame), due to having to store input data every scanline
- changing the list of peripherals, or the way that meka converts raw user data into I/O port data, would lead to incompatibilities
2. Same as above but store input packet every frame. This would involve changing meka to sample input every frame rather than every scanline (because any user input that happens between frames would end up unrecorded).
Advantages:
- very easy to determine original user input, e.g. for an input display
- relatively low data rate
Disadvantages:
- sampling data every frame might have consequences on emulation
- changing the list of peripherals, or the way that meka converts raw user data into I/O port data, would lead to incompatibilities
3. One input packet every time the game reads from the user input I/O ports, consisting of the port number and the value the game read from the port. To play back, simply feed the game the same input data.
Advantages:
- easy to implement initially
- guaranteed to be deterministic
- no need to change format if peripheral emulation changes
Disadvantages:
- hard to implement an input display, because we would need to 'reverse engineer' the data in the movie file into the original data
I didn't get anywhere with the degavi/cygwin stuff. Got it to compile and start encoding but because of a subtle cygwin bug it won't get past the first frame or so. It's certainly possible to dump the raw data to disk and run mencoder over that (rather than piping it in to mencoder directly) but raw data = 150396 bytes/frame at 60fps, so even a 10 minute movie represents about 6GB of raw data.
I have RC3 ready. Fixed the readonly bug, added readonly mode hotkey, choice of status bar modes (hide/auto/show), autofire, autohold, reset speed. No more feature requests please until the release but do report any bugs you find.
Source code: http://www.doc.ic.ac.uk/~pcc03/tmp/dega-1.13-rc3.tar.gz
Win32 binary: http://www.doc.ic.ac.uk/~pcc03/tmp/dega-1.13-rc3-win32.zip
I'm going to change that for the release.
FODA wrote:
1 - AVI dumping
You can already do this via the degavi program (included in the source code archive), but that will only work on Unix-like systems. I'll see if degavi can be compiled and run on cygwin if we need a windows version.
I don't know if it's worth implementing a memory viewer given that there are already external tools for that. I could try to implement a trainer/watcher though.
Here's the second release candidate. It adds save state slots (0 to 9), and contracts the display area when the status bar appears so you can actually read the frame count (whoops...) I've also made the file format more extensible:
0000: identifier 'MMV\0'
0004: dega version
0008: frame count
000c: rerecord count
0010: begin from reset?
0014: offset of state information
0018: offset of input data
001c: size of input packet
0020-005f: author (UTF-8)
0060-625f: savestate if beginning from state
rest: input data, 2 bytes/frame (one for each input)
I've also made this version backwards compatible with old video files.
Source code: http://www.doc.ic.ac.uk/~pcc03/tmp/dega-1.12-rerecording-v7.tar.gz
Win32 binary: http://www.doc.ic.ac.uk/~pcc03/tmp/dega-1.12-rerecording-v7-win32.zip
Here's a WIP which fixes the bugs reported so far and also implements bulletproof rerecording. Obviously the savestate file format changed, but old savestates should still work (if you reload as though you were still using a non-bulletproof version). So to convert to the new format just load and save again.
Source code: http://www.doc.ic.ac.uk/~pcc03/tmp/dega-1.12-rerecording-v6.tar.gz
Win32 binary: http://www.doc.ic.ac.uk/~pcc03/tmp/dega-1.12-rerecording-v6-win32.zip
This implements all the features I said I would implement. So if no more bugs are found this is a release and not a WIP.
Found another bug. (One that pissed me off, because I now have to redo a good segment.)
What happened, is I reloaded a save I didn't want to reload. (I meant to actually save at that point, but hit the wrong key.) Now, I go and reload last known segment, which is farther ahead than the original save, and instead of the emulator refusing to load the save as it should. (Save no longer matches movie, the moment you go back and rerecord the segment before that save.) Rather annoying, because I go to watch my finished work, and now I got to rerecord that final segment.
I don't understand the bug, but what you describe look a lot like bullet-proof rerecording. it seems to be missing from pcc's dega. it is not mandatory to get the emulator accepted (so it should be soon hopefully !), but once you get used to it, I can understand how you can miss it.
Yeah, I'm planning to add bulletproof recording for hopefully the next release.
OK, this WIP adds quick load/save (F5/F6 by default, Windows only for now), as well as speedup/slowdown (+ and -). You can also configure the fast forward key (previously F8).
Source code: http://www.doc.ic.ac.uk/~pcc03/tmp/dega-1.12-rerecording-v4.tar.gz
Win32 binary: http://www.doc.ic.ac.uk/~pcc03/tmp/dega-1.12-rerecording-v4-win32.zip
It looks like the community is divided on whether to use dega for runs. I'm happy to take bug reports/feature requests for now but I can't devote much time to this after a month or so. I don't think it would be worth me working on another emulator now. So dega is available now and obviously if a rerecording meka/gens+ is made by others then it can be used as well. The only problem with that is that it might be hard to compare times between dega and whatever emulator we use due to timing differences. I guess this issue has been considered before (Famtasia/FCEU)?
At this point I'd like to ask TPTB to have a look at this emulator and decide if it can be accepted here. Or is this done on the basis of runs being available?
Hi guys,
I have a new WIP with hotkey configuration (Windows only), read-only mode, encoding support (Linux only) and an author field. Because of that field I had to change the file format so old files are incompatible. Here is the new format:
0000: identifier 'MMV\0'
0004: dega version
0008: frame count
000c: rerecord count
0010: begin from reset?
0014-001f: reserved
0020-005f: author (UTF-8)
0060-625f: savestate if beginning from state
rest: input data, 2 bytes/frame (one for each input)
To use the encoding support build the Linux version and you should get another executable 'degavi'. degavi spawns mencoder for you and feeds in the correct audio and video data so you don't have intermediate test0.avi and audiolog.mp3 files. You only need to give your choice of OUTPUT parameters (except the filename, which is separate). Run ./degavi for the syntax.
The downloads:
Source code: http://www.doc.ic.ac.uk/~pcc03/tmp/dega-1.12-rerecording-v3.tar.gz
Win32 binary: http://www.doc.ic.ac.uk/~pcc03/tmp/dega-1.12-rerecording-v3-win32.zip
as for meka's linux issue, there are already several emulators accepted on this site, that work partially or not at all outside windows, it's not such a big issue thanks to wine.
Hmm, AFAIK those emulators were accepted before the 'new emulator' rules were established, so I guess they were grandfathered in?
SXL wrote:
btw, what conditions is your emulator still missing to get accepted ? some gui code would help maybe :)
What gui code are you referring to?
I think it currently satisfies all the objective conditions at NewEmulatorConditions apart from "author field in movie file", "possible to create avi" and possibly "OSX compatibility". But that is the bare minimum and I'm also looking to hit:
- bulletproof recording
- slow motion/fast forward
- readonly
- info display
- hotkey configuration
from DesiredEmulatorFeatures (which should be easiest/most important).
FODA wrote:
being able to save/load when the emulator is not paused
That should already work? Could you give more details?
Works fine so far as far as recording and playing back movies are concerned, but it crashes whenever I try to load a save state. Still, this is very promising
Does this happen for a particular game, or for every game? Also, does it only happen while rerecording or not? If so, does it still happen if you use a movie file with a shorter path name?
Hi guys,
Thanks for your input. I looked at meka, but there are sound issues on Linux and some soundcards and besides the code is ugly and supposedly nondeterministic, so I'm not going to touch it. If someone else can fix these problems (Bock?) meka would be the clear choice but as it stands might not fulfil the criteria (http://tasvideos.org/NewEmulatorConditions.html)
I have a second WIP ready with Windows support. You can use the p and o keys to pause and frame advance, and the movie functionality is on the Video menu.
Here are the downloads:
Source code: http://www.doc.ic.ac.uk/~pcc03/tmp/dega-1.12-rerecording-v2.tar.gz
Win32 binary: http://www.doc.ic.ac.uk/~pcc03/tmp/dega-1.12-rerecording-v2-win32.zip
Let me know if you have any issues.
Also, I would like to ask anyone with an Intel Mac running OS X to see if they can compile and run the Unix/SDL version on their machine. I believe it should work but don't have a Mac so cannot test.
Here is the first WIP of the rerecording code. Pause and frame advance have been added to the SDL version, and rerecording now works.
Here are the relevant key mappings:
p - pause
o - frame advance
r - record from reset (you are prompted on stdin for movie file name)
e - record from current state (you are prompted on stdin for movie file name)
t - playback movie file (you are prompted on stdin for movie file name)
w - stop recording/playback
s - save state (you are prompted on stdin for state file name)
l - load state (you are prompted on stdin for state file name)
and the movie file format (pretty standard stuff)
0000: identifier 'MMV\0'
0004: dega version
0008: frame count
000c: rerecord count
0010: begin from reset?
0014-001f: reserved
0020-621f: savestate if beginning from state
rest: input data, 2 bytes/frame (one for each input)
and the code: http://www.doc.ic.ac.uk/~pcc03/tmp/dega-1.12-rerecording-v1.tar.gz
This will only work on SDL (Linux), a windows version is forthcoming with a unified source tree
P.S. if your terminal is flooded with 'resetting audio_len' messages, comment out sdl/main.c line 45
How do you record? :) the readme file didnt say :P
Sorry, forgot to mention. You need to give command line options to the dega binary:
-r,--record <file> to record to <file>
-P,--playback <file> to play back from <file>
both recording and playback will start immediately.
Hi,
I'm thinking of doing some development to add rerecording support to an SMS emulator. After looking at the emulators available I believe that dega would be our best choice for doing so, given that it has good cross platform support and a clean code base. I'd like people's opinions on this particular emulator.
As a taster I've also hacked together recording and playback support for this emulator (possibly a bit too cautious as it saves state every few frames). Source code is available here (based on the Linux port): http://www.doc.ic.ac.uk/~pcc03/tmp/dega-1.07-sram-ss.tar.gz