LÖVE

Helllllloooooooow!~
Yay first post~
Billionth visit to these forums, but first time requesting help.
I've been using love on and off for a few months now and i think its totally great!

So in my semester holidays i was playing around and decided to actually make a game, which I did, which was very poorly coded and thrown together and was a bit of a mess, but seemed to run fine.

It got to a point and i decided to re-write it with better practices (like no globals~) in OOP style.

So anyway this game is just like a sort of farm simulator i guess, like, plant things, let them grow, then pick the fruit and sell on a market (which adjusts price randomly and depending on what was sold).

So to make it more OOP i made objects for everything which was fine and cool, however, after not even doing much i noticed that the performance was pretty terrible/not as good! (I am using zerobrane studio package thing which i feel has a bit of overhead anyway)

So i'm just wondering whether the new implementation is very inefficient in design, or whether having lots of instances makes it slow, or whether my OOP closures is slow, etc.

Don't worry about the first file's code, its all terrible!

From tests i think its from having the drawing methods in their own object, but im not sure why that makes it slow?

I'd also be happy to hear cool recommendations~
Yay~

I've attached the code for the first method, and the second slower OOP method.
Click and drag to pan the screen, and Right click on the second game to pan.

Wiwiums~

I don't have time to really dive in at this time, but in general the performance loss from changing to OO is either zero, negligable, or your performance will even go up from doing it.

So I'm guessing you've implemented something poorly and that's causing the problem. Unless someone else chimes in today I'll have a look when I get home from work tonight

Haha thanks!
I was expecting the performance to increase if anything, as i had a lot of globals floating around; so it was probably some terrible implementation on my behalf.
Thanks again~

i.import tiles is being called in love.draw. Based off of the name of the function, that should be in love.draw. I didn't spend a ton of time looking though, so that may not be the problem.

Ohh wow okay that is probably it, i cant believe i actually did that.
i gather you meant to say love.load?
Man, i thought the issue was a whole lot deeper than that haha; but ill change it when i get home.
thanks guys!

Yeah, I meant love.load.
Hope that fixes the problem.

I think I've found the problem. It seems to be the garbage collector.

Place this in interface.lua to see it yourself. This is just a guess, but maybe you are creating lots of throwaway tables. That's the first thing I would check. Oftentimes you can use the same table (especially with the correct use of OOP) for the whole lifetime of the object, instead of disposing of and recreating it on each update.

I also didn't have the time to take a closer look at your code, so I'm not sure what OOP approach you are using. I can recommend the closure based approach:

http://lua-users.org/wiki/ObjectOrienta ... reApproach

Thanks guys!
davisdude had the right idea, that i accidentally put the 'import_tiles" function under love.draw, which of course was the function that imported all the different tiles i had, which was obviously hugely inefficient. Having moved that up it runs absolutely fine!
It seems really silly to do that, i was trying to find out the problem for a while and i guess i just didn't notice it :/

@rmcode the text displayed i assume is some sort of representation of the amount of garbage collected, and it just seems to be going up by like 10 a second...but i have no idea if that is good or bad!~

I am using the closure based approach, as i had a look at the 'normal' and i thought the syntax was...odd.
My only prior programming knowledge comes from python, c and a fair bit of java, and i preferred the closure based stuff, just made more sense to me; but good to see other people use and support it!~

Thanks for all the help so far guys!

Wiwiums wrote:Thanks guys!
davisdude had the right idea, that i accidentally put the 'import_tiles" function under love.draw, which of course was the function that imported all the different tiles i had, which was obviously hugely inefficient. Having moved that up it runs absolutely fine!
It seems really silly to do that, i was trying to find out the problem for a while and i guess i just didn't notice it :/

@rmcode the text displayed i assume is some sort of representation of the amount of garbage collected, and it just seems to be going up by like 10 a second...but i have no idea if that is good or bad!~

I am using the closure based approach, as i had a look at the 'normal' and i thought the syntax was...odd.
My only prior programming knowledge comes from python, c and a fair bit of java, and i preferred the closure based stuff, just made more sense to me; but good to see other people use and support it!~

Thanks for all the help so far guys!

Hm the memory was going up for me pretty fast (from 1000 to 2000 in 1 or 2 seconds). It was just a wild guess

Glad you managed to fix it though. I love the isometric style!

rmcode wrote:
Hm the memory was going up for me pretty fast (from 1000 to 2000 in 1 or 2 seconds). It was just a wild guess

Glad you managed to fix it though. I love the isometric style!

Ohh i guess i only did this after i changed the point at which i imported the tiles hehe, so i guess 90% of the workload was removed.

Thanks for the support guys, the isometric maths was a bit of a hurdle but works super well now that i understand it

If you guys have any other recommendations on ways to improve my code i'd be glad to hear them!
Thanks once again peoples~