Jump to content

  • Log In with Google      Sign In   
  • Create Account


Boreal Games

Member Since 24 Oct 2011
Offline Last Active Yesterday, 09:57 PM

Posts I've Made

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!)


In Topic: Entity component system: efficient component retrieval?

07 January 2014 - 02:31 PM

 

Check out the articles in my signature for how I do my components.  They're basically just arrays of components (one per type) and another array of component masks.  An entity is the aggregation of all the elements at a given index in the arrays, where the component mask describes which components "exist" (are turned on). It's cache friendly and requires no memory allocation past the initial allocation of the arrays.


I'm not sure I agree that components must be data-only and you also specified that systems operate only on groups of components when they all exist. Not sure what you meant by that but doesn't that negate the plug-and-play nature of ECS?

 

 

Nope, my system is perfectly plug-and-play.  The systems read the component mask to determine if they should act upon the component data for that entity.  If you're "adding" or "removing" a component, you're just modifying the component mask to change the visibility of the component to the systems.


In Topic: Entity component system: efficient component retrieval?

05 January 2014 - 09:45 AM

Check out the articles in my signature for how I do my components.  They're basically just arrays of components (one per type) and another array of component masks.  An entity is the aggregation of all the elements at a given index in the arrays, where the component mask describes which components "exist" (are turned on).

 

It's cache friendly and requires no memory allocation past the initial allocation of the arrays.


In Topic: Designing an efficient multithreading architecture

10 December 2013 - 07:08 PM


I personally use my "main thread" as a worker thread too. Whenever any of my threads has nothing to do (e.g. it has to wait for the results of another thread before it can continue), then they make themselves useful by popping jobs from the job queue and doing some work. I basically have a "WaitFor..." busy loop, that continually checks if the condition has been met to exit, else tries to run a job, else after enough tries with no jobs in the queue it yields or sleeps.

Ah, that's a good point.  I could allow the I/O thread to do a work job as well if there are no I/O jobs pending.

 


Regarding embarrassingly parallel jobs -- in order to move these off to the GPU, you also need the consumers of those jobs to be ok with extremely long latencies. It's not possible to get short CPU->GPU->CPU latencies on PC without destroying overall performance.

There aren't going to be many (if any at all) circumstances where a CPU step depends on a single GPU step, no.  I want to keep what I calculate on the GPU on the GPU, so to speak.  The only instance I can think of is using the CPU to do narrowphase CCD after the GPU does broadphase pruning for collision detection (ideally, I'd do the narrowphase on the GPU as well, but I can't think of any good GPU-friendly CCD algorithm),

 


Also, don’t “spawn” threads, awaken them. They should already exist and just be idling in a waiting state, waiting for an event to set them in motion.

And a “wait” state is not a “sleep” state.

Whoops, mixing up my terminology here.  Yes, I plan to have these worker threads always running and waiting for jobs to be queued, not spawned with the jobs themselves.


PARTNERS