Page 3 of 4
Re: New guy, performance question
Posted: Mon Mar 18, 2013 1:58 am
by Kyle
spectralcanine wrote: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.)
Re: New guy, performance question
Posted: Mon Mar 18, 2013 4:26 pm
by spectralcanine
Kyle wrote:spectralcanine wrote: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.
Re: New guy, performance question
Posted: Tue Mar 19, 2013 4:20 pm
by Kyle
spectralcanine wrote:Kyle wrote:spectralcanine wrote: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.
Re: New guy, performance question
Posted: Sun Mar 24, 2013 6:27 pm
by 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!
Re: New guy, performance question
Posted: Sun Mar 24, 2013 7:04 pm
by 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.
Re: New guy, performance question
Posted: Sun Mar 24, 2013 7:20 pm
by 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.
Re: New guy, performance question
Posted: Sun Mar 24, 2013 7:42 pm
by 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.
Re: New guy, performance question
Posted: Sun Mar 24, 2013 7:55 pm
by Hexenhammer
Plu wrote: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.
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.
Re: New guy, performance question
Posted: Sun Mar 24, 2013 8:12 pm
by Hexenhammer
Kyle wrote:
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.
Re: New guy, performance question
Posted: Mon Mar 25, 2013 9:22 am
by 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 :)