Jump to content

  • Log In with Google      Sign In   
  • Create Account

Boreal Games

Member Since 24 Oct 2011
Online Last Active Today, 02:47 PM

#5183961 inheritage with classes

Posted by Boreal Games on 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.

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

Posted by Boreal Games on 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!)

#5116029 Designing an efficient multithreading architecture

Posted by Boreal Games on 10 December 2013 - 04:38 PM

If your jobs are the kind of "update culling", "animate n entities", definitely run them also in the main thread, especially if your frame processing cannot proceed further without completing them first.

Do you think it's better to run jobs on the main thread or instead spawn an extra worker thread and let the main thread sleep while there are jobs still pending?

#5116008 Designing an efficient multithreading architecture

Posted by Boreal Games on 10 December 2013 - 03:37 PM

You probably know a lot more than me, but it may be worth pointing out that every time I see someone ask about multithreading the overwhelming reply is "Don't!". As unless you really know about all the pitfalls it can bring it can just be more trouble than it's worth.

however maybe you do know your stuff, in which case good luck smile.png

Oh, I know what I'm getting myself into.  I know all the issues about memory racing and whatnot across threads, so I'm going to minimize the number of times that threads need to synchronize, and use locks properly when I need to.

#5115996 Designing an efficient multithreading architecture

Posted by Boreal Games on 10 December 2013 - 03:04 PM

I'm designing an engine for my big 3D game project, and I want to make sure everything is very scalable to processors with many cores, without having more threads than necessary spawned at a time.


This is the architecture I'm considering right now in terms of different threads:

  • 1 scheduling thread
    • Runs the main loop
    • Spawns work and I/O jobs
    • Sends draw/compute calls to the GPU
  • 1 I/O thread
    • Blocks on calls to fread and fwrite
    • Spawns work jobs for decoding
  • 1 sound thread
    • Runs from within OpenAL or satisfies SDL audio callbacks
  • n worker threads, where n = ncores - 3
    • Run serial work jobs (embarassingly parallel jobs will be run on the GPU)

While this makes sense to me for processors like Intel i7's or AMD FX's which generally have more than 4 (logical) cores, for a 4-core processor like an i5, there is only one worker thread.

Should the scheduling thread also be able to run work jobs?  If so, is it safe enough to have any thread be able to send draw/compute calls to the GPU (using OpenGL 4)?

#5050992 Questions about Entity-Component Systems

Posted by Boreal Games on 07 April 2013 - 04:17 PM

First point


I gravitate towards keeping components as pure data and having systems provide implicit, automatic logic.  Among other things, it makes inter-component dependencies much easier, as a system (and thus a task) requiring more than one component type will ignore entities that are inappropriate.


To use your example of a Movement component, you propose lumping position, velocity, and collision detecting together.  The problem with this is that it enforces rules that don't need to exist, such as "every entity with a position is movable" and "every movable entity is collidable".  You should split it up into three separate components with three separate domains of data:

  • Position
  • Velocity
  • Collision (shape)

The systems that you should use are:

  • Movement (adds velocity to position)
  • Collision (checks between collision shapes at positions)

As you can see, entities don't need to be movable or collidable to exist spatially, simply give them a Position component.  This is useful for purely aesthetic static objects.  Entities also don't need to be collidable to move, and don't need to move to be collidable.  The latter is useful for static platforms and obstacles, while the former can be used for dynamic background props.


The key thing is that dependencies are automatically resolved if you have a system to detect when a system's desired component group is formed or unformed, registering and removing that entity from that system.


Second point


Components should all derive from a simple base class that holds the entity that component is part of.  I'd avoid any deeper inheritance than that.  You can use inheritance when designing your entities; for example, a robot chicken derives from a chicken class and adds a Robotic component (a bit contrived, but you get the idea).


Third point


The change in executable size will be negligible or even beneficial if you move entity definitions into data.  In terms of runtime performance, entity-component-systems are easy to parallelize because, generally, each system operates on each entity independently.

#4885865 Game Design Question (iOS Game)

Posted by Boreal Games on 20 November 2011 - 07:27 AM

I've seen a lot of games with a minimalistic UI pause when the user puts down, say, 3 fingers at the same time instead of one.