Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 22 Jul 2010
Offline Last Active Yesterday, 03:24 AM

#5197128 Drawing many enemies

Posted by bwhiting on 09 December 2014 - 04:58 AM

I did a demo here of upto 100,000 animated sprites that can run in a flash enabled browser providing you have a machine decent enough to handle it.


The source can be seen here:


It uses indirect addressing in the shader to batch as many draws into one draw call as possible.


The technique means you don't have to modify vertex buffers every frame, but rather offset everything with shader constants.


You can do it the other way too, by just modifying vertex buffers on the cpu and re-uploading them and it will enable you to batch much greater numbers together than the method I used but each has it pros and cons.


On many devices I have found the approach I used to perform better anyway, and it also scales better with more complex meshes, as you have less data to update on the CPU every frame (same for 4 verts as for 40 or even 400). But you are limited by how many vertex constants you can upload.

#5188618 Scenes with large and small elements

Posted by bwhiting on 22 October 2014 - 04:00 PM

probably not much help but pretty cool all the same:



also might be worth looking at the answer to this q:


#5187112 How to Separate the Rendering Code from the Game Code

Posted by bwhiting on 15 October 2014 - 02:49 AM

Just to kind of echo Promit, that is how I separate the two.


A render lib can essentially be as simple as this:


function render(material, geometry)


     //rendering done here



The your game/app is just a system where by you organise a series of calls the the renderer.render function by whichever means suits your purpose.


The renderer  knows nothing of how you structure your game/app, it just sits there waiting for things to draw.

What you draw, the order you draw it, where you draw it... all this information is constructed outside of the renderer.


(obviously this is just high level speak and things can get a little more complex but in general you can make things work like this and it is very flexible)


For instance, a wrote a quick space shooter game using a bitmap blitting renderer and once it was done I was able to swap out the renderer like for like for a GPU based one. Took next to no time at all because there was so very few connections between the two systems.

#5186536 Antialiasing artifacts with render targets (or something else)

Posted by bwhiting on 12 October 2014 - 01:52 PM

Can you post your shader? Is it possible that the values are not clamped and are overflowing?

Also does it do this at all AA levels, i.e. 2 4, 8 and 16?

#5172316 Sorting a bucket

Posted by bwhiting on 08 August 2014 - 11:04 AM

you won't need to extract anything from the keys, they are purely for sorting.

once sorted you should already have the data you need in the original objects


the more weight you want any key to have you just ensure that those bits are more significant

so if you want to prioritise material, then just make sure that its bits are shifted higher. 


your play around above is a great start in the right direction!

just sort your objects based on that uint and boom - roll in your success.

#5167117 Game engine architecture

Posted by bwhiting on 16 July 2014 - 04:35 AM

Firstly get ready to re-factor... a lot.

Secondly keep things simple to begin with.

Many opt for an entity component system as it is flexible, you could take a look at unity as an example of one. Each game object has a number of components such as meshes, transforms, renderers etc...

It might give you some ideas anyway.


But start small! Don't try and solve every problem at once or you will struggle!


The idea of an engine is generally to run though a set of objects created by the user and update them based on some rules (such as physics) then draw them to screen.

Get that working first, then flesh it out as you go along exposing more control to the user as you go. Let them tweak positions, velocities, material textures... simple things like that to start... get that working and you will have a nice starting point!


Good luck

#5166986 What did they used to develop Shovel Knight

Posted by bwhiting on 15 July 2014 - 08:50 AM

Yes haxe is just a language, you can build engine on top of that no problem, there are a few out there already I believe.

#5163849 Is there a way to define a front and back texture on a Quad

Posted by bwhiting on 30 June 2014 - 09:57 AM

I use the 2nd suggested method with a slight twist, I have different vertices (duplicates) used for the back so they can have unique uvs, so a texture atlas can be used (no swapping of textures or shader branches).

As always there are many way to sink a cat (or skin, both are mean if you ask me.. did I just invent a new saying by accident... I hope so).

#5161018 Too large shaders - micro specializations.

Posted by bwhiting on 17 June 2014 - 05:08 AM

Jason is spot on here, if the shaders are not the bottle neck then no need to try to fix it!

I would recommend Intel's GPA  (graphics performance analyzer) if you want a pretty easy profiling solution. Just run it then run your app and boom - useful stats.

(You can even override your shader with a really simple one, so right away you get feedback without having to write a line of code yourself)

#5159740 harder cases of triangle projection

Posted by bwhiting on 11 June 2014 - 05:55 AM

A viewing frustum is not normally an exact pyramid but more like this:


Notice how the top of the pyramid is chopped off.

When a point is projected onto screen, any point behind this plane will wrong, it is the nature of projection.

So when I triangle's vertices pass across this line  things will start to look wrong, hence the need for clipping. You can clip against the other planes if you want to but it may be unnecessary.


With regards to clipping code there should be a fair bit out there if you look for it.



#5159719 harder cases of triangle projection

Posted by bwhiting on 11 June 2014 - 03:35 AM

Clipping against frustum planes is what you want, and the near plane is the most problematic one.

Do a search for triangle clipping against the near plane maybe.

Basically when a triangle intersects the near plane (either one or two of its vertices are behind the near plane) you will need to clip it and create either one or two new triangles to replace the old one.

If two points cross behind the plane will need to calculate two new points that lie on the plane using interpolation and create a new triangle using the vertex in the frustum and your two new verts. If one vertex is behind it, you will again need to make two new vertices on the plane but you will have to create two new triangles to account for the two vertices still left inside the frustum. Hope that made some kind of sense.

#5156662 Problem with SSAO (solved)

Posted by bwhiting on 29 May 2014 - 03:24 AM

Deffo still some kinks to work out but you can avoid some self shadowing issues by checking normals, if you get the normal at each sample and dot it against the main normal you can use that value to determine influence. Normals that are essentially pointing in the same direction means the surface should not be casting shadow... if the normals are facing away then they should have more shadowing. You can get the normals from the depth map or if you have a normal pass available, use that.

It also looks like pixels from very different depths are having influence when they shouldn't, you need to sort out that cut-off/threshold.


You want my super duper top tip for building post processing effects?

Do it on the CPU first! It is so easy to render out some test maps (depth, normal etc...) then use the IDE of your choice to smash out the screen space effects on software.

No need for triangle rasterization just loop through all the pixels and boom.

Why do this you ask? Well being able to debug EVERYTHING at EVERY stage is very very handy! It isn't suited to every situation but I was able to build and SSAO in Flash with actionscript in a lunch break no less to prove my point:



It is not perfect but I was able to test things out and tweak variables incredibly easy, once it was working I just ported it to the GPU one step at a time and just checked it matched the results I was expecting as I went though!


It will help you spot issues very fast indeed, and if you get it working in software you then have a clear understanding of what you need to mimic on the GPU.

Also note the self shadowing on the banana where it shouldn't be, this is because this was a depth only approximation with no normal reconstruction.



#5154590 Level Of Detail

Posted by bwhiting on 19 May 2014 - 02:58 AM

There are programs out there that try and generate them for you but how well they work for you.. will be hard to know until you start experimenting.

One approach is to render your own billboards for your complex meshes and swap out to using those at a some distance threshold. To avoid popping when doing this you can fade the billboard once it is fully there hide the original mesh, This method can work well for things like trees (they are repeated often and usually not too much diversity of models.

#5087748 Ambient Occlusion from Depth Map?

Posted by bwhiting on 21 August 2013 - 12:53 AM

here is a depth only ssao you can take a look at that I have used before:



#5080439 Boat physics engine?

Posted by bwhiting on 25 July 2013 - 07:07 AM

2d or 3d?