Jump to content

  • Log In with Google      Sign In   
  • Create Account

Boreal Games

Member Since 24 Oct 2011
Offline Last Active Jan 23 2015 01:07 AM

Posts I've Made

In Topic: Multi-threading for performance gains

27 December 2014 - 04:16 PM

The way I would structure it is to have one thread for logic scheduling and one thread for graphics/audio/input scheduling, and then saturate the rest of the cores with worker threads.  However, I would only suggest separating the logic and "not logic" threads if you have them decoupled through some sort of buffer, as you would if you were implementing a fixed-update variable-render game loop.  In my mind this type of threading only works if you have that kind of architecture.  Ideally this is also utilizing a sort of MVC where the logic system is completely agnostic to the "not logic" system and its implementation, which is a big deal if you plan to do anything cross platform.

In Topic: Improving component system

01 December 2014 - 04:59 PM

Another solution for dealing with related bone transforms is to consider them as higher-level things of their own rather than an explicit parent-child relationship.  Think about how a weld joint works in a physics engine.  This may not always be the best way to do it but it provides an elegant solution to situations such as the presented case of the cup on the table, where neither entity should be dependent on the other.


And when it comes to using packed, unordered component pools with systems that operate on multiple component types, you should have an array acting as a layer of indirection that maps IDs to offsets within the pool.  This structure can also deal with handle invalidation through "magic numbers".  Again, BitSquid has a good article on this concept.  If you're worried about cache coherency when it comes to these indirected accesses, my advice would be to deal with different object archetypes in heterogeneous ways.  For example, if not every entity has a velocity while every entity has a position, separate your entities into "static" and "dynamic" pools.  That way, your "dynamic" entities can keep their position and velocity components packed and correlated.

In Topic: is there a better way top refer to assets in a game?

17 November 2014 - 04:10 PM

In my system I've been developing I do as Zipster says.  There is no reason for the native code to deal with specific resources - it's all routed through script.  Since I'm implementing a sort of Scheme dialect, I have hashed keywords out of the box, which work just fine.  I limit the use of strings strictly to user interfaces.


My reinterpretation of Zipster's example would be:

(entity gigantopithicus
  (attack-sound :gigantopithicus-attack.wav))

In Topic: inheritage with classes

29 September 2014 - 10:49 PM

I do not need inheritage. It would be nice if I did since it would fulfill another  personal quota for the project but I do not need it.


Never ever ever ever ever ever use a programming pattern just to use it.  Most of the time you will be making the wrong decision.  Code should evolve from your needs, not the other way around.

In Topic: New trends in gaming: voxels are the key to real-time raytracing in near-term...

25 September 2014 - 12:27 AM

Plus, you have to deal with the issue of animating those suckers.


If you need procedural/destructible terrain or something it's much easier to polygonize voxel data using an algorithm like dual contouring (which I advocate over Marching Cubes as it has no corner cases and can handle sharp edges!)