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!

Shannon Barber

Member Since 23 Jun 2000
Offline Last Active Apr 07 2015 09:52 AM

Posts I've Made

In Topic: CMake or Custom ?

07 April 2015 - 09:26 AM

I would not use a custom build system.


Every time I have tried something else I have always come home to GNU make.

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.