nobodynews

Is there anything wrong with handling memory in this manner? Am I overlooking any potential problems with this method?

Yes. You are violating all sorts of good coding practices.

First of all, the fact that you're using a global suggests there's other serious issues with your code.

Second of all, you're requiring that CObjects know about ObjectList for no good reason. Someday you will want to make a CObject without adding it to ObjectList and then you're design is totally screwed and you'll have to redo your design anyway. Don't think that will happen, do you? Well, the entire history of software development says otherwise. Since the only change to your code to *not* do that is just

ObjectList.push_back( new CObject(0, 0, 1) ); 

I don't see what you think your code gains you. Of course the above code isn't really safe either, in the event of an exception occurring.

I'm also curious over whether CObject even needs to be dynamically allocated like that. What does CObject look like? There might be a much better solution for your needs.

Side note: You don't need to check if for the pointer being non-null. C++ as defined considers delete 0; perfectly legal and safe. It contains the check for being null already.

http://en.wikipedia.org/wiki/Paper_size#A_series

To be honest, it's almost impossible to know for sure unless you've been told.

If you go way back to some very old 3d games like Doom, they didn't use a 3d api to make 3d games. They used a 2d API (probably drawing directly to the video frame buffer). It manually did what is now built in to graphics cards. There isn't really anything limiting you by using a 2d API except for the speed of your processor and your own knowledge of 3d mathematics.

Going the other way, a programmer can ignore basically all 3d accellerated features of their API to make their 2d game. The programmer would use 'textured quads' to draw 2d sprites. Once that's implmented all the programmer needs to do is say "draw this sprite at this location" to make their 2d game.

All that being said, there are often hints when seeing a 2d game whether it uses a 3d API under the hood. Rotating sprites is a costly process without using a 3d API in some way. So if you see a lot of rotation it's probably using 3d api. If you see things like the view smoothly zooming in and out on the action that's probably using a 3d API. If you see transparency changes (fade in/out) it's probably using a 3d API. But again, that's all possible without a 3d API.

Things are further confused because a 2d API might be implemented using a 3d API. SFML is implemented in OpenGL for example (and uses that 'textured quads' thing). Because it uses OpenGL, rotating and zooming and using transparency in SFML is simple and fast. SDL was not implemented in a 3d api so you can only do rotating and zooming manually or by getting an add-on, that also does it manually. While SDL allows interoperability with OpenGL, It just creates the window and then the programmer switches to using OpenGL functions so it's mainly just to help set things up in that situation.

You're basically talking about reverse engineering the memory. This pdf might be informative.

I have been told to move on but I did pay $60 at the time for this book and I think its fair that I at least have the working source code to what I am reading.

I'm not saying you should or shouldn't continue, just beware of falling prey to the sunk cost fallacy which it sounds like you might be. Just something to think on. Also, what book are you talking about, exactly? I can't find anything with that exact title on Amazon, but I think you're talking about this one, by Jim Adams. If not, what are you using?

If you insist on using that book then Slig has it right. You should at least post some of the errors you're getting and we can help you narrow down what the causes might be.