New guy, performance question

[Plu]

The missiles just sort of randomly float about, so yeah some will go offscreen of impact the ground where there are no cities (anymore). It's both easier to code and helps give off that "this isn't personal, we're just nuking everything" vibe that the original Missile Command had as well.

Thanks for the explanation on scope. I'll see if I can update the source a bit later.

[requerent]

Didn't read the thread- but in regards to the earlier comment about GC-

There is a LuaJIT based build of LÖVE. LuaJIT is one of the fastest dynamic languages implementations around (it runs circles around every implementation of Python and Ruby for example). I don't think there is anything LuaJIT is too slow for. Remember that Lua uses a garbage collector though. GC languages and real-time action games aren't a natural couple because normal GCs (including Lua's) "stop the world" while collecting garbage and thus can cause noticeable delays. People who use Ruby or Python for games crash into that issue all the time. Ruby is particularly horrible because idiomatic Ruby code creates and destroy objects all the time.

However, you can work around that issue by avoiding the creation/destruction of objects during the action parts of your game. Note that if you are coding the type of game which could run on a 16-bit era console e.g. Super Mario (which seems to be the frame of reference for most people here) you don't need to worry about that. However if you plan to write say a PC-grade real-time strategy game like Age of Empires you don't want to create/destroy objects every time a unit moves. That could get problematic. Fortunately it is very easy in Lua to avoid object creation/destruction if you want to.

So yeah I think basically there are no limits as long as you use the LuaJIT build. However, again, the standard Lua interpreter should handle Super Mario just fine.

You can cheat this by stepping the garbage collector based upon the amount of time left in a given frame. In this way, you could very rationally fix your timestep and simply use any remaining time by looping gc step calls passing some trivially small number- aggregating average time used to ensure you don't overstep the frame. Obviously, this will only work if you have variable amounts of garbage to deal with.

http://luatut.com/collectgarbage.html

[T-Bone]

Didn't read the thread- but in regards to the earlier comment about GC-

There is a LuaJIT based build of LÖVE. LuaJIT is one of the fastest dynamic languages implementations around (it runs circles around every implementation of Python and Ruby for example). I don't think there is anything LuaJIT is too slow for. Remember that Lua uses a garbage collector though. GC languages and real-time action games aren't a natural couple because normal GCs (including Lua's) "stop the world" while collecting garbage and thus can cause noticeable delays. People who use Ruby or Python for games crash into that issue all the time. Ruby is particularly horrible because idiomatic Ruby code creates and destroy objects all the time.

However, you can work around that issue by avoiding the creation/destruction of objects during the action parts of your game. Note that if you are coding the type of game which could run on a 16-bit era console e.g. Super Mario (which seems to be the frame of reference for most people here) you don't need to worry about that. However if you plan to write say a PC-grade real-time strategy game like Age of Empires you don't want to create/destroy objects every time a unit moves. That could get problematic. Fortunately it is very easy in Lua to avoid object creation/destruction if you want to.

So yeah I think basically there are no limits as long as you use the LuaJIT build. However, again, the standard Lua interpreter should handle Super Mario just fine.

You can cheat this by stepping the garbage collector based upon the amount of time left in a given frame. In this way, you could very rationally fix your timestep and simply use any remaining time by looping gc step calls passing some trivially small number- aggregating average time used to ensure you don't overstep the frame. Obviously, this will only work if you have variable amounts of garbage to deal with.

http://luatut.com/collectgarbage.html

While that sounds possible, it feels like a stupid workaround to a stupid problem. If you code your game reasonably well (a requirement for any larger game regardless of language or engine) you won't likely run into issues even without LuaJIT. And if you do, LuaJIT will likely be enough to solve it.

[requerent]

Didn't read the thread- but in regards to the earlier comment about GC-

There is a LuaJIT based build of LÖVE. LuaJIT is one of the fastest dynamic languages implementations around (it runs circles around every implementation of Python and Ruby for example). I don't think there is anything LuaJIT is too slow for. Remember that Lua uses a garbage collector though. GC languages and real-time action games aren't a natural couple because normal GCs (including Lua's) "stop the world" while collecting garbage and thus can cause noticeable delays. People who use Ruby or Python for games crash into that issue all the time. Ruby is particularly horrible because idiomatic Ruby code creates and destroy objects all the time.

However, you can work around that issue by avoiding the creation/destruction of objects during the action parts of your game. Note that if you are coding the type of game which could run on a 16-bit era console e.g. Super Mario (which seems to be the frame of reference for most people here) you don't need to worry about that. However if you plan to write say a PC-grade real-time strategy game like Age of Empires you don't want to create/destroy objects every time a unit moves. That could get problematic. Fortunately it is very easy in Lua to avoid object creation/destruction if you want to.

So yeah I think basically there are no limits as long as you use the LuaJIT build. However, again, the standard Lua interpreter should handle Super Mario just fine.

You can cheat this by stepping the garbage collector based upon the amount of time left in a given frame. In this way, you could very rationally fix your timestep and simply use any remaining time by looping gc step calls passing some trivially small number- aggregating average time used to ensure you don't overstep the frame. Obviously, this will only work if you have variable amounts of garbage to deal with.

http://luatut.com/collectgarbage.html

While that sounds possible, it feels like a stupid workaround to a stupid problem. If you code your game reasonably well (a requirement for any larger game regardless of language or engine) you won't likely run into issues even without LuaJIT. And if you do, LuaJIT will likely be enough to solve it.

Naive. I think you misunderstand the value. It isn't about proper programming, it is about maximizing performance without fear of frame-dropping. GC manipulation allows you to rubber-band extra clock cycles with cached memory to push performance. Dynamic environments, procedural content generation, and AI are some obvious places where you may want as much going on as the player's system can handle. In this sense, having control over the GC allows you to ensure you're always hovering around a reasonable threshold of resource usage.