Omnimaga
Calculator Community => HP Calculators => Topic started by: DJ Omnimaga on August 13, 2013, 06:39:04 pm
-
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 (http://www.omnimaga.org/index.php?action=dlattach;topic=16801.0;attach=15884) (By timwessman) Has a GUI (alternate version (http://h30499.www3.hp.com/t5/Calculators/HP-Prime-Help-Entry-ICON-Setting-App-Icons/td-p/6298613#.UqdCNR9lvSw))
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.
-
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. :-)
-
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.
-
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. :-)
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:
[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
-
Very nice Tim, downloaded !
Thanks :)
-
How are we supposed to put the data onto the calc(emulator)?
-
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 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.
Yes, but how are you supposed to copy the data to the program without typing everything manually?
-
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:
(http://img.ourl.ca//groundtiles2.png)
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)?
(http://img.ourl.ca//groundtilessplitintochunks-1.png)
Although the code required to generate the larger sprites would be a bit large, the overall game would be MUCH smaller.
-
My converter supports transparency now. I didn't enable it yesterday because it wasn't working properly, it gave some strange results. However, it seems that that was due to a little bug in the BLIT_P (which has already been fixed now :)). I modified my alpha conversion code a bit to bypass the bug and it works good now. (thanks timwessman for the help!)
Edit: and now it also minimizes the length for every 64bit group of data.
-
What kind of minimizing would work by the way? Would it be limited to stuff like this?
#0000000000000000:64->#0
#000FFFFFFFFFFFFF:64->#FFFFFFFFFFFFF
-
Well in a sense you probably could minimize stuff like FFFFFFFF mathematically ;P Like replace it with 2^8 - 1.
-
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. :P
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 :P
-
Funny you should mention this. I was just wondering how fullscreen animated gifs would fare using HP BASIC (with a limited pallet).
-
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.
-
Yea size is always an issue. If decompression isn't too slow, this could be really neat though. :D
-
By the way, what is the sprite format for the HP 39gII? I wonder how easy it would be to write a converter? Does it also use hex or something such as 01230123 (4 shades of gray)?
-
Update: I added an alternate link for Tim Wessman's DIMGROB helper program in the first post ( http://h30499.www3.hp.com/t5/Calculators/HP-Prime-Help-Entry-ICON-Setting-App-Icons/td-p/6298613#.UqdCNR9lvSw )
Also, does anyone know where I can find the ICON command? Some people on HP Museum talked about it, but it's not even listed anywhere in the catalog nor drawing commands menu and I couldn't find it in the help. D: