Update to bsnes v028r06? release.

New WIP.

 Richard Bannister asked me a year ago to add support to detect the
file compression type by reading the header, as apparently Mac users
can't be bothered to use proper file extensions.

               In an act of extreme expediency, I've added his request
in record time :P

               Here's the detection code I wrote:







    Reader::Type Reader::detect(const char *fn) {
                       FILE *fp = fopen(fn, "rb");
                       if(!fp) return Unknown;

                       fseek(fp, 0, SEEK_END);
                       unsigned size = ftell(fp);
                       rewind(fp);

                       uint8_t a = size >= 1 ? fgetc(fp) : 0;
                       uint8_t b = size >= 2 ? fgetc(fp) : 0;
                       uint8_t c = size >= 3 ? fgetc(fp) : 0;
                       uint8_t d = size >= 4 ? fgetc(fp) : 0;
                       fclose(fp);

                       if(a == 0x1f && b == 0x8b && c == 0x08 && d <=
    0x1f) return GZIP;
                       if(a == 0x50 && b == 0x4b && c == 0x03 && d ==
    0x04) return ZIP;
                       if(a == 0x4a && b == 0x4d && c == 0x41 && d ==
    0x00) return JMA;
                       return Normal;
                       }




 If anyone sees any problems, please let me know. And unless your name
is Nach, I expect you to read and cite official documentation to point
out any problems.

 Note: I need more than 16-bit accuracy to avoid false positives, so I
read the compression type and flags for GZIP. Compression type should
always be 0x08 according to my understanding of GZ. Flag top 3 bits
are always 0 per spec. I guessed with JMA's fourth byte. I hope it's
always zero, but I don't know that for certain.

 The new WIP has GZ/ZIP/JMA support built-in, so testing would be
appreciated, though I doubt you'll hit any false positives.

               Now, a more important question. Should I enable this
detection by default in bsnes, or go by filename? It's _possible_ an
SNES ROM could have these headers, despite not being compressed at
all. One could even add these signatures intentionally if they really
wanted. A real SNES game could have these bytes at the top of the
file, quite obviously.

So, is it better to cater to people who misname extensions, or to the
possibility that a game might have these bytes in the signature (a one
in four billion chance of happening accidentally. One in 500 million
for GZ false detection.)

               ---

 Also, I added some changes by KarLKoX to allow OpenAL to build on
Windows. Namely, I removed the unused ALut dependency, and added
support to the makefile to include openal32. I don't intend to build
OpenAL into the default Windows binaries (because I don't want extra
DLL dependencies that most people do not have; and because OpenAL
support sucks on Windows for non-Creative cards), but perhaps in the
future I'll offer more than one version for download.







> The "almost black" color below the door is 8/16/24 in bsnes
> (standard preset) and 0/16/16 in SNES9x. It's best to see on a black
> background.

>                    EDIT: This might be due to the RGB565 format.




 Wow, that's quite a difference. If you have bsnes v013-v019, you can
dump the palette through the memory viewer. Perhaps see what SNES9x
has from its savestate, and if it's different -- one of us has an
emulation bug.

               Not an RGB565 problem, or the colors would match when
ignoring the low three bits (two for green.)

               bsnes:
               00001000
               00010000
               00011000

               SNES9x:
               00000000
               00010000
               00010000

[No archive available]
This commit is contained in:
byuu
2008-02-17 16:49:00 +00:00
parent 4cbba77fc7
commit e651beb72e
Update to bsnes v028r06? release.

Diff Content Not Available
