forums.marpirc.net

analog games saved a lot of data anyway didn't they? now they probably save twice as much as input ports can be 32 bit.

maybe the drive can't keep up? (would be weird, its not writing *that* much data) i'm really not sure, i don't use wolfmame (its not much use to me as a developer) but i don't see any dramatic slowdown here.

as for solutions i'm afraid i don't have any... if somebody works out how to record directly to a compressed file it may help, but the compression would require additional cpu time anyway.

This happens in regular MAME 0.85u2 too. Before the input port core change, analogue games added about 4 or so bytes per frame, as the game requests them. Many games don't request the ports every frame, and this is why when an analogue INP goes 'out of sync' the game often freaks out.

Here's a comparison of inps, recorded in MAME 0.85u2:

21/08/2004 11:35 p.m. 250,488 bldyror2.inp
21/08/2004 11:47 p.m. 2,005,764 omegrace.inp
21/08/2004 11:30 p.m. 6,174,876 ssprint.inp

bldyror2.inp - run until the intro freezes (always in the same place) - about 1300 frames, 60fps, not analogue
omegrace.inp - run through a loop or two, about 1100 or so frames, can't remember that well, 30fps, analogue
ssprint.inp - run until the first car finishes a lap in the demo mode, just under 1100 frames, 60fps, analogue

Yeah, something very wrong with 85 and inp size...

tested little more, comparing wolf82 and wolf 85:

Tron inps seem to be about 3 times bigger at 85
...Even this causes some annoying disk access and propably occasional slowdowns. I can hear harddisk all the time.

Starwars about 7 times bigger, not even doing anything when recording.

720...well, must be about 100-1000 times bigger inps...There is something seriously wrong.

Not only at analog games.

They should be at least double the usual size, that much is intentional - port sizes went from 16-bit to 32-bit.