Pacman Nspire

[pianoman]

Hi, everyone!
I figured it was time that this game came to the nspire in Lua, so I decided to start it.
I'm still working on the movement of Pacman and the ghosts, but I thought it through, and it seems like it would be possible.
If anyone would like to attach any maps (not too big), I might use them in the game.
That would be very helpful.
I'll keep you all posted (pun intended) on progress.
Thanks!

[Stefan Bauwens]

Good Luck!

[Jim Bauwens]

Good luck pianoman!

I know its kinda hard to make this game in Lua, because you will need to do lots of calculations and screen refreshes, so I hope that it will work out!

[pianoman]

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

[Art_of_camelot]

Sounds cool, and like it might work decently for Lua. Question: are you going to have stages full screen or are you going to allow them to be larger than the screen and scroll (this would be relevant for people making stages for you )? Personally, I think it might be easier if you just do them full screen and avoid scrolling.

[pianoman]

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

[adriweb]

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



PS : avoiding scrolling is always easier and faster to do

[pianoman]

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

[apcalc]

This sounds quite interesting, I wish you the best of luck with development on this project!

[Levak]

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.

[adriweb]

Well we'd have to test that

But then why would TI do such a thing ... ><

[Jim Bauwens]

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.

[Levak]

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.

Ok, but have you tested without arguments to make a real bench ?
Even if I trust in you, we have to be really sure of this.

[Jim Bauwens]

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.

[Levak]

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.

But, how can be sure of that ? The on.paint(gc) method is one unique function which cannot be defined for different part of the screen.

We have no proof, except a full bench, that the buffer is filled the same way and then superposed over the old screen, or, if the buffer is drawn locally.

Do you follow me ?