al_save_bitmap with DDS outputs nothing

[katastic]

trafficstars

DDS doesn't appear to output any file at all (on Linux) even though the documentation says PCX, BMP, TGA and DDS are always supported.

https://liballeg.org/a5docs/5.2.2/image.html

The following types are built into the Allegro image addon and guaranteed to be available: BMP, DDS, PCX, TGA. Every platform also supports JPEG and PNG via external dependencies.

Using Linux, and DAllegro.

Perhaps DDS is only supported for loading and there's an empty save routine?

No error or segfault is produced when attempting to output to DDS

[pedro-w]

You're right, DDS save has not (ever) been implemented, so the docs are wrong.

However, al_save_bitmap should return false if it fails, per the docs. Additionally there should be an entry in the log if you have logging enabled. https://github.com/liballeg/allegro5/blob/20ea4d7bdd9e9999a9d89278dc06dc453fa3f0a6/src/bitmap_io.c#L234-L240

Is it not working like this for you?

[katastic]

Ah, I was expecting an assert for calling a missing piece of code, not a silent return. Fair enough. The docs make no mention of ALLEGRO_ERROR.

Allegro also apparently doesn't dump to Allegro.log if its is compiled in release mode? What was the rational there? No logging of critical errors... just because it's release mode? How could a few save_bitmap errors, for example, affect performance? Certainly tens-of-thousand-call functions like al_put_pixel aren't dumping to allegro.log is it? Also searching google for ALLEGRO_ERROR or allegro.log on the A.CC man page comes up with nothing.

site:https://www.allegro.cc/manual/5/ allegro.log site:https://www.allegro.cc/manual/5/ ALLEGRO_ERROR

A search through github for allegro_error uses:

https://github.com/liballeg/allegro5/search?q=allegro_error

shows pretty typical error messages. "Out of memory" for example. Isn't that kind of important even when in release mode, being run on machines other than the dev machine?

[SiegeLord]

Yes, al_save_bitmap should return false if it doesn't already.

We probably should document the logging setup somewhere. It's disabled in release mode... I guess for historical reasons. It's possible to enable it at runtime (even in release mode, unless disabled at compile time) by doing:

al_set_config_value(al_get_system_config(), "trace", "level", "debug");

before al_init.

[katastic]

al_set_config_value(al_get_system_config(), "trace", "level", "debug");

This is helpful, thank you. We should definitely document logging--especially since it's an expected part of development--detailed error messages. Many people (like myself) assume that "debug" means "debug symbols and no optimization (plus asserts)" not "doesn't output any error messages at all."

And I realize DDS saving is probably a super rare scenario (and I don't even need it) but it is apart of the API so it should be documented that it's "load only".

Also, one more counter-intuitive thing. I never would have thought (unless maybe I saw it in documentation) to modify a config value before al_init because I was under the mistaken (but usually correct) assumption that you never call anything allegro-related before al_init. I also don't see any other values you can set for Allegro listed in the documentation page. I thought those routines were only for writing and reading ini files.

https://liballeg.org/a5docs/5.2.4/config.html

[edit] Okay, so I see once source of log spam for things like locking bitmaps, bitmap destructors, etc. If we just set it to say "WARNING" or "ERROR" would that work?

font     D                ttf.c:243  alloc_glyph_region               [   0.47941] Glyph 66: 13x4 (16x4)
font     D                ttf.c:287  alloc_glyph_region               [   0.47942] Locking glyph region: 0x55a0520184f0 228 20 16 4
opengl   D        ogl_lock_es.c:297  ogl_lock_region_nonbb            [   0.47943] Locking non-backbuffer WRITEONLY
opengl   D        ogl_lock_es.c:628  ogl_unlock_region_nonbb_2        [   0.47945] Unlocking non-backbuffer (non-FBO)
opengl   D        ogl_lock_es.c:637  ogl_unlock_region_nonbb_2        [   0.47945] Unlocking non-backbuffer non-FBO without conversion
font     D                ttf.c:167  unlock_current_page              [   0.47947] Unlocking page: 0x55a0520184f0
font     D                ttf.c:243  alloc_glyph_region               [   0.47950] Glyph 79: 5x16 (8x16)
font     D                ttf.c:287  alloc_glyph_region               [   0.47951] Locking glyph region: 0x55a0520184f0 244 20 8 16
opengl   D        ogl_lock_es.c:297  ogl_lock_region_nonbb            [   0.47951] Locking non-backbuffer WRITEONLY
opengl   D        ogl_lock_es.c:628  ogl_unlock_region_nonbb_2        [   0.47952] Unlocking non-backbuffer (non-FBO)
opengl   D        ogl_lock_es.c:637  ogl_unlock_region_nonbb_2        [   0.47953] Unlocking non-backbuffer non-FBO without conversion
font     D                ttf.c:167  unlock_current_page              [   0.47964] Unlocking page: 0x55a0520184f0
opengl   D        ogl_lock_es.c:499  _al_ogl_unlock_region_gles       [   5.88155] Unlocking READONLY
opengl   D        ogl_lock_es.c:159  ogl_lock_region_bb_readonly      [   5.89717] Converting from format 25 -> 25
opengl   D        ogl_lock_es.c:499  _al_ogl_unlock_region_gles       [   5.89721] Unlocking READONLY
opengl   D        ogl_lock_es.c:159  ogl_lock_region_bb_readonly      [   5.91843] Converting from format 25 -> 25
opengl   D        ogl_lock_es.c:499  _al_ogl_unlock_region_gles       [   5.91849] Unlocking READONLY

Also, do we have any documentation on what dictates a "normal" log, vs bad coding? Are all these unlocking messages indicating I'm accidentally using a memory bitmap, for example.

Thanks, --Chris

[EdgarReynaldo]

Read the example allegro5.cfg file that comes with allegro. It tells you what is what. There is also this : https://github.com/liballeg/allegro_wiki/wiki/Debugging-and-logging-with-A5 . Those D 'debug' warnings are freetype and allegro caching font glyphs. Usually you want to set the trace level to error and let it filter the junk for you.