You do need to set the screen to 160x240 mode before drawing, otherwise you will only be able to draw to half a screen. I could have it do it anytime you try to draw something however.

I will add the ability to offset the LCD if needed, its only a few lines of code.

The command is used to draw 4 8x8 sprites which are the tiles that the sprite is currently over (to erase the sprite).

real(4 is draw sprite so:

real(4,x,y,w,h,pic,transcolour,updateLCD,tile0,tile1,tile2,tile3 ...

for tile0 etc there is: real(3,1,2,3,7,0,0) which is the 'getTile' command (real(3,0.. is drawMap, real(3,1.. is getTile) so:

real(3,1,x,y,mapwidth,xoff,yoff) where xoff/yoff is an offset you can provide that will add to x/y so that you can get tiles for larger sprites. The result is stored to Ans (and is just used inline in the example).

Sprites are drawn in 8x8 chunks, but also in columns first, then rows.

Would love to see a demo of this method.

Here is an incredibly crappy quality screenshot showing  16x16 sprite (with transparency) moving around. It appears to run a little slower than on calc (due to capture issues).

The 16x16 sprite is made up of 4 * 8x8 tiles. You can specify which tiles in a PIC make up the sprite, and they dont have to be in order in the PIC either.

For example you could say that tiles 1,2,3,4 make up your sprite, or if you say want to have the same body but a different head on the sprite you can say that 55,56,3,4 make up the sprite etc (if that makes sense).

The screenshot is actually drawing 2 16x16 sprites since the 4 tiles that are 'behind' the main sprite are calculated and drawn every off-screen-frame in order to clear the sprite. This saves having to clear and redraw the entire screen ... which would be very slow!

Ive been well!

Ill be keeping an eager eye on this project as it progresses. Im sure your talents will shine through once this baby nears completion .

Wow this is awesome! It was a shame that RFG closed since it was so fast and easy.

Great work and a big thanks to everyone involved in bringing this to life!

It would be cool to get an explanation of the method used ... plus more screenies .

The concept art looks great!

What stage of planning is the project at?

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.