Main > Software Forum
MAME Movie Maker released
sWampy:
history.dat and mameinfo.dat cause it, the others don't.
Silver:
--- Quote from: BuZz880 on January 06, 2005, 01:11:48 pm ---term2, possibly revx as well but I need to fix the zip.
shufshot
capbowl
wcbowl
simpbowl
slither
cryptklr and carnevil too; I think ther error was not the -100 but it was related to different resoultions being used.
--- End quote ---
Sorry - my post earlier I meant to say that the (-100) error is probably the weird resolution error - not changing resolution!
There is already a fix for this for another resolution. Exactly the same code should work here - so Buddabing just needs to add the resolution of these games to the list to be checked for...
We already know and check for
Silver:
--- Quote from: Buddabing on January 06, 2005, 02:03:08 pm ---It is trivial (and cheap, time-wise) to detect a change in the dimensions of the png snapshots. What do you want to happen if the resolution changes during png generation?
--- End quote ---
Well I'm 99% sure that these changes will only occur during boot, so we could simply only load the pngs after the resolution change in Vdub. (I think its eg. Addrange 50, lastframe - but I will check) But then we will have to add a fudge factor for the audio, trying to look at the easiest way of doing this.....
Buddabing:
--- Quote from: Silver on January 06, 2005, 05:04:48 pm ---
--- Quote from: Buddabing on January 06, 2005, 02:03:08 pm ---It is trivial (and cheap, time-wise) to detect a change in the dimensions of the png snapshots. What do you want to happen if the resolution changes during png generation?
--- End quote ---
Well I'm 99% sure that these changes will only occur during boot, so we could simply only load the pngs after the resolution change in Vdub. (I think its eg. Addrange 50, lastframe - but I will check) But then we will have to add a fudge factor for the audio, trying to look at the easiest way of doing this.....
--- End quote ---
I was thinking that if a change is detected, the program could copy the current png and overwrite all the previous pngs. That way, no audio fudge factor would be required.
Silver:
--- Quote from: Buddabing on January 06, 2005, 05:15:39 pm ---I was thinking that if a change is detected, the program could copy the current png and overwrite all the previous pngs. That way, no audio fudge factor would be required.
--- End quote ---
That would be perfect.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version