Main > Software Forum

MAME Movie Maker released

<< < (16/153) > >>

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