Draw to bitmap failing

Space cpp

tl;dr: setting the display depth size > 0 causes all bitmaps larger than the display to not accept drawing functions.

The project I'm doing right now auto generates a texture atlas, and after adding a few high resolution textures suddenly the atlas is empty.
Loading big bitmaps and using al_clear_to_color are fine, but any drawing function does not work at all.
After hours of testing I found out that the maximum bitmap width(the atlas bitmap) usable without causing the bug equals to my display size.
By randomly changing my code I found that if I remove the line that sets the depth buffer size the error is gone. But it is a 3D game so I really need it.

Edgar Reynaldo

It would help if you could recreate this with a simple test program that we could all try.

It may not behave the same on all systems.

What are your specs, hardware, and OS? And what compiler was used for Allegro? Which version?

Space cpp

Here you go:

#SelectExpand
  1#include <allegro5/allegro.h>
  2#include <allegro5/allegro_font.h>
  3#include <allegro5/allegro_color.h>
  4
  5
  6#define DISPLAY_WIDTH 1024
  7#define DISPLAY_HEIGHT 768
  8
  9int main(int argc, char **argv)
 10{

if (!al_init() ) return -1;
al_init_font_addon(); 


// uncomment this for the bug
//al_set_new_display_option(ALLEGRO_DEPTH_SIZE, 24, ALLEGRO_SUGGEST);

ALLEGRO_DISPLAY * display = al_create_display(DISPLAY_WIDTH, DISPLAY_HEIGHT);

ALLEGRO_FONT * font = al_create_builtin_font();


ALLEGRO_BITMAP * atlas_texture = al_create_bitmap(DISPLAY_WIDTH + 1, DISPLAY_HEIGHT);
if (atlas_texture)
{
  
  ALLEGRO_STATE previous_state;
  al_store_state(&previous_state, ALLEGRO_STATE_TARGET_BITMAP);
  al_set_target_bitmap(atlas_texture);
  
  al_clear_to_color( al_map_rgba_f(0,0,0.5f,1.0f) );
  al_draw_text(font, al_map_rgb_f(1,1,1), 10, 10, ALLEGRO_ALIGN_LEFT, "Some text");
  
  al_restore_state(&previous_state);
  
}

al_clear_to_color( al_map_rgba_f(0,0,0,0) );
al_draw_bitmap(atlas_texture, 0, 0, 0);
al_flip_display();

al_rest(5);

al_destroy_font(font);
al_destroy_bitmap(atlas_texture);

return 0;

 50}

I'm using windows 7 x64, intel core i7-4790, nvidia geforce gtx 970,
mingw i686 gcc 8.1.0, allegro 5.2.5.1

Update:
I did a workaround by creating the atlas as a memory bitmap, drawing, and then converting it to video bitmap.
During the process I found 2 problems:

al_convert_memory_bitmaps() does nothing. Had to explicitly call al_convert_bitmap.

For al_store_state, ALLEGRO_STATE_BITMAP and ALLEGRO_STATE_ALL are not saving the new bitmap flags. So I had to store ALLEGRO_STATE_NEW_BITMAP_PARAMETERS alone and restore it.

Edgar Reynaldo

Well, better that you discovered these bugs than let them remain in the wild. I'm confident we can get a fix out here.

So I modified your example a little bit to do some more in depth testing.

The altered code :

