I thought I read somewhere that it was. Is this true? do I need to call it explicitly?
The only reason I'm asking is because the image stretch and rotation routines don't appear to have the same filtering I'm used to with hardware acceleration.
ALLEGRO_OPENGL doesn't seem to exist and transformations don't yet appear to be working. Did I forget a call somewhere?
I thought I read somewhere that it was. Is this true? do I need to call it explicitly?
Hardware acceleration is ALL it supports atm.
The only reason I'm asking is because the image stretch and rotation routines don't appear to have the same filtering I'm used to with hardware acceleration.
You can separately enable filtering.
ALLEGRO_OPENGL doesn't seem to exist
if your system is lacking in decent GL drivers, the OpenGL code won't work that well, so you'll be stuck with the D3D9 code. Which is the default on windows anyhow.
Hardware acceleration is ALL it supports atm.
sweet! 
Nah, like, ALLEGRO_OPENGL isn't even defined. 
I'm using 4.9.15. I tried passing it through al_set_new_display_flags(ALLEGRO_OPENGL); and get a comile error. "ALLEGRO_OPENGL: undeclared identifier" I suppose it doesn't matter anyway.
You can separately enable filtering.
How do I do that? I don't see it in the manual.
Nah, like, ALLEGRO_OPENGL isn't even defined. I'm using 4.9.15. I tried passing it through al_set_new_display_flags(ALLEGRO_OPENGL); and get a comile error. "ALLEGRO_OPENGL: undeclared identifier" I suppose it doesn't matter anyway.
Thats not supposed to be possible. The CMake script is set to error out if either OpenGL or D3D are disabled or not available on windows. Unless you compiled it yourself in static mode. Then you need to enable it again 
How do I do that? I don't see it in the manual.
I'm not sure an allegro specific function exists yet to set the filtering modes. It has been suggested, and will get done if it hasn't already... Just not sure when 
I tried passing it through al_set_new_display_flags(ALLEGRO_OPENGL); and get a comile error. "ALLEGRO_OPENGL: undeclared identifier" I suppose it doesn't matter anyway.
Did you #include "allegro5/allegro_opengl.h"?
Do the examples (say, ex_opengl) work?
Did you #include "allegro5/allegro_opengl.h"?
Should that be necessary just to use ALLEGRO_OPENGL?
Did you #include "allegro5/allegro_opengl.h"?
Ohp! there it is. 
Should that be necessary just to use ALLEGRO_OPENGL?
Didn't used to be, but there's a comment in display_new.h that says both ALLEGRO_OPENGL and ALLEGRO_DIRECT3D were moved to the header files for those graphics drivers. Might be a recent change.
One I agree with, I might add: it makes it just a little bit harder for people to accidentally write non-portable code (think people passing GFX_DIRECTX instead of GFX_AUTODETECT because they think that will be better). Admittedly less of a problem if you're using OpenGL. Still, it's not something that you normally need to care about. When you do, you'll probably want access to the DX or the OpenGL functions anyway, and it's not a big deal to include the other header file.
I see having to specify more headers as a backward step. All you should have to do to use the core libraries (not the plug-ins) is specify one header file.
All you should have to do to use the core libraries (not the plug-ins) is specify one header file.
I agree. And it's not like having your game carry on an extra megabyte or two of unused features is that big of a deal these days. Perhaps the idea is that if we start thinking of these components as "add-ons" then people will make more of 'em.
And it's not like having your game carry on an extra megabyte or two of unused features is that big of a deal these days.
One of the reasons thats wrong, is it makes it a LOT harder to build on some platforms *cough*windows*cough*.
Oh, and the OpenGL support isn't in an addon. Its a core feature of the main library.
All you should have to do to use the core libraries (not the plug-ins) is specify one header file.
This has been debated back and forth, and there is no way to satisfy everyone. People used to complain that A4's #include <allegro.h> pulled in everything.
It's certainly easier on the developers/maintainers to keep header files well separated and distinct modules distinct.
That said, there's nothing stopping anybody from making an "allegro5.h" that simply #includes everything. Hell, there's nothing stopping anyone from making an addon that does nothing other than that.
How do I do that? I don't see it in the manual.
See the allegro5.cfg file. OpenGL driver doesn't support filtering at this time, but that's an already filed bug.
People used to complain that A4's #include <allegro.h>
People used to complain that it made a mess of windows.h, that's about all I can remember.
It's certainly easier on the developers/maintainers to keep header files well separated and distinct modules distinct.
it's the end user you need to focus on, not the whims of the developers
People used to complain that it made a mess of windows.h
We used to get a LOT of bloat complaints.
it's the end user you need to focus on, not the whims of the developers
Only if your end users actually PAY for the product You willing to pay for allegro?
it's the end user you need to focus on, not the whims of the developers
Depends on whether said end user wants to have said software to be supported/developed in the future. There's no point in writing software that is hard to maintain, because software that is hard to maintain gets abandoned by its developers and its users.
Besides, as said, this is a non-issue for the reason given in my previous post.
Hey did you guys reference my Thing library at all? 'Cause that would be cool if I contributed somehow (without having to do the actual work).
I did try to make the IRC meetings but they were always at the worst time for my timezone.
Besides, as said, this is a non-issue for the reason given in my previous post.
Yea, I'm sure you guys know better than I do. Regardless, I'm finding allegro 5 to be super fun and I appreciate all the work everybody is putting into it.