Depth bug (Allegro 5 + Opengl)

no-reply@allegro.cc (Space cpp) — Sun, 17 Jun 2018 01:29:27 +0000

Hello people.
I made a simple 3D sokoban game combining Allegro and Opengl. It runs fine on Windows, but either on Mac OSX or iOS it produces a wierd rendering bug.
It seens that objects draws last are always over other things as if the depth buffer was not working.
I'm attaching a screenshot to ilustrate the problem (Left is Windows, right is iOS simulator)

no-reply@allegro.cc (Edgar Reynaldo) — Sun, 17 Jun 2018 01:35:02 +0000

You have to enable the depth buffer before it will work.

https://liballeg.org/a5docs/trunk/display.html#al_set_new_display_option

al_set_new_display_option(ALLEGRO_DEPTH_SIZE , 32 , ALLEGRO_SUGGEST);
al_set_new_display_option(ALLEGRO_FLOAT_DEPTH , 1 , ALLEGRO_SUGGEST);

The second is optional, but the first is necessary to enable the depth buffer. You must call these before creating your display.

no-reply@allegro.cc (Space cpp) — Sun, 17 Jun 2018 05:43:20 +0000

This actually worked.. in an older version that does use the fixed pipeline, which is not compatible with iOS.
The current version still produces the bug.

I guess I have to show some code
My initialization routine looks like this:

#SelectExpand
  1if (!al_init() ) { printf("al_init Failed!\n"); return false; }
if (!al_install_mouse() ) { fprintf(stderr, "failed to initialize the mouse!\n"); return false; }
al_init_font_addon(); 
  if (!al_init_ttf_addon() )  { fprintf(stderr, "failed to initialize the ttf addon!\n"); return false; }
if (!al_install_audio() ) { fprintf(stderr, "failed to initialize audio!\n"); return false; }
if (!al_init_acodec_addon() ) { fprintf(stderr, "failed to initialize audio codecs!\n"); return false; }
if (!al_reserve_samples(8) ) { fprintf(stderr, "failed to reserve samples!\n"); return false; }
  if (!al_install_keyboard() ) { fprintf(stderr, "failed to initialize the keyboard!\n"); return false; }  
timer = al_create_timer(1.0 / FPS); if (!timer) { fprintf(stderr, "failed to create timer!\n"); return false; }
  if (!al_init_image_addon() ) { al_show_native_message_box(display, "Error", "Error", "Failed to initialize al_init_image_addon!", NULL, ALLEGRO_MESSAGEBOX_ERROR); return false; }
  if (!al_init_primitives_addon() ) { printf("al_init_primitives_addon Failed!\n"); return false; }
if (!al_install_touch_input() ) { printf("Could not init touch input.\n"); return false; }
  


if (!use_vsync)
  al_set_new_display_option(ALLEGRO_VSYNC, 2, ALLEGRO_REQUIRE); // force off vsync to avoid high cpu usage

  al_set_new_display_flags(ALLEGRO_OPENGL | ALLEGRO_OPENGL_ES_PROFILE | ALLEGRO_PROGRAMMABLE_PIPELINE);
  
  al_set_new_display_option(ALLEGRO_DEPTH_SIZE, 32, ALLEGRO_SUGGEST);
  al_set_new_display_option(ALLEGRO_FLOAT_DEPTH, 1, ALLEGRO_SUGGEST);
  
  
display = al_create_display(800, 600);
if (!display) 
{ 
  al_show_native_message_box(display, "Error", "", "al_create_display Failed!", NULL, ALLEGRO_MESSAGEBOX_ERROR); 
  return false; 
}

At the beginning of the draw routine:

#SelectExpand
 1glViewport(0, 0, al_get_display_width(display), al_get_display_height(display));

  glClearColor(0.5f, 0.5f, 0.5f, 1.0f);
  glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
  glEnable(GL_DEPTH_TEST);
  glEnable(GL_CULL_FACE);

For every object to be drawn I store the vertices on a std::vector then use glVertexAttribPointer, glEnableVertexAttribArray and glDrawArrays.

no-reply@allegro.cc (Edgar Reynaldo) — Sun, 17 Jun 2018 07:46:29 +0000

Well, since you know how to set the new display options, you should know how to get them after they've been set to see what they are.

https://liballeg.org/a5docs/trunk/display.html#al_get_display_option

See what they return for ALLEGRO_DEPTH_SIZE and ALLEGRO_FLOAT_DEPTH.

no-reply@allegro.cc (Space cpp) — Mon, 18 Jun 2018 03:42:10 +0000

On iOS simulator it returns 0 and 0.
On Windows 24 and 0.

Edit:
Just tested on my iPad and the results are exactly the same, so it's not a simulator issue.

no-reply@allegro.cc (Edgar Reynaldo) — Tue, 19 Jun 2018 00:25:30 +0000

Well, then that means the depth buffer is either not available, or didn't score well in allegro's display testing phase.

