Originally reported by: scherno2000

Original Ticket: "alleg/bugs/106":https://sourceforge.net/p/alleg/bugs/106

1. rest(0) does not yield.
2. in fbcon.c console_users is incremented twice, but decremented only once.
3. If allegro application is run in console mode, and get_tty() returns 0 (running application from midnight commander), problems with threads created before fork().
4. If allegro application is run in console mode, from midnight commander, then the shell thinks the application is ended too early because of main process is killed in allegro initialization.

Please read the readme file in attached zip file.

If a window (display) was created with the ALLEGRO_MAXIMIZED flag then call to al_set_window_constraints() will be a cause of strange behavior as depicted below:

The patch is fixing such problem. Tested only under Windows 7, 64-bit. Thanks!

Note: This pull request is mostly for review purposes, probably shouldn't be merged in just yet.

Recently I've started looking into the possibilities of porting Allegro (and, in turn, my game engine) to various platforms. I've found @ptitSeb fork with OpenPandora and ODroid support, @allefant's patches for Emscripten and also started playing with Nokia N900 support by myself. SDL backend allowed me to experiment with X11/EGL without actually implementing it in Allegro itself just yet, so I could focus on the GLES stuff alone.

What I found was a huge mess of #ifdefs. If I wanted to consolidate all the patches I found into one codebase, I would end up with lines like: #if defined ALLEGRO_IPHONE || defined ALLEGRO_ANDROID || defined ALLEGRO_RASPBERRYPI || defined ALLEGRO_PANDORA || defined __EMSCRIPTEN__ so before I went further, I decided to clean it all up and make parts that are actually GLES specific (as opposed to device specific) check for GLES instead of any particular device.

In turn I've found out some other issues. For instance, on some platforms linking both libGLESv1_CM and libGLESv2 into the same binary breaks GLES2. Also, it wasn't actually easily possible to request a GLES build on a device that wasn't Android-based, iOS-based or Raspberry Pi. In turn, I've reworked the build system a bit.

When it comes to the code, I've tested it so far on GNU/Linux on X11/GLX/GL, SDL/GLX/GL, SDL/EGL/GLES and Android. It still needs to be tested on other platforms - I should be able to do it for macOS and Raspberry Pi, but I can't for iOS, so that would need some external testing. I think it should be fairly solid, aside of iOS-case, where I have no idea, so I might have broken something there.

Compiling with GLES3 is broken right now with this patch, I'll look into it later. Compiling with GLES1 was already broken (and impossible without modifying CMakeFiles.txt), but I've seen some patches floating somethere that should fix it, just haven't looked into them yet.

When it comes to the build system, I'm not sure whether the way I've taken is the best one. Especially I don't like that WANT_GLES2 requires WANT_GLES, which alone means GLES 1.1, and together means GLES 2.0, which are completely different builds (GLES3 could stay that way though). I'd be thankful for any comments on how to tackle it.

On macOS, al_get_monitor_info returns the wrong values when called on a Retina display, specifically it seems like x2 and y2 are half of what they're supposed to be. As miniSphere uses this function to determine window scaling and position, this results in game windows which are too small and off-center:

As Allegro is otherwise Retina-aware, al_get_monitor_info should return the native resolution rather than the one the system is faking.

GDI+ was supposed to have been fixed in #529, but I'm still getting failures when running CMake:

Could NOT find GDIPLUS (missing:  GDIPLUS_INCLUDE_DIR) 
WARNING: cannot use GDI+. Will try other libraries.

The value of GDIPLUS_INCLUDE_DIR is set to GDIPLUS_INCLUDE_DIR-NOTFOUND at this point. If I set it manually to my WinSDK include path in cmake-gui and reconfigure, it will work. But it will not find it by default.

Specifying -lm on Arch Linux is necessary for DUMB support: Otherwise, cmake concludes that DUMB is not available. I used the DUMB 1.0-1 binary package from the Arch repo. This Arch package points to kode54's fork of DUMB with version 1.0 as suggested by the DUMB homepage, not to version 0.9.3 that A5 officially supports.

I didn't test whether this is required on other systems, or whether it breaks the build on other systems.

