STL and the TGE memory manager

#41 EDIT:

I understand Jeff's point on using Garage Games as a game making site... using it as a technical platform has been no end of frustration (and unfortunately joy) for me.

It appears very difficult to find any kind of division line between Torque and the www.garagegames.com forums. This is unfortunate as many ideas get shouted down/derailed with defensive "party lines".

For the record, I do not believe Garage Games owes me or anybody else anything... and I apologize where my tone has been otherwise.

-J

#42 Representing "the community":

@Joshua: You rock! Guys like you, Beffy, and Melv (and others I'm forgetting) have made this community 1000 times better by exploring this huge engine and sharing your knowledge (and work) about it! You make guys like me want to do as much as I can to give back to the community and make it better, as well. In many ways, you're a role model for all starting independant developers!

@Jeff: I check GarageGames.com more times a day than my email. I'm serious about game development and I see GG and the Torque engine as my best ticket to do what I want to do for a living. I can't thank you and the GG Team enough for making the sacrifices to make this a reality.

Sure, I get frustrated when I find myself stumped on a programming problem for a few days... and I understand that the GG staff is very busy and can't always take the time to give me personal aid... but 9 times out of 10, there's one of the Joshua's there to nudge me in the right direction.

My point is, you guys mean too much to us to let a little misunderstanding cause friction. We're blessed to be surrounded by perfectionists who are bound to butt-heads once in a while! So, from "the community", a million thanks to you both!

Now kiss and make up! :)

#43 You are right, this isn't really about the STL. It is, however, about whatever the problem of the day is. We could spend absolutely more than 100% of our time cruising these forums, answering questions, and "fixing" every perceived bug or change in methodology that is on somebody's hot list. It would not make the engine better. It would be a declining asset, and eventually everybody would move on.

Most of you are here at GarageGames because you believe in what we do, think the Torque is good enough, that GG are doing the right thing, or believe in what we have done in the past. In other words, GG has a heart. We absolutely believe in what we are doing, but our mission is a lot bigger than what kind of memory manager is in a particular technology. We are forming a vision for the Torque, and it will be revealed when it is time. Nobody has ever done a company like GG and there is no manual to look up how to do it.

Of course we are open to ideas that are not 100% aliagned wiht ours, but I think there is a positive way of making a point. If anybody in the community wants to help us make Torque better that is ok, but comments like the following have a very negative connotation and make it sound like we are a bunch of slackers.

Quote:
Yup... thread should be renamed.. crushed by the TGE Memory Manager!!! Help!!! :)

It took 1 year and 2 months to get a statement on this problem from Garage Games... 2 days after a bump, and immediately after Jeff's comment, behold... a comment, I am not so sure bumping doesn't work :|

I can assure you, we are not slackers. Smileys or not, those comments are derogatory.

If you want to set up a CVS inside GG to help us make it better, then ask. If you have ideas for how to make the TGE a better "technology" platform rather than a game engine, then send us a proposal. Don't' however, try to put a round peg in a square hole, then try to make it fit with a lot of forum posts. We are very open to helping the community make the Torque better.

Jeff Tunnell GG

#44 *bink*

#45 Ok... just because some people seem bent on turning the world into a flaming pile of slag, doesn't mean we have to follow suit here :) We gotta get a little love flowing on this thread...

As I posted a couple of weeks ago (right before GDC), we're about to lay out a roadmap for the next major revision of the Torque. It's gonna be sexy, it's gonna be fast, and it'll pay all its bills on time. It'll be seperated into modular components, the renderer will take advantage of modern hardware, any and all Tribes 2 related cruft will disappear and comments will outnumber code lines (ok, the last one might be a stretch, but not by much ;).

We're going to need help to flush it out, help to code it, and help to evangalize its use as a vehicle for ending world hunger. For members of the GG community interested in technology development, this will be the chance to have input into the process from almost the beginning to the finish.

Torque as it stands now is a good, solid platform for game development. We are currently working on ways to make the Torque experience also a good fit for pure technology development. I think sometimes we here at GG are a tad sensitive to what we perceive as GG/Torque bashing, intended or not, by experienced members of our community. We've got big plans, and we're trying to make them happen as quickly as we can... please be patient, we won't disappoint.