#SelectExpand
  1
  2#include "allegro5/allegro.h"
  3#include "allegro5/allegro_font.h"
  4#include "allegro5/allegro_color.h"
  5#include "allegro5/allegro_ttf.h"
  6
  7#include <cstdio>
  8
  9
 10int main(int argc , char** argv) {
 
 (void)argc;
 (void)argv;
 14
 int DISPLAY_WIDTH = 1024;
 int DISPLAY_HEIGHT = 768;
 
 
 if (!al_init() ) {return -1;}
 if (!al_init_font_addon()) {return -2;} 
 21
 if (!al_install_keyboard()) {return -10;}
 
 24
 printf("Creating %d x %d display...\n" , DISPLAY_WIDTH , DISPLAY_HEIGHT);
 
 /// uncomment this for the bug
 al_set_new_display_option(ALLEGRO_DEPTH_SIZE, 24, ALLEGRO_SUGGEST);
 29
 30///   al_set_new_display_flags(ALLEGRO_FULLSCREEN);
 
 ALLEGRO_DISPLAY * display = al_create_display(DISPLAY_WIDTH, DISPLAY_HEIGHT);
 if (!display) {
    printf("Failed to create display.\n");
    return 1;
 }
 
 
 
 ALLEGRO_FONT * font = al_create_builtin_font();
 41
 printf("Created display dimensions : %d x %d\n" , al_get_display_width(display) , al_get_display_height(display));
 
 int ATLAS_WIDTH = al_get_display_width(display) + 4;
 int ATLAS_HEIGHT = al_get_display_height(display);
 
 const int maxsize = al_get_display_option(display , ALLEGRO_MAX_BITMAP_SIZE);
 
 printf("Max bitmap size is %d x %d\n" , maxsize , maxsize);
 
 printf("Creating %d x %d atlas bitmap...\n" , ATLAS_WIDTH , ATLAS_HEIGHT);
 
 ALLEGRO_BITMAP * atlas_texture = al_create_bitmap(ATLAS_WIDTH , ATLAS_HEIGHT);
 if (!atlas_texture) {
    printf("Failed to create atlas.\n");
    return -20;
 }
 58
 const int flags = al_get_bitmap_flags(atlas_texture);
 
 if (flags & ALLEGRO_MEMORY_BITMAP) {
    printf("Atlas is a memory bitmap!\n");
 }
 
 
 al_set_target_bitmap(atlas_texture);
 al_clear_to_color(al_map_rgb(255,127,0));
 al_draw_text(font , al_map_rgb(0,0,0) , 10 , 10 , ALLEGRO_ALIGN_LEFT , "Hello depth test");
 al_set_target_backbuffer(display);
 
 
 72
 ALLEGRO_EVENT_QUEUE* q = al_create_event_queue();
 
 al_register_event_source(q , al_get_keyboard_event_source());
 al_register_event_source(q , al_get_display_event_source(display));
 77
 78
 79
 al_clear_to_color( al_map_rgba_f(0,0,0,0) );
 al_draw_bitmap(atlas_texture, 0, 0, 0);
 al_flip_display();
 83
 ALLEGRO_EVENT ev;
 al_wait_for_event(q , &ev);
 86
 al_destroy_font(font);
 al_destroy_bitmap(atlas_texture);
 89
 return 0;
 91
 92}

For now I left out testing of state storage and retrieval. That's a separate bug.

I can't reproduce the bug with my code, or with yours.

The one thing I can do is make the text disappear when using an NVIDIA gpu.

I also tested storing the target bitmap and restoring it, and it worked fine in all cases.

Can you provide a static debugging binary I can try that exhibits this problem for you? If it works for me and not you, then there is something different between our hardware that is causing it, or possible the Windows version.

I used Allegro 5.2.5 for all testing.

Space cpp said:

For al_store_state, ALLEGRO_STATE_BITMAP and ALLEGRO_STATE_ALL are not saving the new bitmap flags. So I had to store ALLEGRO_STATE_NEW_BITMAP_PARAMETERS alone and restore it.

I didn't test for this, so this probably is still a bug of some kind.

Space cpp

Haven't installed the static allegro yet, but I did a test in OpenGL mode and it works fine. So I guess it is something on the direct3D implementation.

Edgar Reynaldo said:

I also tested storing the target bitmap and restoring it, and it worked fine in all cases.

No no, this part works fine. The problem was just with the new bitmap flags. if I stored ALLEGRO_STATE_BITMAP or ALLEGRO_STATE_ALL then called al_convert_bitmap it was still a memory bitmap rather than a video one.

Edgar Reynaldo

Space cpp said:

if I stored ALLEGRO_STATE_BITMAP or ALLEGRO_STATE_ALL then called al_convert_bitmap it was still a memory bitmap rather than a video one.

This is definitely a bug then. New bitmaps flags should be restored along with the rest of the state at least I think so.

Space cpp

What are the required parameters for the static debug build? I'm using -lallegro_monolith-static and getting lots of undefined reference errors.

Edgar Reynaldo

-lallegro_monolith-debug-static
-ljpeg 
-ldumb 
-lFLAC 
-lfreetype 
-lvorbisfile 
-lvorbis 
-logg 
-lphysfs 
-lpng16 
-lzlibstatic 
-ldsound
-lgdiplus 
-luuid 
-lkernel32 
-lwinmm 
-lpsapi 
-lopengl32 
-lglu32 
-luser32 
-lcomdlg32 
-lgdi32 
-lshell32 
-lole32 
-ladvapi32 
-lws2_32 
-lshlwapi 
-static-libstdc++ 
-static-libgcc

Space cpp

