### Author Topic: HP-Prime prototype performance test: color graphic programs  (Read 23023 times)

0 Members and 1 Guest are viewing this topic.

#### Jim Bauwens

• Lua! Nspire! Linux!
• Editor
• LV10 31337 u53r (Next: 2000)
• Posts: 1881
• Rating: +206/-7
• Linux!
##### Re: HP-Prime prototype performance test: color graphic programs
« Reply #30 on: August 12, 2013, 03:06:34 pm »
Hello,

The code I'd posted previously (the little sprite command), shows how to load colors to a grob, and how to scale it.

Code: [Select]
EXPORT Sprite()BEGINDIMGROB_P(G2,4,4,{ #7C0003E0001F0000:64, #0, #0, #7C0003E0001F0000:64 });BLIT_P(G0,20,20,100,100,G2,RGB(0,0,0));WAIT(3);END;
Note that scaling is only a pixel by pixel things. It doesn't not interpolate. Also note that you can specify different source regions from the grob. This means you could have a larger grob containing a tileset, and blit in from a specific location.

I've tried some of my own 4x4 sprites and they work fine. However, I can't manage to go beyond 4x4 because I can't specify hex strings longer than 64 bits. Any way that bigger sprites can be done (using hex strings)?

#### critor

• Editor
• LV11 Super Veteran (Next: 3000)
• Posts: 2079
• Rating: +439/-13
##### Re: HP-Prime prototype performance test: color graphic programs
« Reply #31 on: August 12, 2013, 03:38:30 pm »
You forgot to remove the WAIT(0.02) commands

That said, we already notice it's not even running at 50 FPS like the WAIT command tried to slow it down to, but there will be a speed gain if you remove it for sure.

Thank you DJ_O.

I've retried the scaling demo by:
- removing the wait command
- adding double buffering to avoid flicking (which happened because of redrawing the screen twice on each loop)

Except that the display is better, the speed seems similar:
« Last Edit: August 12, 2013, 03:47:01 pm by critor »

#### TIfanx1999

• ಠ_ಠ ( ͡° ͜ʖ ͡°)
• CoT Emeritus
• LV13 Extreme Addict (Next: 9001)
• Posts: 6173
• Rating: +191/-9
##### Re: HP-Prime prototype performance test: color graphic programs
« Reply #32 on: August 12, 2013, 03:44:17 pm »
The speed actually looks faster, even with double buffering. Very nice!

#### critor

• Editor
• LV11 Super Veteran (Next: 3000)
• Posts: 2079
• Rating: +439/-13
##### Re: HP-Prime prototype performance test: color graphic programs
« Reply #33 on: August 12, 2013, 03:56:58 pm »
You forgot to remove the WAIT(0.02) commands

That said, we already notice it's not even running at 50 FPS like the WAIT command tried to slow it down to, but there will be a speed gain if you remove it for sure.

Thank you DJ_O.

I've retried the scrolling demo by removing the wait command.

It's much faster:

#### TIfanx1999

• ಠ_ಠ ( ͡° ͜ʖ ͡°)
• CoT Emeritus
• LV13 Extreme Addict (Next: 9001)
• Posts: 6173
• Rating: +191/-9
##### Re: HP-Prime prototype performance test: color graphic programs
« Reply #34 on: August 12, 2013, 03:59:34 pm »
That looks great! By the way, how is the directional pad in the center? Does it feel solid, and is it responsive?

#### DJ Omnimaga

• Former TI programmer
• CoT Emeritus
• LV15 Omnimagician (Next: --)
• Posts: 55913
• Rating: +3152/-232
• CodeWalrus founder & retired Omnimaga founder
##### Re: HP-Prime prototype performance test: color graphic programs
« Reply #35 on: August 12, 2013, 04:02:51 pm »
Yup it definitively seems faster. The speed may not be as fast as drawing 1 sprite, but it's still very impressive.

Hello,

The code I'd posted previously (the little sprite command), shows how to load colors to a grob, and how to scale it.

Code: [Select]
EXPORT Sprite()BEGINDIMGROB_P(G2,4,4,{ #7C0003E0001F0000:64, #0, #0, #7C0003E0001F0000:64 });BLIT_P(G0,20,20,100,100,G2,RGB(0,0,0));WAIT(3);END;
Note that scaling is only a pixel by pixel things. It doesn't not interpolate. Also note that you can specify different source regions from the grob. This means you could have a larger grob containing a tileset, and blit in from a specific location.

I've tried some of my own 4x4 sprites and they work fine. However, I can't manage to go beyond 4x4 because I can't specify hex strings longer than 64 bits. Any way that bigger sprites can be done (using hex strings)?
Hmm that sucks >.<. I assume this means that our sprites (for example 16x16 tiles) will have to split into 16 chunks placed one after another vertically? (So if your game has 16 tiles that are 16x16, you would have a 4x1024 pixels GROB instead of 16x256). Then to draw the sprite, you would just use a For loop that scans through the 16 chunks vertically.

#### critor

• Editor
• LV11 Super Veteran (Next: 3000)
• Posts: 2079
• Rating: +439/-13
##### Re: HP-Prime prototype performance test: color graphic programs
« Reply #36 on: August 12, 2013, 04:07:35 pm »
That looks great! By the way, how is the directional pad in the center? Does it feel solid, and is it responsive?

Unlike the TI-Nspire CX/CM, the directional pad is a normal key here, thus being as responsive as the other keys.
« Last Edit: August 12, 2013, 04:12:55 pm by critor »

#### TIfanx1999

• ಠ_ಠ ( ͡° ͜ʖ ͡°)
• CoT Emeritus
• LV13 Extreme Addict (Next: 9001)
• Posts: 6173
• Rating: +191/-9
##### Re: HP-Prime prototype performance test: color graphic programs
« Reply #37 on: August 12, 2013, 04:10:34 pm »
I see, that's very good news indeed.

#### timwessman

• LV3 Member (Next: 100)
• Posts: 94
• Rating: +32/-0
##### Re: HP-Prime prototype performance test: color graphic programs
« Reply #38 on: August 12, 2013, 05:53:15 pm »
By the way, is there any image<>hex converter that supports A1R5G5B5 format or something that can convert JPEG/BMP/GIF to exactly that image format?

No, don't have anything for that. Sorry. (might tweak one and post it later though). It is a very basic encoding scheme though.

Basically, all that is happening is that you convert a #FF value into a linearly scaled #1F value. Here is a C macro that shows how this is done internally.

#define RGBToColor(R,G,B) (((R>>3)<<10)+((G>>3)<<5)+((B>>3))) // transforms 0-255 RGB into color

The 16 bit is just a flag that signifies transparency.

Note that the DIMGROB command just takes the information in order. So if you want to make a 6x3 grob, The first 4 16 bit groups come out of the first hex numb, the next hex num takes the first 2 and then the last 2 are the start of the second line and so on...  { |#64bits, #(upper32)||(lower32), #64bits|,|#64bits,#(upper32bits)|(unused) }.

Each line in the 6 width takes the first 6 16 bit groups it finds. Each "line" of the grob is defined between the paired | |. Remember that all hex numbers, regardless of sign/unsigned/bits is internally 64 bits of data.

« Last Edit: August 12, 2013, 07:23:30 pm by timwessman »
TW

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

#### DJ Omnimaga

• Former TI programmer
• CoT Emeritus
• LV15 Omnimagician (Next: --)
• Posts: 55913
• Rating: +3152/-232
• CodeWalrus founder & retired Omnimaga founder
##### Re: Re: HP-Prime prototype performance test: color graphic programs
« Reply #39 on: August 12, 2013, 10:44:00 pm »
Oh ok thanks, so after all sprites larger than 4x4 are possible.

That said I was contemplating just using 8x8 sprites scaled up to twice their size, because when xLIB comes out for the TI-84 Plus C Silver Edition it would make it easier to port games to the Prime and it would be 4 times smaller anyway.

#### Jim Bauwens

• Lua! Nspire! Linux!
• Editor
• LV10 31337 u53r (Next: 2000)
• Posts: 1881
• Rating: +206/-7
• Linux!
##### Re: HP-Prime prototype performance test: color graphic programs
« Reply #40 on: August 13, 2013, 06:39:21 am »
By the way, is there any image<>hex converter that supports A1R5G5B5 format or something that can convert JPEG/BMP/GIF to exactly that image format?

No, don't have anything for that. Sorry. (might tweak one and post it later though). It is a very basic encoding scheme though.

Basically, all that is happening is that you convert a #FF value into a linearly scaled #1F value. Here is a C macro that shows how this is done internally.

#define RGBToColor(R,G,B) (((R>>3)<<10)+((G>>3)<<5)+((B>>3))) // transforms 0-255 RGB into color

The 16 bit is just a flag that signifies transparency.

Note that the DIMGROB command just takes the information in order. So if you want to make a 6x3 grob, The first 4 16 bit groups come out of the first hex numb, the next hex num takes the first 2 and then the last 2 are the start of the second line and so on...  { |#64bits, #(upper32)||(lower32), #64bits|,|#64bits,#(upper32bits)|(unused) }.

Each line in the 6 width takes the first 6 16 bit groups it finds. Each "line" of the grob is defined between the paired | |. Remember that all hex numbers, regardless of sign/unsigned/bits is internally 64 bits of data.

Ah thanks for the information. I made a quick converter in javascript to convert sprites: http://bwns.be/jim/hpsprite.html .
« Last Edit: August 13, 2013, 06:39:40 am by Jim Bauwens »

#### deeph

• LV4 Regular (Next: 200)
• Posts: 138
• Rating: +6/-0
##### Re: HP-Prime prototype performance test: color graphic programs
« Reply #41 on: August 13, 2013, 06:49:12 am »
And here is a small converter for windows : img2prime.zip (just drag and drop the image to convert on it)

It even handles transparency

But I'm not sure if the ":64" are always necessary.

#### DJ Omnimaga

• Former TI programmer
• CoT Emeritus
• LV15 Omnimagician (Next: --)
• Posts: 55913
• Rating: +3152/-232
• CodeWalrus founder & retired Omnimaga founder
##### Re: Re: HP-Prime prototype performance test: color graphic programs
« Reply #42 on: August 13, 2013, 03:19:00 pm »
I was scared when I saw the 56 KB thing lol , but then I saw your program and said phew. I hope that a 16x16 sprite won't take 50 KB because imagine if someone decides to port Zelda Links Awakening or something.

Anyway thanks, I'll try both programs

#### bb010g

• LV6 Super Member (Next: 500)
• Posts: 428
• Rating: +22/-1
• I do stuff
##### Re: HP-Prime prototype performance test: color graphic programs
« Reply #43 on: August 13, 2013, 05:38:39 pm »
And here is a small converter for windows : img2prime.zip (just drag and drop the image to convert on it)

(image)

It even handles transparency

But I'm not sure if the ":64" are always necessary.

For Linux and OS X users:
The source file is small enough that you can install the PureBasic demo and compile an executable for deeph's program on your respective platform.
I have attached an i686 Linux executable made on Arch Linux with GCC 4.8.1-2, for those on Linux who don't want to install it. (If it doesn't work, just pull down the demo.)
http://db.tt/9PLl5hL8
Arch Linux user
Haskell newbie | Warming up to Lua | Being dragged into C++
Calculators: HP 50g, HP 35s, Casio Prizm, TI-Nspire CX CAS, HP 28s, HP Prime, Mathematica 9 (if that counts)
π: 3.14...; l: 108; i: 105; e: 101; l+i+e: 314
THE CAKE IS A LIE IS A PIE

#### deeph

• LV4 Regular (Next: 200)
• Posts: 138
• Rating: +6/-0
##### Re: HP-Prime prototype performance test: color graphic programs
« Reply #44 on: August 13, 2013, 05:56:08 pm »
Cool, thanks !

Don't hesitate to optimise it or ask me for new features/bug fixes.

I've not tested it a lot so I don't know if there are bugs in some cases.