100% great.

Pretty much what phantom said.

You want deterministic memory usage... write your own allocator. Why reinvent the wheel? IMHO the best thing about the STL and to a lesser extent Boost is that it is a standard. Learning specifics to an engine or company because they've decided to roll their own rather than use something most people should already be familiar with is crazy. The exceptions occur when you want to be doing something REALLY specific or are working with a legacy codebase.

Quote:Original post by BlueHabu
I don’t know what "continuously streaming" means, but I am sure you have done some performance analysis of the STL on the PS2. Care to share?

I'd be very suprised if he didn't mean continuously streaming in content from DVD, HDD or similar.

Absolutely we use STL on console games. The main problem of lots of small allocations is trivially dealt with by writing your own allocator. The neat thing about the STL is that you can guarantee that not a single byte is allocated without you knowing about it and being able to change its behavior.

-me

Quote:Original post by Christer Ericson
What I tried to point out, without having to go into a lot of detail is that we have very strict memory use (see below) and trying to coax something to adhere to our rules just isn't worth the effort especially when we can write a version that suits our needs in half the time it would take to "fix" some other system.

To be honest it all really boils down to familliarity with the STL and somewhat of a religious issue. It's trivial to "fix" the STL for games(console or otherwise) w/r/t memory management/fragmentation if you know what you're doing. Even then though, there are a lot of people who just won't use the STL either due to not being familliar with it or because of something akin to whether or not an opening curly brace should be on a newline or not.

The bottom line is preference. If you like the STL and know it well and want to use it for console games it's trivial to "fix" it. If you just don't like the STL or aren't really familliar with it, then it's easy to write your own container. There are zero technical reasons that you cannot use it. It's just an OpenGL v. DirectX religious war.

-me

Quote:Original post by Christer Ericson

Quote:Original post by meh
You want deterministic memory usage... write your own allocator. Why reinvent the wheel?

What I tried to point out, without having to go into a lot of detail is that we have very strict memory use (see below) and trying to coax something to adhere to our rules just isn't worth the effort especially when we can write a version that suits our needs in half the time it would take to "fix" some other system.

This is assuming that writing/debugging/mantaining an appropriate STL allocator takes twice as long as writing/debugging/mantaining an appropriate non-STL allocator plus the special containers (plural) that use it (not to mention any bugs caused out of unfamiliarity with project P's containers by newer teammates).

Which sure dosn't make sense to me unless the allocator interface is badly incompatible with whatever you're trying to accomplish. And I dare say that I don't think that it is for preventing memory fragmentation, or similar.

There will be exceptions, of course, if you're more familiar with what you may have repeatedly written, than you are with the STL, but that is a matter of personal experience rather than STL being somehow harder in general.

Jesus Christ...I am truly amazed with the things I see posted on this forum.

Christopher is, and I quote from his site, Director of Tools and Technology for internal development at Sony Computer Entertainment America in Santa Monica, and you people are...who exactly? Someone called phantom, another called funny... Learn to show some respect to the TRUE professionals of the industry that you claim to support and STOP BEING ELITISTS.

To Christopher

Don't waste your time with these bozos. You are a professional who speaks eponymously and civilly on the Internet, both of which are your credit. It seems to me that some of these guys are just hoping to "debate" with someone of your STATURE so that they can tell their friends at work (i.e. tech support offices) how they PAWNED a professional of the game industry. I remember there was another thread where another author, like yourself, debated with some of these guys and ended up being insulted multiple times (sarcastic comments and the like). I am appalled...

He is providing great help, and although your right, not everyone is a professional like him, or probably as intelligent as him, people are just giving their opinions and thoughts. Maybe they learned things wrong or their opinions are skewed, don't go off on them, and he's not wasting his time. These forums are one of the greatest assets to up and coming and recreational game developers. They are an amazing resource, and he is helping out in conversations that hopefully people can learn some things from, I know I did, and it helps, so don't say he shouldn't be in here discussing these issues. People take them seriously and his input helps us learn what is the best way of doing certain things and just helps people learn things to a more full extent. So thank you Mr. Ericson, cheers,

-Karakadin (a current CS major who really appreciates you being active in the forums / community)

Quote:Original post by Anonymous Poster
Jesus Christ...I am truly amazed with the things I see posted on this forum.

Christopher is, and I quote from his site, Director of Tools and Technology for internal development at Sony Computer Entertainment America in Santa Monica, and you people are...who exactly? Someone called phantom, another called funny... Learn to show some respect to the TRUE professionals of the industry that you claim to support and STOP BEING ELITISTS.

This is commonly referred to as the fallacy of authority. That is, somebody's being an authority doesn't make them right, although it certainly indicates that such might be more likely. In any case, people are pointing out a number of valid contradictions to the assertion that STL/boost are useless on consoles, so citing authority isn't going to cut it as a rebuttal. And yes, some of us might just be professionals as well.

In any case, I think the first question that has to be asked is WHAT PARTS of STL/boost are in question? It's not like they are all or nothing propositions--you can choose to use as much or as little of them as you want. Are we talking iostreams? In my opinion (just mine mind you) those barely even cut it for PC games, let alone consoles... Perhaps collection classes? Well, that depends on the collection. std::vector, for example, tends to have extremely deterministic behavior--much moreso than, say std::map (which again shouldn't really be used much in PC games either). As far as boost goes, some of its classes are specifically designed to PROMOTE deterministic memory behavior. Memory pools anyone? On the other hand, I certainly wouldn't try to do any sophistocated template metaprogramming (boost::mpl) in a console game (but again that pretty much applies to PC games as well IMO). And on top of all that there's the potential, as has been mentioned by other posters, to write custom allocator classes to get complete control over memory usage.

To put it bluntly, there are a good number of reasons that a categorical rejection of standard libraries as being universally useless on consoles is, shall we say, somewhat misinformed. I haven't done any console programming per se, but I have used such techniques in other embedded systems programming (often on even tighter memory and processor budgets) quite successfully. It's just a matter of putting in a bit of time and effort to learn the inner workings of the library in question (not difficult because source is obviously available) so you KNOW what's going on. Even then if you don't like it, you can always change the parts that don't do what you want rather than reinventing the wheel.

But please, appeals to so called "authority" will not avail you without meaningful argumentation to back them up...

EDIT: I think the original poster hit the nail on the head anyway. It's not so much a matter of template libraries being ill suited to consoles, it's a matter of compilers for consoles--at least those I've seen--being incredibly ill suited to template libraries. They just don't tend to be anywhere near as sophistocated as their desktop brethren.