Hi everybody,
I made some binaries and turns out Neil Roy's Deluxe Pacman 2 game no longer correctly loads ttf files from within a .zip physfs file archive. See thread here. Also, in my distribution, ex_physfs fails to work and quits silently, as it doesn't load 02.bmp from the zip file correctly, even though the zip file is present.
My question, do the other builds of allegro suffer this same difficulty? I built Allegro 5.2.3 from GIT shortly after 5.2.2 was released, so if anyone else using 5.2.2 has this same problem or if it works for them, please let me know.
I built Allegro 5.2.3 from GIT with PhysFS 2.0.3, FreeType2.7.1, LibPNG1.6.28, and ZLib 1.2.11.
Does ex_physfs work for you in your build of allegro? Please tell me if it does.
Thanks, Edgar
It was working here, then I updated all of the dependencies (FreeType, libpng, and zlib) and it no longer works. I modified the example program and saw that it is seeing the structure of the ZIP file, it just can't load the bitmap.
Append: I modified the example to open 02.bmp with al_fopen() and dump the contents and they appear correct. Not sure why al_load_bitmap() can't load it.
Append 2: al_fseek() is failing inside the BMP loader.
Append 3: It works fine when using the zlib provided by Mac OS X.
Do you remember which versions of freetype2, libpng, and zlib were working? I would guess it has something to do with zlib, as a .bmp file isn't png and ttf's load fine outside of physfs.
No, I think I was actually originally using the built-in zlib. I tried installing the old version I had (1.2.8), but it still didn't work. I think I only had that version because I needed it for Android.
Can anyone with windows or other OS'es test out ex_physfs for me? I need to know if the problem is with PhysFS or with Allegro and from when.
Apparently the last time it worked was with Allegro 5.2.1.1 and with FreeType2.6.5 and PhysFS 2.0.3, so PhysFS was the same and it worked. I tried ex_physfs (5.2.1.1) with ex_physfs.zip from 5.2 and it still worked, so the zip file is fine.
{"name":"610860","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/4\/54d2acf8320d0693dd71dd9e166d20e7.png","w":845,"h":326,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/4\/54d2acf8320d0693dd71dd9e166d20e7"}
It has to be something to do with allegro and the physfs addon. FreeType wouldn't matter when loading a .bmp and the zip file and physfs are both fine. But the version of zlib I used in 5.2.1.1 was 1.2.8 and the version of zlib I used in 5.2.3 was 1.2.11. It may be a problem with zlib, but if it's not :
Should I file a bug report on github? Send an email to the mailing list? What is the preferred way of reporting things these days?
Can I look up by commits on github or something? Or find all commits that have to do with a certain file?
Can I look up by commits on github or something? Or find all commits that have to do with a certain file?
You can see all of the commits made to a certain file by clicking on the file on GitHub and then clicking on the "Blame" or "History" buttons to the top right of the page.
Todd, I believe this is where you found it was failing before.
It fails on line 1320 of bmp.c in the call to al_fseek. I'm trying to step further into the code as we speak. It's failing inside f->vtable->fi_fseek which is file_phys_seek.
Yeah, that's exactly where I wound up. The PhysFS call is failing (returns a fail code). I'm not familiar with zlib so I didn't keep going.
EDIT
This is from a known physfs bug in v. 2.0.3. A copy of the patch from that thread is attached here :
https://www.allegro.cc/files/attachment/610879
Original Message
Todd, I believe this is where you found it was failing before.
It fails on line 1320 of bmp.c in the call to al_fseek. I'm trying to step further into the code as we speak. It's failing inside f->vtable->fi_fseek which is file_phys_seek.
EDIT
It's failing inside ZIP_seek in a call to ZIP_read.
Here's the debug output :
It's failing inside a call to inflate and zlib_err is returning -2 which means #define Z_STREAM_ERROR (-2). That's the best I can make of this.