As you know, the HP Prime supports sprites, via the DIMGROB_P and BLIT commands and it is even possible to scale them up. There are now three tools to convert PNGs (or perhaps other formats) to HP Prime sprite data:

Online:           http://bwns.be/jim/hpsprite.html  (By Jim Bauwens) Supports any size, but not transparency. Works fine in Firefox
Windows:       http://www.mirari.fr/mjJj  (By Deeph) Supports transparency
                    http://www.omnimaga.org/index.php?action=dlattach;topic=16801.0;attach=15884 (By timwessman) Has a GUI (alternate version)
Linux/Mac OS: http://db.tt/9PLl5hL8 (By bb010g)
          

However, we have a problem: Because the sprites are 16 bits (A1R5G5B5), this means that one 16x16 sprite takes 512 bytes of RAM. Also, in BASIC, one pixel hex value takes 4 characters because the hexadecimal isn't squished like in Axe Parser or Z80 assembly, plus the Prime uses unicode, meaning that one character takes more than 1 byte. So imagine, for example, if somebody decided to port Reuben Quest to the HP Prime, using new 16x16 graphics: The game would most likely use 500+ KB just for graphic data!

So on IRC we were discussing the possibility of getting a different type of converter that would instead generate a string of 8 bit sprite data (or why not 4 bits, where the programmer just groups 5-6 tiles together with 1 15-color palette, then anothr bunch of tiles using another palette, and so on?), still with transparency support, then you would use a program that reads through that string (assuming the HP Prime has a substring command) then draw the sprite with pixel commands into a previously initialized but empty GROB, pixel by pixel, using the corresponding color.

Do you have other ideas? Also keep in mind that some people might prefer to use 8x8 sprites (that they scale up with BLIT later) to save even more space or to make it easier to port xLIB games.

Anyway I thought I would create a new thread, because the news aren't in the HP Prime sub-forum and it would be good to keep some of the extra discussion in here.

Oh nice for that one . it even has a GUI and stuff too. One small nitpicking though: You spelled Dimension wrong

One thing to note, btw: When converting larger stuff like the entire Omnimaga logo (307x46), you'll get a memory error. To get around this I think you need to setup an empty 307x46 GROB, then create a smaller GROB with parts of the Omnimaga logo (eg 307x10), BLIT it on the large one, then replace the content of the smaller GROB with the next part of the logo, BLIT it on the large one, and so on, until you're done.

Very nice Tim, downloaded !

Thanks

You need to use the DIMGROB_P and BLIT_P commands with the data. See http://tiplanet.org/hpwiki/HP_Prime/HP-BASIC for more info on those commands.

You just copy it to your clipboard, then CTRL+V in the program editor (not with the calc paste option, but the one in the emulator menu bar).

EDIT: UPDATE:

I found another idea to minimize space used by your programs by sprites! You know that unlike older calcs, sprites don't have to be a certain multiple and that you have 9 extra buffers (of any reasonable size) to store graphics, right? Well, if you have complex sprites such as this:



Then why not just splitting those sprites even more, into 8x8 chunks, then through a tilemap, simply generate the more complex sprite sheet you need for your game, also copying the background layer in the process (when needed)?



Although the code required to generate the larger sprites would be a bit large, the overall game would be MUCH smaller.

What kind of minimizing would work by the way? Would it be limited to stuff like this?

#0000000000000000:64->#0
#000FFFFFFFFFFFFF:64->#FFFFFFFFFFFFF

Semi off-topic:

You know, someone could totally make an animated GIF converter that generates 5 FPS 80x60 video GROB data and the necessary code to store each frame one by one, then run through them.

Of course you could use something smoother or a larger resolution, but at 16 bits color depth, one 320x240 frame would take 153600 bytes (even more in the program code), so to fit something like a rickroll, you would not even have close to enough Flash memory

The major issue would be the size. I think we would really need to store them in a compressed format that only uses like 16 colors and lower resolution, then decompress them on launch. If decompressing isn't brutally slow, then maybe it could be decompressed frame by frame as we display them to not take too much RAM in one shot. If everything is decompressed before the GIF runs, then WAIT commands would be required to prevent it from running too fast.