Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 24 Apr 2011
Online Last Active Today, 07:54 PM

Posts I've Made

In Topic: Mutexes and the render thread

15 September 2016 - 12:22 PM

The problem is that I have a voxel game with chunks (similar to Minecraft) and I generate these chunks multi-threaded. I definitely need some sort of map for the chunks and I think I need a lock everytime I access the map. I already create the buffers themselves in the render thread, but I need a lock for accessing the data these buffers should be filled with.


Any idea on how to create the chunks multi-threaded but without locking - and remove them if they are too far away?


Generally speaking, look at a copy on write model instead of a lock on write model.  This should get rid of any vb/ib locking outside of the renderer at the cost of a memory copy when you have prepared all the data and sent it to the renderer which will then perform the lock/copy/unlock without sharing issues.  Playing with thread priorities and such things is generally a bad practice as it may work good on one machine and not another due to different virus scanners, services running etc.

In Topic: Recalculate trajectory?

01 September 2016 - 08:28 PM

Making games is all about cheating... big time.  That effect has nothing to do with physics or proper motion, it is simply a trick that looks nice.  There are several ways they could pull it off, but given it has to happen on a timer to hit the 'heal tick rate', I suspect it is very simple.  If you ignore the trajectory portion, they are basically just interpolating a line between source and target to control the position.  So, you interpolate a value 0-1 between two points which track source and target based on the 'tick' rate of the spell.  It looks smooth even in 2D without height applied since it still gets to the target at 1 eventually no matter how the source and target move.  Then you apply a height value to the particle probably via sine of the 't' in the linear interpolation and some max height.


It is a cheap, dirty hack that looks good.  Nothing very fancy, just a lot of cheatery.. :)

In Topic: need a algorithm to update skin mesh global AABB

13 August 2016 - 09:29 PM

Dirk's suggestion is probably the most common solution and JoeJ's would be effective.  But, if you have need of tighter bounds the manner I've always used is to simply compute the bounds into the animation itself at point of export.  It's the same cost as computing an extra joint and you can get accurate bounds.  If you are doing blending, you simply take the max bounds of all running animations.  It is not quite as performant as a single unified bounds but it is better than the capsule method since you have no traversal involved, but it is not as tight when using blended animations.


At this point, the suggestions should solve whatever you are looking for.  The benefits/detriments are:


Unified bounds:  No computation overhead.  Sloppy so often animating even if not in view.

Capsules: Relatively tight bounds.  Requires a hierarchical traversal, can cause cache issues if you have lots of characters.

Animation driven: Perfect for single animation, not as tight as capsules when blending animations, but tighter than unified.  Cost is the same as an additional bone in the skeleton and costs no traversal.

In Topic: Where To Place External Libraries

02 August 2016 - 10:27 AM

As Paragon says, it depends on your intentions.  I personally use two git repositories which has it's own downsides but has some preferable bits.  So I have project x in git 'x' and its dependencies in 'x_deps'.  I build x_deps, copy the appropriate headers and the built libs (automated via CMake in my setup) into a folder of 'x' such that when working in x I have the minimal needed set of items.  Those get committed with the source so everything is usable without messing around.  Anytime I need to update an external I jump back to x_deps, do the updates and recopy the includes and libraries to 'x'.  This has benefits in terms that my primary work repository stays relatively clean and small but it can be a hassle to update libs since I have multiple targets and have to move from machine to machine updating the libs.


It is one one of doing things.

In Topic: Multithreading Library Preference

30 July 2016 - 04:58 PM

Another reason folks end up rolling their own is that the available libraries are not always available on all the desired target platforms.  Additionally in house threading is specialized for games which can get very specific gains.  Having written a number of threading solutions for shipped titles, these were the reasons we didn't start with some existing solution.