Good Luck!

Thanks! It will be a lot of screen refreshes, but I suppose that's one advantage of event-based languages

Yeah, I was planning on full screen.
I might open up a thread on that later.

Yeah, I'll be using oclua to test out some stuff like that before i hit the computer with it

About the screen refresh, don't forget the optional parameters of platform.window:invalidate()

( platform.window:invalidate([x, y, width, height]) )

That refreshed only the part of the screen you want

This hasn't been tested as a bench, but I don't think that it's as faster as without argument.
There is two way of mind :

 - The on.paint(gc) is the user part of drawing the screen. Thus, the concerned shapes are drawn with a condition in all the gc:draw/fill routines. That will slow the entire process with a, most of the time, useless condition.

 - The on.paint(gc) fills the entire buffer without condition. When there is a specified condition, we apply a fusion mask to overlay the new buffer with the old screen. This is even faster when there is no condition, slower when there is one.

Thus, two ways of mind that have their avantages. I think a full bench will reveal which method is used, but I'm pretty sure it is the second one, so it is slower to draw a specified part of the screen.

Well, I'm developing a game (not saying the name :p) and the extra parameters are really important for me. Now I don't need to redraw all the images on the screen using gc:drawImage (which is slow), and I notice a big speedup. The game will be unplayable without it.

Well, the thing is that I don't have to draw more images if I use this. Redrawing the screen alone might be faster, but for many games that need images, the combination will be faster. drawImage really can be a bottleneck in programs, and that is why I try to limit using it with redrawing only parts.