Calculator Community > HP Calculators
Sprite data conversion/compression discussion (HP Prime)
DJ Omnimaga:
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.
timwessman:
Here's another one. Supports direct editing and transparency color flagging. Also will load from source.
With regards to size, you really don't have to worry about it much. There are 256mb of flash so there is lots of space... I don't think you'd start running into issues till your program files are several mb or more.
That being said, there is a PNG library in the calculator which is used for screen shot compression internally for wireless classroom monitoring. I suspect at some point we'll expose that for use directly.
Also, it would be helpful to collect a list of improvements/changes to be passed along to us. One that came into my mind was a GSCROLL or something that would do internal scrolling on the grobs. Would probably come in handy. :-)
DJ Omnimaga:
Oh nice for that one :D. it even has a GUI and stuff too. One small nitpicking though: You spelled Dimension wrong :P
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.
DJ Omnimaga:
--- Quote from: timwessman on August 13, 2013, 06:49:26 pm ---Here's another one. Supports direct editing and transparency color flagging. Also will load from source.
With regards to size, you really don't have to worry about it much. There are 256mb of flash so there is lots of space... I don't think you'd start running into issues till your program files are several mb or more.
That being said, there is a PNG library in the calculator which is used for screen shot compression internally for wireless classroom monitoring. I suspect at some point we'll expose that for use directly.
Also, it would be helpful to collect a list of improvements/changes to be passed along to us. One that came into my mind was a GSCROLL or something that would do internal scrolling on the grobs. Would probably come in handy. :-)
--- End quote ---
I thought that programs were stored in RAM like on the 39gII? ??? I guess that explains why in the memory menu we can't see how much remaining space we have then :P
Also I was pointing out about the 307x46 memory error since that's what someone got when he tried to use DIMGROB with this much data at once.
As for suggestions, as mentionned above in my other post, here is the suggestion I just posted on IRC:
--- Quote ---[19:01:07] DJ Omnimaga what i would like is maybe a different conversion format like bb010g described or close
[19:02:35] DJ Omnimaga converting the hex data to 8 bit color hex (I guess with transparency) into a string var or something, followed with the code required to decompress the result into a GROB
[19:04:17] DJ Omnimaga another idea I had was the one with 15 colors + transparency, where you would just group a bunch of tiles together with the same 15 color palette (of your choice), followed by another set of tiles associated with a different palette, and so on. I wonder if
[19:04:23] DJ Omnimaga it would be more complicated tho
--- End quote ---
Adriweb:
Very nice Tim, downloaded !
Thanks :)
Navigation
[0] Message Index
[#] Next page
Go to full version