Author Topic: Sprite data conversion/compression discussion (HP Prime)  (Read 12756 times)

0 Members and 1 Guest are viewing this topic.

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55941
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Sprite data conversion/compression discussion (HP Prime)
« 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 (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.
« Last Edit: December 10, 2013, 02:42:01 pm by DJ Omnimaga »

Offline timwessman

  • LV3 Member (Next: 100)
  • ***
  • Posts: 94
  • Rating: +32/-0
    • View Profile
Re: Sprite data conversion/compression discussion (HP Prime)
« Reply #1 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. :-)

 

« Last Edit: August 13, 2013, 06:57:03 pm by timwessman »
TW

Although I work for the HP calculator group, the comments and opinions I post here are my own.

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55941
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Sprite data conversion/compression discussion (HP Prime)
« Reply #2 on: August 13, 2013, 06:54:09 pm »
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.

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55941
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Sprite data conversion/compression discussion (HP Prime)
« Reply #3 on: August 13, 2013, 07:08:19 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. :-)

 


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

Offline Adriweb

  • Editor
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1708
  • Rating: +229/-17
    • View Profile
    • TI-Planet.org
Re: Sprite data conversion/compression discussion (HP Prime)
« Reply #4 on: August 13, 2013, 08:56:21 pm »
Very nice Tim, downloaded !

Thanks :)
« Last Edit: August 13, 2013, 08:58:12 pm by adriweb »
My calculator programs
TI-Planet.org co-admin.
TI-Nspire Lua programming : Tutorials  |  API Documentation

Offline Spenceboy98

  • LV7 Elite (Next: 700)
  • *******
  • Posts: 547
  • Rating: +59/-2
    • View Profile
Re: Sprite data conversion/compression discussion (HP Prime)
« Reply #5 on: August 13, 2013, 09:48:31 pm »
How are we supposed to put the data onto the calc(emulator)?
I like milk.

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55941
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Sprite data conversion/compression discussion (HP Prime)
« Reply #6 on: August 13, 2013, 11:00:38 pm »
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.

Offline Spenceboy98

  • LV7 Elite (Next: 700)
  • *******
  • Posts: 547
  • Rating: +59/-2
    • View Profile
Re: Sprite data conversion/compression discussion (HP Prime)
« Reply #7 on: August 13, 2013, 11:07:28 pm »
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?
I like milk.

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55941
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Sprite data conversion/compression discussion (HP Prime)
« Reply #8 on: August 14, 2013, 12:52:06 am »
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.
« Last Edit: August 14, 2013, 12:52:59 am by DJ Omnimaga »

Offline Jim Bauwens

  • Lua! Nspire! Linux!
  • Editor
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1881
  • Rating: +206/-7
  • Linux!
    • View Profile
    • nothing...
Re: Sprite data conversion/compression discussion (HP Prime)
« Reply #9 on: August 14, 2013, 07:18:13 am »
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.
« Last Edit: August 14, 2013, 07:30:17 am by Jim Bauwens »

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55941
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Sprite data conversion/compression discussion (HP Prime)
« Reply #10 on: August 14, 2013, 12:57:16 pm »
What kind of minimizing would work by the way? Would it be limited to stuff like this?

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

Offline Jim Bauwens

  • Lua! Nspire! Linux!
  • Editor
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1881
  • Rating: +206/-7
  • Linux!
    • View Profile
    • nothing...
Re: Sprite data conversion/compression discussion (HP Prime)
« Reply #11 on: August 14, 2013, 02:01:09 pm »
Well in a sense you probably could minimize stuff like FFFFFFFF mathematically ;P Like replace it with 2^8 - 1.

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55941
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Sprite data conversion/compression discussion (HP Prime)
« Reply #12 on: August 21, 2013, 12:46:42 am »
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

« Last Edit: August 21, 2013, 12:47:11 am by DJ Omnimaga »

Offline TIfanx1999

  • ಠ_ಠ ( ͡° ͜ʖ ͡°)
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 6173
  • Rating: +191/-9
    • View Profile
Re: Sprite data conversion/compression discussion (HP Prime)
« Reply #13 on: August 22, 2013, 11:21:08 pm »
Funny you should mention this. I was just wondering how fullscreen animated gifs would fare using HP BASIC (with a limited pallet).

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55941
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: Sprite data conversion/compression discussion (HP Prime)
« Reply #14 on: August 22, 2013, 11:53:11 pm »
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.