Still no successful playback: I've merely fixed A5's build for me. I can load a module with Allegro 5, but then my application will immediately crash within DUMB. Crashlog follows. I haven't debugged this crash yet! The fault could be in DUMB, in the DUMB Arch package, in A5, in my code, in a faulty module, ...

I'll understand if you won't merge this PR before we have seen successful playback with DUMB 1.0 and A5. According to @SiegeLord, DUMB 1.0 made breaking changes. Still, I'm opening this PR to share my findings, allowing others to shed more light on this.

#0  0x0000000000000000 in ?? ()
#1  0x00007ffff3dd1962 in ?? () from /usr/lib/libdumb.so
#2  0x00007ffff3dd2d15 in dumb_read_it_quick () from /usr/lib/libdumb.so
#3  0x00007ffff3dd0996 in dumb_read_it () from /usr/lib/libdumb.so
#4  0x00007ffff78d5d74 in mod_stream_init (f=0x555556284600, buffer_count=3,
    samples=2048, loader=0x7ffff3dd0990 <dumb_read_it>)
    at /home/simon/c/notown/allegro5/addons/acodec/modaudio.c:213
#5  0x00007ffff78d625c in _al_load_it_audio_stream (filename=<optimized out>,
    buffer_count=3, samples=2048)
    at /home/simon/c/notown/allegro5/addons/acodec/modaudio.c:391

For reference, here's an excerpt from cmake's error log when DUMB's libraries don't specify -lm:

Run Build Command:"/usr/bin/make" "cmTC_5d751/fast"
/usr/bin/make -f CMakeFiles/cmTC_5d751.dir/build.make CMakeFiles/cmTC_5d751.dir/build
make[1]: Entering directory '/home/simon/c/notown/allegro5/simon/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_5d751.dir/src.c.o
/usr/bin/cc   -msse -W -Wall -Wpointer-arith -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes -DDUMB_COMPILES   -o CMakeFiles/cmTC_5d751.dir/src.c.o   -c /home/simon/c/notown/allegro5/simon/CMakeFiles/CMakeTmp/src.c
Linking C executable cmTC_5d751
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_5d751.dir/link.txt --verbose=1
/usr/bin/cc  -msse -W -Wall -Wpointer-arith -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes -DDUMB_COMPILES    -rdynamic CMakeFiles/cmTC_5d751.dir/src.c.o  -o cmTC_5d751 /usr/lib/libdumb.so 
/usr/lib/libdumb.so: undefined reference to `__pow_finite'
/usr/lib/libdumb.so: undefined reference to `__log_finite'
/usr/lib/libdumb.so: undefined reference to `__exp_finite'
/usr/lib/libdumb.so: undefined reference to `sin'
/usr/lib/libdumb.so: undefined reference to `__log2_finite'
/usr/lib/libdumb.so: undefined reference to `cos'
collect2: error: ld returned 1 exit status
make[1]: *** [CMakeFiles/cmTC_5d751.dir/build.make:99: cmTC_5d751] Error 1
make[1]: Leaving directory '/home/simon/c/notown/allegro5/simon/CMakeFiles/CMakeTmp'
make: *** [Makefile:126: cmTC_5d751/fast] Error 2

Source file was:

            #include <dumb.h>
            int main(void)
            {
                dumb_register_stdfiles();
                return 0;
            }

al_get_text_dimensions is supposed to return the text bounding box, but currently only the width is correct (for the height it returns the font line height instead of a tight bounding box). This fixes it so that bbh is the exact height of the bounding box and bby is the offset from the top.

This seems to be a very device specific problem, looking for leads on what's causing it. Whenever the page bitmap is re-locked, the first glyph drawn shows up blank on Samsung S6. I know this because I tried calling al_get_text_width on the entire translation and only the first character on a new row other than the first row is blank, which is how the locking works. I tried different sized fonts which results in different first characters on rows and those characters are also blank. When not calling al_get_text_width like this, many more characters are blank which I assume must be the first characters in each lock (but I don't have a good way to test this as I don't have the device in my possession.) This problem doesn't affect all Androids, right now the only one I know of is the S6. Potential suspects: ttf addon, OpenGL ES locking code, ???.

