Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


Shannon Barber

Member Since 23 Jun 2000
Offline Last Active Dec 07 2014 07:27 PM

Posts I've Made

In Topic: Casting Pointer to Derived Type

16 November 2014 - 12:02 PM

Performance et. al. are not arguments in this matter.

 

dynamic_cast is thee mechanism designed into C++ to handle the exact scenario the OP is asking about.

 

If you don't want to use RTTI then you can't use RTTI and down-casting properly requires RTTI.

If you turn it off, you are just going to have to implement it yourself with a virtual call to get an enumeration (and design some mechanism to ensure those ID's are unique).

Next is if you use a interface-based design then your RTTI implementation is going to have to handle reporting multiple IDs ...

COM's QueryInterfacePointer is the abomination that resulted from going down this path.

 

If you have a tree or whatever of ITiles and want to know which of them implement ITilePlayer then you check for that when you put the instance into the container (with dynamic_cast) and maintain a second parallel container with just ITilePlayer's in it. Now you can iterate the player tiles without testing for it during an iteration of the general tiles thus avoiding dynamic cast during the part that matters. (Since it's a mix of different types of tiles, static_cast is not appropriate.)

 

I personally wouldn't consider the player a tile - I would have an 'overlay' concept the movable entities / sprites implemented.

Render in two (or more) passes. Render the tiles then render the entities (overlayed on the tiles).

You now have a game-engine reason to main separate list of the different things as well.

 

Though it does beg the question why not just have two functions to add stuff to the game and treat the tiles and entities differently (thus avoiding RTTI & dynamic cast entirely).


In Topic: A short discussion on PODs

31 October 2014 - 09:34 AM

Under C++11 POD's can have trivial ctor's & dtor's. I think you can even inherit (with restrictions).

 

Practically speaking you just can't do anything that results in the class having a vtable.

 

This has all worked for years it just was guaranteed by the standard.


In Topic: Is optimization for performance bad or is optimizating too early bad?

31 October 2014 - 09:13 AM

If you don't know how to organize your data for optimal execution then it doesn't matter.

You have to learn that first.

Changing this generally means a rewrite.

 

By the time you measure it is "too late" to do anything easy about data access.

All you can do is find terrible algorithm mistakes that were made and remove them.


In Topic: Poor STL threads performance

31 October 2014 - 09:06 AM

Timing debug code is a waste of effort. Always time release builds.

You don't have 64 cores so making 64 threads will not help.

 

You have to create the threads in advance and they need to be waiting there ready to go. As mentioned above create and destroying threads is, relatively, expensive.

You should only make 2 to 8 threads depending on the capabilities of the hardware it's on.

 

 

FFT's are one of the most computationally intensive things you can do. They produce mathematically "perfect" frequency results.

This is probably not needed for a game. Look for simpler approximations. I would start with the Hartley transform.

Also, somewhat ironically, I have an old FFT article here on gamedev with an optimized routine for it.


In Topic: My goodness multiple inheritage is like a taboo. Why?

31 October 2014 - 08:53 AM

Multiple interface inheritance is regarded as good OOD.

Multiple class inheritance gets complicated quickly and there's often a simpler way to accomplish the same thing (that is often more flexible/powerful as well).

 

The one semi-useful scenario I have seen for MI is if you design your interfaces and then create "optional" mix-in classes to provide default implementation for those interfaces.

Then you can quickly put together your spread of objects which will execute and you can refine their behavior over time.

 

You might have an interface for IWeapon and IDegrades. The default Weapon class behavior might require contact and do 1 damage. The default Degrade class behavior might be it degrades 1 point per minute. Later you might make a sword degrade an extra amount when it does damage and replace the default classes.


PARTNERS