I've updated my Allegro and AllegroGL (Win32 only, tomorrow I'll update my Kubuntu). They works nice, specially AllegroGL because the prior version (CVS) didn't work with my Intel GFX, the new version works without big problems, but I find two bugs:

Allegro: The square root doesn't works well. In the math test I tried "49 [sqrt]" and it doesn't return exactly 7 (7 * 7 = 49, so sqrt (49) = 7). I don't remember what it returned before the update.
AllegroGL: fonttest.c doesn't work. No error message, no window, no output, no nothing, just do nothing...

My System is Pentium 4, Windows XP SP2, MinGW32 5.0, MSys 1.0, Graphics Intel i810, Allegro 4.2.1, AllegroGL 0.4.0 RC7

I'll put my previous post into this thread instead:

AllegroGL: I have just recompiled the released version of allegrogl on my PC here, and dumbtest crashes again. The PC has an Intel Graphics chipset, and we had this problem discussed some time ago, a few weeks I think. There was a fix, and I thought it should have been in the SVN, but now I see that seemingly that fix got lost somewhere? Please check! I have double checked that my local files are identical to those from the released version. Ah, btw, dumbtest crashes in line 52, because in line 51 the allocation of a video bitmap of dimension 50x50 failed, but the resulting pointer isn't checked to be non 0.

About fonttest: This is due to a broken a32.tga file. I'm not sure if the reason os known, but it was something about SVN and Windows or so...

Do the other AllegroGL examples work?

If you have the time, you could compile in debug mode (make DEBUGMODE=2 LOGLEVEL=2; make install DEBUGMODE=2 LOGLEVEL=2), and AllegroGL will write down everything it does in the file allegro.log. But maybe it's related to tobing's problem in the other thread, since you both have an Intel card.

The other examples work for me. The point is, there has been a fix for this around...

Found the thread: http://www.allegro.cc/forums/thread/588077

It has to crash because your GFX cars doesn't support either ARB_npot or ARB_texture_rectangle OGL extensions. The fix you are probably referring to was for your other card, X850Pro. I proposed the patch on the ML, Bob was against it, so it was left unapplied. http://sourceforge.net/mailarchive/message.php?msg_id=37179899
It's not a big deal though, dumbtest should be rewritten properly to handle such situations.

I remember it crashing when my desktop color depth was 16-bit depth. set_gfx_mode failed or something... Can you try it in 32-bit?

I see, thanks.

I have tried fonttest with 32bit resolution, but the point was that the file a32.tga is somehow damaged. Never got a proper version of that file, even not when I accessed the SVN depot using the web interface. Strange.

Here's the posting I'm refering to:
http://www.allegro.cc/forums/thread/588077/622392#target

What would be a fix for dumbtest? Recreate the bitmap as 64x64 if NULL is returned?

or just create it as 64x64 instead.

There is no point creating a 64x64 bitmap. dumbtest is used to test the capabilities of gfx card and the AGL ability to use this capabilities. The returned bitmap pointer should be tested all over the code and display "unsupported" where the image should be.

edit:
a32.tga is damaged in RC7?

OK, I'll wait for the corrected dumbtest.c in SVN then.

Just checked: The a32.tga file in the distribution is identical to the one I have retrieved from SVN. Size is 9984 bytes, if that helps...

Can't you open it in a image viewer/editor and see if it's corrupted or not?

I can do that when I'm back home. I don't have a viewer at work that can display tga-files, but I remember that I have once opened the file with IrfanView, and only saw the letter a in that file...

It's supposed to contain only the letter A

Aha, so why does it not load then? Now I'm a little confused...

set_color_depth(32); in fonttest.c is wrong. set_gfx_mode will fail if desktop color depth is other than 32, because can't change that in windowed mode.
Should be:
allegro_gl_set(AGL_COLOR_DEPTH, 32);
allegro_gl_set(AGL_SUGGEST, AGL_COLOR_DEPTH);
... which should be fine but I don't feel like restarting my X server now to test it.

And fonttest doesn't display correctly in 16-bit mode. 32-bit ALPHA, LUMINANCE and INTENSITY are not displayed.

It doesn't help: I've replaced set_color_depth(32); by the two lines you suggested, but the crash remains the same. Happens in allegro, file fontbmp.c, line 263, when it tries
f->height = cf->bitmaps[0]->h;
but cf->bitmaps[0] does not point to valid memory.

Desktop resolution is 32 bit, and everything was built from scratch and as debug version, too.

Just to make sure, are you using Allegro 4.2.1?

No, I'm using 4.2.0, didn't have much time to upgrade to 4.2.1 yet. Is there a fix which could affect that behavior in 4.2.1?

Yes. The anti aliased fonts require Allegro 4.2.1. In general, I see AllegroGL 0.4.0 depending on Allegro 4.2.1 - that's also why I wanted to wait with the release after 4.2.1 comes out.

Just unpacked the all421.zip file and started to compile.

First, fix msvc7 --msvcpaths
OK.

Then, make.
Compilation fails, complains saying
Error, could not find '.rsp' in _tmpfile.arg.

What's going wrong here? I'm using MSVC 7.1 and MinGW is also installed...

Edit: Seems that the compiler installation is different from what would be needed to build allegro. No idea what's wrong though, I'll try again at home.

Edit again: At home now, allegro 4.2.1 compiled, dumbtest OK, fonttest OK. Great!
Thanks for all your replies and help!

I disagree: AGL should support all video bitmap sizes that we can.

I think this is a bug I accidentally added with revision 1016. Before that, AGL did support NPOT video bitmaps on GPUs that don't support NPOTs.

But it can't. His card doesn't support either ARB_npot or ARB_texture_rectangle.

I think, this was solved by scaling the image to the next power of two, and using a PO T texture.

Of course, I doubt that usually can be a good idea.. what might work though is, combine multiple POT textures into a single video bitmap, I think AllegroGL already can do that. Not that I know the code well enough to implement/fix it.

This is what used to work (and probabaly still does).

We do this for textures, not for bitmaps.

Yeah, I realized - but the combination could work (?)

I'm late, sorry. I was out-line

I remember it crashing when my desktop color depth was 16-bit depth. set_gfx_mode failed or something... Can you try it in 32-bit?
</quote>

I am in 32-bit yet... Anyway, I've loaded the fonts (a1.bmp, a8.bmp, a24.tga and a32.tga) with The Gimp and I get an 64x64 bitmap. I think they are corrupt or so... I've attached the bitmaps I have.

Just found a minor bug in the documentation:
(a /* turned the wrong direction in the example)

http://www.allegro.cc/manual/api/bitmap-objects/create_bitmap_ex

its the same in the tar.gz package at least, but not at all equally visible, due to syntax highlighting. Typically, right after release of 4.2.1...

(I tried to mail [AD], but didn't manage to do it for some reason, so I report it here instead.)

Niunio: Are the other bitmaps (e.g. mysha.pcx) ok? I remember something about mysha.pcx getting corrupted by something in the past.. can't remember what though. You can always get the correct pictures here btw: http://allegrogl.svn.sourceforge.net/viewvc/allegrogl/trunk/examp/

If I unpack the .tar.bz2 here, it has the correct files as well.. so not sure what's going on. Do .tar.bz2 archives have line-ending conversion markers or something?

bhagabhi: thanks, fixed in SVN

You're right. mysha.pcx was corrupted. I've downloaded the bitmaps from the link you put and it worked.

You should fix this in the nex releases.

Thanks.

Which package did you download exactly: zip, tgz or bz2? Or it was SVN?

I download alleggl-0.4.0_rc7.tar.bz2

I downloaded the same file. No corruption

Niunio's files are missing all 0x0d (13, CR) bytes. Independent of if they are near LF bytes or not, any 0x0d in the files is gone. So it seems, somewhere along the way, a program strips all 0x0d bytes.. my guess would be whatever unzip program he is using. This would leave all text files intact, but destroy any binary files.

It still seems strange.. would be a pretty serious bug of an unzip program, so something else must be going on here, like maybe .tar.bz2 can mark files as binary or text (and the way i create them, anything is text).

Maybe. I use 7-zip. I'll download the tar.gz of the final version and try it.