Attached the output from debug_cache in TTF addon using the same font size as used on S6. The first characters in the second, third and fourth rows are blank (O, 2, 0) on S6. (background has been coloured black so you can see the glyphs on the white webpage background...)

In Windows 7/8, you can pin application shortcuts to the taskbar. If you run an Allegro 5 app from such a pinned taskbar icon, there is a chance that al_install_audio returns 0. The same app would run with sound when you doubleclick the executable in file browser.

My Windows testers can reproduce with Allegro 5.2.3.1 binary releases in Lix (my own game with Allegro 5). Lix is too big an example, and I still have to get their feedback on a short, self-contained example program.

Still, I'm starting to believe this is an Allegro issue, not an issue in my game, because other Allegro 5 users ran into the same problem:

• A.cc thread from 2016: al_install_audio fails when started from quick launch bar
• Recent feedback from my Lix players. They crash because I blissfully called further A5 audio even after logging that al_install_audio() == 0. The crash is a bug in Lix, I should handle the failure better. But the al_install_audio() == 0 in the first place is this reported issue.

I'll try to get more info from my testers with a small example program and Allegro debugging libraries.

Using the tutorial here, Allegro seems to be unable to play tracker modules. I've tried installing dumb and using -ldumb, but while it compiles without errors, it can't load the audio sample.

The new Android SDK deprecates the 'android' command and the SDK manager, moving everything to Android Studio. This makes the final 'make' compile fail with the following error:

Scanning dependencies of target jar
[  8%] Generating allegro_activity/AndroidManifest.xml, allegro_activity/build.xml
[  8%] Generating allegro_activity/local.properties
*************************************************************************
The "android" command is deprecated.
For manual SDK, AVD, and project management, please use Android Studio.
For command-line tools, use tools/bin/sdkmanager and tools/bin/avdmanager
*************************************************************************
Invalid or unsupported command "update project -p . -t android-12"

Supported commands are:
android list target
android list avd
android list device
android create avd
android move avd
android delete avd
android list sdk
android update sdk
make[2]: *** [android/CMakeFiles/jar.dir/build.make:75: android/allegro_activity/local.properties] Error 2
make[1]: *** [CMakeFiles/Makefile2:649: android/CMakeFiles/jar.dir/all] Error 2
make: *** [Makefile:128: all] Error 2

see the osx implementation

on windows the "heading" looks like this (heading is "I AM ERROR" text):

maybe can just add to start of setInformativeText the heading text + a newline (if present)?

Whenever an Android app powered by Allegro 5.2.8 returns from background mode, receives an ALLEGRO_EVENT_DISPLAY_RESUME_DRAWING and calls al_acknowledge_drawing_resume, it crashes. Allegro 5.2.7 works fine. I compiled both versions from the sources (arm64-v8a). I see the problem in ex_android and in other examples.

After investigating the issue, I found that it's already solved by SiegeLord with a change made in October. I think that the crash was related to this commit. Once you apply this patch, the problem vanishes.

I could not find any information about this crash, so I just opened this issue in case anyone else struggles with Allegro 5.2.8 on Android. :+1:

backtrace

12-09 22:35:52.238 24474 24474 F DEBUG   : backtrace:
12-09 22:35:52.238 24474 24474 F DEBUG   :     #00 pc 000000000005c378  /data/app/org.liballeg.ex_android-FSYOpTnS2qvoKzgGIT-L9A==/lib/arm64/liballegro.so (_al_create_default_shader+16)
12-09 22:35:52.238 24474 24474 F DEBUG   :     #01 pc 00000000000969c8  /data/app/org.liballeg.ex_android-FSYOpTnS2qvoKzgGIT-L9A==/lib/arm64/liballegro.so (android_acknowledge_drawing_resume+164)
12-09 22:35:52.238 24474 24474 F DEBUG   :     #02 pc 0000000000001e2c  /data/app/org.liballeg.ex_android-FSYOpTnS2qvoKzgGIT-L9A==/lib/arm64/libnative-lib.so (main+1652)
12-09 22:35:52.238 24474 24474 F DEBUG   :     #03 pc 000000000009a210  /data/app/org.liballeg.ex_android-FSYOpTnS2qvoKzgGIT-L9A==/lib/arm64/liballegro.so (android_app_trampoline+216)
12-09 22:35:52.238 24474 24474 F DEBUG   :     #04 pc 000000000005ce20  /data/app/org.liballeg.ex_android-FSYOpTnS2qvoKzgGIT-L9A==/lib/arm64/liballegro.so (thread_func_trampoline+152)
12-09 22:35:52.238 24474 24474 F DEBUG   :     #05 pc 000000000009265c  /data/app/org.liballeg.ex_android-FSYOpTnS2qvoKzgGIT-L9A==/lib/arm64/liballegro.so (thread_proc_trampoline+28)
12-09 22:35:52.238 24474 24474 F DEBUG   :     #06 pc 0000000000081b70  /system/lib64/libc.so (__pthread_start(void*)+36)
12-09 22:35:52.238 24474 24474 F DEBUG   :     #07 pc 00000000000235f8  /system/lib64/libc.so (__start_thread+68)

