Nice. How big is a full screen (well not really full, but taking all available space) image? Since we got 64 MB of RAM, hopefully for sprites size shouldn't be a concern, although compression would definitively be welcome for complex games with over 200 sprites.

What is the Nspire color depth anyway? I know on the Nspire Click/Touchpad it's 16 shades of gray and the Casio PRIZM 65536 colors (with the ability to switch in 8 colors mode)

The available space is 318*212 pixels (what an unpractical resolution I have to say, multiples of 8 would've been a lot better). It's 15-bit color, with 1 alpha bit. Not sure for the non-CX calculators though.

I added support for color. Haven't fully tested it, tried with a colored pikachu once and it seemed to work well. We'll see how it goes. Also the header is generated as it should, so no more resolution restriction.

Edit:
I tried with an actual picture of a landscape, this is what I got:

I'll try to fix that as soon as possible, seems like the some very dark colors are not converted correctly.
Edit 2:
It's been fixed, check out the screenshot on the first post. Now I still need to make it transform some 'bytes' into ASCII characters in order to slightly decrease the size of the output.

Hello!

Here is a tool I wrote (even though I'm everything but a fan of PHP; it's just easier for everybody to use) to convert PNG/GIF/BMP/etc. images to the TI.Image format, usable within Lua scripts. It supports all image sizes and is able to convert colored images. CX or non-CX, it should work with both (color will just be transformed into shades of gray). Anyway, here's the link, try it out yourself:

http://hoffa.franceserv.fr/tiimage/

The usage is simple: select your file and press the button. The long string you'll see is the image in the TI.Image format. Use the image.new() function with that string to load the image, and draw it on the screen with gc:drawImage(). Nothing too complicated.


(that grayish square behind the sprite only shows up on the emulator, it shouldn't show up on the calculator. It's probably there so it's easier to differentiate transparent from white pixels)

Because the output is usually quite big, there will probably be some sort of compression (at least ~50% smaller) option in the near future, along with a Lua function to decompress the image in order to save some space.

Here is a very simple image viewer made with TI.Image images if you want to see what it looks like (use left and right arrows to change image): http://webgel.net/bf/simple_image_viewer.tns

Changelog:

• 0.7
  
  • Now uses ImageMagick instead of GD, i.e. numerous image formats are now supported
  • Code cleanup and speed improvements
  • Minor UI changes
  • All bytes now have a length of 3 digits, otherwise some bugs might occur (e.g. \12\52 is changed into \124, which is the wrong byte)
  • Fixed a bug with transparency not working properly
• 0.6
  
  • All possible "bytes" are now replaced with ASCII characters (except double quotes and backslashes for obvious reasons) to decrease the size of the output
  • Added option to enable/disable transparency
  • Minor code/UI changes
• 0.5
  
  • Fixed a bug with some colors not being converted properly
  • Less function calls; the conversion should now be slightly faster
• 0.4
  
  • Added support for color (CX and non-CX)
  • Minor code changes
• 0.3
  
  • No more size restriction, the header is now generated as it should
  • Minor code/UI changes
• 0.2
  
  • Added support for transparency
• 0.1
  
  • First version

Notes: (these are just interesting things I've noticed while playing around with Lua and graphics, might be useful to some)

• The screen is cleared at every call of on.paint(), so no need to fill the screen as with SDL and other low-level graphics libraries to avoid trailing
• gc:drawImage() handles negative and out-of-the-screen coordinates well (i.e. just draws the visible part)
• Moving a single sprite over a fullscreen background image is very slow, same thing with the same sprite drawn multiple times on the whole screen (i.e. tiling)
• Slower using tiles converted from colored pictures than using tiles converted from black and white pictures (at least seems like it, I might be wrong. But it's still very slow), might be because the Nspire converts the colors at every single call to gc:drawImage() to shades of gray (if that's the case, I'll add an option to convert specifically to non-CX calculators some time)
• Using transparent pixels is a lot faster than using plain white pixels. Using a background of fully transparent sprites is a lot faster (as if there was no background) than using a background of completely white sprites (which is as slow as if there were any kinds of sprites)