Omnimaga
Calculator Community => TI Calculators => ASM => Topic started by: JamesV on May 17, 2013, 01:41:24 pm
-
After finally getting my 84+C last night, I decided to try and display a (small) splash screen. Here's the first working version. Currently it's an uncompressed 16-bit BGR image. The image is 82x42 pixels, thus 6888 bytes.
http://youtu.be/8vDO5Zvj6Ik (http://youtu.be/8vDO5Zvj6Ik)
The next step I plan to take is compressing the image and then having the program decompress and display it.
-
Any thoughts about doing some fancy lossy image compression? I estimated that, using JPEG-like DCT compression, you could fit a full-resolution image that's almost indistinguishable from an uncompressed image in about 20 K.
-
Ooh I like it! The best thing would definitively be compression, especially for people who will use 320x240 title screens.
-
That is pretty nice! I like it :D
Compression would be awesome, yeah, maybe you can also add a option for only half screen?
-
Thanks guys. Yeah the next step is I want to implement some compression, so we'll see how that goes.
This program isn't really intended to be particularly useful, it's more just me learning how to use the 84+C lcd. But I'm releasing the source with each version in case anyone wants to see how it works :)
-
I think the best would be to use 256 colors (or 255+transparency) or even less, then use RLE compression or something.
This program isn't really intended to be particularly useful, it's more just me learning how to use the 84+C lcd. But I'm releasing the source with each version in case anyone wants to see how it works :)
Can we expect an Alien Breed, Banchor or Centipede port in the future? :P
-
I think the best would be to use 256 colors (or 255+transparency) or even less, then use RLE compression or something.
Can we expect an Alien Breed, Banchor or Centipede port in the future? :P
Yeah I was thinking about 8-bit color images today, which I'll try over the next few days, as well as some other cool ideas.
I do have a lot of ideas for different games I'd like to make on the 84+C, but I won't promise anything until I see what I'm capable of actually doing with it first lol. I'm thinking my first game will be something new that I haven't made before though :)
-
awesome! What did you use to convert the image?
-
awesome! What did you use to convert the image?
Thanks tr1p! I wrote a small C# Windows console utility, it's included in the zip file (on Cemetech, and ticalc.org once it's processed) :)
EDIT:
Tonight I've made some updates, so that it can now load images that are stored in 8-bit format, with a color index table. As long as your original 16-bit image used 1KB+ of space, then 8-bit with the color index table is more memory efficient, and still loads nice and fast. Of course, the only downside is that the colors aren't quite as smooth
I'll post another video showing this update tomorrow, and then start working on a compressed 8-bit image version :)
-
It would be nice if image compression could be integrated into DCS8 or some standalone lib for BASIC programmers as well. How fast is it for full screen (or at least 160x240) animations?
-
Here's where it's currently at. This is a 180x171 image, compressed in 8-bit colour. The program uncompresses it and converts back to 16-bit BGR on the fly.
An uncompressed 180x171 16-bit image would take up 61560 bytes, but the image data used in this program takes up only 6828 bytes, plus 512 bytes for the colour index table used to convert from 8-bit to 16-bit. Of course, the compression is fairly good on this image, as there aren't a lot of different colours being used..
I should note that I'm very new to working with 8-bit / 16-bit colour conversions, etc. so I wouldn't be surprised if this could be done better. I'll release the updated code in the next day or so once I've cleaned it up and tested it some more.
Apologies for my iPhone/hand reflection on the calculator when the screen goes dark :P
It would be nice if image compression could be integrated into DCS8 or some standalone lib for BASIC programmers as well. How fast is it for full screen (or at least 160x240) animations?
I'm sure some kind of library will get coded up eventually. I have some ideas for it, but I don't have a lot of experience in creating ASM tools for BASIC programs. I'd love to give it a try (and maybe I will!), but no doubt someone else could do a better job.
I haven't done any animation testing yet, although tr1p1ea did a scrolling background test running in 160x240 mode, and it looked quite fast!
-
Waw ... it's looking great :D now to see how fast it is with animations.
-
That is pretty quick for a fullscale image O.O Nice job! :D
-
- Brandon Wilson for the LCD driver info on WikiTI, and for ti84pcse.inc
Actually, Brandon Wilson provided almost none of that information. If you check the history, you will see that I did 98% of the LCD driver write-up. The RAM, B_CALL, and flag equates of ti84pcse.inc were discovered by Benjamin Moody (Flop) and the new token equates were given by Christopher Martin (KermM). I wrote up the list of symbolic names for ports and collected the data into a unified include file, and I just posted a minor update to the file. The MicrOS post (http://ourl.ca/18786) I made a while ago contains a complete text-mode driver for the color screen, and shows both writing (PutC) and reading (ReadChar). I may also soon post code for turning the LCD on and off and for controlling the backlight.
-
- Brandon Wilson for the LCD driver info on WikiTI, and for ti84pcse.inc
Actually, Brandon Wilson provided almost none of that information. If you check the history, you will see that I did 98% of the LCD driver write-up. The RAM, B_CALL, and flag equates of ti84pcse.inc were discovered by Benjamin Moody (Flop) and the new token equates were given by Christopher Martin (KermM). I wrote up the list of symbolic names for ports and collected the data into a unified include file, and I just posted a minor update to the file. The MicrOS post (http://ourl.ca/18786) I made a while ago contains a complete text-mode driver for the color screen, and shows both writing (PutC) and reading (ReadChar). I may also soon post code for turning the LCD on and off and for controlling the backlight.
Sorry DrDnar, I hadn't realised this. I'll correct the readme when I upload the updated version :) And thank you!
-
Technically the scrolling is only drawing the edges as required so its not really animation I guess.
The first image test I did was half res 16 colour stored in nibbles. Was just a quick test but did use pucrunch since that's pretty simple. What compression techniques are you using currently and planning to use in the future?
Also when you say 8bit colour you mean 8bit index to a 16bit colour table?
-
That's what I meant yeah, 256 colours based on a colour index table to convert them to 16-big BGR for the LCD driver :) My terminology probably isn't the best, as this is my first time finally tackling this kind of thing lol
My utility converts the .bmp to 256 colour binary data, and then I used Jimmy Mardell's Huffman compression tool. On the calculator I used slightly modified version of his decompression routine, which for each byte it decompresses, then looks it up on the colour table and sends the respective 16-bit colour to the LCD.
Yeah I'm thinking 16 colour nibble data too for sprites, tiles, etc. for any games I make. Well to clarify, 15 colours and one transparent, provided that it's workable. I may or may not use the half-res mode, depending on what the game is, and how practical it is.
How are your tests going?
-
I posted a WikiTI page (http://wikiti.brandonw.net/index.php?title=84PCSE:OS:Applications) about making applications for the TI-84+CSE. Maybe you can turn this into a full library with API?
-
That would definitively be a good idea. It might convince some ASM coders to venture into 84+CSE coding, since there were basically no tools to make games for it, particularly graphical routines.
-
I posted a WikiTI page (http://wikiti.brandonw.net/index.php?title=84PCSE:OS:Applications) about making applications for the TI-84+CSE. Maybe you can turn this into a full library with API?
Cool! :) I've just applied for a WikiTI account as per your suggestion via email the other day too.
Turning this into a library is something I'd love to do. I haven't really looked at this for the last fortnight, but when I get some free time I'll be digging back into it again and seeing what else I can do. I have started preliminary work on 16-colour splash screens / graphics as another alternative, which will help to get image sizes down for those that aren't after a huge colour depth.
-
Hey James, whats the compression ratio using your huffman program? When I try to use the build.bat file it says that it cant create ab.bin and I dont get the .asm file. I made IViewer and it stores images as app vars and displays them but the max size for the app var is 65400 bytes. I cant fit complex images such as a jungle with a lot of leaves using only RLE unless I reduce the quality to an unacceptable level. From what I've read about huffman compression, it sounds good for text but is it better than RLE for images?
-
Hey James, whats the compression ratio using your huffman program? When I try to use the build.bat file it says that it cant create ab.bin and I dont get the .asm file. I made IViewer and it stores images as app vars and displays them but the max size for the app var is 65400 bytes. I cant fit complex images such as a jungle with a lot of leaves using only RLE unless I reduce the quality to an unacceptable level. From what I've read about huffman compression, it sounds good for text but is it better than RLE for images?
It depends on the image. I'm certainly no expert on compression and the various techniques, Huffman just tends to be the one I use thanks to the tools that Jimmy Mardell (http://tistory.wikidot.com/jimmy-mardell) made available with Sqrxz.
Did you want to email me the original image you're trying to compress? I'd be happy to see how it works with the program I've been working on (although admittedly, I haven't done any work on it in around a month, but it's still fairly fresh in my mind :) )
-
Here's an image that will not compress for me under 70,000 bytes. It's a jungle scene with a waterfall. Reducing the colors or blurring it (within reason) does not get it to the 65,400 limit. As it currently stands, it is 73,553 bytes compressed using rle. Can huffman get it smaller? Thanks.
(Oh yeah, I like your site too!)
-
RLE is typically not that great for images that have a lot of detail. Huffman should work better, but i would also suggest trying puCrunch as well (though most puCrunch compressors wont work with anything over 64KB so it may need to be split? (Though im sure this can be rectified)).
EDIT - I tested it with a puCrunch compressor just quickly and it compressed the image down to 50.5% of its original size, which is promising.
-
50% Wow! So I guess puCrunch is what it needs to be using! Thanks a lot for the info!
-
Well that said, huffman should fare pretty good as well.
Really with images the ideal compression schemes to use are those that are already established in other OS's, like gif, jpeg, png etc. However there arent any on-calc decompression routines that i am aware of (Perhaps png variants). Either way it would be a good exercise :).
I only tried puCrunch since i already had the tools lying around. Bare in mind that with other types of images, puCrunch might not be most viable solution.
My first test with the 84C was an image viewer that uses puCrunch (since it was only a quick test). I did limit this to half resolution (160x120) at 16 colours (pixel index packed into nibbles). Uncompressed images are 9632 bytes, but with compression it can be a lot lower (depending on the image). At 256 colours (standard palette) this would be 19200 bytes for an uncompressed image, with compression bringing it down also ... anyway it was just a test and not as feature filled as this project.
We need a good image viewer and JamesV is the man to do it :).
EDIT - Uhuh! Now i see your interest in this project :).
http://www.ticalc.org/archives/files/fileinfo/454/45449.html
Looks to work pretty nicely, although the menu messes up a bit in jsTIfied. Ill test it on hardware when i get home.
-
I couldn't even get it to work on jsTIfied. Following the code, the bit commands come up as ????. I dont think they're implemented yet or something. It's solid on real hardware though.
-
Yeah jsTIfied is still not very accurate. For example, it lacks 160x240 support and Buttonz is messed up. I guess the calc is just not documented enough to allow jsTIfied to support them or there was just lack of time.
-
yeah jsTIfied has only been updated to allow minimal 84C (as in TIOS) LCD operation.
Kerm is very pressed for time, but im sure he will get around to it :).