I've only been working with Allegro 5.0.5 for a few weeks now. I a problem that I shouldn't be having. I have an ATI Raedon with 256MB RAM. I'm loading less than 5 MBs of bitmaps. No matter how I set al_set_bitmapflags(flags|ALLEGRO_VIDEO_BITMAP), I can get no more than a handful of MBs loaded into video memory(I assume I don't even need to change the bitmap flags as the default setting are what I need). I've read at least half of the posts that discuss this issue, with no information being present that leads me in a direction to resolve this issue.

I'm loading a modular game suite as a control frame with under 1MB of bitmaps and that works well with abundant FPS. However, when I load a game selected from a list, not one of those bitmaps load into video memory. With 256MB available, I don't understand the problem. I have multiple times verified that all needed addons are loaded successfully and in the correct order. 5 FPS is completely unacceptable. What could be preventing such a small number of bitmaps from loading into video RAM?

Could we see some of the code that might be causing the problem?

there are 6 buttons loaded with 3 80x20 bitmaps loaded into them. A handful of text based labelbs and outputs, none with the font loaded larger than 20.
This much of my code runs very smoothly.

Loading the next stage is where the problems begin.

Is this enough to see what I'm doing?

A few things I noticed:

Any reason why you need an opengl 3.0 context explicitly? Usually just ALLEGRO_OPENGL is fine. Try that.

Usually you should init your addons before creating the display. That might be causing a problem.

You use 1000/60 to create your timer, you might want to double check that it is indeed 16.666 because neither your numerator or denominator are floats so C++ might do integer division which would give you a weird framerate maybe.

I would also highly recommend that you throw exceptions instead of returning numbers like that. I would much rather see "Allegro Display Failed To Create" in my console than 2 or something.

Also, there's no sense in checking for NULL every time you call new. The only way that will return NULL is if you run out of memory and if that happens the runtime will throw an out of memory exception or something.

You are often changing targets which requires render to texture support. Maybe you do not have that?

Also note that ALLEGRO_OPENGL_3_0 is only a modifier for ALLEGRO_OPENGL, if you don't specify ALLEGRO_OPENGL, Allegro will fall back to its default on a given platform. For windows the default is ALLEGRO_DIRECT3D.

Also ALLEGRO_VIDEO_BITMAP is the default.

Would you be able to post the entire code? Or even better, make a small, simple example that displays the same problems? (I would prefer that over your original code, that way if it is an allegro bug, it would be extremely obvious that it is an allegro bug, and be easier to debug).

I've been trying various unnecessary changes to my code attempting to track down the bottle neck. No other reason for for setting the display atm.

Ok, I can try changing the order of init'ing the addons, again. I can typecast the timer rate, np. I'm working on a overloaded new operator to use as a mixin class(once I verify Allegro can meet my needs), so had planned to deal with that later.

Checking for NULL is good practice no matter how long you've been coding.???
Just how many cycles will it save to not do it?

The target bitmap is changed once per loop, no more than that other than in Init().

Loading and running the first stage(host frame with controls) runs like a charm. I haven't measured FPS, I've merely used fprintf every 100 frames. I see it printed more than twice a second.

Once I've loaded and closed the playlist popup and started the game, every single bitmap is a memeory bitmap, not a video bitmap and everything becomes moot with 5 FPS. If I want a card game where the cards don't move, I could use windoze and be done in a week or probably less.

When I close the game and only the frame is running again, the frame rate returns(all of the first stage of bitmap loading are video bitmaps and accelerated).

-------------------------------------------------------------------------------

Changing ALLEGRRO_OPENGL_3_0 TO ALLGRO_OPENGL solved the issue.

Thanks all for your input.

When it comes to Operator new, I feel it is better that the operator checks for failure and throw an exception. That way you can catch it somewhere else, and keep your code clean and modular. I always check for NULL when using C functions that could fail, but in C++ there are exceptions which IMO result in cleaner modular code.

I find exceptions clutter code more than explicit error checking does. Especially when you have to start creating a boat load of custom exception classes. It gets to be a mess very quickly.

Unrelated, but exceptions are also very expensive on some embedded hardware, especially game consoles. In some cases, they are unsupported on these systems. So if you develop a very budget game and happen to have a console development kit, keep this in mind...

(Alternatively, you can use homebrew compilers for current consoles and come to the same conclusion, such as on the Wii.)

I only use them for exceptional circumstances that would otherwise result in a crash or a state where the application can no longer continue. This way I can quickly see why it crashed. I agree that if you used them for anything that could return NULL it would get messy. As for expensiveness, since after my exceptions are thrown the application closes, I don't care if it takes a second or two.

In theory, I do not expect my games to throw any exceptions for the end user. If it does, there is a bug.

I like to use assert/ASSERT for that. Just make it puke and throw a backtrace to the debugger.

His point is that new will throw an exception if there's any error, so the check for NULL is useless (the code inside the if is just unreachable).

You can use new (nothrow) if you don't want new to throw an exception on failure, and make it return NULL instead.

I thought assertions were skipped in release builds? That is why I use exceptions.

Yup. I want the app to crash hard if theres a fatal error. Maybe my idea of a fatal error is different from yours. I tend to split errors into "unimportant", "recoverable", "fatal, but needs graceful handling" and "fatal". That last one usually means things are so far beyond anything I can check for that things crash regardless. second last one is where I'd check return values, and bail out of a function, which would bubble back up and somewhere the app would puke. recoverable is stuff like not being able to fetch a file off the internet, the app shouldn't crash, but it might not be as useful, and unimportant is... well I'm not sure, doesn't often come up, more like an error I turn into a warning and paper over completely.

But yes, ASSERT is compiled out in release mode. So the overhead isn't there. And you should have done a bunch of testing in debug mode, so you have a chance to hit those ASSERTs, meaning you get a nice backtrace rather than some nasty chain of exceptions.

Is this true?

What does that mean? What does the code that does work look like? You know your mainline (probably) always calls sol.Abort ? Lines 27 to 35 make no sense to me.

Yes, my c++ is weak. I'm aware of this.

The lines you question are there to test for Initialization failure and returns what stage of initialization failed. If 0 is returned, the code enters the play loop of the host frame, load graphics for the Play Popup dialog, then waits for the user. Yes, I know I could have just used the constructor for initialization, but I wanted a return value. So, I chain up to the base class with the calls to Init(), and chain up with the Abort() functions as well. Maybe Abort() was a bad choice for the function name? Regardless, it gives me the opportunity to sort the errors rather than just going straight to crash mode.

I think what he means is you've got

  if(!ret)
  {
    sol.Play();
    if(sol.IsLoaded())
      sol.Abort();
  }
  if(sol.IsLoaded())
    sol.Abort();

so you are calling if(sol.IsLoaded()) and sol.Abort() whether you enter the condition or not, so you only need have it once after the condition.

TBH my internal parser crashes when encountering redundant conditionals. (I really didn't get it ) Also it is confusing that CGamebase returns 0 on failure and you said CGamebase was where the trouble begins. Is CSolitaire derived from CGamebase? If so, I'd exepct a call to CGamebase::init() somewhere.
Is "Abort" the opposite of "init"? (I also struggle to define the opposite of "init" ) Using an init method which returns false on error is ok, if done consistently.
Perhaps you should more clearly define the problem (What class is not functioning. Which bitmap fails to load. Does it fail to load if you don't load others.)

I saw that not long after I posted it and corrected the redundant call.

if(!ret)
sol.Play();
if(sol.IsLoaded())
sol.Abort();

CSolitaire::Init() returns int, CGameBase::Init() returns bool so it can be the first check during game instance loading.

CSolitaire serves as little more than a host frame, event router, and play loop. CGameBase won't be initialized until a game is selected from the resulting popup from clicking the "Play" button CSolitaire displays and manages.

Yes.

All classes are functioning. The problem was that I wasn't happy with the default DirectX window and needed to specify OpenGL; which I did incorrectly.