That's because SiegeLord uses MSYS to build allegro and the winpkg. Try installing MSYS2 and the allegro packages.
Or use my binaries
with this compiler :
Or build allegro yourself using whatever compiler you want. 
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.
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?
]]>Here you go:
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.
]]>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 :
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.
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.
]]>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.
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.
]]>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.
]]>What are the required parameters for the static debug build? I'm using -lallegro_monolith-static and getting lots of undefined reference errors.
]]>-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
]]>
It says I'm missing -lzlibstatic
I downloaded the dependencies here:
https://github.com/liballeg/allegro_winpkg/releases
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.
]]>Now I'm getting this:
]]>
You aren't using the same compiler that was used to generate the binaries.
]]>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?
]]>7.4.X will work. You must compile as c++, because the windows d3d code is in c++
]]>Do you know where I can download it? I already searched mingw sourceforge page and google, can't find it.
]]>That's because SiegeLord uses MSYS to build allegro and the winpkg. Try installing MSYS2 and the allegro packages.
Or use my binaries
with this compiler :
Or build allegro yourself using whatever compiler you want.
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:
]]>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? 
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.
]]>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
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.
]]>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?
]]>No, it comes with my binaries. Msys binaries use a different name(s).
]]>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?
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?
]]>My command line includes -lwinmm, so, yes.
]]>Post the full command line you used.
It shouldn't depend on any dlls at all.
]]>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
]]>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.
]]>Ok, attached it on the post.
]]>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?
]]>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.
Do you know how to use gdb?
Sorry, never used it before.
]]>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?
]]>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.
-o bitmapbug
The only thing I see is that this produces bitmapbug.out, and not bitmapbug.exe .
Otherwise it looks correct. :/
]]>Can you upload your exe for me to test if that bug still happens?
]]>Attached.
]]>Yes, no text appears, just the orange screen.
]]>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?
]]>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.
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.
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.
]]>