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.

The next step I plan to take is compressing the image and then having the program decompress and display it.
That looks pretty awesome! Can't wait to see how this progresses! Very Happy
Ooh, looks quite nice. Any chance of getting the code for it?
Delightful. Keep it up! Look forward to more creativity on your part.
merthsoft wrote:
Any chance of getting the code for it?

Certainly - I've just uploaded it here and at Smile
Thanks for sharing, James. Smile I'm glad you're starting to look into basic LCD manipulation.
I've had a few more ideas today too when I was eating lunch, so I've got some more things to try tonight Smile

There is also a small Windows console utility in the zip file that I wrote that converts .bmp files into .asm files suitable for the 84+C; hopefully that can be useful down the track!
FYI, SourceCoder can also do that as well, if you ever happen to be on a computer that you don't have console access to for some reason. Smile
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, this 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 Smile
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 Razz

That was sooo cool o.o
That. is. amazing.

but how do you minimize the size by two-thirds, by halving the bit amount? Razz
LuxenD wrote:
That. is. amazing.

but how do you minimize the size by two-thirds, by halving the bit amount? Razz

Woops, I should have explained better! During assembly of the program, the .bmp is converted to 8-bit data, which is then further compressed using Jimmy Mardell's Huffman tools.

Thus, on calc, it's effectively uncompressing the data two-fold, the first step being to get the 8-bit value from the compressed file, and then to convert the 8-bit value into a 16-bit value again. Hence the slight delay during rendering Smile
what slight delay? it seems to me to be as fast as Ti's menus are.

anyone too lazy to google Jimmy Mardel: Click Here!
LuxenD wrote:
what slight delay? it seems to me to be as fast as Ti's menus are.

anyone too lazy to google Jimmy Mardel: Click Here!

I just meant that you can see the vertical scroll of the image being drawn. This is running at 15Mhz as well, compared to TI-OS, which (I believe) is only running at 6Mhz.

LuxenD++ for the Jimmy Mardell link. He certainly was one of the early greats of the TI community, and a super nice guy as well. Sqrxz is still one of my favourite TI games to this day Smile
Wow, that is awesome, great job o.o When I get a TI-84+C, I will probably look a this program as well as some of Kerm's to figure out the LCD stuff (though I have already written some routines).
Nice job, JamesV. I see the slight delay too, but we already proved that we can push a maximum of about 4FPS of data to the screen (5FPS if you're willing to stick with solid colors), and your decompression presumably has significant overhead. I'm therefore not terribly concerned with that slightly-visible draw.
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are UTC - 5 Hours
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum