That wasn't my intention, but maybe I ended up doing that.
All I planned to do was add rerecording features to advancemame and fix savestate support for the few games I actually play. I just posted here in case it might be useful to anyone. I never intended to do a Mame32 port, or to fix the multitude of mame games which don't have savestate support. I do plan to fix any bugs/problems if people tell me about them.
As far as I know, everything works correctly. I've only gotten one PM, someone had a problem compiling it under windows, and I couldn't help. I apparently don't get emails when people reply to the topic either, so I thought nobody was posting or found this useful.
To partially answer your question about configuring, load state is hard-coded to F7, and save-state to shift-f7 (not my doing).
Type "advmame --default" to generate a defaullt rc file, then edit away. I list all the configuration options I've added in the main readme file included with the patch, and on my site.
To set the player 1 button 1 to "a" for example, use the line
input_map[p1_button1] keyboard[0,a]
and for frame advance,
input_map[ui_singlestep] keyboard[0,a]
feel free to PM me
that's awesome your soo deticated and all, but what about a patch for Mame32 ?? 90% of all playing Arcade roms uses Mame32.
That may be, but I don't have convenient access to a Windows machine so I can work on Windows-only programs. Advancemame is cross-platform, the closest I could come. Sorry.
Yeah, new stuff is happening, I'll give a summary here.
I put up a webpage so I don't keep bumping the topic every 5 minutes with minor changes.
I'm pretty sure I have the rerecording part all worked out. The only reason games desync should be that savestates aren't properly implemented. (Savestates are a relatively new thing, there was a long debate about whether to include them in MAME, so most games don't have proper support yet)
As far as I can tell, I have NeoGeo savestates fixed. Gradius desyncs occasionally on me, and I fixed savestates for Karnov, the grandest arcade game of all time!
Now for the patch thing, I'll put the patched source on my website in a few minutes, but I'd like to figure out if I'm generating patches wrong or something. Are you getting the source through CVS, shakespeare?
That sounds neat, I'm trying to watch it.
Unfortunately, Finalburn alpha crashes a lot under wine (I don't have windows), and says it can't play back that file. Do you know offhand which version can play it?
Hi everyone, I've recently been playing around with the Metal Slug series, and was wondering if you guys would like to see a TAS speedrun of one of them.
I made a recording of the first mission of Metal Slug 1 on the hardest difficulty, so you could get an idea what the finished product might look like. In this recording, I rescue every hostage and kill/destroy everything I can without slowing the forward progress more than a second. It could be ~10 seconds faster by ignoring score.
So, I'm curious if you consider this entertaining, and if another idea might be more entertaining (such as a pure speedrun/ignoring score and hostages).
To play, you need a recent version of MAME. mame32, xmame, etc should all work. I used a hacked advancemame 0.104.0
a long url/mslug-example.7z (2 KB)
To playback:
Unzip it and move the recording (mslug-example.inp) to MAME's inp/ directory, and delete the mslug files (if any) in mameversion/memcard/ and mameversion/nvram/ in case it desyncs. These are the only things that aren't reset at power on.
Most mames will then play it back with "mame -playback mslug-example"
Well, I unpackaged the source and looked at it a while. It uses the unmodified MAME source for emulation (yay).
But after reading through half of win32ui.c, i've come to the conclusion:
- The code is sufficiently complex that I can't design a change to the UI without being able to compile/run what I make.
- It's been 4-6 years since I wrote native win32 ui code. I'm not sure what's the best way to integrate the time management features just from looking at it.
If someone else can do the UI, I can supply code that supports the re-recording part, or explain how I came up with it. I plan to clean up and document my patch this weekend.
If you're in a hurry to do TAS work with some MAME, advancemame should run under Windows and provide what you need to get started. Plus, the recordings it produces should run perfectly under Mame32 when you finish.
Yes, that patch only works for that specific version of advmame.
I'm not familiar with mame32, but I think all mames share most of their emulation code. I think the differences would be
how mame32 handles speedup/slowdown/frame advance and how to bind them to keys.
Plus, compiling it would be interesting... I don't have a working installation of Windows right now :S
I went over to the mame32 website, and I find it curious that the source code distribution is only shipped as an .exe installer o.O
(fwiw, advancemame is supposed to build on Windows)
I'll try to take a look at it tonight or tomorrow, no promises on making it till I check it out though.
Here's a little test we could do, I made a recording of the first mission of Metal Slug while I was building this. It should beat the first mission with a score of 48700 without getting hit. You might need to backup/delete the metal slug memory card and nvram files.
http://krispnet.ath.cx:800/krispy/files/mslug-m1.7z
Does it work or not/what version of mame32?
Yes, it is nasty :(
EDIT: rewrote the post
I feel stupid, I was in too much of a hurry to get something out everyone could play with.
I took the time to read through most of the MAME emulation code, and more importantly, to properly test what I wrote. Now I'm fairly sure this will work without desync on any MAME platform that supports savestates, and generates recordings that similar versions of MAME can play.
I just hope I didn't upload the wrong file, now :X
http://krispnet.ath.cx:800/krispy/files/advancemame-0.104.0-rerecording-patch3.7z (22KB)
In case anyone's using my patch, I should warn you of a bug I just found.
Advancemame records keystrokes every vsync, but it records states anytime. It's possible for the game and recording to desynch by 1 frame when you load state.
Workarounds: reset and use -playback every so often, or
hold the exact same buttons when you load state as when you save state.
I'll try to fix this tomorrow.
EDIT:
Since a bunch of people are downloading the first version of the patch, which doesn't work as well, I think I'll make a webpage for this patch which explains my progress, any bugs, and how I'm coming along with them.
http://krispnet.ath.cx:800/krispy/advancemame-rerecording/
Then I won't have to flood the forum or bump the topic every time I make a small improvement.
My original post to this topic:
chucky wrote:
if not can sombody add a re-recording support in a Mame32 emulator..?
This is an interesting coincidence, I felt like trying to make a video of the arcade version of gradius3 to see how it compared to the SNES version. I made a patch to AdvanceMAME to support re-recording and savestates.
Here's a patch against advancemame-0.104.0, tested on Linux. (I'm hosting it on my own computer, so I might take it down because of bandwidth.)
The archive contains 3 things: a readme, the patch, and a sample .inp for grdius3e which _should_ play through the entire game without desynching, on any mame. It's not perfect, but there are enough near deaths to detect desynchs.
http://krispnet.ath.cx:800/krispy/files/advancemame-0.104.0-rerecording-patch.7z (81 KB)
It's got speedup, slowdown, frame advance, and each savestate now records the entire input history. Read the readme, I have too much to say.
4matsy wrote:
The main problem with this, I think, is that the savestates themselves are unstable for some games.
(Like the Gradius series...last time I tried to load a savestate, the graphics scrambled and the game froze. o_O)
The only problem I had with gradius3 was the screen would be malformed after loading a state. The game still played correctly, if you could imagine where the solid things would be :)
I added a few lines of code to fix the screen, and everything seems to work. gradius3 is the only game I tested (and I used re-recording to make that .inp)
4matsy wrote:
So, since rerecording is kinda impossible without savestates, the savestate system will need to be fixed first.
And since just about every arcade game's architecture is different, the amounts and types of data the savestate will need to store will change across games.
I get the feeling it'll be a while before someone manages to fix MAME's savestates...<_<
Fortunately, for gradius3 at least, MAME saves all the data needed to reconstruct the machine state. It just uses a little trick to save render time, which causes the graphics glitch upon loading a state.