Owl — A fast, lightweight, and flexible game engine for the TI-Nspire

[Nick]

i know the scrolling issues with lua, for now it's too slow, maybe some improvement on the that in the future? let us hope

but it's really nice, why did you change the name to owl (i like it, just to know)?

[adriweb]

Looks quite nice so far. By the way although smooth scrolling cannot be implemented, have you tried 8 pixel scrolling or even 4 pixel scrolling?

No but I have tried some sort of smooth scrolling in the past. Way too slow for what it gives back, not worth the pain of implementing it. Well, at least not a this point, maybe if Lua gets a bit faster in the future, then why not.

Smooth scrolling for the character's sprite is easily possible... just a for loops over the coordinates from source to destination (maybe with actually a partial window:invalidate() to accelerate the specific screen part refresh)
But yeah, smooth scrolling for the rest (background and tiles) would indeed be slow.

[hoffa]

but it's really nice, why did you change the name to owl (i like it, just to know)?

I like owls and it's shorter, and somehow feels a lot less clumsy.

Looks quite nice so far. By the way although smooth scrolling cannot be implemented, have you tried 8 pixel scrolling or even 4 pixel scrolling?

No but I have tried some sort of smooth scrolling in the past. Way too slow for what it gives back, not worth the pain of implementing it. Well, at least not a this point, maybe if Lua gets a bit faster in the future, then why not.

Smooth scrolling for the character's sprite is easily possible... just a for loops over the coordinates from source to destination (maybe with actually a partial window:invalidate() to accelerate the specific screen part refresh)
But yeah, smooth scrolling for the rest (background and tiles) would indeed be slow.

My experience with partially updating the screen is that it is pointless. The thing is the TI-Nspire stupidly clears the whole screen before calling on.paint, which means I am required to "draw" (or rather, copy the stuff into some buffer) the whole screen every single time anyway. That's what takes a lot of CPU time, not the actual flipping of the screen. So, just scrolling the characters would be just as slow as scrolling the background (unless I had some blank background).

[Jim Bauwens]

This is not the case if you only invalidate a certain spot (by giving arguments to invalidate() ).
I've made some stuff with it (smooth scrolling) and it works very good.

[hoffa]

This is not the case if you only invalidate a certain spot (by giving arguments to invalidate() ).
I've made some stuff with it (smooth scrolling) and it works very good.

I'd like to see how you do that, as this simple example does clear the whole screen whenever I press the enter key:

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10 11 12 13

sprite = image.new("some 318*212 ti image") drawn = false function on.enterKey()     platform.window:invalidate(10, 10, 10, 10) end function on.paint(gc)     if not drawn then         gc:drawImage(sprite, 0, 0)         drawn = true     end end

[Nick]

well, you make drawn true when painting, so when you press enter, the drawn isn't false anymore and the sprite won't get drawn, just change that drawn=true in =false (or just delete it) and it should work
you still have to say what it has to paint on the screen..

the rest of the code is correct imo

[hoffa]

well, you make drawn true when painting, so when you press enter, the drawn isn't false anymore and the sprite won't get drawn, just change that drawn=true in =false (or just delete it) and it should work

the rest of the code is correct imo

Well that was to show that it does clear the screen every time, which is absolutely dumb speed-wise (i.e. I am forced to recopy all the data to the screen no matter what).
EDIT: If only TI had made their library simple and hassle-free like SDL, it would loads better.

[Jim Bauwens]

Your code works with me, although I did not use a fullscreen picture (32*32).
When pushing enter only a 10*10 square is cleared.

Edit:
Also, you can expect improvement in the next OS release.
TI did not create Lua for game programming, so its not hard to understand that its not optimized for games.
Anyway, I don't have any problem with TI.Image.

[hoffa]

Your code works with me, although I did not use a fullscreen picture (32*32).
When pushing enter only a 10*10 square is cleared.

Edit:
Also, you can expect improvement in the next OS release.
TI did not create Lua for game programming, so its not hard to understand that its not optimized for games.
Anyway, I don't have any problem with TI.Image.

Actually I tried it on the official emulator, maybe the behavior is different on the actual hardware. Once I return home I'll try it on the calculator, so hopefully that was the reason why it didn't seem to work. Thanks for clearing that up anyway.
Hopefully they will indeed improve it in the next OS!

[Jim Bauwens]

Ah, yes. I never use the official emulator because I can't trust it

And about improving stuff, they are adding some nice stuff

[hoffa]

Just to let you know, Owl now runs at a good 50 FPS (from a previous 9 FPS) when not scrolling (thanks to jimbauwens for clearing me up).
Here is a small demo you can try out yourself to see how it runs speed-wise: http://bb.xieke.com/files/1/owl_test.tns
(The code itself is crappy, but I quickly did something dirty so I have a good base from which to write clean code)
It won't work on the official TI-Nspire emulator though, so you have to try it on the actual hardware if you want to actually see something. Also I changed Link to a Link that is the size of a tile (16x16 in this case), as it is currently too much of a mess to deal with arbitrary sized sprites.

[DJ Omnimaga]

Interesting. Could you sum up how you got to improve the speed? Also does it use any undocumented tricks? Because maybe that won't work in future OSes then

EDIT Weird I don't notice much of a frame difference. Is it just due to the getkey speed limitation and lack of smooth character movement?

[hoffa]

Interesting. Could you sum up how you got to improve the speed? Also does it use any undocumented tricks? Because maybe that won't work in future OSes then

Well it basically keeps track of tiles that need to be redrawn and only refreshes that part of the screen (which doesn't work on the official emulator). That speeds things up a lot. No undocumented stuff.
Edit: that also means that at some point I'll be able to add a feature to use animations for the characters, as it won't really slow things down.

[Jim Bauwens]

Glad I could be of a help

[hoffa]

EDIT Weird I don't notice much of a frame difference. Is it just due to the getkey speed limitation and lack of smooth character movement?

Actually I just noticed that that TNS used the timer to refresh the screen every 0.01s (I was measuring the FPS), rather than updating after moving Link (I uploaded again and updated the link). I think why it doesn't seem to be that much faster is because of the key repeat limitation indeed. Also if I had used a map with loads of sprites you would have seen a huge improvement, but even now it should be quite a bit more responsive.