It says I'm missing -lzlibstatic

I downloaded the dependencies here:
https://github.com/liballeg/allegro_winpkg/releases

Edgar Reynaldo

So link to the zlib that came with the winpkg release. Those are the list of libraries when you build allegro and everything else yourself.

Space cpp

Now I'm getting this:

#SelectExpand
  1C:\mingw32_gcc810\i686-w64-mingw32\lib\liballegro_monolith-debug-static.a(d3d_display_formats.cpp.obj)  In function `al_d3d_generate_display_format_list':
  249    C:\dev\allegro_winpkg\universal\allegro\src\win\d3d_display_formats.cpp  undefined reference to `__cxa_guard_acquire'
  349    C:\dev\allegro_winpkg\universal\allegro\src\win\d3d_display_formats.cpp  undefined reference to `__cxa_guard_release'
  450    C:\dev\allegro_winpkg\universal\allegro\src\win\d3d_display_formats.cpp  undefined reference to `__cxa_guard_acquire'
  550    C:\dev\allegro_winpkg\universal\allegro\src\win\d3d_display_formats.cpp  undefined reference to `__cxa_guard_release'
  649    C:\dev\allegro_winpkg\universal\allegro\src\win\d3d_display_formats.cpp  undefined reference to `__cxa_guard_abort'
  750    C:\dev\allegro_winpkg\universal\allegro\src\win\d3d_display_formats.cpp  undefined reference to `__cxa_guard_abort'
  8C:\mingw32_gcc810\i686-w64-mingw32\lib\liballegro_monolith-debug-static.a(d3d_display_formats.cpp.obj)  d3d_display_formats.cpp:(.eh_frame+0xab): undefined reference to `__gxx_personality_v0'
  9C:\C programing\Testing\bitmapbug\collect2.exe  [Error] ld returned 1 exit status

Edgar Reynaldo

You aren't using the same compiler that was used to generate the binaries.

Space cpp

So in order to use allegro-i686-w64-mingw32-gcc-7.4.0-posix-dwarf-static-5.2.5.1 I do need mingw exactly at version 7.4.0?

Edgar Reynaldo

7.4.X will work. You must compile as c++, because the windows d3d code is in c++

Space cpp

Do you know where I can download it? I already searched mingw sourceforge page and google, can't find it.

Edgar Reynaldo

That's because SiegeLord uses MSYS to build allegro and the winpkg. Try installing MSYS2 and the allegro packages.

Or use my binaries

https://bitbucket.org/bugsquasher/unofficial-allegro-5-binaries/downloads/Allegro525_GCC81_MinGW_W64_i686_posix_dwarf.7z

with this compiler :

https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/8.1.0/threads-posix/dwarf/i686-8.1.0-release-posix-dwarf-rt_v6-rev0.7z

Or build allegro yourself using whatever compiler you want.

GullRaDriel

Or also: instructions to install allegro5 with msys2 I made for myself

https://www.allegro.cc/forums/thread/617736/1041205#target

Another one by Polybios:

https://www.allegro.cc/forums/thread/616828

Space cpp

At first I tried the binaries you provided with a fresh mingw install. Still got the same undefined reference errors.

Now I'm doing the MSYS2 way.
I was able to compile a regular executable with dll dependencies with it, but for a static debug build it seems to be missing the necessary lib files... or am I using incorrect command line parameters?

Edgar Reynaldo

I'm guessing you forgot to define ALLEGRO_STATICLINK before including the allegro headers. If you linked to all the libs above, and you're still getting errors, post them. And please post your command line, so we can see what's going on.

Space cpp

Ok, added #define ALLEGRO_STATICLINK

The command line:
gcc main.cpp -Wall -o bitmapbug -lallegro_monolith-debug-static -ljpeg -ldumb -lFLAC -lfreetype -lvorbisfile -lvorbis -logg -lphysfs -lpng16 -ldsound -lgdiplus -luuid -lkernel32 -lwinmm -lpsapi -lopengl32 -lglu32 -luser32 -lcomdlg32 -lgdi32 -lshell32 -lole32 -ladvapi32 -lws2_32 -lshlwapi -static-libstdc++ -static-libgcc

results in:
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lallegro_monolith-debug-static
collect2.exe: error: ld returned 1 exit status

Edgar Reynaldo

You're not setting the compiler and linker search directories.

Use -I "path/to/include" and -L "path/to/lib" in your command line. Compiler include search paths go before your source files and linker search paths go after them. Order matters.

