Author Topic: [Lua] Worms Clone (Read 7523 times)

Jens_K · « **on:** August 03, 2014, 02:48:49 pm »

Why no script editor update lately? Because I'm also working on a new project: A Worms clone for the Nspire!
The game is far from finished but the attached little tech-demo is already playable: Me and some friends successfully wasted some of the last lessons before holidays blowing each other up

Because of minimalistic frame updates it runs increadibly fast and smooth even on calc!
It also has a completely overdone intro animation!

But as said, this is a very early tech-demo lacking all the fancy weapons and other features like wind, custom spawn points, heal- and weapon boxes etc.; right now there are only 3 maps, a bazooka-like weapon and (sometimes wacky) character physics.

Read the "Help" page for controls!

DJ Omnimaga · « **Reply #1 on:** August 03, 2014, 02:51:12 pm »

Ooh that looks fun

LDStudios · « **Reply #2 on:** August 03, 2014, 03:02:23 pm »

Lots of fun, but occasionally parts of the screen go blank. Also, the map generation is a little awkward

Adriweb · « **Reply #3 on:** August 03, 2014, 05:38:43 pm »

Very cool

I believe I don't have many things to say about the code layout, at least from what I quickly saw it looks well indented and pretty clear to read (classes and good (enough) seperation from code and paint

)
What editor did you use, btw ?

And I like the intro

