al_acknowledge_resize and al_create_builtin_font
gillius

I have a game using some text with al_create_builtin_font, and I wanted to add resizing to it. I noticed whenever I call al_acknowledge_resize, everything works as I expect, except the builtin font stops rendering. If I don't call the al_acknowledge_resize, or if I call again al_create_builtin_font after resize, it works again.

I'm using Allegro 5.2. I don't see anything in the documentation (http://liballeg.org/a5docs/trunk/display.html#al_acknowledge_resize) that suggests any resources should be invalidated by this call. Is this a bug in Allegro or am I doing something wrong? Might anything else be invalidated?

Mark Oates

Interesting.

Whenever a resize is created, it destroys and recreates a new display. Since all bitmaps are attached to the display, you'll need to reload and/or recreate any bitmaps.

My guess is that a note should be added to the documentation.

RPG Hacker

Whenever a resize is created, it destroys and recreates a new display. Since all bitmaps are attached to the display, you'll need to reload and/or recreate any bitmaps.

But doesn't Allegro already do that for you? I thought it already backs up all resources for you and restors them when you call al_acknowledge_resize(), so you would expect that it also backs up any fonts for you (which I suppose internally are just stored as textures, anyways). If this is the case, then the font not being restored definitely sounds like a bug.

Mark Oates

I think you might be right. This particular discussion is about the display losing focus but I believe the principal is the same:

On some platforms the contents of video bitmaps may be lost when your application loses focus. Allegro has an internal mechanism to restore the contents of these video bitmaps, but it is not foolproof (sometimes bitmap contents can get lost permanently) and has performance implications. If you are using a bitmap as an intermediate buffer this mechanism may be wasteful. In this case, if you do not want Allegro to manage the bitmap contents for you, you can disable this mechanism by creating the bitmap with the ALLEGRO_NO_PRESERVE_TEXTURE flag. The bitmap contents are lost when you get the ALLEGRO_EVENT_DISPLAY_LOST and ALLEGRO_EVENT_DISPLAY_HALT_DRAWING and a should be restored when you get the ALLEGRO_EVENT_DISPLAY_FOUND and when you call al_acknowledge_drawing_resume (after ALLEGRO_EVENT_DISPLAY_RESUME_DRAWING event). You can use those events to implement your own bitmap content restoration mechanism if Allegro's does not work well enough for you (for example, you can reload them all from disk).

I don't see how an ALLEGRO_BITMAP can be created and then all the pointers that previously referenced it are now able to point to the new bitmap.

RPG Hacker

You brought up a good point. I don't know if a window resize actually causes it to lose focus. I don't think it should (unless fullscreen shenanigans are involved).

I don't see how an ALLEGRO_BITMAP can be created and then all the pointers that previously referenced it are now able to point to the new bitmap.

The pointer itself doesn't need to change in this case, it can still point to the same ALLEGRO_BITMAP since that's basically just a struct. Only the texture held by that ALLEGRO_BITMAP struct (which is either a D3D texture or an OpenGL texture) needs to be restored. For simplicity, you can imagine it as a pointer to pointer. The second pointer can change without the first pointer needing to change. For fonts, this may just not work correctly yet.

Elias

Can you try if it also happens with a TTF font? It definitely sounds like a bug in Allegro to me.

SiegeLord

5.2 has a bug with resizing that was fixed. I'd try verifying this on master first.

gillius

As a test, I called al_acknowledge_resize even when the window had not actually been resized and when it was in windowed mode, and it killed my font. I didn't have any other bitmaps yet so I didn't notice anything (the rest is draw via primitives calls).

This may be partially my fault, because if I wrap the al_acknowledge_resize call with a condition (for example on a key down event), it works. I actually was testing whether or not I really needed to listen for resize events and call resize -- if I could just call it every loop, since on every loop I already call al_get_display_width and al_get_display_height and set a transform to scale the "fixed" game to the window. I should try legitimately listening for the resize event and only calling ack then to see if there are any problems.

I also tested this with a normal load_bitmap call loading a JPG and saw the same results. Interestingly in one test Windows 10 said my NVIDIA windows kernel driver crashed and it restarted it.

I'm willing to try any version of Allegro but I'm working from my jalleg library and trying to call every module, so I don't have any C compiler, plus I've heard the dependencies build on Windows is quite involved. I didn't see any 5.2.1 snapshot on GNA.

SiegeLord

What binaries were you using, MinGW ones or MSVC ones? I'll compile you a snapshot.

gillius

I am using the 64-bit Windows prebuilt binaries linked from the site: http://download.gna.org/allegro/allegro-bin/5.2.0/, so based on the name it's MinGW.

SiegeLord

Alright, here it is. Keep in mind that the version that this one responds to is 5.2.1:

https://www.dropbox.com/s/ndxvm8px5qdofdz/allegro-master.zip?dl=0

gillius

Hi SiegeLord, I tried out the new DLL, there is no change from my current Allegro (which reports as 5.2.0.1, while yours reports as 5.2.1.0). However, I will say that when I implement the resize properly, I can't reproduce it, by that I mean:

al_set_new_display_flags(ALLEGRO_RESIZABLE);
mainDisplay = al_create_display(640, 480);
//... in event loop:
if (event.type == ALLEGRO_EVENT_DISPLAY_RESIZE) {
  al_acknowledge_resize(mainDisplay);
}

instead of just calling al_acknowledge_resize constantly. Since it's really not that hard to add to my loop, I am doing it that way. But it would be nice to know if formally I am guaranteed not to lose bitmaps, etc., or whether or not I need to know to reload them.

Thread #616340. Printed from Allegro.cc