Omnimaga
Calculator Community => TI Calculators => Lua => Topic started by: hoffa on May 28, 2011, 02:58:26 pm
-
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 (http://wiki.inspired-lua.org/TI.Image), 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/ (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() (http://wiki.inspired-lua.org/image.new) function with that string to load the image, and draw it on the screen with gc:drawImage() (http://wiki.inspired-lua.org/gc:drawImage). Nothing too complicated.
(http://webgel.net/bf/5/screen3.png) (http://webgel.net/bf/6/screen3.png) (http://webgel.net/bf/6/screen2.png)
(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 (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
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)
-
Wow, nice!
I've been planning to do this, but haven't had any time.
Good job!
Edit:
If you need any help with the 'bit splitting' part, I'm willing to help!
-
That goes well with jimbauwens' tools (http://bwns.be/jim/sprite.html) :)
And thanks for using the official wiki \o/
-
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/
-
This looks great good job. I hope you keep up with good development for the Nspire community
key cracking maybe...
-
This looks nice! Also welcome on the forums.
-
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:
(http://bb.xieke.com/files/4/screen3.png)
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.
-
Definately using this!
-
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.
-
This ooks great hopefully it will help the game developers out a lot.
-
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. :)
-
WOAH! I just saw the new screenshots, awesome! Is it possible to display the images wherever you want? This could make game development much easier! Transparency will definitively be nice for that.
-
Yeah, you can place it where ever you want :)
The only thing is that the format is HUGE. But I've got some compression routines that I'll share one of these days to the world. (That is, when I have time)
-
This. Is. Awesome.
Nice job!
-
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)
-
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.
-
Thanks for the info. Hopefully this shouldn't make games too hard to make, although I am a bit concerned about how to draw images and sprites in softwares like paint that supports 2, 4, 8, 16 and 24 bit color depths but not 15. I hope it won't make it too hard to convert stuff. Granted, the quality drop shouldn't be as noticeable as someone converting an image from 8 bit to 6 or 7 bits, but I know for certain people quality is extremly important, and they might hate if certain image colors they think as important suddently appeared in different colors on their TI-Nspire.
Oh well... at least TI finally added colors to their calcs. I'm also glad they opened them to Lua dev (now the next step for them is to not try blocking Ndless anymore)
-
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.
-
OOh ok I see now. I guess that might be good then. And yeah it shouldn't be a big issue. After all, it's several thousands of colors on a tiny screen. Pixels are very small and the CX screen smaller than the regular TI-Nspire screen, so it's not like a few dithered sprites will hinder quality too much.
-
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)
TI refuses to reveal the color depth of the screen (and I think they don't even tell us the size!) but I would guess that it's 16-bit. I think the image format for Lua is 15-bit with one transparency bit.
-
The screen itself is 16 bit color, but the Ti.image format can only handle 15 bit color (with the 1 bit alpha).
-
I changed the host, it should be a lot faster and now all kinds of image formats are supported. :)
-
I spy TF2!
Also great job implementing IM for more formats.
-
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.
-
Like the 84, or slower?
-
It depends how you use it.
I'm using this format in my game (Block Breaker), and it isn't really slow, while every step I redraw the whole screen.
-
It's usually slow with colored images drawn on the whole screen (i.e. all the gc:drawImage() functions at the end draw on every pixel on the screen). A Mario-like platformer that utilizes every single pixel of the screen might not be very playable (Edit: unless there are a lot of transparent pixels). Those are the current results of years and years of rigorous scientific experiments on the Nspire using Lua.
-
(http://bb.xieke.com/files/7/screen1.png)
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:
(http://bb.xieke.com/files/8/screen2.png)
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).
-
Hmm that looks nice :D
You should probably move those in another thread, though, so more people see it and it's less off-topic. :P
Also are monochrome images the same format as grayscale/color ones? I wonder what causes the slowdown otherwise?
-
Hoffa, is there any way to get an offline converter, or is this only online?
-
Hoffa, is there any way to get an offline converter, or is this only online?
Actually there is, and there have been one since TI released Scripting Tools. I had never noticed it (actually I did, but wasn't sure what it was for), but the button for "image serialization" actually copies to clipboard the TI.Image of an traditional image format (PNG, BMP, nearly anything).
-
Got it, thanks.
-
I was first :p
I made a offline converter in python more than a month ago :D
-
Lol nice jim :P. Also we released Lua makers before TI did :P. On top of that on TI site good luck finding the Lua tool from the front page. It's well-hidden.
-
Wait, where is this python converter?
-
This is the link to it http://bwns.be/jim/convert.py .
You need pythonmagick to use it (Linux users can use the package manager to install it).
Usage: convert.py infile.png data.txt
-
Hi Hoffa,
Can you please send me the Lua script for simple_image_viewer.tns?
I try to use the functions directly by I got an error
gc:drawimage (image,0,0) attemp to index global "gc" (a nil value)
Thank you
Joaquim
-
jboavida, you need to put gc:drawimage (image,0,0) inside on.paint, like this:
function on.paint(gc)
gc:drawimage (image,0,0)
end
on.paint get called every time the screen gets/needs to be redrawn (for example when you open the program or run platform.window:invalidate()
Everything that uses gc should be called from on.paint. I recommend you to read the tutorials at http://www.inspired-lua.org/category/tutorials/starting-in-lua/ , they will help you understand how nspire Lua works.
-
jimbauwens thanks for the tip . It's working now.
-
The website in the first post is now filled with pictures of birds and the hoffa.zzl.org site I had been using a while is now down.
So what're my options for converting pictures of .png into TI Image with support for transparency (any color)?
-
hoffa.zzl.org is up for me. It doesn't seem to be updated tho.
-
Ah it has returned! :w00t: 0.6 is good enough for me.
-
I haven't been here for a while as I'm currently in the army. I updated the link to the newest version.
-
More necroposts. (shows a bit of inactivity in Lua lately)
Yeah Image to TI.Image is now at http://hoffa.franceserv.fr/tiimage
-
shows a bit of inactivity in Lua lately
I've been fairly busy in the Lua world, I just don't post a lot ^^
And I'm sure others do the same ;)
-
Do you think it should be a version for Ndless C / ASM ? It'd be really helpful.
-
What format would it convert the images to?
-
Well, Ti.Image too. Or NTI, as hoffa called it.
-
Er, if it's the same format, why do we need a separate converter?
-
I added an image to NTI converter: http://hoffa.franceserv.fr/nti/ (http://hoffa.franceserv.fr/nti/)
-
How did you get that split screen in the 3rd image?
-
Can't remember to be honest, it was some key combination to display two pages at once.
-
You can either group the pages, one at a time (Ctrl + 4), or change the layout from the Documents "Doc" menu -> Page Layout -> Select Layout -> Layout X