Also, you have to use g++, not gcc.

Space cpp

It wasn't that, I'm really lacking the allegro-debug-static lib. I thought msys was going to install it too. Do this means the only way is to build allegro myself to generate it?

Edgar Reynaldo

No, it comes with my binaries. Msys binaries use a different name(s).

Space cpp

Got it compiling finally. However, when I try to run the executable it says something like "The procedure entry point timeBeginPeriod could not be located in the dynamic link library KERNEL32.dll.
Also, the file is 8.11mb, is this normal?

Edgar Reynaldo

The size is normal for a static debugging executable, yes.

Not sure why timeBeginPeriod is not being found. It's in winmm, and you linked to that, right?

Space cpp

My command line includes -lwinmm, so, yes.

Edgar Reynaldo

Post the full command line you used.

It shouldn't depend on any dlls at all.

Space cpp

g++ -I"C:\allegro_edgar\include" -L"C:\allegro_edgar\lib" main.cpp -Wall -o bitmapbug -lallegro_monolith-debug-static -ljpeg -ldumb -lFLAC -lfreetype -lvorbisfile -lvorbis -logg -lphysfs -lpng16 -lzlibstatic -ldsound -lgdiplus -luuid -lkernel32 -lwinmm -lpsapi -lopengl32 -lglu32 -luser32 -lcomdlg32 -lgdi32 -lshell32 -lole32 -ladvapi32 -lws2_32 -lshlwapi -static-libstdc++ -static-libgcc

Edgar Reynaldo

Ok, I'm officially confused.

One thing you forgot is -g for debugging symbols.

I don't see what is wrong. Can you upload the static exe you produced here for me to try? Add debugging symbols first.

Space cpp

Ok, attached it on the post.

Edgar Reynaldo

Ok, I tried it. Aside from a dependency on libpthread-1.dll it ran fine.

Just add -lpthread before the static stdc++ and libgcc libraries.

Do you know how to use gdb?

Space cpp

That's strange, adding -lpthread made no difference for me. Puting libpthread-1.dll on the same folder as the executable also didn't solved.

Edgar Reynaldo said:

Do you know how to use gdb?

Sorry, never used it before.

Edgar Reynaldo

Then we're not running the same exe...???

You need to learn how to use gdb or at least some kind of debugger, if you're going to be a programmer.

See my little guide here :

https://github.com/liballeg/allegro_wiki/wiki/Debugging-and-logging-with-A5#debugging-with-gdb

When you link statically, it doesn't depend on any dlls, so something is wrong.

Are you sure you're running the right program?

Space cpp

Just checked it again, yes.
The command line:
g++ -I"C:\allegro_edgar\include" -L"C:\allegro_edgar\lib" -g main.cpp -Wall -o bitmapbug -lallegro_monolith-debug-static -ljpeg -ldumb -lFLAC -lfreetype -lvorbisfile -lvorbis -logg -lphysfs -lpng16 -lzlibstatic -ldsound -lgdiplus -luuid -lkernel32 -lwinmm -lpsapi -lopengl32 -lglu32 -luser32 -lcomdlg32 -lgdi32 -lshell32 -lole32 -ladvapi32 -lws2_32 -lshlwapi -lpthread -static-libstdc++ -static-libgcc

Compiled using mingw32.exe included in msys2 installation; include and lib paths set to your allegro build.

Is everything correct at this point?

Edit:
Oops, I forgot that gdb is THE debugger.

Edgar Reynaldo

Quote:

-o bitmapbug

The only thing I see is that this produces bitmapbug.out, and not bitmapbug.exe .

Otherwise it looks correct. :/

Space cpp

Can you upload your exe for me to test if that bug still happens?

Edgar Reynaldo

Attached.

https://www.allegro.cc/files/attachment/612089

Space cpp

Yes, no text appears, just the orange screen.

Edgar Reynaldo

Sorry, forgot to reply to this thread.

Regarding the orange screen, that's what I get when I render with OpenGL. There must be some font corruption. But the actual video image, does it get created successfully or no?

Space cpp

Quote:

But the actual video image, does it get created successfully or no?

The "atlas_texture" is created (no error message is shown, also, not a memory bitmap) but no text is drawn to it.

Quote:

There must be some font corruption

It doesn't look like to be a font issue since al_draw_bitmap calls also don't work.

Quote:

Regarding the orange screen, that's what I get when I render with OpenGL

My machine does the opposite: rendering in OpenGL eliminates the bug.

Thread #617860. Printed from Allegro.cc