{"name":"612915","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/e\/7efe48fa468c9db7964883c9c392687b.jpg","w":640,"h":400,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/e\/7efe48fa468c9db7964883c9c392687b"}

Coming through! We've got another Allegro release! One notable feature of this release is that Elias got Allegro working semi-well with Emscripten (via the SDL backend), and adjusted our website to have some runnable examples: https://liballeg.org/examples_demos.html

Amazing.

You can find the source tarballs and MinGW binaries here (dependencies MinGW binaries are here here). Nuget packages are available here . Ubuntu and OSX packages aren't ready yet, but will be made soon.

Here's the changelog:

Changes from 5.2.6 to 5.2.7 (March 2021)

The main developers this time were: SiegeLord, Peter Hull, Elias Pschernig, Aldrik Ramaekers, Andreas Rönnquist.

Build system

• Allow generating projects with a suffix (lorry-lee).

  
  

• Fix build under Clang-CL in Visual Studio.

Core

• Avoid some undefined behavior errors.

  
  

• Return key modifiers in ALLEGRO_EVENT_KEY_UP and ALLEGRO_EVENT_KEY_DOWN.

  
  

• Allow calling al_map_* color functions before Allegro is initialized.

  
  

• Allow minimum bitmap size to be something other than 16 on non-Android platforms (controlled via allegro5.cfg).

  
  

• Add al_get_monitor_refresh_rate (only implemented on Windows for now).

Graphics

• Fix ALLEGRO_KEEP_INDEX flag for bitmaps.

  
  

• Add ALLEGRO_OPENGL_CORE_PROFILE display flag.

Emscripten

• The experimental Emscripten support (via the SDL backend) is now documented in README_sdl.txt.

OSX

• Move more Cocoa operations to the main thread.

  
  

• Explicitly link CoreVideo to fix the static build.

Windows

• Issue #1125: Speed up OpenGL extension detection (Tobias Scheuer).

  
  

• Use Unicode APIs when enumerating joysticks.

  
  

• Use WM_DEVICECHANGE rather than polling to detect joystick hotlugging, reducing input drops and lags (Todd Cope).

  
  

• Fix joystick polling period.

  
  

• Restore WinXP compatibility by using slightly older API when loading shared libraries (Julian Smythe).

  
  

• Fix build with HLSL disabled (Julian Smythe).

  
  

• Raise DirectInput MAX_JOYSTICKS to 32 and DEVICE_BUFFER_SIZE to 128.

SDL

• Issue #1224: Fix bug in SDL voice driver.

Audio addon

• Allows playing sounds in reverse by specifying a negative speed.

Acodec addon

• Fix edge-case looping in Ogg Vorbis stream (Cody Licorish)

Audio addon

• Use more sensible values for PulseAudio's playback buffer, potentially
  resolving some crashes and high CPU usage.

Native Dialog Addon

• Migrate from GTK2 to GTK3. Sadly, we lose menu icons as GTK3 dropped support for them.

TTF addon

• Allow initializing TTF addon before the Font addon.

  
  

• Shut-down the TTF addon automatically in al_uninstall_system.

PhysFS addon

• Fix handling of native path separators.

  
  

• Stop using deprecated PhysFS API.

Primitives addon

• Fix segfault in al_draw_ribbon when num_segments > 128 (Rodolfo Borges).

  
  

• Issue 1215: Correctly handle small scales when determining subdivision level
  for high level primitives (Robin Heydon).

Documentation

• Fix LaTeX errors in the generation of the reference manual PDF.

  
  

• Add links to examples into the reference manual.

  
  

• Allow pressing 'S' to focus the search bar in the docs.

  
  

• Assorted documentation improvements.

Misc

• Add a security policy and an associated private security mailing list - allegro-security@lists.liballeg.org.

  
  

• Add Emscripten-powered examples to https://liballeg.org/examples_demos.html.

Examples

• `ex_audio_simple` now displays instructions and supports bidirectional looping.

  
  

• Add default files to some audio examples.

SHA256SUMS

7b2a778f62e990e6f2a9135a7580d9cf679a452c72cb5a5139e6f8a54fd35152  allegro-5.2.7.0.7z
c1e3b319d99cb453b39d393572ba2b9f3de42a96de424aee7d4a1abceaaa970c  allegro-5.2.7.0.tar.gz
a9ce3dfa7612d607b6c51e45f6ead9b53b2b8e922ce7308feb6bc9a0fbab5800  allegro-5.2.7.0.zip
2d291fd8217bbe0fcb3efff4891318e43ab8c227fafb378b3c205a37225d6f3c  Allegro.5.2.7.nupkg
23c7aeb5ab9732a170160ee02dcf87a801600af7e6fd7bdf1423d0b8cac4999a  AllegroDeps.1.12.0.nupkg
2604d91e91bf0001d72967aad864e0e614e43a517f0f03688ab572b398eab38c  allegro_deps-i686-w64-mingw32-gcc-10.2.0-posix-dwarf-1.12.0.zip
eaca487c68a06c2f709cef93eb958cc3d2a8a0402757b290f4b56ddfd63eecfc  allegro_deps-x86_64-w64-mingw32-gcc-10.2.0-posix-seh-1.12.0.zip
7b5342fc998056f65b20b59a96596b5fa9414765099b022557d837321fead25f  allegro-i686-w64-mingw32-gcc-10.2.0-posix-dwarf-dynamic-5.2.7.0.zip
4b286c647c38d1799a01e875376e1040ff8c41d98bc3bf1f574a07024be2da53  allegro-i686-w64-mingw32-gcc-10.2.0-posix-dwarf-static-5.2.7.0.zip
8a92fbec3685be78f63d22b45b9c6aa5854a897c637557c6acf9f2533224904e  allegro-x86_64-w64-mingw32-gcc-10.2.0-posix-seh-dynamic-5.2.7.0.zip
9da78e1bb0417235f20575b0ce83df24fffc306ab82b4f082f434de4456733ef  allegro-x86_64-w64-mingw32-gcc-10.2.0-posix-seh-static-5.2.7.0.zip

Thanks!

Yay! Thanks for all the hard work.

Heck yea, I love new allegro releases.

{"name":"612917","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/c\/1\/c17082db7d561538459736500cbfbda2.gif","w":307,"h":329,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/c\/1\/c17082db7d561538459736500cbfbda2"}

Wow. Game changer. Elias, bringin' the heat!! 🔥🔥🔥.

I've got to get on this. That's amazing.

edit: added a follow-up on this to the issue here.

Woo! I have workarounds for this so can fix.

I submitted a news item to allegro.cc so we'll be on the front page for a while after Matthew approves it.

Allegro+Emscriptem: Incredible. I'm testing but on my Linux the display is not coming. Will test on my Windows partition tomorrow.

Edit: Only Skater isn't working, Cosmic Protector is working fine !!

I am quite happy that we got Clang support in the Nuget package! I got a couple new delicious compiler error messages to fix that neither GCC nor VC managed to detect.
Thank you!

That Emscriptem work is impressive! The SPEED example doesn't have a 'try' link, is that an oversight or is there a reason for that? I can't wait to play SPEED on the web...

Examples/demos without the 'Try' button are just known not to work well with Emscripten (e.g. their main loops don't fit a somewhat restricted pattern, they use shaders etc). We can and probably will fix them at some point, Emscripten is relatively easy to develop for.

Speed would be easy to fix but it's probably better if we fix the underlying SDL2/emscripten issues which make it not work currently

Basically we use emscripten with no threads at all, instead of using threads the web browser has a set of timers and periodically calls into javascript. To make this work with Allegro there's a workaround where al_wait_for_event() just returns control to the web browser instead of actually waiting and then whenever the browser calls back it collects events and if any are found continues with the application.

Now if an application ever has a loop which doesn't use al_wait_for_event() (like speed which is a line-by-line translation of A4 code) - that doesn't quite work

It would not be too hard to fix this, however emscripten actually does have threads, just as of a few weeks ago their bundled SDL2 did not support them yet. Once that is fixed upstream everything will just work on our side without extra work

In case anyone is interested, I'm attaching an ancient and somewhat janky patch that I made ~10 years ago for the native dialogs addon. I apply this patch every time I build a new version of Allegro.

Without this patch, al_show_native_message_box running on Windows cannot make dialog boxes with custom button names. With the patch, it can - but they look bad. Message boxes without custom button names are unchanged.

The reason the custom button dialogs look bad is that my implementation uses the 'system' font rather than the usual message box font. And the reason for using the system font is that I don't really know anything about the win32 api, and I was just trying to make something that worked! At the time I was writing the patch, this was the best I could come up with. (It is certainly possible to get the right font with some more code; but it isn't totally straight forward.)

In any case, feel free to use it, or not use it. I personally use it for showing debug messages, and nothing else; so I don't really care what it looks like anyway.

Example:
{"name":"612920","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/d\/b\/db80c1a390dcaee7c49c5b903034d487.png","w":462,"h":187,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/d\/b\/db80c1a390dcaee7c49c5b903034d487"}

I made a Pull Request for some code to fix a DX window flickering upon creation when MSAA is enabled. It works for FULLSCREEN_WINDOW and WINDOWED modes on my NVIDIA, but not on my integrated Intel for some reason. It also doesn't work in true fullscreen modes, so I'm requesting help with the issue if anyone has the time to look at it. This has been a longstanding bug that still hasn't been resolved.

The pull request is here (with comments) :
https://github.com/liballeg/allegro5/pull/1228

When compiling a new game with freshly built allegro 5.2.7.0 on linux, I got:

src/text2.cpp:4:10: fatal error: allegro5/allegro_native_dialog.h: No such file or directory
    4 | #include <allegro5/allegro_native_dialog.h>

allegro_native_dialog.h is in the allegro sources, but for some reason it wasn't copied to /usr/local/include/allegro5. Could you think of any reason why it wouldn't be copied? Perhaps a new dependency on linux?

I have a second question:

I scanned the cmake output for warnings. I added libopus, libwebp and libfreeimage. There is also a complaint about minimp3. I presume that refers to this: https://github.com/lieff/minimp3, but it's surprisingly hard to find any further documentation with google. Any chance there are any pre-built debian packages for this?

I doubt this is related to the native dialog problem though.

On Linux, the native dialog addon depends on GTK3 now. It won't be included if that is not installed when compiling Allegro 5.

Good to know. I did apt get libgtk-3-dev and things are working again.

What would be the proper place to document this? The README.txt just has this paragraph:

Linux users likely have all the dependencies already, except PhysicsFS
and DUMB. If your distribution uses separate development packages, they
will need to be installed.  The packages are probably named *-dev or *-devel.

Which didn't help me a lot in this case.

In hindsight, there was a warning in the cmake output:

-- Could NOT find MiniMP3 (missing: MINIMP3_INCLUDE_DIRS) 
WARNING: minimp3 was not found
-- Found Freetype: /usr/lib/x86_64-linux-gnu/libfreetype.so (found version "2.10.1") 
-- Performing Test TTF_COMPILES
-- Performing Test TTF_COMPILES - Success
-- Found PhysFS: /usr/lib/x86_64-linux-gnu/libphysfs.so  
-- Found PHYSFS: /usr/lib/x86_64-linux-gnu/libphysfs.so  
-- Performing Test PHYSFS_IMPLICIT_ZLIB
-- Performing Test PHYSFS_IMPLICIT_ZLIB - Success
-- Checking for module 'gtk+-3.0'
--   No package 'gtk+-3.0' found
-- Checking for module 'gthread-2.0'
--   Found gthread-2.0, version 2.64.6
-- Found THEORA: /usr/include

But I missed it, it doesn't stand out as much as the other warnings (like the one for minimp3 for example). It would be nice if the warnings were more consistent.

I may make binaries again, but I think bitbucket upload is broken atm or maybe forever

Please do if you can. I don't depend on them, but I think many first-time users do.

By the way, I've also updated the dockerized allegro build environment to 5.2.7

I'm kind of waiting until the pull request gets considered

They could use the official binaries too...

The flicker one? It says it's not ready, no? It's not clear what the status of it is.

I need help on that one. My approach works for windowed modes, but not fullscreen ones, and I don't know how to fix it. I was hoping someone would have some helpful comments for me as to how to keep working on it.

Ah, okay, I'll try to take a look soon then.

It's total BS of course, because DX9 is insane and so is whoever designed win32 and their Tech Center.

Relevant link :
https://docs.microsoft.com/en-us/windows/win32/direct3d9/full-scene-antialiasing

fook me they had to do fullscreen different than windowed

UPDATE
Trying something for fullscreen now after I RTFM

EDIT2
Stuck again. Tried something, didn't work. Also, allegro is destroying and recreating display internals every time it tries a new mode that doesn't work.

I wrote some code a while ago to list all audio devices for the alsa, sdl, dsound and pulseaudio backend https://github.com/aldrikboy/allegro5/tree/list_audio_devices. Is anyone interested in implementing the other backends (openal, kcm, aqueue, oss)? This would allow for features like audio device selection to be implemented.

That seems like a very useful feature. Perhaps for the other backends a dummy implementation would suffice for now? I.e. return an empty list or return an error code?

I don't like the idea of delaying a good feature just because it doesn't work on some more exotic backends.

Yes, that's a good feature.

I made an amendment to my pull request in an attempt to enable full scene (fullscreen) antialiasing but to no avail.

FYI Aldrik's already done it, just waiting for review & merge.
https://github.com/liballeg/allegro5/pull/1238

I think I've found a bug, since ex_threads doesn't work on my system (Xubuntu 20.04.2, I've just realized I should update it). It just creates a bunch of small windows and then exits with a "segment violation (`core' generated)". ex_threads2 seems to work.

I have no idea how to debug threads so I can't be for much more help. BTW, since Allegro.pas version of ex_threads2 doesn't work outside GDB (but it does inside GDB ) may be it is something similar to this old bug in Allegro 4 (just speculating).

ex_threads doesn't work with DX on Windows. It creates a bunch of threads and starts them all and they all create a window, and the window creation code isn't thread safe so it segfaults.

SiegeLord - could you look at the attached allegro.log and tell me what you see? I see a whole ton of "d3d_create_fullscreen_device: Mode not supported." messages. Why is allegro trying to create an unsupported mode? Can't the display modes be sorted or filtered somehow?

EDIT
I should say, they originate in d3d_check_mode called from d3d_create_fullscreen_device called by d3d_display_thread_proc called by create_display_internals, which loops over the modes checking each one.

Is that the log from ex_threads?

I don't know but d3d_check_mode looks a bit strange - if EnumAdaptorModes fails the whole function returns false (line 402), I would have though it should skip that mode and continue the enumeration?
https://github.com/liballeg/allegro5/blob/4aa54e6c994af21bc63d8b593673ab3df62390f8/src/win/d3d_disp.cpp#L389-L410

SiegeLord - that's the log from my MSAA test program.

Try the patch from here https://github.com/liballeg/allegro5/pull/1228#issuecomment-826285289

Would it be possible (in the next build) to update the HLSL to something higher than v2?

Or even make it possible to choose which HLSL version to use? v2 is really limiting on the number of instructions that can be used.

I've done some updates and, on my Xubuntu 20.04LTS ex_threads doesn't work (freezes the computer) but ex_threads2 seems to work.

@SiegeLord - sorry for the slow reply

So, your patch works for my Nvidia GPU, but not the onboard intel.

Which means, all the multisample requirements are being met, for fullscreen, fs window, and windowed mode, but ONLY with my Nvidia.

You mean, in the logs, it tries the first mode and succeeds? What happens with the Intel, it still tries many modes before it fails?

It's great to see Allegro is constantly developing. I think I have a question or two though. I heard previous versions did not work well with Windows using C code. Has that been addressed or is that a major version issue? Also, has it been released on Fedora?

That's still an issue. To be clear, you can write your entire program in C, but you need to link in the C++ runtime, since Allegro uses some C++ internally. If this can be fixed, it won't require a major version.

No idea.

On Fedora, dnf will install 5.2.4. I don't know who (if anybody) is in charge of updating that.

SiegeLord - to be clear, it may be succeeding, but if allegro doesn't report the number of samples to be other than zero, it turns red. That's the only way I know if its ms.

What exactly is affected by msaa? Primitives? Triangles? Fonts? Bitmaps?

If you look at the logs on your Intel system, do lines like this:

display  D E:\usr\libs\Allegro52X\src\display_settings.c:212  debug_display_settings           [   0.51161] color: 32 (rgba 8880), depth: 0, stencil: 0, acc: 0000, samples: 0/0

Have the samples line be anything other than 0/0?

It affects everything with polygon edges that aren't aligned to pixels.

SiegeLord, in every case with the Intel, they all report the format as supporting 0/0 samples, all 64 of them for fs.

UPDATE
Yeah, the Intel reports everything as 0/0 samples. This laptop is from 2015, it's Windows 10, and the integrated chipset is Intel HD 5600 .

And by the way,

does anyone know what it takes to build MinGW-W64 with GCC 10 support? I despise MSYS2 and I want to build distributable binaries for MinGW-W64 since the package manager fell off the planet.

Why do you despise msys2 ?

Because it tries to be like Linux on Windows but it sucks.

Bump.

This thread shall live on.

Will there be a 5.2.7.1 release to address some of the problems?

No. Point releases are pretty much just for newly broken releases (like it doesn't build or something) or regressions; these issues have been there for over a decade, they're not worth releasing over.

I do want to release 5.2.8 earlier than next year though...

I think it's worth it this time. MSAA and no window flickering? Some people are still using custom builds and need binaries that are fixed. I'll probably do it sometime soon. Pissed that mingw-w64 binaries are still stuck on GCC 8.1 and I don't know how to build MinGW-W64 with GCC 10 or I would build binaries for that too.

EDIT The log deadlock sucks too.

And yet msys 2 is having gcc version 10.3.0 ;-p

i had problems with minGW too

something related to the symbol _moddiv4 is missing in mingw library available only w64-mingw

now i'm using MinGW bundled with Qt Creator, works fine and my previous mingw i686 DWARF
installation didn't go well with Allegro 5.2.7

this problem can be fixed if you build allegro by yourself
but doing it on windows sucks

I put together a compile guide for A5 on Windows with MinGW-W64. Read it here :

http://members.allegro.cc/EdgarReynaldo/BuildA5.html

The link is in my sig too.