More soon... I swear!

#46 Where do I sign up?

#47 @Jeff:

Frankly, I deserved some of that... I respect your opinions and appreciate your efforts... which makes your comments pretty hard on my soul...

I am always trying to fit round pegs in square holes... part of my job and being.

On the quotes:

I have seen *bump* as a pet peeve of yours before... bumping DOES work in forum situations. Unfortunately, the *bumps* here are often specifically targeted at Garage Games employees a lot of the time... and this indeed must be annoying...

On the crushed comment... this in reference to the problem not being specific to the STL and because I found the imagery of being crushed by it humorous... the smiley was not to hide some deep dark plot or to imply Garage Games was made up of slackers.

On the CVS, proposals, etc... perhaps I miscalculated, I didn't want to fill your emails in private... I have been very visible on your forums on many issues, proposals, and enhancements.. for everyone's benefit... the comments on this really smack me in the face... I'm not asking for a special status... I am looking for solutions, alternatives, different approaches, etc.

I am sometimes wrong, I sometimes make my point poorly... I am almost always loud.

On the edits... I am a hot head (and a perfectionist)... I find an edit preferable to leaving my wind publically visible... others may disagree

@MarkF: Cool

-J

#48 I don't think anyone is trying to bash on Torque or GarageGames, I started ooing to my local IGDA Chapter and evangelize Torque and GarageGames every chance I get, but I am not a GarageGames apple polisher either. Someone asks me about it I tell them honestly what I think it GREAT and what I think is not so great and frame it as an OPINION.

Torque is really awesome for the price, but it is not a "generic" as it could be to support MY vision of what my game needs to support.

I am glad to hear that some offical GarageGames support for refactoring the engine might be in the works.

Right now everything is very tightly coupled and making small changes in behavior in one area has unexpected side effects on other areas. A good example is the TerrainManager just thinking about looking at that code makes my head hurt :) there are so many gotchas, side-effects and undefined behavior once you start straying from the norm.

I really don't think GG needs to go very far on getting Torque to be a productive platform.

The art pipeline is a big stumbling block as is just learning the engine.

I mean it can do anything once you have the source, knowing where to cram a new piece of code takes lots of time to figure things out and then dealing with the side effects of the change is more time spent.

I will stray from the party line and say that as much as I appreicate all the work that Melv and the other folks have done on eye-candy and other things, especially Melv's fxRender resource which should be used as a model for how every resource should be documented, Joshua's Python contributions have had the most impact on my making progress with my project.

Having a real scripting language with 3rd party documentation that is over 10 years old and specifically designed for embedding and extending C/C++ applications is one of the heretic things that Torque should embrace as a standard. As clever as TorqueScript is it is much less productive and even less supported than a "standard" scripting language like Python and the IDE's that support it natively.

I had never really looked at Python until Joshua started discussing it on the GarageGames forums and made some really compelling arguments for it so I decided to investigate and see what the fuss was about. I was sold after seeing the clear understandable syntax that really does look like pseudo-code.

There is a new book out Massively Multiplayer Game Development, not that I am building a MMORPG, but it opened my eyes even more to the tremdous acceptance of Python as a standard scripting language for the game industry!

So GG, don't take things so personally. It is a forum after all and INTENT is very hard to communicate via text.

#49 Ok this is on topic!!!! I promise!

I have been doing some research on different custom memory management solutions some of which are quite recent trends some are old hat. From class level custom operator new to crazy templates and what not!

I have to say I still think the way the operator new is overridden in the global namespace is heavy handed. I also don't think a lumping the existing custom memory manager into a namespace is the "best" solution. But these are just my naive opinions :)

What I do want to know from someone is why was operator new not overridden at the class level instead? I went back to Effective C++ Second Edition last night and re-read up on overloading operator new and operator delete and all the pitfalls and strategies and what not.

Just out of curosity would using the plugable ability to switch memory handlers using set_new_handler be a better/worse/no difference solution? At least at the class level if they memory handler was switched out and back to global then we could have the best of both worlds?

I am looking for advice on this subject, would it be worth while to engage in some refactoring at this level of the existing objects?

#50 I really don't think having more than one global allocater in your program is a good idea. At the very least, you're going to see unnecessary OS allocation requests as each memory manager allocates large chunks of VM to parcel out to the app. You might think the way operator new is overloaded is "heavy handed", but it was made that way on purpose - to track every memory allocation the program does, so that all the debugging and profiling code would be useful.

My suggestion would be to just disable the Torque Memory Manager when using libraries that have conflicts with it, since it won't really be useful in general if it's not doing all the allocation, and I think it'll just get you into trouble to use more than one. Just my $.02 :)

#51 I think you mis-understood me Mark, I am not saying have more than one global memory manager but having them specific for each class or groups of classes. I think the profiling can and should still be done but at a more granular and flexible level, at least that is what the books I am studing about this seem to imply. I am sure the all or nothing way it is done now is "solveable" with some of these techniques, I was just looking for some ideas on a "community" solution and to try and get a DISCUSSION going on this, it is important to some of us, some really don't care . . .

It is obvious certain objects can and should come out of pools of memory, some are singletons or FlyWeight objects that do not come and go constantly. Others are much more dynamic . . . ect.

Anyone have any ideas other than quick and dirty solutions?

#52 Jarrod,

I think the point being made is that Garage Games doesn't see this as an issue... if you do, fix it...

I've had to here and there, for instance, the FSRad radiosity code doesn't like it, etc... there are plenty of bigger fish to fry...

-J

#53 Well I was hoping for some COMMUNITY feed back, regardless whether the offical GarageGames response is NAPWAD I was still hoping for some other COMMUNITY members to maybe give me some intelligent feedback or interest in making this core part of the engine a little less restrictive/more flexible?

I have never had to do alot of custom memory management coding before and apsergers kicked in and I bought about
$300 US in books about this and related subjects a few nights ago, some real feedback on some of the possible approaches in a game context would be educational.

#54 All I really know is that 'most' games I would have to say use this heavy handed approach to memory management anyway...if you don't your going to be subject to having the OS allocate the memory for you and memory fragmentation will become a nightmare to game content loading times and game performance entirely.

Now, Torque may seem to use a heavy handed approach but they by far didn't go far enough as it is. I've seen game memory managers where one big allocation is made for the game(like Torque does now), and then of that allocation, 'pools' are created for specific game contents to use. For example, sounds would get it's own specific chunk of that pool, meshes would get their own chunk, interiors their own chunk, and so on and so forth. This concept further helps combat memory fragmentation because then each object of the same type is guaranteed to be in the same relative area of memory. To my knowledge, Torque doesn't use that approach for most things, except the Terrain.

#55 @Robert - Thanks this is what I am looking for, it validates my plans which is to do some cacheing and pooling of memory. But I want to try and do it in a more object oriented manner at the class level instead of at the global level. I am interested in your view that they did not go far enough, that means anything else that might get added should not be a wasted effort then.

#56 Jarrod,

Check out Paul Nettle's memory manager towards the bottom of this page. Might give you some ideas...

It may be compatible with STL, etc... I haven't tried it... want to make a report? :)

-J

#57 @Joshua thanks for the link I will research that and post a follow up, maybe in a new thread since this one seems to have alot of "emotional" baggage ;)

#58 Maybe GG should just make the TGE code go into a namespace called TGE. Wouldn't that fix everything all at once?

#59 Not really... :)

#60 Mark Frohnmayer's last statements are right on. I gues you should make a choice between one TGE mem management or STL mem management. There seems to be no good way to use both.

I'm using TGE 1.2.1. I added the preprocessor define

TORQUE_DISABLE_MEMORY_MANAGER

and #ifdef'd the code in winMemory.cc :

//hide redefinition of new when ...
#ifndef TORQUE_DISABLE_MEMORY_MANAGER

void* FN_CDECL operator new(dsize_t, void* ptr)
{
   return (ptr);
}   

#endif

After a full recompile, there is no noticable difference from when I used TGE mem manager. (haven't done any serious benchmark tests though. Also I'm using VC++ 6.0)

I am working on AI code and will need to allocate large amounts of memory (up to 10MB). Could this be a problem without TGE mem manager? Has anyone encountered any problems with disabling TGE mem manager?