Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 27 Aug 2002
Offline Last Active Today, 12:46 PM

Posts I've Made

In Topic: leave function definition "empty" (c++) ?

Today, 02:42 AM

Considering this involves gameplay data I would be careful in using code constructs to do this. What about something along the lines of:

typedef std::map<gameItem*, std::string> SpecialNamePool;
// ^ one of those created somewhere, populated at runtime with data, possibly dynamically updated


char * gameInventoryMaster::getItemName(gameItem * uu)
    // assume SpecialNamePool *namePool = some persistent object, also std::reference_wrapper will do
    if(this->namePool) {
        auto spec(namePool->find(uu));
        if(spec != namePool->cend()) return spec->second.c_str(); //<-- ok, don't do that. Really. Not even valid code. Maybe return std::string
    return IDATA[uu->type].name;

Note this buys considerably more flexibility than you probably need and in some cases isn't even viable but this is a data-oriented problem and should be solved with data IMHO.

In Topic: Dynamic Memory and throwing Exceptions

Today, 02:27 AM

Maybe worth recalling somebody isn't AAA. Exceptions are extremely handy and considering the first few posts of this thread are clearly written by someone who doesn't have an accurate view of what's going on, I'd suggest to stick to what C++ suggests to do as canon as long as there isn't a specific product to talk about.

In Topic: Component-based architecture - entity and component storage

26 February 2015 - 01:06 PM

As a side note, if physics is your stuff, play with some physics API first!



Then you have a really weird definition of a component. His game objects are very clearly composed and not monolithic. That's all using components means, in any context; ECS is _hardly_ the first place the word "component" has ever been used in computer science or even game development.

Well, you got me there. I should have been more explicit in intending the word component in this case is to be intended uniquely as intended in CES.


In Topic: Believe reports about Next Gen Computer and API Performance?

26 February 2015 - 09:22 AM

There has been a lot of press releases and discussions about both computer and API performance jump in the next generation. Do you believe it and why?
Depends on which rumors.

The 100x more drawcallz meanz 100x more perf... no, not at all. Synthetic benchmarks do not always translate in real world usage.


The "twice as fast in the real world" yes, I believe that easily.

In Topic: Component-based architecture - entity and component storage

26 February 2015 - 09:06 AM

No idea what exactly is going on there but what you have done isn't a component thing to me.

Just because you can put arbitrary "component" object handles inside an array, which allows you to build "entities" does not mean you are component based.

The above is not component based either, it's switching behaviors exactly like a monolithic entity would do. I'll agree that has some very slight flexibility added.


No idea what a "physics" component is supposed to be either. I assume it is a rigid body representation.


Here is ECS, condensed to the its core.


There are no entities. There are only the components.

See Fig-2.gif



The message "between the lines" and showcased in the above diagram is: the execution/update of components is independent from other types and can be - in theory - completely asynchronous. I dare everyone in writing a fully async, fully ECS-only system but that's for another time.


So, what does that mean? It means basically the opposite of this:

One idea that came to mind was having a vector of pointers for each type of component and passing the corresponding vector to the corresponding system.

You should really have the components exist in the systems only and link to them on need rather than keep them floating around and putting them back in on need. Seriously, where do you think rigid bodies are going to go each frame? In the physics library. Where do you think the models will go if not in the rendering subsystem? No point really in taking them out: you take out reference / pointers to them and leave them live in their own land using a base class or a proxy of some sort. Internally the subsystem accesses everything it needs while externally you don't.