(I may have a few optimizations, for example, you already make good things, like localizing things etc., but here is a mistake :

Code: [Select]

function Player:tick(del)
    local floor,abs=math.floor,math.abs
...

The point of localizing the math functions is to not having Lua access the math table. Here it's still being accessed at each tick

You could simply put the local out of the function

Sure, what you do is already better than nothing since the local version will be used for the loops calculations, but anyway, let's go all the way

(and localize every math functions you use, btw, it can't be bad.)
Also, I see you declare functions within the paint function... why ? I suppose you can just put them somewhere else (and add parameters if needed), so they just get defined once, that'll speed things up.

One more thing (but you already know about that

) : Computerview/iPad support

Jim Bauwens · « **Reply #4 on:** August 03, 2014, 06:00:12 pm »

Quote from: Adriweb on August 03, 2014, 05:38:43 pm

The point of localizing the math functions is to not having Lua access the math table. Here it's still being accessed at each tick You could simply put the local out of the function
Sure, what you do is already better than nothing since the local version will be used for the loops calculations, but anyway, let's go all the way
(and localize every math functions you use, btw, it can't be bad.)

Localizing variables inside a function is not bad (unless you only need to use it only two times inside the function or something). I don't know how it is in his code, but if you have many function calls to the same function it can improve speed. But of course, he should also localize it out of the function. You just need to see how many level of access you have.

Adriweb · « **Reply #5 on:** August 03, 2014, 07:11:31 pm »

( Note that I was especially talking about the math functions

)

Well, I didn't say "bad"

However... I wrote "mistake" because I suppose it is (?) since he apparently knows about the localizing trick

The reason why I think it's a mistake (ans worth mentionning in this case) is because it's within a tick() function that gets called often by the timer and re-localizing these each time are pointless (the math functions aren't gonna change

) so it can only waste (a little) time at each tick.

But in other circumstances, one would have to analyse more deeply the code to tell if it's needed or not, I obviously agree

Anyway, the main point is to reduce to the maximum the number of things that the tick function(s) have to do !

Oh by the way, I also saw something like :
function foo() ... end
local foo = foo.

It's probably more efficient to directly do local function ...
(but I doubt any difference will be felt - at least it's cleaner ^^)

Jens_K · « **Reply #6 on:** August 03, 2014, 07:16:23 pm »

Quote from: LDStudios on August 03, 2014, 03:02:23 pm

occasionally parts of the screen go blank

I think this is a problem with the 3.6 emulator. I think setting EMULATOR=true in my code should fix it (only suggested when actually using it on the emulator!)

Quote from: Adriweb on August 03, 2014, 05:38:43 pm

I believe I don't have many things to say about the code layout, at least from what I quickly saw it looks well indented and pretty clear to read (classes and good (enough) seperation from code and paint )

Thanks, I think I'm getting better with object-oriented programming. Although other parts of the code are very bad (intro is completely hardcoded

)

Quote from: Adriweb on August 03, 2014, 05:38:43 pm

What editor did you use, btw ?

I still use the Student Software Editor *Jens runs

Quote from: Adriweb on August 03, 2014, 05:38:43 pm

(I may have a few optimizations, for example, you already make good things, like localizing things etc., but here is a mistake :
Code: [Select]
function Player:tick(del) local floor,abs=math.floor,math.abs ...The point of localizing the math functions is to not having Lua access the math table. Here it's still being accessed at each tick You could simply put the local out of the function
Sure, what you do is already better than nothing since the local version will be used for the loops calculations, but anyway, let's go all the way
(and localize every math functions you use, btw, it can't be bad.)

I understand, but wouldn't those variables be localized on a lower level, so that everytime when I call them on a higher level, they have to be loaded into the ligher level which takes time? Or do the different levels make no difference? What about just writing

Code: [Select]

local math=math at the beginning of the script, would then all math functions be as fast accessible as if I localize them individually?
And btw. I noticed that the localizing itself takes time, so if you call a math function only once, it seems be faster not to localize it.

Quote from: Adriweb on August 03, 2014, 05:38:43 pm

Also, I see you declare functions within the paint function... why ? I suppose you can just put them somewhere else (and add parameters if needed), so they just get defined once, that'll speed things up.

I was just lazy here ^^ I'll change that!

But thanks for looking through the code and giving useful advices!

I still have much to learn!

Adriweb · « **Reply #7 on:** August 03, 2014, 07:26:54 pm »

Quote from: Jens_K on August 03, 2014, 07:16:23 pm

I understand, but wouldn't those variables be localized on a lower level, so that everytime when I call them on a higher level, they have to be loaded into the ligher level which takes time? Or do the different levels make no difference? What about just writing
Code: [Select]
local math=math at the beginning of the script, would then all math functions be as fast accessible as if I localize them individually?

Argh, I actually had benchmarks recently but I can't get them right now - I was experimenting with different scopes and globals/locals (it was to determine the best way to localise (as in multilingual, this time

) strings and use them efficently). I'll try to get that soon (I told Jim about the results, so maybe he still has that conversation in his IRC logs)
In the meantime, look at this : http://www.lua.org/gems/sample.pdf and http://stackoverflow.com/a/4646957 (and other links on Google when you search for 'lua optimization local' with no quotes)
IIRC, the reason why locals are faster is because global access (through _G) is done by hash, whereas local access is by index, and that's much faster.

Quote from: Jens_K on August 03, 2014, 07:16:23 pm

And btw. I noticed that the localizing itself takes time, so if you call a math function only once, it seems be faster not to localize it.

Oh yes, sure, when used once (or a few times, even), you really don't have to worry about it.
It's "only" when functions/variables are called very often that the difference between globals and locals start to get noticeable.
So, that tends to be very useful for calculations (big for loops, for example), and fast timer funcs.

Ivoah · « **Reply #8 on:** May 03, 2015, 12:46:33 am »

*Bump* Has there been any progress on this?

Jens_K · « **Reply #9 on:** May 04, 2015, 12:38:47 pm »

Quote from: Ivoah on May 03, 2015, 12:46:33 am

*Bump* Has there been any progress on this?

Not much yet and since I finished school and I don't use my calculator regulary anymore, I kind of lost interest in calculator programming

But until I go to university this fall I don't have much to do anyways, so maybe I'll continue some of my projects but don't expect too much! This project is extra laborious to develop on though, because it all bases on the idea of updating the screen only partially to update those parts much faster. Therefore I have to take care of that system whenever I want to create new interfaces like an inventory and stuff.
So if I work on this project again, it probably won't be as extensive as initially planned!

Author Topic: [Lua] Worms Clone (Read 7523 times)

Jens_K

[Lua] Worms Clone

DJ Omnimaga

Re: [Lua] Worms Clone

LDStudios

Re: [Lua] Worms Clone

Adriweb

Re: [Lua] Worms Clone

Jim Bauwens

Re: [Lua] Worms Clone

Adriweb

Re: [Lua] Worms Clone

Jens_K

Re: [Lua] Worms Clone

Adriweb

Re: [Lua] Worms Clone

Ivoah

Re: [Lua] Worms Clone

Jens_K

Re: [Lua] Worms Clone