Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug in TxImage.cpp (TxImage::readPNG(...)) #31

Open
JayTee42 opened this issue Dec 24, 2014 · 4 comments
Open

Bug in TxImage.cpp (TxImage::readPNG(...)) #31

JayTee42 opened this issue Dec 24, 2014 · 4 comments

Comments

@JayTee42
Copy link

Hi guys, thanks for your great work - keep it up.

I'd like to point out a little bug: When trying to run Super Smash Bros. N64 with an additional texture pack, glide64mk2 failed to load the provided PNG files. I did some debugging research: The problem is located inside GlideHQ/TxImage.cpp (uint8* TxImage::readPNG(FILE* fp, int* width, int* height, uint16* format)): The vars o_width and o_height should be png_uint_32 instead of int (allowing you to omit the cast). After recompiling everything worked well for me.

Merry Christmas!
J.T.

@richard42
Copy link
Member

I don't see how changing these variables from int to uint could fix anything. Perhaps you were originally using an older build which had a bug, and by downloading the latest code and rebuilding from source, you built a newer version without the bug?

@JayTee42
Copy link
Author

JayTee42 commented Jan 1, 2015

I downloaded the latest bins and tried to use them for loading the textures, but they wouldn't load (more precisely, the BMP files did actually load, but the PNGs didn't), so I got the source and started debugging.

For all PNGs that were loaded, I realized png_ptr to become null after calling png_get_IHDR (line 102), so I checked the API (http://refspecs.linuxbase.org/LSB_4.0.0/LSB-Desktop-generic/LSB-Desktop-generic/libpng12.png.get.ihdr.1.html) just to see they are using png_uint_32.

After changing, png_get_IHDR works like a charm (just tried to reproduce it, still behaving that way). It might be related to sizeof(int) on different systems ... ?

@JayTee42
Copy link
Author

JayTee42 commented Jan 1, 2015

Just checked it out, sizeof(int) is 4 on my system, but png_uint_32 is typedefed as

typedef unsigned long int png_uint_32; //pngconf.h

and sizeof(unsigned long int) prints 8. So you are passing pointers to 4-byte-variables that are assumed to provide 8 bytes of space. Hope this makes it clear :-)

@richard42
Copy link
Member

Thanks very much for tracking this down; I'll make a patch to fix it. I never really liked every project having it's own typedefs, and this shows why. It's pretty surprising that a png_uint_32 would be 64 bits long.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants