chondee

I'd guess Line 20:
g.fillRect(spaceShip.xpos+xOffset, spaceShip.ypos+yOffset, 20, 10);

where the offsets are the x and y distances from the top left corner of the spaceship to the point where you actually want it to spawn (middle of spaceShip)

Thanks for your help, I'll try your example, my uncertainty in this topic is because I didn't work with custom << operator before.

I guess it comes down to this:

Do I have to sacrifice one of the following:
1. String based color tags and macros
2. <<Operator for string conversion of variables

for this to be possible in a one line statement?

Edit:
If yes, than for THAT I could actually use a macro that aggregates the stringstream statement and the myFormattingCout(stringstream.str())

If it is however possible without a macro I would rather take that, so please let me know if you think it is.

Thanks for your replies doeme and mrjones!

The reason I would like it string based, that in that way I could also parse text from files that will be formatted and colored the way I want.

The reason I don't want to use hardcoded macros is because I would like my engine to be able to handle per-project custom tags, such that a file can be parsed that describes a list of custom tags and their corresponding custom strings (defined by the user without knowledge or access to engine code) that they resolve into and will be placed in a std::map<string, string>
example : "/goblin" = "/fgCyan GoblinName: /fgDarkGreen /bgWhite"

Any ideas?
Or is this impossible with a one liner? (like a cout statement?)

Hmm, the above example of a component based system really makes me confused as it completely goes against what I have believed component based design stand for.

I thought that ideally there should be only 1 entity type, that doesn't differentiate between a weapon, a rock or a spaceship.
I have also thought that the components should be mostly uniform, or at least to the entity (as to the entity the only interface open is Update() towards component).

For example in your sample, what if that character system works for almost every character, but one guy is on fire and needs a particle emmitter component?
Do you rewrite the whole CharacterEntities class and add a vector for particle emmitters, that won't ever be used on 99% of the characters, or do you accept the limitations of the CharacterEntities class and represent the flaming guy in his own class, as an exception? How about the player character? Should all characters have some function, or component vector for components that handle input, or playerCharacter needs a separate class? Or if you want to include a special weapon that works differently for every other one, should the whole Weapon class get rewritten because of it?

I though things like these were the reason why game development started to shift towards component based design from object oriented.

Please correct me if I am seeing this from the wrong perspective, or if my picture on component based design is wrong.
This is what convinced me of redesigning my engine to component based: GDC_Powerpoint_OOvsComponentOriented