Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - hoffa

Pages: 1 ... 20 21 [22]
What I meant was that the actual color data of the pixel holds on 15 bits, but there is another bit for alpha. So you might call it 16-bit color (but there are only 2^15 colors), just depends what kind of 16-bit (ARGB?). Any decent program can save in that format. Also as you can see there is not a huge amount of loss in the final result, so I don't think it will be too big of a problem.

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.

Looks very good! Good job again!

Now I still need to make it transform some 'bytes' into ASCII characters in order to slightly decrease the size of the output.
The range of that you can compress it 32-126 (except 92 and 34), higher than that causes problems, because its stored in utf-8 and they then take 2 bytes.
Thanks! The bytes are now compressed and everything should be working well. :)

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.

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.

Alrighty added some basic transparency support (actually just transparency based on a certain color). Real PNG transparency is messy when it comes to small sprites, so I'll leave that out for now.

If you need any help with the 'bit splitting' part, I'm willing to help!
I just finished doing that monochrome converter, haven't really played around with actual color and the TI.Image format yet (I'll see how it all works when moved between CX/non-CX calculators, etc.). For now I don't need any help, but I'll probably need some hints later. I'll contact you as soon as I need any help, if that's fine for you. :) (also, that's a damn nice tool you're making) Edit: just noticed on the wiki that you have already made a converter in Python, seems like I wasn't the first one. Oh well, but I'll try to finish this one for the sake of it. o/

And thanks for using the official wiki \o/
No problem, thanks for having an official wiki. o/


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:

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 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):

  • 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)

Pages: 1 ... 20 21 [22]