LÖVE

Hi guys. I just wanted to know what are your tips to be aware if your game uses too much processing power. Is there even a way to measure this? I'm currently switching between my fucking-beast-8000-computer to my flipplity-doo-1997-notebook, and I'm having some trouble trying to get this right.

I'd love if you guys could enlighten me to the path of knowledge. Thanks mates <3love2dpeople<3

Sticking to your notebook is probably a good idea for development.
That's what I did and it taught me lots.

First and most important tip: Don't worry about it until it's a problem. Code in a way to turn on and off a framerate counter and enjoy that smooth 60FPS.

Will you run into problems? Probably. But there's no real way to know what they'll be until you run into them. Especially if this is your first or second project.

undef wrote:Sticking to your notebook is probably a good idea for development.
That's what I did and it taught me lots.

Thing is, even without anything being processed it only reaches 100 fps tops. Add some simple objects and it goes to 40 real fast. Now, my main computer can run everything with 900+ fps. It's literally an I7 3770 against a low grade Intel Celeron. It's ridiculous.

Inny wrote:First and most important tip: Don't worry about it until it's a problem. Code in a way to turn on and off a framerate counter and enjoy that smooth 60FPS.

Will you run into problems? Probably. But there's no real way to know what they'll be until you run into them. Especially if this is your first or second project.

This is my second big project. I like your advice, because I'm actually being a little neurotic on this too soon I guess. I'm not sure how real developers handle this. They first make things work then they test it for speed and improve on this? (After typing that out it actually makes a lot of sense).

My big problem is that I'm in a dilema to choose between two ideas to make pipes (entities that transfer liquids) in my game. I guess I will try the easiest one (lazyiness all the way) and test to see if it is slow, if it is, then I will replace it with the other one. Thanks mate

Zarty55 wrote:Hi guys. I just wanted to know what are your tips to be aware if your game uses too much processing power. Is there even a way to measure this?

Yes, it's called profiling.
The basic idea is finding the critical parts of the code that run most often.
You don't want to spend your time optimizing code that is rarely used.

This is my second big project

With larger projects, priority number 1 for me is keeping everything maintainable.
What I mean is, you should be able to change parts of the code without affecting other parts of the program.

Zarty55 wrote: Thing is, even without anything being processed it only reaches 100 fps tops. Add some simple objects and it goes to 40 real fast. Now, my main computer can run everything with 900+ fps. It's literally an I7 3770 against a low grade Intel Celeron. It's ridiculous.

Hmm I guess it depends on what game you want to make and what hardware you want to support.
For most games made with LÖVE a low grade Intel Celeron or anything over 800Mhz should be sufficient to get constant 60 fps (unless there are lots of shaders or something).

That being said, I don't think it's too reasonable to care about efficiency too much (unless you plan on making a mobile game), but I personally find it interesting to know what things are expensive performance-wise through direct feedback.

When I started programming I also asked this question at some point. The most common answer is the one you allready got: "Don't worry about it until it happens and then tweak your program."

This is very true and also reflects my experience in some cases. But it is only half the truth.

This rule doesn't just come out of nowhere.
It is based on this famous quote from Donald Knuth:

The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.

Donald Knuth taught us alot of important things, so I highly recommend checking out his work. When it comes to performance especially, he popularized a mathematical technique to determine how efficient an algorithm is: https://en.wikipedia.org/wiki/Big_O_notation

So when you encounter performance problems, you should first find the bottlenecks as ivan allready answered. But then what do you do?

Optimizing algorithms can be very hard, especially in real time games because you have a constant flow of new data you have to process (this is not true for most of applications).

Typically when you ask about that issue you start by looking at algorithm design: https://en.wikipedia.org/wiki/Algorithm_design
It is very useful to know this and explore some of the design prinziples. For example a very common technique in dynamic programming is to use memoization when you need too much prozessing power by storing intermediate calculations in memory (note that this is a tradeoff). Which could be useful in your case.

The things I mentioned are all about optimizing and designing a process. What I and alot of people often forget about is their data. There is also a famous quote about this from Linus Torvalds:

Bad programmers worry about the code. Good programmers worry about data structures and their relationships.

http://programmers.stackexchange.com/qu ... programmer

This is also a recurring statement which you find especially in functional programming communities. Examine how your process has to retrieve the information it needs to get the results. Often when we worry too much about the process and not enough about the data, we end up with data which is too complex and processes which have to do too much to get their results. Getting the datastructures right often requires some research: https://en.wikipedia.org/wiki/List_of_data_structures

It is very common that programmers, who where taught Object Oriented Programming (OOP) as the end all be all paradigm, are too focussed on modelling data as homogenous collections, which encapsulate their relations. I often got stuck with suboptimal solutions by thinking too much about how my objects interact instead of thinking about how my data should be layed out in the first place to model the problem I try to solve.

I agree with most of what's already been said, mainly not to optimize before it's an issue, but pretending that code doesn't ever need to be optimized is just wishful thinking. Poorly thought out code will be slower, and poorly optimized code will be faster in all of the wrong places.

First, be aware of big O notation. Not in the sense of knowing the exact complexity of every one of your functions, but in the sense of making as may things as possible that happen very often constant time operations. This is often impossible to do completely, but is very important when considering how to represent your data and choosing algorithms. This is actually far more important than micro-optimization in determining how fast your code will run. Most of the time, you can and should stop here.

Another thing is to avoid creating a large number of objects every frame. If you routinely create many large tables or large strings every frame, they can make the garbage collector work a lot. If this is your problem, you probably shouldn't try to optimize this without profiling your code. If you optimize without measuring your code, your 'improvements' could end up not doing much at all, or even making your code slower (have done this before). This could also be a sign, however, that you haven't chosen good data structures.

Next, be aware that Lua is a very flexible language, and that OO is not the only solution or even the best solution to most problems. Lua actually shows a lot of influence from Lisp and other functional languages, so understanding the power of first class functions is very helpful.

Lastly, if you're programming Lua in LuaJIT (Which LOVE is), and you need that last bit of speed to get perfect 60fps on mobile, check out LuaJIT's FFI. You can use it to call C functions with essentially no overhead. Be careful here, though, as it is very easy to actually hurt performance here if your not careful, and/or create code that's unreadable.

A lot of what I said has been said already, but I thought I'd throw in my own two cents.

Rob Pike compiled an very smart and general set of rules about this topic:

http://users.ece.utexas.edu/~adnan/pike.html

Rob Pike's 5 Rules of Programming

Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is.

Rule 2. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest.

Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.)

Rule 4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures.

Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.

Pike's rules 1 and 2 restate Tony Hoare's famous maxim "Premature optimization is the root of all evil." Ken Thompson rephrased Pike's rules 3 and 4 as "When in doubt, use brute force.". Rules 3 and 4 are instances of the design philosophy KISS. Rule 5 was previously stated by Fred Brooks in The Mythical Man-Month. Rule 5 is often shortened to "write stupid code that uses smart objects".