Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » al_draw_bitmap crashes on Windows XP

Credits go to SiegeLord for helping out!
This thread is locked; no one can reply to it. rss feed Print
al_draw_bitmap crashes on Windows XP
Barinzaya
Member #16,528
August 2016

While working on a program using Allegro, I happened to notice that the program crashed when I attempted to run it on my Windows XP testbed (a virtual machine). It didn't crash immediately, and sound started to play before it did. I have no debugger on my testbed, but using console prints I was able to narrow the crash down to a call to al_draw_bitmap. I was also able to confirm that the bitmap being drawn there was valid, as was the target bitmap, so I made a separate project to test it out.

I was able to make a minimal working example (attached as main.c) that demonstrates the crash. The program crashes on the Windows XP system upon the call to al_draw_bitmap, but only when ALLEGRO_PROGRAMMABLE_PIPELINE is included in the display flags. I have attached a copy of the allegro.log file generated by a run which crashed. It does not seem to contain anything that might indicate a problem. The same executable works on my development system (Windows 7).

The same program works on the Windows XP system if it displays a primitive instead of a bitmap. Shaders work correctly in that case too, so it doesn't seem like a problem with the system.

My development environment is Visual Studio 2015, using the Allegro 5.2.1 binaries from the NuGet package (specifically, the static monolith library). I also tried building the attached example with MinGW and its official Allegro binaries, and observed the same behavior.

Is Windows XP still supported by Allegro? If so, is this a bug or am I doing something wrong? Thanks in advance for your time.

SiegeLord
Member #7,827
October 2006
avatar

Officially, we do still support Windows XP, or at least we don't actively remove support for it.

Would it be possible for you to compile with the debug version of Allegro and get a backtrace on WinXP?

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Barinzaya
Member #16,528
August 2016

I think I've found the problem. I've attached the stack trace to this post. It doesn't seem to include file names, but it includes function names and line numbers.

The culprit appears to be ogl_draw.c:405, which is a call to glGenVertexArrays in ogl_flush_vertex_cache. I added an ALLEGRO_DEBUG call to print the value of the pointer to glGenVertexArrays prior to calling it, and sure enough, it's NULL. The allegro.log in the OP indicates that the OpenGL version is 2.1, and VAOs weren't added until 3.0.

I've attached a patch which adds checks to bypass the VAO calls if the functions aren't available. Note that the call to unbind the VAO later in the function also needs to be bypassed. With this change, the example program works on my Windows XP system, but I haven't tested it with anything more complex yet to know if it might cause other problems.

SiegeLord
Member #7,827
October 2006
avatar

I filed an issue about this so this isn't forgotten: https://github.com/liballeg/allegro5/issues/668

Not sure what the right way forward is, however, I was always under the imporession that for the programmable pipeline VAOs were not optional.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Barinzaya
Member #16,528
August 2016

In modern OpenGL (core profile), they're definitely not optional. From the OpenGL wiki: "The compatibility OpenGL profile makes VAO object 0 a default object. The core OpenGL profile makes VAO object 0 not an object at all." However, with a version prior to 3.0 (in which they don't exist outside of an extension) or in a compatibility profile (where 0 is a valid VAO), they're not required.

Checking whether the VAO functions are available before attempting to use them should solve this issue. That way, VAOs are used anywhere they're available, and it doesn't crash if they're not. The concern I would have with this is whether the other things that are set in the VAO (vertex attributes and bound buffer) would carry over to anything else it wasn't supposed to. It looks like all changes made are undone after drawing, so at a glance it looks like it should be safe to use without a VAO.

Of course, there are probably other ways to handle it too. That's if you even bother; admittedly, OpenGL <3.0 is quite outdated now.

Go to: