Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 22 Jul 2010
Offline Last Active Yesterday, 05:18 AM

Posts I've Made

In Topic: A good way to handle managing bullets/projectiles

11 July 2016 - 08:59 AM

I have used object pools combined with linked lists for this kind of thing in the past. Provided you don't need random access to a projectile it should work just fine.

Pool allocates and stores references to the objects, it can create a bunch upfront based on and educated guess and expanded if needed at runtime, uses a vector behind the scenes and a pointer to the last unused item.

Then you just run though your linked list in the update function advancing and collision testing. It is then extremely fast to add/remove projectiles from the linked list and return/retrieve them from the pool. Most of the time there will be 0 allocations and 0 vector resizing/copying. It is not as cache friendly as blasting though a flat vector but plenty fast enough and the ease of implementation is a real plus.

There are no doubt other ways, this is just something I have used successfully many times and is both easy on the GPU and minimises memory allocation/GC.


In Topic: Help with Farseer Physics Engine Slowdown

29 June 2016 - 10:27 AM

Another option might be to disable the collision physics for the first few frames of the bullets life to given them a chance to not all be on top of eachother which is a worst case scenario for phyisics. Do look into the collision masking though as that could well be the fix you need and should be very easy to turn on.

In Topic: Batching draws - keeping buffers up to date

15 June 2016 - 04:11 AM

I really like this question (or set of questions) as it presents a large number of the issues developers in your position face.

From my experience if you are already on the right track, you identified a large bottleneck and improved it.


What you need to avoid it trying to catch/handle every situation in the most efficient way - this can often end up worse! I recommend an approach that doesn't try to solve all of the issues but just the main ones. Often enough the performance of such a solution is plenty good enough for most applications.


If you are optimising your engine for this game and this game alone things might be different, but suppose you want to use the engine for a future game one that has more transparent objects, or transparent objects completely mixed in with opaque ones all over the place? Then a seemingly good solution might end up being a bad one.


In terms of over complexity avoiding you could start with very simple dirty flags for things like children changed or not, rather that trying to work out which exact child was removed or added it might be easier just to know IF one was added or removed and respond accordingly, hope that makes some kind of sense.


You will have to make those calls though based on your needs.


That said some kind of double buffer might work for handling changes (or lack thereof) well i.e. for each frame swap buffers and copy large chunks from the last one where possible when no changes occur otherwise just write in the new data.

Just remember that blasting through more linear data can often be faster than jumping around all over the place trying to avoid unnecessary work due to cache misses anyway.


Look forward to seeing other replies in here :)


In Topic: Directional lighting trouble.

07 June 2016 - 08:51 AM

Use vertex normal and pass it to fragment shader, renormalise it, then use that.

If you use normal mapping you can use the normals from that.

So essentially just dot the normal against the transformed light direction (which should now be in the same space as the normal)

In Topic: Directional lighting trouble.

07 June 2016 - 08:38 AM

don't "translate" the direction to model view, if the model has any position other than 0,0,0 then it will break the normalized direction.


use a m33 rather than an m44 to "transform" the light direction into the models space without taking any translations into account, i.e. only scales and rotations as they are the only things that matter for a directional light.