Hi,
al_get_opengl_texture() returns a texture with garbage in data
(see screenshot). I've tried with .bmp and .tiff files.
I'm using Allegro 5.0.1 with MacOS X 10.5.8.
Here is my method to load a bitmap and return its OpenGL id:
So, what is going (am I doing) wrong?
Thanks in advance for any answer,
azerty
What is it supposed to look like?
Hi,
Here is the original texture...
Hm, does the picture work fine if you draw it with al_draw_bitmap? Else can you make a small example program reproducing the problem?
Hi,
Here is the program that reproduces the problem.
I hope it is clear enough.
Works fine here in Linux. I had to disable vsync, depth_size and float_depth though and convert the .tiff to a .png. Can you try making those changes and see if the problem is fixed?
Hi Elias,
I've used a png file and removed all the calls to al_set_new_display_option() but the result is the same... Maybe this is a MacOS X specific issue? I also have the problem when I use al_draw_bitmap()...
Thanks for your help...
I also have the problem when I use al_draw_bitmap()
Is ex_bitmap also broken?
Hello Elias,
ex_bitmap works but not ex_draw_bitmap...
ex_bitmap uses a .pcx file; ex_draw_bitmap a .png, so I've saved my texture as .pcx and the problem has disappeared. But I don't want to use PCX, because of
transparency, so if you have another suggestion, please tell me.
I've compiled the Allegro library with this version of GCC:
Using built-in specs.
Target: powerpc-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5465)
Ok, PowerPC. That could be important.
Can you try toggling the option for the native image loader in the CMake options and recompile?
If you switch it off, you'll need libpng and zlib to load PNG images. If that works there's an endianess bug in the native image loader.
I can try your example later (on 10.6) to see if it works here.
.png (as well as .tiff) is handled by the OSX image loader. .pcx is read directly. So guess we have a good indication now that the OSX image loader is broken.
Since you are using 10.5 but all devs are using 10.6 I'm fairly certain that's the problem. OSX must somehow load images differently under 10.5. Is there a way to debug 10.5 specific problems under 10.6?
[edit:] Oh, didn't see PowerPC, that could be another reason of course, swapped byte order always can cause problems.
Since you are using 10.5 but all devs are using 10.6 I'm fairly certain that's the problem. OSX must somehow load images differently under 10.5. Is there a way to debug 10.5 specific problems under 10.6?
Probably. Just compile an executable that is designed to run under 10.5. I don't think that's the problem though.
In fact, it's probably possible to debug the PPC build on an Intel machine by just setting the target to PPC (and the OS X version to 10.5, if it doesn't do that automatically), recompile and run (you can run PPC binaries on Intel Macs through some sort of emulation, or maybe it actually JIT re-compiles it, I'm not entirely sure other than that it works).
As I've reported many times, the native loader does not work properly on 10.4/PPC. The screenshot is the same type of results I get. I fixed some endian issues with the locking code, but that didn't fix the horizontal garbage of some images.
The libpng/libjpeg loaders work fine.
Hi,
I've installed libpng15 and zlib (/usr/local/lib) but I don't know how to tell cmake to use them instead of native image loaders.
Can you help me?
Thanks...
Grep the cmake log or txt files or something like:
cmake .. -DWANT_NATIVE_IMAGE_LOADER=off
Hi Matthew,
It is working now, thank you. Is there any hope to see the problem with native loaders on ppc solved in the future?