pcc, i would just like to say thank you for making an emulator with re-record for ms. i had always thought ms games were all like the sonic ones, slow clunky and full of lag. thanks to you my eyes have been opened to some of the most fun games i have seen tas'd as well as how great the ms truly is. thank you, kind sir! *hug*
Requests:
- Default to "read-only" when replaying a movie.
- Show the frame count even when a movie is not running.
- When in frame step mode, update the screen when the user loads a savestate and not one frame later.
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.
(Unless this is already available and I've missed it somehow.)
<Swordless> Go hug a tree, you vegetarian (I bet you really are one)
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?
<Swordless> Go hug a tree, you vegetarian (I bet you really are one)
Added to my (ever-increasing) todo list.
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.
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
>... essentially means that I would have to store the contents of the screen in the savestate.
If it helps any, I think this is how the other emulators do it as well.
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.
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.
How fleeting are all human passions compared with the massive continuity of ducks.
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.
I know little about emulation, but I have got an idea:
- When you make a savestate, the emulator saves the previous frame and any input at that frame instead of the current frame as recording a 1-frame-only movie.
- When you load the savestate, the emulator restores the saved frame and then advances one frame with the saved input as playing a 1-frame-only movie in Read-Only Mode.
I don't know if this is feasible.
EDIT: I mean that every savestate done this way is actually a 1-frame-only movie....
BTW: I have got a problem that Dega v1.14 for Win32 doesn't work under Windows 98 Second Edition....
<klmz> it reminds me of that people used to keep quoting adelikat's IRC statements in the old good days
<adelikat> no doubt
<adelikat> klmz, they still do
Then the emulator will record it.
EDIT: I misunderstood what you said.
<klmz> it reminds me of that people used to keep quoting adelikat's IRC statements in the old good days
<adelikat> no doubt
<adelikat> klmz, they still do
Joined: 11/18/2006
Posts: 2426
Location: Back where I belong
Don't know if this has been addressed yet, but in 1.14 there's an option under "Key Mappings" for 'Save slot' 0-9, but no option for 'Load slot' 0-9. Is there something I'm missing, or do I have to try to get used to the quicksave system?
EDIT: Don't mind me, I don't know how to use the quicksave/load system well. I got it figure out now.
The labels are a little confusing ... "Save slot" in this case means "selects a slot where you can put a save", rather than "save to save slot". For both saving and loading, you choose the slot first, then push another hotkey to actually save or load to the slot. It bothered me at first, but I kind of like it now.
For those of us who are too lame to use MHS, a while back I added save/load capabilities to dega's built in python memory watch function.
http://aldentas.googlepages.com/memory-alden.py
Put that in the dega folder and rename to just memory.py (and delete/rename the old one)
Oh, and to use this or the old one, you must install Python 2.4 (not 2.5) http://www.python.org/download/releases/2.4/
Joined: 5/1/2004
Posts: 4096
Location: Rio, Brazil
This page needs some organization... And it should be moved to other emulators forum or create a Master System one under emulators. Also, there's no info about DEGA on the emulator resources page in tasvideos.org
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/
Guys I come from the DidyKnogRacist communite, and you are all wrong, tihs is the run of the mileniun and everyone who says otherwise dosnt know any bater! I found this run vary ease to masturbate too!!!! Don't fuck with me, I know this game so that mean I'm always right!StupedfackincommunityTASVideoz!!!!!!
Arc wrote:
I enjoyed this movie in which hands firmly gripping a shaft lead to balls deep in multiple holes.
natt wrote:
I don't want to get involved in this discussion, but as a point of fact C# is literally the first goddamn thing on that fucking page you linked did you even fucking read it
Cooljay wrote:
Mayor Haggar and Cody are such nice people for the community. Metro City's hospitals reached an all time new record of incoming patients due to their great efforts :P
The Windows build supports zipped ROMs, however I couldn't get zipped or gzipped ROMs to run so far. Is there some trick I'm missing or is it just simply not supported?
since there in no AVI dump in the windows version, is there any screen recorder that can record dega? i've tried some screen recorders but i just get a black screen. they can record from all other emulators and movies and everything, except dega. i remember i could record it with windows XP. vista doesn't even let me change the hardware acceleration, which possibly could let me record it. any suggestions would help.
There's a binary called degavi for Linux that lets you capture the game. Maybe it's even compilable for MinGW, but I have no idea about that.
nfq, Vista always made problems for me when I had Aero activated (i.e. transparent title bars). As soon as I deactivated it, it worked fine.