I just recently started into allegrogl, and I"m not sure what all of this means, but I know a bit of it. This code compiles fine, but when I run it, I get the standard windows error "This program has experienced an error and needs to close".
| 1 | #include <allegro.h> |
| 2 | #include <alleggl.h> |
| 3 | |
| 4 | int main() { |
| 5 | |
| 6 | // Init Allegro and AllegroGL |
| 7 | allegro_init(); |
| 8 | install_allegro_gl(); |
| 9 | |
| 10 | install_keyboard(); |
| 11 | |
| 12 | allegro_gl_set(AGL_Z_DEPTH, 8); |
| 13 | allegro_gl_set(AGL_COLOR_DEPTH, 16); |
| 14 | allegro_gl_set(AGL_SUGGEST, AGL_Z_DEPTH | AGL_COLOR_DEPTH); |
| 15 | |
| 16 | set_gfx_mode(GFX_OPENGL_WINDOWED, 640, 480, 0, 0); |
| 17 | |
| 18 | glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); |
| 19 | |
| 20 | glMatrixMode(GL_MODELVIEW); // Select The Modelview Matrix |
| 21 | glLoadIdentity(); // Reset The Modelview Matrix |
| 22 | |
| 23 | glShadeModel(GL_SMOOTH); // Enables smooth shading |
| 24 | |
| 25 | glClearColor(0.0f, 0.0f, 0.0f, 0.0f); // Clears screen to black |
| 26 | |
| 27 | glBegin(GL_TRIANGLES); // Drawing Using Triangles |
| 28 | glVertex3f( 0.0f, 1.0f, 0.0f); // Top |
| 29 | glVertex3f(-1.0f,-1.0f, 0.0f); // Bottom Left |
| 30 | glVertex3f( 1.0f,-1.0f, 0.0f); // Bottom Right |
| 31 | glEnd(); // Finished Drawing The Triangle |
| 32 | |
| 33 | glTranslatef(3.0f,0.0f,0.0f); // Move Right 3 Units |
| 34 | |
| 35 | glBegin(GL_QUADS); // Draw A Quad |
| 36 | glVertex3f(-1.0f, 1.0f, 0.0f); // Top Left |
| 37 | glVertex3f( 1.0f, 1.0f, 0.0f); // Top Right |
| 38 | glVertex3f( 1.0f,-1.0f, 0.0f); // Bottom Right |
| 39 | glVertex3f(-1.0f,-1.0f, 0.0f); // Bottom Left |
| 40 | glEnd(); // Done Drawing The Quad |
| 41 | |
| 42 | readkey(); |
| 43 | |
| 44 | return 0; |
| 45 | } |
| 46 | END_OF_MAIN(); |
I remember openlayer not working for my computer, so I don't think allegrogl does either. OpenGL does work as far as I know because I've played games with OpenGL only. I dunno what's going on. Any help would be pretty awesome right now. Thanks a lot.
Where's all your error checking code? Unless you know precisely what you're doing, and sometimes even then, if something can fail, make sure it doesn't.
And you also need allegro_gl_flip(); before readkey();.
Tell us the AGL version, and yes, check for return values.
Allegro version is needed too. Thanks.
Ok well I'm using allegro 4.2 (Should I be using 4.3 now? I thought it still had bugs) and I put in some checks and I checked for the return values of install_keyboard and set_gfx_mode. Basically I have an allegro_message after a couple of actions. So it installs allegro and allegrogl, installs the keyboard, suggests the graphics mode, but once I actually get to set_gfx_mode, it crashes.
EDIT: Also, one of the main reasons I don't have a lot of checks for return values is I'm not sure exactly what all returns values. Since I've never used AllegroGL, I still don't know what everything does, but I guess I get the general idea.
You just have to read Allegro && AllegroGL documentations to found the return values.
Also tell us more about the crash.
Try to compile a debug version (link with -lallegd and (i do not remember the name) the debugged version of AllegroGL))
Do the AllegroGL examples works fine ? And Allegro ones ?
Do you have a proper driver for your GFX card ? What is your GFX card ?
EDIT:
Allegro manual
AllegroGL manual
_
I'm not sure where to find some allegroGL examples, but the allegro ones do. All of Shawn Hargreaves 3d examples work, but I don't think he's using allegroGL. Every single OpenLayer or AllegroGL game for me though seems to fail. I'm not sure how to check my drivers for my graphics card since I'm not really that well-versed on the topic. My gfx card is a piece of crap, it's an Intel Graphics Media Accelerator 900, built in with the computer. At the moment I'm trying to get a new one, but can't afford one at the moment. Like I said in my first post, I just think that my graphics card isn't good enough to handle AllegroGL.
Your gfx card can handle DirectX 3D games can't it? I'm not sure if there are OpenGL drivers out there for it, but I find it hard to believe you can't do at least basic 3D gfx with it..
Yea, neither can I. It supports direct X games fine, and I'm sure I've even played some OpenGL games fine, I really don't know what the deal is. I've tried looking into it a bit further, but I don't find much unfortunately.
Well, according to Wikipedia:
http://en.wikipedia.org/wiki/Intel_GMA
GMA 900
On Intel i910G, Intel i915G, Intel i915Gx chipset motherboards.
T/L support: Software based (no Hardware T&L Support)
Clock speed: 333 MHz
Pixel Pipelines: 4
Pixel Fillrate: 1333 MPixel/s
Vertex Shaders: 1 (v2.0) (software)
Pixel Shaders: 4 (v2.0) (hardware)
OpenGL: Yes. v.1.4
DirectX (hardware): Yes. v.9.0
Notice the OpenGL 1.4 support.
Intel's page:
http://www.intel.com/design/graphics/gma900/
And details on drivers and support:
http://www.intel.com/support/graphics/intel915g/index.htm
Can you tell which line in your program triggers the error?
Ok well you're much better at finding things than I am Richard.
I'm going to update my drivers then. Bob, it gets as far as the set_gfx_mode(); then it crashes.
Can you track down the crash inside of AGL? Maybe the allegro.log file contains some useful information?
I don't get an allegro.log, isn't that only with Visual-C++? I'm using Dev-C++ atm.
You need to build the debug version of AllegroGL and link with agld.a
Tell us the AGL version!!!
I'm guessing the error you are experiencing was fixed in the current SVN version.
Sorry I haven't replied, my internet has been down for almost 3 hours. Internet service really sucks here. I know this sounds stupid, but I've looked around and I can't find what version of AllegroGL I'm using. I'll compile a debug version and post the results here later as well. Could you tell me how to find out the version of AllegroGL I have? Sorry, I'm a bit slow.
printf("%s\n", AGL_VERSION_STR);
0.2.5 CVL is the version I have.
old
edit:
try this http://allegrogl.sf.net/alleggl-svn-01082006.zip
I feel incredibly stupid. I have no clue how to compile AllegroGL so I can use it for dev C++. I looked around, but I can't find anything. Can you help me with this?
Should I be using 4.3 now? I thought it still had bugs
You absolutely shouldn't use 4.3. It's not yet suitable for normal use (just for testing).
I feel incredibly stupid. I have no clue how to compile AllegroGL so I can use it for dev C++. I looked around, but I can't find anything. Can you help me with this?
Did you read the readme files?
Mingw/32 instructions
---------------------
Mingw 2.0 and higher already come with the OpenGL header files
and libraries, so you can skip the next step.
If you don't have the OpenGL header files (GL/gl.h) and libraries, you will
first need to acquire thrm. These can be obtained from the Microsoft site,
or from MSVC.
If you obtained the self-extracting archive from the Microsoft site, then
run it. Move the produced header files (*.h) into C:\Mingw32\include\GL\
(replace C:\Mingw32 by wherever you happen to have installed Mingw).
Ignore the other files, as they are only useful for MSVC.
You will need to run 'fix mingw32' in the AllegroGL directory
to update makefile for Mingw32.
Since both Allegro and AllegroGL have native Mingw support
I am happy to say that you can build Allegro/AllegroGL programs
entirely using free software.
For an optimised build, run `make' from the directory containing
this file. Use `make install' to install the library and header
file. Some versions of Mingw come with `mingw32-make' instead of
`make', so you may need to run that instead.
For a debug build, do the same but write `DEBUGMODE=1' on each
of the command lines; for example, 'make DEBUGMODE=1' and
'make install DEBUGMODE=1'.
It worked fine for me. I had to install the lib and header files in my Dev-c directory manually, but that's to be due to a strange dev-c folder setup some years ago. The new version seems to work fine for my game and I hope that means for more people than with the old 0.2.5 version.
Well I tried to read the readme files but they got all messed up when I unzipped them. Sorry for not replying and seeming incredibly stupid, just internet is been very jacked up lately. So Richard, you just took the header files and the lib files and just put them right into the folders for Dev-C++?
Do it soon before this thread disappears.
Ok so sorry to sound stupid, but what files am I dealing with exactly? I looked in the lib folder and all the folders are empty except for a delete.me file. I moved the header files if I recall, but it didn't seem to do anything. 
EDIT: Nevermind, I did a new project and it turns out I did install it. But unfortunately it still crashes.
What alegroGL version string does your project now print out?
Ok, first, let's get your AGL version as reported by AGL itself. Then, I'll have to ask you to track down where AGL crashes. There might be an AGL bug that only manifests itself on your system. Most of us don't have Intel Integrated Graphics so it's difficult to debug this issue without your help.
Thanks!
Ok I have this code
| 1 | #include <allegro.h> |
| 2 | #include <alleggl.h> |
| 3 | |
| 4 | int main() { |
| 5 | |
| 6 | /* Initialize both Allegro and AllegroGL */ |
| 7 | allegro_init(); |
| 8 | install_allegro_gl(); |
| 9 | |
| 10 | allegro_message("Installed allegro and allegro GL"); |
| 11 | allegro_message("%s", AGL_VERSION_STR); |
| 12 | |
| 13 | /* Tell Allegro we want to use the keyboard */ |
| 14 | install_keyboard(); |
| 15 | |
| 16 | allegro_message("Keyboard installed"); |
| 17 | |
| 18 | /* Suggest a good screen mode for OpenGL */ |
| 19 | allegro_gl_set(AGL_Z_DEPTH, 8); |
| 20 | allegro_gl_set(AGL_COLOR_DEPTH, 16); |
| 21 | allegro_gl_set(AGL_SUGGEST, AGL_Z_DEPTH | AGL_COLOR_DEPTH); |
| 22 | |
| 23 | allegro_message("Suggested color depths"); |
| 24 | |
| 25 | /* Set the graphics mode */ |
| 26 | set_gfx_mode(GFX_OPENGL_WINDOWED, 640, 480, 0, 0); |
| 27 | |
| 28 | allegro_message("Graphics mode set."); |
| 29 | |
| 30 | /* Clear the screen */ |
| 31 | glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); |
| 32 | |
| 33 | allegro_message("Cleared buffer"); |
| 34 | |
| 35 | /* Set up the view frustum */ |
| 36 | glMatrixMode(GL_MODELVIEW); |
| 37 | glLoadIdentity(); |
| 38 | glFrustum(-1.0, 1.0, -1.0, 1.0, 1, 60.0); |
| 39 | |
| 40 | /* Draw a quad using OpenGL */ |
| 41 | glBegin(GL_QUADS); |
| 42 | glColor3ub(255, 255, 255); |
| 43 | glVertex3f(-1, -1, -2); |
| 44 | glVertex3f( 1, -1, -2); |
| 45 | glVertex3f( 1, 1, -2); |
| 46 | glVertex3f(-1, 1, -2); |
| 47 | glEnd(); |
| 48 | |
| 49 | /* Flip the backbuffer on screen */ |
| 50 | allegro_gl_flip(); |
| 51 | |
| 52 | /* Wait for the user to press a key */ |
| 53 | readkey(); |
| 54 | |
| 55 | /* Finished. */ |
| 56 | return 0; |
| 57 | } |
| 58 | END_OF_MAIN(); |
It returns the version as "0.4.0 RC4" and the code gets to
allegro_message("Suggested color depths");
then it crashes.
he code gets to allegro_message("Suggested color depths"); then it crashes.
Can you step in AllegroGL's win.c, function allegro_gl_win_init() and see where it crashes there?
What do you mean? Do you mean use that function in my code? I'm a little confused on the subject.
No. I mean use a debugger (or lots of printfs, whichever you prefer) and try to figure out where is AGL crashing.
Ok, if you are new to debugging then do this:
Add some printf("1"); printf("2"), etc.. to different lines in the allegro_gl_win_init() function that Bob describes. Recompile the AllegroGL lib and reinstall it. Run your program and make it open a console window (should be done normally, as one of the compile flags removes it) and see what number it gets upto in the console window.
That should help narrow it down so it can be fixed.
So what do I need to include in the parameters to recompile allegrogl? Guys, I'm really sorry that I'm slow, I'm just new to all of this.
Just do what you did before.. For mingw: fix mingw32, make and then make install. 
EDIT: Come on Brian. If you figure it out if will help you and other people trying to run AllegroGL / Openlayer games.
I will finish debugging this tomorrow, but for now here are the offending lines (from win.c):
if (allegro_gl_extensions_GL.ARB_multisample) { glSampleCoverageARB(1.0, GL_FALSE); }
Apparently, the variable allegro_gl_extensions_GL suggests that the Intel 915series chipset is capable of handling this Open GL extension, but it is not. I suspect that the extensions are being parsed improperly, but I ran out of time to verify this today.
Tomorrow, I will try to find out the root of the problem, but for now, if you comment out the lines I copied above, you can at least get allegrogl to run.
Thank you for your help!
Thank you too! I hope we can find the problem and fix it so AllegroGL can work on these chipsets. 
EDIT: I found this snippet of code for X at : http://www.ks.uiuc.edu/Research/vmd/doxygen/OpenGLDisplayDevice_8C-source.html
00058 // determine if all of the ARB multisample extension routines are available 00059 #if defined(GL_ARB_multisample) && defined(GLX_SAMPLES_ARB) && defined(GLX_SAMPLE_BUFFERS_ARB) 00060 #define USEARBMULTISAMPLE 1 00061 #endif
Does this mean we need GLX extensions as well to use it for some chipsets?
And this link might be useful:
http://oss.sgi.com/projects/ogl-sample/registry/ARB/multisample.txt
You probably know this already though.. 
Hope you can fix this one!
I just ran into this little problem myself when sending a binary to a friend of mine on a laptop with the 915m chipset. I think we may have to put another branching point to detect this particular chipset, or we need to contact intel, as This piece of software crashed in a similar way on the test "Static VAO".
Hope that helps!
Drew
In the file "gl_ext_list.h"
The number "1.3"
AGL_EXT(ARB_multisample, 1.3)
is causing this code; (in "glext.c")
/* Get extension info for the rest of the lib */ # define AGL_EXT(name, ver) { \ allegro_gl_extensions_GL.name = \ allegro_gl_is_extension_supported("GL_" #name) \ || (allegro_gl_info.version >= ver && ver > 0); \ } # include "allegrogl/GLext/gl_ext_list.h" # undef AGL_EXT
To set
allegro_gl_extensions_GL.ARB_multisample = 1
However, the extension GL_ARB_multisample is apparently NOT available on this chipset (INTEL 915GM)
OpenGL Version: 1.4.0 - Build 4.14.10.4332
Vendor: Intel
Renderer: Intel 915GM
GLU Version : 1.2.2.0 Microsoft Corporation
subsequently, when allegrogl attempts to use the extension (in "win.c")
if (allegro_gl_extensions_GL.ARB_multisample) { glSampleCoverageARB(1.0, GL_FALSE); }
It crashes (and burns).
Two possible solutions:
1. change line in "gl_ext_list.h" to read:
AGL_EXT(ARB_multisample, 1.4)
OR
2. change line in "win.c" to read:
if (allegro_gl_is_extension_supported("GL_ARB_multisample")){ glSampleCoverageARB(1.0, GL_FALSE); }
Thanks a lot Mike! 
Mike, Bob, which option do you recommend? I'll be changing my version of AllegroGL so that it works on this chipset.
We should do Option 3: Detect Intel 915G chipsets and force multisampling to be disabled. We alreday do this for ARB_texture_non_power_of_two.
The fix would be in src/glext.c in function __allegro_gl_manage_extensions(void).
For now I've implemented no. 2 and my game now works on a Intel 915 laptop.
Can one of the AllegroGL devs post in the forum when this fix is applied to the CVS branch and I'll download.
Also, I'm not sure if this problem applies to other Intel chipsets in that range..?
Thanks Bob!
The problem with Option 2 is that it will work in Windows XP and under, but it will not necessarily work properly in Linux or Windows Vista. The extensions string does not need to contain things that are part of the core spec.
So is this a bug in the OpenGL drivers for this Intel chipset?
What does printf("%s", (const char*)glGetString(GL_VENDOR)); say?
Should GL_ARB_multisample be disabled only for Intel 915G? I've seen AGL working fine on some other Intel chipsets (not sure which ones).
Milan:
From Mike's Allegro Log file:
OpenGL Version: 1.4.0 - Build 4.14.10.4332
Vendor: Intel
Renderer: Intel 915GM
GLU Version : 1.2.2.0 Microsoft Corporation
Is that the vendor string you refered to?
The problem with Option 2 is that it will work in Windows XP and under, but it will not necessarily work properly in Linux or Windows Vista. The extensions string does not need to contain things that are part of the core spec.
I was wondering if you could point me at any documentation regarding this? I would like to learn more. Most of what I have read in regards to glGetString(GL_EXTENSIONS) merely mentions that it returns "A list of supported GL extensions." If they didn't mean "all supported extensions" it seems like there would be some documentation somewhere explaining which supported extensions would be in this list?
edit I don't doubt you, I just would like to read more about this.
Richard: yes that's it, thanks
edit:
Here is the patch. If someone could test it that would be great.
Most of what I have read in regards to glGetString(GL_EXTENSIONS) merely mentions that it returns "A list of supported GL extensions." If they didn't mean "all supported extensions" it seems like there would be some documentation somewhere explaining which supported extensions would be in this list?
I think it's because if something is part of the core spec, it's not technically an extension, and thus doesn't have to be listed.. but it's still available to use. So like, if you have a driver that supports OpenGL 2.0, everything in the OpenGL 2.0 spec is implied. The extensions only need to list what isn't included in the core spec for the supported version.
Milan: Can you just tell me the changes? I'm not having any luck with patches and MSYS.
| 1 | Index: src/glext.c |
| 2 | =================================================================== |
| 3 | --- src/glext.c (revision 1132) |
| 4 | +++ src/glext.c (working copy) |
| 5 | @@ -630,6 +630,16 @@ |
| 6 | } |
| 7 | } |
| 8 | } |
| 9 | + |
| 10 | + /* Intel 915G chipsets do not support ARB_multisample even though they claim to be |
| 11 | + * OpenGL 1.4 compilant. |
| 12 | + */ |
| 13 | + { |
| 14 | + const char *renderer = (const char*)glGetString(GL_RENDERER); |
| 15 | + if (strstr(renderer, "Intel 915G")) { |
| 16 | + allegro_gl_extensions_GL.ARB_multisample = 0; |
| 17 | + } |
| 18 | + } |
| 19 | } |
I hope you can read patches. It's easy. File src/glext.c, line 630, add the code.
About the extension promotion, the OGL specs say:
G.2 Promoting Extensions to Core Features
ARB extensions can be promoted to required core features in later revisions of
OpenGL. When this occurs, the extension specifications are merged into the core
specification. Functions and enumerants that are part of such promoted extensions
will have the ARB affix removed
GL implementations of such later revisions should continue to export the name
strings of promoted extensions in the EXTENSIONS string, and continue to support
the ARB-affixed versions of functions and enumerants as a transition aid.
If I understand that correctly, the promoted extension should still be listed in EXTENSIONS string, and can be accessed the same way before they were promoted, i.e. it should be backward compatible.
Thanks Milan! Hopefully this will work. 
One thing: I'm not sure if any other 915x chipsets or 9xx chipsets are affected. Does anyone know?
If I understand that correctly, the promoted extension should still be listed in EXTENSIONS string, and can be accessed the same way before they were promoted, i.e. it should be backward compatible.
should != must. Even though it would be a (really) bad idea for compatibility reasons, they aren't required to.
Well... I was doing some reading and thinking about what has been said on this thread, and I downloaded GLEW library. (http://glew.sourceforge.net/)
And I made a discovery:
GL_ARB_multisample: MISSING
-------------------
glSampleCoverageARB: MISSING
However, the interesting part was back in the GL 1.3 spec, which said:
GL_VERSION_1_3: OK
---------------
glActiveTexture: OK
glClientActiveTexture: OK
glCompressedTexImage1D: OK
glCompressedTexImage2D: OK
glCompressedTexImage3D: OK
glCompressedTexSubImage1D: OK
glCompressedTexSubImage2D: OK
glCompressedTexSubImage3D: OK
glGetCompressedTexImage: OK
glLoadTransposeMatrixd: OK
glLoadTransposeMatrixf: OK
glMultTransposeMatrixd: OK
glMultTransposeMatrixf: OK
glMultiTexCoord1d: OK
glMultiTexCoord1dv: OK
glMultiTexCoord1f: OK
glMultiTexCoord1fv: OK
glMultiTexCoord1i: OK
glMultiTexCoord1iv: OK
glMultiTexCoord1s: OK
glMultiTexCoord1sv: OK
glMultiTexCoord2d: OK
glMultiTexCoord2dv: OK
glMultiTexCoord2f: OK
glMultiTexCoord2fv: OK
glMultiTexCoord2i: OK
glMultiTexCoord2iv: OK
glMultiTexCoord2s: OK
glMultiTexCoord2sv: OK
glMultiTexCoord3d: OK
glMultiTexCoord3dv: OK
glMultiTexCoord3f: OK
glMultiTexCoord3fv: OK
glMultiTexCoord3i: OK
glMultiTexCoord3iv: OK
glMultiTexCoord3s: OK
glMultiTexCoord3sv: OK
glMultiTexCoord4d: OK
glMultiTexCoord4dv: OK
glMultiTexCoord4f: OK
glMultiTexCoord4fv: OK
glMultiTexCoord4i: OK
glMultiTexCoord4iv: OK
glMultiTexCoord4s: OK
glMultiTexCoord4sv: OK
glSampleCoverage: OK
Which, got me thinking... If it was upgraded to Core in 1.3 and Intel failed to maintain backwards compatibility (by defining glSampleCoverageARB()), perhaps just using "glSampleCoverage" would work.
Sure enough I changed the lines in "win.c"
from -
if (allegro_gl_extensions_GL.ARB_multisample) { glSampleCoverageARB(1.0, GL_FALSE); }
to -
//if (allegro_gl_extensions_GL.ARB_multisample) { glSampleCoverage(1.0, GL_FALSE); //}
And... it worked.
So, my theory seems to be correct, that Intel chipset does support the command (glSampleCoverage), but not the compatibility version of the command (glSampleCoverageARB).
Will glSampleCoverage work on OGL < 1.3?
I am no expert, but probably not.
Here's one possiblity to fix this in AllegroGL:
/* On platforms where glSampleCoverageARB is a function pointer, ONLY */ if (glSampleCoverage && !glSampleCoverageARB) { glSampleCoverageARB = glSampleCoverage; }
Michael, are there other extensions which may require the same fix, CompressedTexImage2D for example?
Curious.. should you hack AllegroGL to work with Intel's drivers, or should you fix Intel's drivers to work better?
Those drivers seem to be for Linux, KC. I didn't think the windows drivers were open source?
Depends on how much code is shared between the two. Since this specific problem seems to be only due to missing API symbols, it's not inconceivable that the fix for Windows isn't very different than for Linux. And who knows. With open source drivers that can show you how to handle the hardware, open source drivers could pop up for other platforms, perhaps with better OpenGL support in Windows.
But is that a bug at all? This is the "should" part of the specification. It seems to be a AGL bug or a design flaw.