New guy, performance question

[Kyle]

About skeletal animations, how are triangles (or texture coordinates) related?

I saw a good example of this somewhere, but I seem to have lost it. I'm referring to animations where the shape itself is distorted, rather than just rotating, scaling, or translating distinct parts. It's more or less essential for making organic characters that actually look good without making gigantic spritesheets at a limited framerate. Especially for mobile devices, where space is limited but GPU power usually isn't (in recent devices, anyway.)

[spectralcanine]

About skeletal animations, how are triangles (or texture coordinates) related?

I saw a good example of this somewhere, but I seem to have lost it. I'm referring to animations where the shape itself is distorted, rather than just rotating, scaling, or translating distinct parts. It's more or less essential for making organic characters that actually look good without making gigantic spritesheets at a limited framerate. Especially for mobile devices, where space is limited but GPU power usually isn't (in recent devices, anyway.)

Ah yes, weights (multiple bones affecting the same geometry). Not really sure how applicable they are for 2D games, but I guess that mostly depends on the artist.
Do note that you'd need to make actual geometries, with good topology, for this to look anything near decent (as in, a few boxes would look ridiculously bad). Easiest way would be to use an existing 3D application and just not use depth (or ignore it when importing the model, or better - use it for character layers).

The actual skinning would benefit much from vertex shaders (Love 0.9.0?), but I guess it doesn't really matter unless you have tens of thousands of vertices.

[Kyle]

About skeletal animations, how are triangles (or texture coordinates) related?

I saw a good example of this somewhere, but I seem to have lost it. I'm referring to animations where the shape itself is distorted, rather than just rotating, scaling, or translating distinct parts. It's more or less essential for making organic characters that actually look good without making gigantic spritesheets at a limited framerate. Especially for mobile devices, where space is limited but GPU power usually isn't (in recent devices, anyway.)

Ah yes, weights (multiple bones affecting the same geometry). Not really sure how applicable they are for 2D games, but I guess that mostly depends on the artist.
Do note that you'd need to make actual geometries, with good topology, for this to look anything near decent (as in, a few boxes would look ridiculously bad). Easiest way would be to use an existing 3D application and just not use depth (or ignore it when importing the model, or better - use it for character layers).

The actual skinning would benefit much from vertex shaders (Love 0.9.0?), but I guess it doesn't really matter unless you have tens of thousands of vertices.

That's the point. You can't really do it without texture coordinates on your vertices. Vertex shaders would be the best way to do it, I don't think calculating all that in slooooow Lua would be good for much more than a few hundred vertices, and that almost defeats the point.

[Plu]

Thanks for all the tips and explanations guys
(And the tech talk, which is probably also pretty cool but so far goes a bit over my head )

To have a bit of a test-run with LÖVE I made Missile Cömmand. If anyone would be willing to do a short code-review I'd love to hear what I messed up and could've done easier/better
I think I'll be working with this framework more in the future, because so far I'm really liking it!

[Hexenhammer]

Looks nice, except that you should use locals instead of globals e.g.:

Code: Select all

local blasts = {}

function love.update( dt )
...
  for key, value in ipairs( blasts ) do
...
end

instead of..

Code: Select all

function love.load()	
...
  blasts = {}
...
end

function love.update( dt )
...
  for key, value in ipairs( blasts ) do
...
end

Globals are both, less efficient (access is slower) and more error-prone. Personally I think you should almost never use globals.

[Plu]

What will be the scope if I define it as local just before love.update?

Will it be available in all the love. functions? (Since I need to draw them?)
Will it be available in deeper functions?

Using locals is probably a better idea but I was afraid they'd go out of scope in the draw event.

[Kyle]

Defining it as local at the top level of your file will make it local to THAT file. It'll carry down into scopes inside that - for example, this will work as expected:

Code: Select all

local x = 42
function love.update(dt)
if x == 42 then
print("this will print!")
end
end

However, worrying about this is micro-optimization and that's bad. Unless you're accessing something thousands or millions of times, it's not going to be much of a problem. The difference could probably be measured in microseconds.

[Hexenhammer]

What will be the scope if I define it as local just before love.update?

The variable will be accessible in all code following its original declaration.

Will it be available in all the love. functions? (Since I need to draw them?)

It will be available in all functions (love. or your own) which follow its declaration.

Will it be available in deeper functions?

Yes, nesting is irrelevant here.

Using locals is probably a better idea but I was afraid they'd go out of scope in the draw event.

You can make a file scope local (i.e. it will be available to all functions in that file) by simply putting your local declarations at the top of the file e.g.

Code: Select all

local blasts = {}
-- Everything after the above line can access "blasts", no matter how deeply nested or whatever

Note that you can also export locals to other files if you want. The common approach (for bigger projects) is to separate the code into modules, one module per file. All functions and data of are module are put into a file-scope local table e.g.

Code: Select all

local Area = {
  width = 128
  height = 128

  Clear = function() 
    ..
  end
}

And then you can export the entire module with a simple return statement at the end of the file.

Code: Select all

return Area

Now other modules can access all the data/functions of that module by simply importing that one local variable e.g. at the top of another module which uses the Area module you simply write:

Code: Select all

local Area = require "Area"   -- this assumes your Area module is in a file named "Area.lua"

After that line you can do stuff like this in the other module

Code: Select all

Area.Clear()

for i = 1, Area.width do
  ..

.. and all access will still be local despite the fact that you are actually accessing things defined in another file.

In general you want to modularize your project if it is meant to be big instead of stuffing everything into main.lua. It's not necessary but after your code reaches a certain size you start to appreciate some organization.

[Hexenhammer]

However, worrying about this is micro-optimization

No, it's not. The big issue here is not the overhead caused by accessing globals. But that code written like that is extremely error-prone, hard to read, and maintain.

[josefnpat]

Very nice game. I didn't look at the source code, but I did enjoy the gameplay;

Did you mean for some of the missiles to go off screen and miss the cities entirely?

Also, consider speeding the missiles up, and making the explosions larger :)