Run a debug build and check allegro.log. There will be a 'depth' entry for every display configuration scored. See if there are even any available.

You can also set ALLEGRO_DEPTH_SIZE to ALLEGRO_REQUIRE and test several values. If the driver comes back null, it's just not available.

no-reply@allegro.cc (Space cpp) — Tue, 19 Jun 2018 04:11:57 +0000

By debug build you mean I have to recompile the allegro static library with some different configuration?

Now that I thought about it just saw the following on README_iphone.txt:

"Can use either OpenGL ES 1 or 2 for graphics, by default OpenGL ES 1 is
used."
I was wondering a while ago why glGetString(GL_SHADING_LANGUAGE_VERSION) always gives me "OpenGL ES GLSL ES 1.00".

I`m guessing the problem is not the code but how the library file was compiled.
How do I set up these options?

Before I forget: using ALLEGRO_REQUIRE does not seen to be doing any difference, the display is still created, with depth size 0.

no-reply@allegro.cc (Edgar Reynaldo) — Tue, 19 Jun 2018 12:26:59 +0000

Space cpp said:

By debug build you mean I have to recompile the allegro static library with some different configuration?

Generally, yes. But you can enable the allegro.log in release mode as well. (Don't ask me how I can never remember)...

Space cpp said:

"Can use either OpenGL ES 1 or 2 for graphics, by default OpenGL ES 1 is
used."

The manual for al_set_new_display_flags says this :

al_set_new_display_flags said:

ALLEGRO_OPENGL_ES_PROFILE
Used together with ALLEGRO_OPENGL, requests that the OpenGL context uses the OpenGL ES profile. A specific version can be requested with al_set_new_display_option. Note: Currently this is only supported by the X11/GLX driver. Since: 5.1.13

I'm guessing you enable GL ES 2 by requesting the major opengl version to be 2. I don't know for sure. Try this :
al_set_new_display_option(ALLEGRO_OPENGL_MAJOR_VERSION , 2 , ALLEGRO_REQUIRE);

The manual entry for al_set_new_display_option doesn't explain much about this part of things.

Space cpp said:

Before I forget: using ALLEGRO_REQUIRE does not seen to be doing any difference, the display is still created, with depth size 0.

If you use ALLEGRO_REQUIRE and a non zero depth size, creating the display should fail if it can't find a display mode with the requested depth. Check your code, and if it's okay, then that's a bug in allegro.

But first, enable the log and check the display scores.

no-reply@allegro.cc (Space cpp) — Wed, 20 Jun 2018 01:48:22 +0000

I'm stuck at the log part.

no-reply@allegro.cc (Edgar Reynaldo) — Wed, 20 Jun 2018 02:01:34 +0000

Okay, first did you download binaries? Or build allegro yourself?

If you're building allegro yourself, all you have to do is set the CMAKE_BUILD_TYPE to 'Debug' or 'RelWithDebInfo' and then rebuild.

A quick google search reveals how SiegeLord enables the log :

Allegro 5.1.11 released said:

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

Call that line before you call al_init() and the log should be enabled if support was compiled in.

no-reply@allegro.cc (Space cpp) — Thu, 21 Jun 2018 04:45:33 +0000

Edgar Reynaldo said:

Okay, first did you download binaries? Or build allegro yourself?

Since I'm compilling for iOS now I used the included pre-built xcode project to build the static library.

Edgar Reynaldo said:

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

To make sure I wasn't doing anything wrong I tested this on windows first and it worked. On iOS by other hand, the filesystem seems to be a bit different, I couldn't find the allegro.log file inside the app file / folder.

Maybe, is there a way to dump the log contents on console instead?

no-reply@allegro.cc (Edgar Reynaldo) — Thu, 21 Jun 2018 05:26:24 +0000

Yes. See al_register_trace_handler.

void printme(const char* cstr) {
   fprintf(stdout , "%s\n" , cstr);
}

al_register_trace_handler(printme);

no-reply@allegro.cc (Space cpp) — Fri, 22 Jun 2018 06:39:32 +0000

Uh oh, it seems my build was compiled without support for it.

So, I'm going to rebuild it and report here later.

no-reply@allegro.cc (Edgar Reynaldo) — Sun, 24 Jun 2018 08:07:42 +0000

Bump for news of your progress.

no-reply@allegro.cc (Space cpp) — Wed, 27 Jun 2018 06:44:08 +0000

My apologies for taking long to respond.
I tried rebuilding allegro with either RelWithDebInfo / Debug but still no success generating the log.

no-reply@allegro.cc (Edgar Reynaldo) — Wed, 27 Jun 2018 11:25:50 +0000

The log is there somewhere. You just have to find it.

There are different directories allegro uses on OSX. See al_get_standard_path for an idea of where to search.

SiegeLord or anyone else - if you're listening, where do you guys store allegro.log on OSX?