PlayKode D4

[beepy]

A new, non expiring version of PlayKode is (finally) available: http://biggerplanet.com/download/PlayKode.app.zip

This version is a universal binary, and produces universal binaries. It also adds automatic updating via Sparkle, uses Lua 5.1, and adds graphic fonts.

[Leisure Suit Lurie]

Might I request giving sprites a priority variable so we don't need to worry about what order we draw them in?

[beepy]

I don't know that there is a one-size-fits all solution for sprite prioritizing. The current solution -- drawing the sprites in the order that you draw them, permits you to intersperse any other graphic calls in there.

I whipped up the code below to provide basic layering -- the idea is that it allows you to call sprite draw as normal with the extra parameter layer, then when you're ready to draw all the sprites, you call sprite.drawLayers. Is that kind of what you're looking for?

click here to enter this code automatically (playkode://com.biggerplanet.playkode/?action=new&script=sprite.oldDraw%20%3D%20sprite.draw%0Asprite .draw%20%3D%20function%28%20aSprite,%20layer,%20x, %20y,%20rot,%20scale,%20alpha%29%0A%09if%20sprite. layers%20%3D%3D%20nil%20then%20sprite.layers%20%3D %20%7BlayerIndexes%20%3D%20%7B%7D%7D%20end%0A%09if %20sprite.layers%5Blayer%5D%20%3D%3D%20nil%20then% 0A%09%09sprite.layers%5Blayer%5D%20%3D%20%7B%7D%0A %09%09table.insert%28%20sprite.layers.layerIndexes ,%20layer%29%0A%09end%0A%09%0A%09table.insert%28%2 0sprite.layers%5Blayer%5D,%20%7B%20sprite%20%3D%20 aSprite,%0A%09%09%09x%20%3D%20x,%0A%09%09%09y%20%3 D%20y,%0A%09%09%09rot%20%3D%20rot,%0A%09%09%09scal e%20%3D%20scale,%0A%09%09%09alpha%20%3D%20alpha%7D %0A%09%29%0Aend%0A%0Afunction%20sprite.drawLayers% 28%29%0A%09table.sort%28%20sprite.layers.layerInde xes%29%0A%09for%20i%20%3D%201,%20%23sprite.layers. layerIndexes%20do%0A%09%09for%20k,%20s%20in%20pair s%28%20sprite.layers%5Bsprite.layers.layerIndexes% 5Bi%5D%5D%29%20do%0A%09%09%09s.sprite:draw%28%20s. x,%20s.y,%20s.rot,%20s.scale,%20s.alpha%29%0A%09%0 9end%0A%09end%0A%09sprite.layers%20%3D%20%7BlayerI ndexes%20%3D%20%7B%7D%7D%0Aend%0A)


sprite.oldDraw = sprite.draw
sprite.draw = function( aSprite, layer, x, y, rot, scale, alpha)
if sprite.layers == nil then sprite.layers = {layerIndexes = {}} end
if sprite.layers[layer] == nil then
sprite.layers[layer] = {}
table.insert( sprite.layers.layerIndexes, layer)
end

table.insert( sprite.layers[layer], { sprite = aSprite,
x = x,
y = y,
rot = rot,
scale = scale,
alpha = alpha}
)
end

function sprite.drawLayers()
table.sort( sprite.layers.layerIndexes)
for i = 1, #sprite.layers.layerIndexes do
for k, s in pairs( sprite.layers[sprite.layers.layerIndexes[i]]) do
s.sprite:draw( s.x, s.y, s.rot, s.scale, s.alpha)
end
end
sprite.layers = {layerIndexes = {}}
end

[Leisure Suit Lurie]

Yeah. I don't want to sort them every time I draw if GL can just resolve it with the depth buffer.

I wasn't thinking of layers, so much as each sprite having a priority property which GL could use to depth sort the sprites.

[beepy]

Currently depth testing is explicitly disabled for sprites, which I think I did in part for speed. I'll take a look at it and see if actually makes a difference, or if there was another good reason for me to do it.

In any case, I could probably make it an option to turn on depth testing for 2D graphic calls, then you could translate along the z axis all you wanted.

[Joseph Duchesne]

openGL note: unless I'm mistaken you can't automatically z-sort anything that supports partial transparency.

[Leisure Suit Lurie]

I don't think that'd matter with stuff like this, Joseph.

I might be insane though.:wacko:

[Skorche]

No, it's relevant. If you want to use alpha blending, you have to draw stuff in order. The Z-buffer won't sort things for you, it just masks them.

[beepy]

This is correct -- I knew I had a good reason.

[Leisure Suit Lurie]

OK. I'm insane. Layers it is then.

Wouldn't it be preferable to specify aSprite's layer when its first created as opposed to each time we have to draw?

[beepy]

OK. I'm insane. Layers it is then.

Wouldn't it be preferable to specify aSprite's layer when its first created as opposed to each time we have to draw?

That's kind of what I mean when I say "I don't know that there is a one-size-fits all solution for sprite prioritizing." It's not hard for me to imagine someone wanting to use the same sprite on two different "layers."

You could certainly use the same method I did in this thread to associate a layer value with a sprite. Something along the lines of:
sprite.layerDraw = function( aSprite, x, y, rot, scale, alpha)
if sprite.layers == nil then sprite.layers = {layerIndexes = {}} end
if sprite.layers[aSprite.layer] == nil then
sprite.layers[aSprite.layer] = {}
table.insert( sprite.layers.layerIndexes, aSprite.layer)
end

table.insert( sprite.layers[aSprite.layer],
{
sprite = aSprite.sprite,
x = x,
y = y,
rot = rot,
scale = scale,
alpha = alpha
}
)
end

sprite.oldNew = sprite.new
sprite.new = function( imageName, layer, ...)
if layer == nil then
error("sprite.new [patched] layer required")
end
local result = sprite.oldNew( imageName, ...)
return {sprite = result, draw = sprite.layerDraw, layer = layer}
end


then you could create your sprites as normal with the extra layer parameter, draw them using mySprite:draw (not sprite.draw( mySprite)) and call my little drawLayers function.

Or something like that.