The state of a PCB is generally the same on every initial power up; the random number generator is seeded with something to start with, but it's probably initially a fixed number.
There's a whole bunch of ways to make things seem more random; you can reseed the RNG at every credit with say, the number of milliseconds since the PCB has booted. That alone provides enough of an illusion of randomness.
Note I said 'illusion'; the entire system is 100% deterministic. Inputs A,B,C lead to output/condition Z every time (barring weird processor bugs or something)
Mame input files are recorded from the emulation equivalent of a PCB cold-boot. Which means the initial state is always the same (with some potential exceptions) and therefore the inputs should lead to the same output consistently.
RNGmaster wrote:
emphatic wrote:
If your playback file isn't working, then either your nvram file is corrupt or you are using a different MAME build to play it back. There is no such thing as "random patterns" with MAME and inputs. Only human error when playing it back.
I didn't know how MAME computed "random" patterns. So, if I'm following, that means that if I do EXACTLY the same thing every time I play, then the game will use the exact same patterns, even with ones that seem to be randomly chosen.
Seahawk wrote:If possible I recommend dumping the video to a secondary hard drive, it will speed things up greatly. Also, make sure frameskip is ZERO (0) otherwise you will get very choppy video. This takes longer but it's worth it.
False. You'll get choppy immediate output but the video written on the HDD will be perfect whether it's running slow or fast.
When you're done, use ffmpeg to save yourself some stupid GUI navigation time. You can adjust the parameters if you feel the need to (for example, to raise the video bit rate) but this is a good setting for the Cave PGM games:
As for (possible) playback problems, just delete your nvram file before recording and delete it again before playback. This is necessary depending on your build -- ideally, it would only record the section around 0x801000 (for Ketsui) but the actual PCB has everything in NVRAM.
<RegalSin> It does not matter, which programming language you use, you will be up your neck in math.
Does anyone off-hand happen to know if you can actually dump to AVI with MAME32k? The "playback" command doesn't seem to work with it via console, and I've been trying to record something using a screen capture with Hypercam2 instead, but I keep running into issues. If I run it windowed, 32k removes 4 pixels from each border due to some emulation issue, and if I try to record it fullscreen I get black frames inserted with triple buffering on, and hiccups with triple buffering off.
EDIT: Looks like I managed to get rid of the hiccups by capturing to raw uncompressed. Still wanna know if MAME32k can dump to AVI though.
Of course, that's just an opinion. Always seeking netplay fans to play emulated arcade games with.
I just recorded my gameplay of Battle Bakraid in MAMEUI and all seemed to be fine, but when I watch the inp stage 6 in the video is somehow effed up and is not how I played it. Anyone had similar problems?
"I will not die until I achieve something.
Even though the ideal is high, I never give in.
Therefore, I never die with regrets." 1CC
RNGmaster wrote:I didn't know how MAME computed "random" patterns.
MAME isn't computing them. The game is computing them. MAME is just shuttling input variables from point A to point B. In principle, if you could synchronize it properly you could play your .inp file recorded in MAME into a gadget that attaches to the PCB and get the same behavior. There are enough minor inaccuracies in MAME that many games would end up desynced somewhere, but this has actually been done with a Super Mario Bros. speedrun (granted, SMB has essentially zero pseudorandom behavior, but the basic idea is the same).
Fraps and DirectDraw being mentioned - I haven't tested this out, but DDraw blur with Fraps would be, I assume, the result of forgetting to turn off the bilinear filtering option.
emphatic wrote:I did a Ketsui recording using these steps:
1.Run MAME with record option in my cabinet pc -> inp file (500kb)
2.Run MAME on my laptop with inp playback + avi write -> .avi file (14GB)
3. Use VirtualDub to resize the raw output (5:4 ratio) to 3:4 @ 480p -> .avi file (25GB)
4. Encode to .mp4 using Handbrake -> .mp4 file (400mb)
5. Uploaded to YouTube: http://www.youtube.com/watch?v=T6tbnLFcMIw
Why you use Handbrake to encode avi file instead VirtualDub?
But one question: