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

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?

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.

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.

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.

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.

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.

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.

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.)