Okay now Ash looks like he's actually moving, rather than just magically teleporting from one square to the other. Yeah, basic animation is working now (after hours I finally understood how invalidate() worked, forgot to check the wiki). Also I added some more sprites and cleaned up and structured the code better. There's not much to try, but at least you can move Ash around and enjoy the wonderful scenery: http://webgel.net/bf/fuschia_test.tns (best tried on the actual calculator though, it's too fast on the computer) Edit: it is still quite slow (but playable) at the moment, but there are still things I need to optimize, it'll be done later.
I'll now work on some basic interaction with objects and other stuff.

Quote from: hoffa on May 31, 2011, 12:11:08 pm

It's Fuchsia because I didn't even know what kind of color fuchsia was, and also because it's such a manly color. (I don't even know how you pronounce "fuchsia")

It's pronounced similar to "few-shaw," but without the 'w' in shaw.  The color fuchsia is a purple color, similar to these: (Note how many people accidentally misspell fuchsia.)

Spoiler For Spoiler:

Thank you good sir. o/

That's why I told you

It's there : http://wiki.inspired-lua.org/platform.window:invalidate

This is so great. Just tried it out, Ash now moves faster than light (well you get the point). Having a lot of stuff on the screen might not be an obstacle after all!

That looks nice. If I was you however, I would start with a small Pokémon demo with only like 20 Pokémons maybe to not start too big. That's unless you have a lot of project and programming experience, though. I guess maybe there will be no smooth scrolling, right?

Fortunately Lua speed is better than nothing at least. It seems we can do pretty awesome stuff in it and the slow speed might encourage people to try finding new optimizing tricks in the process.

What I really wanted to try here wasn't that much the Pokémon part, but the tile-based-game part. I'm not even thinking about the Pokémons and fights yet, just about how it would all work and checking the performance and stuff like that. When it comes to the slow speed, the problem is that if the most primitive functions are already slow, it'll be hard to optimize that.
Edit: about scrolling, well I think that kind of smooth scrolling you have on Pokémon would be hard and/or laggy. Insted what could be possible is the kind of Zelda-like "fake" scrolling (as on the NES version). But anyway, the screen is quite big and quite many sprites fit on it, so I don't think it will be a huge problem.

Hey,

I yesterday started experimenting with Lua to see how well it handled graphics and other game-related stuff. I wrote on the other thread about my results. Well it seems like the calculator is not fast enough to handle games where fluidity in the gameplay is an important factor (i.e. many platformers). It's not that the calculator itself is slow, it's just the way Lua has been implemented on it that makes it inefficient for such games (Edit: invalidate() is able to update the screen partially, so all that written before might be wrong). I then decided playing around with Pokémon-like games, where speed is not the most important thing. And that's basically where I'm at, at the moment. For now with what I have done it seems to be working well. This also helps me to test Lua in a "real-life situation", with title screens and everything that a game usually has, in order to see what the difficulty of making such a game is and whatnot.

Everybody loves screenshots, so I give you screenshots:



It's not much (at least Ash can move and the basic tile "engine" is done), and I'm only in the experimenting/testing phase right now. I still have to see how to actually save an eventual game (it might be possible to do something with var.store() and its friends), if it is even possible, and many other things to see if it's even worth trying to make the game.


That's it for now.

PS: Also notice the small black on the second screenshot at the bottom. By "removing" 4 pixels (which is the same width as the upper bar, so it's symmetrical and doesn't look ugly) I have a resolution of 318*208, which is a lot better (especially in a tile-based game) than normally.

I made a very simple tile-based platformer "game" to check out how it runs. With that many tiles, it runs reasonably well. I still got some optimization tricks up my sleeve.

Edit:
I also tried with only black and white sprites (i.e. more transparency), and it does run faster and shouldn't look too ugly.

Edit2:

With more stuff on the screen (and Ash gone), the so-called game is still playable, but nothing great. The problem with platformers is that the whole screen has to be updated after every movement, and fluid movement is somewhat important in those games. I'll now play around with fullscreen Pokemon-like games, where the FPS is not as important (also movement is easier, no acceleration and other stuff).

I started playing around with sprites to see how well the Nspire handles tile-based games and games in general. I'll keep the notes updated on the first page (at the bottom of my first message). Right now it seems like the Nspire is very slow with a lot of stuff on the screen.