I'm back with the first view on ColorTetris!! .
It does not yet feature highscores and other stuff, but it works! many bugs have already been eliminated from ColorTetris (1st version, i restarted from scratch), and here's a short screenie to give you an idea.

Please tell me which sprite i should use for the tiles. I really don't know, but if you have something better, show me, i want it to be good this time they have to be 10*10px


Sprite 1:

Sprite 2:

Sprite 3:

Well, Sprite 1 is very similar to what I designed for Tetrizm, so I'd lean towards something like that, but I find Sprite 3 to be very creative as well. I'm not too fond of Sprite 2, personally. May I ask what inspired you to make a second version of ColorTetris? I'm particularly curious if the "competition" from Tetrizm was a factor at all.

well, in fact i was first i released the first version on 14 November xp ( http://www.omnimaga.org/index.php?action=downloads;sa=view;down=742 )
whatever, i just want to improve my coding skills..

I know you did, I saw the ticalc.org news article on it, and it was your Lua program that inspired me to write a version of Tetris in C for the Prizm, for which I thank you! But I was curious if you inspiring me to try to make an attractive, fast Tetris version in turn inspired you to try to improve your own work, as friendly competition often goes. And I salute your willingness to continue to improve your work over time.

Can you do a mockup with some pieces in the field with sprite 3? I'd love to actually see it "in action" before I make the choice. I'm between 1 and 3.

I'm actually between 2 and 3. 1 seems unoriginal to me -- it's too flat, and would likely be hard to see the pseudo-cubeness on such a small resolution. 2 makes it look like nice blocks. 3 is original, but I have no idea what it would look like in action. Mockup, please

Here are the asked screenies, the one with sprite 3 isn't develloped as it should (only red has been added), but i like this one the most in fact i love it xp i also added an effect when removing a row, no all the block seem to dissapear to the right instead of just a line removed



i have to say that it runs smoother irl than you see in the screenie, but nvm that

I somewhat like the second better; it provides an allusion of parallax, but the first one doesn't seem natural at a closer resolution.

I still like the uniqueness of 3, but 2 looks surprisingly nice in the animated screenshot.

After seeing the screenshot I've cast my vote for sprite 3, I quite like it... Maybe have all three of them, though, and let the user pick?

I was just thinking the same thing. Hell, you could even have a mini editor for players to draw their own sprites in addition to pre-loaded ones...

That might be difficult, but it's an interesting idea. I definitely support letting the user choose which tile of those three to use, though.

I'm kinda in favor of sprite 2. It's unoriginal (that's what you want)(the sprite) in design, and (imo) looks kinda cool.

well, i think i'm going to add multisupport sprites, so you can choose between them an editor would be loads of works and totally exaggerated, since the editor would take more space than the game itself.. but i think 2 is seems to be the favorite here. btw, i posted here yesterday, and it doesn't show up, seems strange, but nvm xp

--edit--
and does anyone know why that white flash (when dead) doesn't play good on the calc? it works perfect in the emulator, but on the calc it just gives a semi transparent layer, instead of fading away
it uses the timer, and every on.timer it reduces the alpha for the white rectangle, so it becomes invisible and dissapears eventually

Do you think it's a problem with the actual code, or something with the way the LCD works? I know that on the TI-8X series, the LCDs have extremely slow response times, which cause a variety of funky effects. Could the same effect be kicking in here?

probably, maybe it's because the gc:setAlpha() command isn't official (saw that on inpired lua wikià, so maybe the calc can't handle it fast enough to do it within a time limit of 0.05 secs..and the emulator can, i think that's the problem

That's very possible. Speaking of speed, has anyone tried to come up with benchmarks for Lua on the Nspire, especially with its graphics and its sprites?

Nick, the reason is that it isn't officially documented.
TI said it was good that we would warn the users about it, because the functions might get removed/changed for certain reasons.

Kerm, there haven't been any benchmarks yet (nobody had the time to do so ).

Understandable; we haven't really come up with benchmarks for the Prizm either.

Well, the Prizm will definitely be faster

Its quite easy to make a bench-marker though, as we got all the timer functions we need