Hi Shri

The new stuff is specifically for fragment / pixel shaders. We are not adding an API for manipulating vertex shaders directly from WADE, because that would destroy our quadtree-based optimizations and would prevent further optimizations such as auto-batching that is coming in the next version of WADE. In other words, there is more to lose than there is to gain by exposing vertex shaders for WADE sprites.

Having said that, you're still free to override a Sprite's draw function to do whatever you like, e.g. interfacing with three.js. I think this is probably similar to what you've done before if I remember correctly. It makes sense to use the same solution for vertex and fragment shaders, i.e. I'd use three.js for both rather than doing vertex shaders with three and pixel shaders with WADE.

Gio,

Thanks for the info. I wasn't sure if there was something to be gained by using wade for the fragment shading or not.

As a general follow on question, when would I want to use fragment shaders versus doing it the old way ? Also, what are the limitations regarding multiple sprites using multiple shaders ? What are the limitations regarding textures (16, but 8 on mobile I think you said before).

I guesss what I am looking for are some general usage guidlelines regarding fragment shaders in Wade. If you could provide some, or point me at a site/article, I would appreciate it.

cheers,

Shri

Pixel shaders in a 2D game are mainly useful when you want some special effects rather than just displaying a plain old texture.

WADE's API for pixel shaders was designed to make it quick and easy to write simple shaders that you want to apply to your sprites. It's pretty cool if you do it from the editor because you can see what happens literally as you type, and that saves you a lot of time.

The fact that we abstract away some of the complexity (e.g. you don't have to define your shader function, you just type the shader code that you want to execute) allows us to do some clever optimizations.

If you do things manually, i.e. you override a Sprite's draw function with your own and do all the low-level stuff such as sending uniform data to the GPU and all that, you have to be a bit careful with potential performance issues.

If you let WADE handle things, it will introduce its own caching mechanism for shaders, textures and context states, so it doesn't do any expensive operations if it doesn't need to. For example, if you're drawing 2 sprites that use the same texture with the same shader, it can recognize that and save time by not associating the texture with the sampler twice. It's also got an efficient hashing system for the shader source code, so it can recognize that two shaders are the same even if you try to create them twice using the same source code, and it can do that without any costly string comparisons.

In the near future (hopefully version 3.3) there will be some more advanced optimizations that reduce the number of draw calls automatically where possible, without you, as a user, having to do anything.

If you do things manually, you don't have any restrictions whatsoever, but you lose those benefits. So my advice would be to only override a Sprite's draw function with your own when there is a very valid reason for doing so. Drawing 3D objects with your own vertex / fragment pipeline may be a good reason.

Now for best practices, I normally refer to this article for the general ideas, but its numbers are a bit outdated and you may want to look at WebGL Stats to get more current ones.

Finally I'd also recommend a quick read of mozilla's recommended best practices in case you want to do some low-level graphics programming.