Main > Software Forum
MAME Movie Maker released
<< < (45/153) > >>
Buddabing:

--- Quote from: Howard_Casto on January 26, 2005, 12:58:08 am ---I wanted to point out that on further use I've ran into similar issues.  Nearly any game with a complex intro fails loop detection, or detects the loop improperly.  Most fighters fail as they have complex intros and several transitions (attract mode, demo mode, highscore mode ect). 

Is it my understanding that you are doing a simple getpixel point check then?  Imho this isn't gonna work well at all.  Disable compression (as others have suggested) and do crc checks of the spit out image files.  Only when the frame is exactly, exactly, exactly the same will the crc check pass. You'll have to do a get pixel test on top of that to get the color level (make sure it isn't matching on an all black or all white screen).  Of course, depending upon how accurate the render method is, that may cause even worse performance, I dunno. 

--- End quote ---

I thought the compression was lossless. Lossy compression could indeed cause imprecise loop detection, espcially on larger images such as propcycl.

The current loop detection does a md5 checksum over the entire file. As a test, I modified it to do the checksum over only the image data. Same results.

Instead of the sampling method, I'll look into creating lossless frames instead. Performance may not be very good. :)

Silver:
PNG files use completely lossless compression - I believe it is part of the PNG spec.

The only way these files are different would be if the rendering process of the games in mame produces non-repeatable images, which I find extremely unlikely. (Or they really are different).

If there is an obvious loop that is not detected, then I would simply recommend comparing two pngs from appropriate spots. There may be something unusual like a pixel or line of 'garbage' rendered to the screen which prevents identical comparisons.

Note if any of the games mentioned change their resolution during the attract loop, it will not work (each time the resolution changes, the loop detection restarts and previous frames are wiped.) I know cool borders (cbaj) does this as the logo is a different screen resolution to the rest - although it does find a loop later on in the attract which looks nice. A single resolution change in bootup is fine as its not part of a loop.
A simple way to test for a resolution change is to not delete all the snaps, the open the first one in Vdub manually and it will tell you if it finds pngs in the sequence with a different resolution. (note buddabings more recent patches get rid of most of these errors)

The fact that this process works for so many games suggests the difference is with the specific games.

On a side note, I would also argue that a lossy compression for SINGLE images would most probably produce an IDENTICAL file given EXACTLY the same input images - I know this is true for jpgs. So it would actually still work..... It would only fall over if the lossy compression was designed for mulitple frames (video codecs) and used info from frames before and after as well. Howver, this is probably beside the point.
rerstad:
I think I'm having some problems with moviesnp and the precompiled version of .90.  I get an initial error that it can't find c:\mame\moviesnp\****.png, then, even those it completed said that it could not find the moviesnp file to delete.  When I went into the moviesnp file, it was huge--apparently nothing was being deleted, which I assume it should be. If I have to stop (like when it took more than an hour and was still running anteater), I get an error that vdub can't find the ****.png frame.  May be the same problem Popcorrin discussed.
Buddabing:

--- Quote from: rerstad on January 26, 2005, 10:37:18 am ---I think I'm having some problems with moviesnp and the precompiled version of .90.
--- End quote ---
sWampy:
I'm trying to compile 90 with this, and keep getting the following error.

Compiling src/common.c...
src/common.c: In function `save_movie_snapshot':
src/common.c:2016: `FILETYPE_MOVIESHOT' undeclared (first use in this function)
src/common.c:2016: (Each undeclared identifier is reported only once
src/common.c:2016: for each function it appears in.)
src/common.c: In function `detect_png_resolution_change':
src/common.c:2169: `FILETYPE_MOVIESHOT' undeclared (first use in this function)
src/common.c: In function `detect_loop':
src/common.c:2231: `FILETYPE_MOVIESHOT' undeclared (first use in this function)
src/common.c: In function `generate_vdb_file':
src/common.c:2308: `FILETYPE_MOVIESHOT' undeclared (first use in this function)
make: *** [obj/mame/common.o] Error 1

I unzipped clean .90 source, made it, it compiled fine, unzipped mame90 on top, typed make, and got  this error.
Navigation
Message Index
Next page
Previous page

Go to full version