If it helps any (though I doubt it will), when I close degavi after getting the file error it gives this error: "The instruction at "0x032c18c5" referenced memory at "0x00000004". The memory could not be "read". Click on OK to terminate the program"
So which one do you recommend we get? The Doze core version or the MAME?
The Doze core was used in previous versions of Dega and is included for compatibility with existing movies (about half of the movies here sync using this core, including nineko's Chuck Rock movie).
The MAME core is more accurate (e.g. Sonic Drift games now run) and so should be used for new movies.
Hello,
I finally got round to making a prerelease of the next version of Dega, 1.16.
+ Movie file format altered to record whether this is a Game Gear game
+ Now uses ROM file header rather than file extension to determine
game type
+ Added optional new portable Z80 core from Final Burn Alpha (originally MAME)
+ Fixed a number of emulation bugs affecting a variety of games
+ Fixed flickering issue with SDL version affecting games which change the
palette during the frame
+ degavi ported to Windows using VfW
+ Windows: act more friendly to the CPU by not busy looping
Get it from the website: http://www.pcc.me.uk/~peter/dega/
Please let me know about your experiences recording movies with the new core. Obviously you will likely experience desyncs playing a movie recorded using another core. I am also interested in hearing about your experiences with the Windows version of degavi. As I do not currently have access to a Windows machine I was unable to test it fully. There is a known bug with the Windows degavi in that there is a gradual A/V desync during the movie. If there are any VfW experts around I'd like to hear how to solve this problem (patches please, if you can).
I finally had some time to work on dega again... I made a new release fixing a few emulation bugs: a minor one affecting the vertically scrolling stages in Rygar, and a more significant bug that corrupted enemy sprites in Golden Axe Warrior.
Alden's version of the memory viewer including saving/loading of the memory watch list is also included in this release.
Get it from the website: http://www.peter.uk.to/~peter/dega/
Uh, the contents of the screen should already be stored, in the form of the VDP's pattern RAM, palette RAM, registers, and nametable. All you should have to do is call the function which actually turns the VRAM data into a rendered screen. Or possibly copy the relevant stuff from wherever it normally happens during a frame being called, into a new function that only does the rendering, without changing anything's emulation state.
That won't work. The game might be changing VRAM while the screen is being drawn (see http://www.smspower.org/meka/gallery/meka072-sagaia.png for an illustration of X-scroll value being changed in this way), and storing an entire copy of VRAM for each scanline would be wasteful.
hazeus wrote:
FYI recordings of Ys (Vanished Omens) de-sync after a few minutes. It's the only game to do so and I've tried maybe 10 times and all 10 efforts de-synced.
Thanks, I got your PM about that. It's on the todo list.
Requests:
- Default to "read-only" when replaying a movie.
- Show the frame count even when a movie is not running.
It would be convenient to be able to select individual hotkeys for each state being saved and loaded, rather than having a generic save and load button, with individual state selection buttons.
Example setup for this would be to use 1 to load state 1, Shift+1 to save state 1, 2 and shift+2 to load and save state 2, etc.
Added to my (ever-increasing) todo list.
- When in frame step mode, update the screen when the user loads a savestate and not one frame later.
This is harder than it sounds, as it essentially means that I would have to store the contents of the screen in the savestate. But I'll see what I can do.
I have a question regarding this file format, as I'm going to add support for it to QuickHex. I haven't been able to find a better explanation of the format than this post.
In all MMV movies that I downloaded, the frame data starts at location 00F4. Also, location 0018 holds the value F4.
Does location 0018 represent the controller offset? And is the offset ever anything but F4?
Yes, 0018 is the input data offset and currently will always contain F4. But this may change in the future. There is also 0014 for the offset of state information (for movies which start at a state) and 001C for the size of the input packet. The reason for the presence of these fields is to support future extensibility in the file format.
Note that the file format you have quoted is outdated and more up to date documentation is found in the source code. See the comments in the MvidStart function in mast/video.cpp
The Linux UI is pretty rough but it looks like most people interested in TASing SMS movies are using Windows... one serious problem (that exists in other emulators as well) is that while in fullscreen mode, hitting keys to bring up the console causes a lock-up since the focus is fixed on the SMS window.
I committed an experimental fix to the repository... experimental as I cannot test it (my video drivers are buggy and seem to crash when entering fullscreen). If you are in full screen mode the emulator should revert to windowed mode to prompt for input.
If I ever have time I hope to develop a cross-platform UI using wxWidgets or similar.
ermacone wrote:
I assume the display of the emulator is blank because your recording program cannot capture overlays? Looks like the exact steps you are taking are:
pause
play
unpause
stop
pause
unpause
play - crash
I tried to reproduce those steps but couldn't get a crash. Did you do anything else before the movie? (apart from loading the rom)
Managed to fix the overlay bug. It looks like Vista's compositor conflicts with overlay, so compositing is now disabled while the emulator is open. Whether this is a good thing or not is your opinion :) Latest version available from the website: http://www.doc.ic.ac.uk/~pcc03/dega/
Just curious, the download page mentions 1.14 has memory viewer, but I didn't see that in any of the menus... is there something I'm missing?
Awesome work pcc by the way ;)
You need Python 2.4 installed, you can get it from here. Then the Python menu will be enabled and you will be able to use the viewer.
The revert-to-1x bug was rather intermittent. I made some changes which I think have fixed it, but I'm not sure. There's now also a menu option which lets you toggle whether the menubar auto-hides when you load a ROM.
I have released version 1.14 with these changes. Get it from the website at http://www.doc.ic.ac.uk/~pcc03/dega/
pcc, if it's not too much trouble, do you think you could add AVI dumping for the windows version? Whenever you have time, it would be much appreciated.
Whereas AVI dumping is relatively simple on *nix, AVI creation on Windows seems to be an overengineered mess. However you can use software like fraps to create rough test AVI files. If anyone can help with the windows side of things they are free to send in patches.
Since no bugs have been reported to me (apart from frenom's crash bug which I can't reproduce myself) I'm going to go ahead and make the release soon. If anyone spots any more bugs please let me know.
Sure, no problem.
You load a rom(lets say Psycho Fox) and then playback a movie. Now.. go to playback again and try to open the same movie or another movie. I know I cant ;)
I get to the load movie window and then it dies.
Sorry, still can't reproduce, even with the same ROM and movie. What OS are you running? Can anyone else reproduce the crash?
I have another WIP ready. This is the 1st release candidate. I reworked the Python interface to allow scripts to run in a separate thread, so sound works while the memory viewer is open and you can perform all actions from the normal user interface. There are now two modes for running Python scripts: control (for writing bots, replaces the normal behaviour of the emulator) and viewer (for scripts that provide user interface, runs in separate thread). Also added fixed size scaling options (1x...4x) instead of the standard 3/4 of the screen.
What are people using for key assignments? I'd like to know so I can provide sensible defaults for the keys that I haven't assigned a mapping for. These will go into the final version (1.14).
Also has anyone played with the python interface so far?
As always please let me know of any bugs.
Source code: http://www.doc.ic.ac.uk/~pcc03/dega/wip/dega-1.14-wip20070723.tar.gz
Win32 binary: http://www.doc.ic.ac.uk/~pcc03/dega/wip/dega-1.14-wip20070723-win32.zip
I have another WIP ready. It adds state saving/loading and movie record/playback capabilities to the Python interface, and adds hotkeys and ini-file entries for the OSD options, but perhaps more urgently, fixes a potential desync bug.
To use the state capabilities, the "magic" variable dega.state is exposed. Its value is the current state of the program expressed as a string (the string has the same format as dega's save state format). You can read from this variable to 'save' state, and write to it to 'load' state. You can also write this string to a file to produce a state file in the same form as dega's (under Windows, state files are gzipped, so you will need to use the Python gzip module when saving/loading states to/from files).
Movie capabilities are exposed via the dega.movie_start(movie, mode, reset) and dega.movie_stop() functions. For movie_start, movie is the movie filename, mode should be one of PLAYBACK_MODE or RECORD_MODE, and reset should be a boolean indicating whether to start recording from reset.
I found the desync bug while playing with the state and movie functionality in python. It can potentially write corrupted data to the movie file in some cases, thus causing a desync.
Source code: http://www.doc.ic.ac.uk/~pcc03/dega/wip/dega-1.14-wip20070718.tar.gz
Win32 binary: http://www.doc.ic.ac.uk/~pcc03/dega/wip/dega-1.14-wip20070718-win32.zip
I now have the newest WIP ready.
I thought the feature described here was rather cute, so the main new feature here is a Python scripting interface. Currently you can frame advance and inspect/change RAM using the interface, but I also plan to add state loading/saving and movie record/playback capabilities.
The Python interface can either be used in standalone mode where the emulator is loaded as a Python module, or in embedded mode where scripts are loaded from within the emulator and have access to the current emulator state.
For the interface to work you will need Python 2.4 installed, else the Python menu option will be unavailable.
Example of how to use the interface:
from pydega import *
XPOS = 100 # we want to get to this X position
dega.input[0] = BTN_RIGHT # joypad right
while dega.ram[1234] < XPOS: # read ram address 1234 (note: dega.ram[0] corresponds to $C000)
dega.frame_advance()
dega.input[0] = 0 # joypad neutral
As an example Python script I have included a memory watcher/trainer tool. The user interface is a bit rough at the moment and includes the following caveats:
- you cannot perform most emulator actions while a script is running c.f. the memory watcher/trainer is open, instead you can use the buttons provided on the tool itself. You can however use the keyboard to control the game (make sure the dega window has focus) while the trainer is in "Run" mode
- no sound while the trainer is open
- game might run slowly while trainer is open because frameskip is disabled
Most of these stem from the fact that the script 'drives' the emulator while it is running. I'm thinking about ways around this problem.
Source code: http://www.doc.ic.ac.uk/~pcc03/dega/wip/dega-1.14-wip20070717.tar.gz
Win32 binary: http://www.doc.ic.ac.uk/~pcc03/dega/wip/dega-1.14-wip20070717-win32.zip
It looks like that particular movie has had its first 4 bytes corrupted (this doesn't seem to have happened to any other movies people have posted, so I don't know what is going on there). The problem occurred because the new version is more strict about the file format. If you hexedit 'MMV\0' onto the first 4 bytes of the file it should still play.
moozooh, most of your usability comments make sense. I'd like any more comments from anyone else regarding usability.
moozooh wrote:
Speedup/slowdown should change the speed in fixed increments instead, be it percent scale (10%, 25%, 33%, 50%, 66%, 75%, 100%, 150%, 200%, 300%, 400%, etc.), or fps scale (5, 10, 20, 30, 40, 50, 60, 90, 120, 180, 240, etc.), or any other you can come up with
What do you mean by this? Currently the scale is ..., 25%, 50%, 100%, 200%, 400%, ... i.e. powers of 2. Do you mean there should be more choices? I don't particularly see the value of letting the user fine tune this.
Does this work with vista? It worked on my xp computer fine, but when i load rom, the music plays but the video is still blank.
On my computer with Windows XP, if I use Switch User, then when I log back in, Dega is blank until I load another ROM. Probably not related, but whatever.
the bar shows but the lists won't : impossible to select any option, it's ultra super slow.
Can you see if changing the "overlay" option or making the window smaller helps? Failing that, can you check if the problem occurs with the original dega 1.12 so I can see if it's something I've done? I admittedly don't have a great deal of access to windows and do most Windows testing using wine or a slow rdesktop session (I don't have any access to vista at all) so I don't know if I can help with those bugs.
Thanks for that. It looks like that game detects the region in a different way which wasn't supported by dega. Since meka supports it it was trivial to find the appropriate code and port the fix to dega. I wish fixing all emulation bugs would be this easy :). Website updated with new version.
I've released Dega 1.13 final. I fixed some minor bugs and added PAL/NTSC and Japan/world flags to the movie file. The new version should be backward compatible with old movie files but if your movie file is recorded in PAL or Japanese mode you should convert it with the included mmvconv utility. Full details in the dega.txt file. I tested the utility with all the runs that people have posted in this forum but do make a backup before converting your file.
I now have a web site for this project. You can get the latest version here: http://www.doc.ic.ac.uk/~pcc03/dega/
As always do let me know of any bugs.