I thought of doing this edit when I tried passing pointers to const-qualified Allegro objects, but the function signature didn't allow for that.

This is a first step towards propagating as many const-qualifiers to the API level as appropriate.

I've got a few general questions regarding the drawing functions.

Is there a reason some of the bitmap region drawing functions are omitted? All of them are implemented in terms of the same function anyway so the only reason I can think of to omit them would be percieved bloat, but its not really that many extra functions and helps makes things more clear in my opinion.

The only exception I can see is the scaled bitmap drawing, where for some reason the base function has the behavior matching the other region drawing functions. Why's that like that anyway? It makes for a weird inconsistency.

Lastly, what would the attitude here be towards implementing elliptical pieslice drawing functions? All of the other circular functions have elliptical variants so it'd also be more consistent.

I'm partly asking this because I maintain these changes in a personal patch, so I could push them back to here if people think it's a good idea (besides changing scaled bitmap drawing because it'd break API). I'd love to hear your thoughts before i make a PR for anything.

If the mouse cursor is hidden when the user goes into the window title bar, the cursor is made visible. It is set to be re-hidden when the cursor goes back into the window client area. This behavior is from https://github.com/liballeg/allegro5/blob/master/src/win/wwindow.c (see all the usages of we_hid_the_mouse).

This presents a problem when the cursor should be made visible because of an action the application performs on ALLEGRO_EVENT_DISPLAY_CLOSE. This mouse state internal to wwindow.c has no idea the application has changed that the cursor should now be visible, so when the mouse re-enters the window client area it is incorrectly hidden.

I've provided an example program.

This program has been adapted from an allegro example. You can just copy over ex_mouse_cursor.cpp and build that target.

Include is some commented out code that provides a partial workaround. The cursor can still act funny when on the very edge of the display as it re-enters, but it at least is not hidden when it should be shown.

#include <allegro5/allegro.h>
#include <allegro5/allegro_font.h>
#include "allegro5/allegro_image.h"

#include "common.c"


#define MARGIN_LEFT  20
#define MARGIN_TOP   20

bool state = false;

ALLEGRO_DISPLAY *display;
ALLEGRO_FONT *font;

static void draw_display()
{
   int th;

   if (state)
      al_hide_mouse_cursor(display);
   else
      al_show_mouse_cursor(display);

   if (state)
      al_clear_to_color(al_map_rgb(255,114,118));
   else
      al_clear_to_color(al_map_rgb(128, 128, 128));

   al_set_blender(ALLEGRO_ADD, ALLEGRO_ONE, ALLEGRO_INVERSE_ALPHA);
   th = al_get_font_line_height(font);

   al_draw_text(font, al_map_rgba_f(0, 0, 0, 1),
      MARGIN_LEFT, MARGIN_TOP + 5 * th, 0,
      "Press S/H to show/hide cursor. Q to quit.");
   
   al_draw_text(font, al_map_rgba_f(0, 0, 0, 1),
      MARGIN_LEFT, MARGIN_TOP + 7 * th, 0,
      "For bug, try close win w/ cursor.");   
   al_draw_text(font, al_map_rgba_f(0, 0, 0, 1),
      MARGIN_LEFT, MARGIN_TOP + 8 * th, 0,
      " visible and move mouse down.");
   
   al_draw_text(font, al_map_rgba_f(0, 0, 0, 1),
      MARGIN_LEFT, MARGIN_TOP + 10 * th, 0,
      state ? "HIDDEN" : "VISIBLE");

   al_flip_display();
}

static void set_state(bool s)
{
   state = s;
   draw_display();
}

int main(int argc, char **argv)
{
   ALLEGRO_BITMAP *bmp;
   ALLEGRO_BITMAP *shrunk_bmp;
   ALLEGRO_MOUSE_CURSOR *custom_cursor;
   ALLEGRO_EVENT_QUEUE *queue;
   ALLEGRO_EVENT event;

   (void)argc;
   (void)argv;

   if (!al_init()) {
      abort_example("Could not init Allegro.\n");
   }

   al_init_image_addon();
   init_platform_specific();

   if (!al_install_mouse()) {
      abort_example("Error installing mouse\n");
   }

   if (!al_install_keyboard()) {
      abort_example("Error installing keyboard\n");
   }

   al_set_new_display_flags(ALLEGRO_GENERATE_EXPOSE_EVENTS);
   display = al_create_display(400, 400);
   if (!display) {
      abort_example("Error creating display\n");
   }

   bmp = al_load_bitmap("data/allegro.pcx");
   if (!bmp) {
      abort_example("Error loading data/allegro.pcx\n");
   }

   font = al_load_bitmap_font("data/fixed_font.tga");
   if (!font) {
      abort_example("Error loading data/fixed_font.tga\n");
   }

   shrunk_bmp = al_create_bitmap(32, 32);
   if (!shrunk_bmp) {
      abort_example("Error creating shrunk_bmp\n");
   }

   al_set_target_bitmap(shrunk_bmp);
   al_draw_scaled_bitmap(bmp,
      0, 0, al_get_bitmap_width(bmp), al_get_bitmap_height(bmp),
      0, 0, 32, 32,
      0);

   custom_cursor = al_create_mouse_cursor(shrunk_bmp, 0, 0);
   if (!custom_cursor) {
      abort_example("Error creating mouse cursor\n");
   }

   al_set_target_bitmap(NULL);
   al_destroy_bitmap(shrunk_bmp);
   al_destroy_bitmap(bmp);
   shrunk_bmp = NULL;
   bmp = NULL;

   queue = al_create_event_queue();
   if (!queue) {
      abort_example("Error creating event queue\n");
   }

   al_register_event_source(queue, al_get_keyboard_event_source());
   al_register_event_source(queue, al_get_mouse_event_source());
   al_register_event_source(queue, al_get_display_event_source(display));

   al_set_target_backbuffer(display);
   draw_display(font);

   while (1) {
      al_wait_for_event(queue, &event);
      if (event.type == ALLEGRO_EVENT_DISPLAY_CLOSE) {
         set_state(!state);
         continue;
      }
      if (event.type == ALLEGRO_EVENT_DISPLAY_EXPOSE) {
         al_set_target_backbuffer(event.display.source);
         draw_display(font);
         continue;
      }
      // Uncomment for partial bug workaround.
      // if (event.type == ALLEGRO_EVENT_MOUSE_ENTER_DISPLAY)
      // {
      //    if (state)
      //       al_hide_mouse_cursor(event.mouse.display);
      //    else
      //       al_show_mouse_cursor(event.mouse.display);
      // }
      if (event.type == ALLEGRO_EVENT_KEY_CHAR) {
         switch (event.keyboard.unichar) {
            case 27: /* escape */
               goto Quit;
            case 'h':
               set_state(true);
               break;
            case 's':
               set_state(false);
               break;
            case 'q':
               goto Quit;
            default:
               break;
         }
      }
      if (event.type == ALLEGRO_EVENT_MOUSE_AXES) {
         static bool done = false;
         if (!done)
         {
            al_set_mouse_cursor(event.mouse.display, custom_cursor);
            done = true;
         }
      }
   }

Quit:

   al_destroy_mouse_cursor(custom_cursor);

   return 0;
}