Skip to main content
GameDev.net gamedev.net
🔒 Locked

Memory manager for a 3D graphics engine

Started by pillowpants Jun 28, 2009 at 7:17 PM 5 replies 3.4k views
Original Post
pillowpants
pillowpants
Hi All, I've started writing a small, simple, 3D graphics engine using OpenGL and C++. So far my only accomodation for memory management is a reference counting scheme and a number of smart pointer classes for internal and external objects. I'm looking at writing my own memory manager for the engine as well; however, I'm unsure as to where to start. I've read a couple of articles on the topic: http://www.gamasutra.com/features/20020802/hixon_01.htm (which was kinda helpful from a design point-of-view) and two IBM articles: http://www.ibm.com/developerworks/linux/library/l-memory/ http://www.ibm.com/developerworks/edu/au-dw-au-memorymanager-i.html Both of which were very helpful. One thing I haven't been able to find out is whether there is a defacto-standard design for memory managers used in graphics/games programming. A lot of forum posts I see suggest using the boost library and it's pooled memory management scheme (I had a look at that article as well, also quite handy); however, don't really have any suggestions for implementing your own. I guess what I'm after is some more information to digest (books, articles, journals, advice) before I have a go at writing my own. Any info would be great. :)
Hodgman
Hodgman
If you're just making a 3D graphics engine, then it will probably be used in conjunction with a game engine.

The only commercial "graphics only" engine that I used implemented a default memory manager, but allowed the game to override it (because the game engine probably already has it's own).
pillowpants
pillowpants
Quote:
Original post by Hodgman
If you're just making a 3D graphics engine, then it will probably be used in conjunction with a game engine.

The only commercial "graphics only" engine that I used implemented a default memory manager, but allowed the game to override it (because the game engine probably already has it's own).


I should add a little back story here. My friend and I are developing this engine with the intention of using it in a couple of small game projects of our own. We decided that we didn't want to spend ages on the 'engine' part and let it detract from time spent working on the actual game(s). Therefore, we decided to reduce our scope to just a small and simple graphics engine, nothing too fancy.

If down the track we put together enough code that we want to make reuseable we might try remodelling the engine with all of the features a normal game engine would have (physics, scripting, network capability etc).

I'm mainly interested in the memory manager as a means of improving speed and ensuring that no there are no memory leaks upon the program closing.
Zakwayda
Zakwayda
Quote:
I'm mainly interested in the memory manager as a means of improving speed and ensuring that no there are no memory leaks upon the program closing.
You don't need a custom memory manager to ensure that there are no memory leaks; all you need to do is follow good programming practices (which in this case basically boils down to consistent use of RAII containers and proper handling of special cases such as circular references).

Regarding the performance issue, let me ask: if you haven't even started writing the engine yet, how can you already know that memory management is going to be a bottleneck?
Quote:
We decided that we didn't want to spend ages on the 'engine' part and let it detract from time spent working on the actual game(s).
It seems to me that developing a custom memory manager for your engine might be counter to your stated aim. (At the very least, I'd consider using pre-existing tools such as boost/tr1::shared_ptr and boost::pool rather than creating your own implementations from scratch.)
pillowpants
pillowpants
Quote:
Regarding the performance issue, let me ask: if you haven't even started writing the engine yet, how can you already know that memory management is going to be a bottleneck?


Well the memory manager was actually more of an after-thought than an actual design goal. I've been using my own smart pointer classes up until this point and a reference counting scheme similar to Irrlicht's. I don't know whether memory management will be a bottleneck yet, I was doing the reading now to figure out whether or not it will be viable or too much work for our purposes.

Quote:
It seems to me that developing a custom memory manager for your engine might be counter to your stated aim.


It does seem that way, yes. I might stay clear of it for now and look into it in greater depth later.

This forum post was primarily designed to see what I information I could glean from people that may have already been down this road and also to find recommendations on resources for further reading.

Hodgman
Hodgman
Quote:
Original post by pillowpants
I'm mainly interested in the memory manager as a means of improving speed and ensuring that no there are no memory leaks upon the program closing.
As jyk said, I wouldn't worry about the speed issue for now.

If you want to do some book-keeping for debugging purposes, you could look into overloading the global operator new/delete.

I've seen engines keep track of allocations (to report memory leaks) by overloading global new, and using their own new 'keyword' like this:
#ifdef _DEBUG#define MyNew new (__FILE__, __LINE__)#else#define MyNew new#endif

So in debug builds, a special version of new will be used that logs the file and line number of where the allocation occurs. Delete will be modified to remove entries from the log. When the program exits, you can check the log to find any leaks.

This page contains some info on overloading the new/delete operators for this purpose.
pillowpants
pillowpants
Yep, that's how I was planning to go about it, by overriding the operators for new/delete.

I might do as you suggest to keep track of memory allocations and deallocations for debugging purposes; but for now I think I've concluded that a memory manager is too much work for this stage in the project. I might come back to it later if I see the need.

Thanks for all of your advice guys. :)

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.