There is a Theme system setting variable...but...
|
09-12-2017, 09:39 AM
Post: #1
|
|||
|
|||
There is a Theme system setting variable...but...
The on-calc help just says it contains information about color, etc, but it doesn't explain what the numbers mean or what they represent. It seems to be a 2 element list....that's all I can figure out. Please....more details...I need to know if the theme is dark or light...what do the 2 numbers represent and what are the possible values?
Thanks -Donald |
|||
09-12-2017, 09:51 AM
Post: #2
|
|||
|
|||
RE: There is a Theme system setting variable...but...
I found Carlos' ITEMA app, but from the source, I have figured out the first element is 1 for light and 2 for dark theme. I don't know what the second element is????
Thx -D |
|||
09-12-2017, 09:55 AM
(This post was last modified: 09-12-2017 09:55 AM by Didier Lachieze.)
Post: #3
|
|||
|
|||
RE: There is a Theme system setting variable...but... | |||
09-12-2017, 10:33 AM
Post: #4
|
|||
|
|||
RE: There is a Theme system setting variable...but...
Ah, I just figured this out myself. Does anyone know the RGB values of these 6 colors?
I want to use these in my app to make it have the same look and feel of the calculator settings.... I'm assuming the dark is black (0,0,0) and the light is white (255,255,255), but the other 6 is guesswork.... Thanks -Donald |
|||
09-12-2017, 12:58 PM
Post: #5
|
|||
|
|||
RE: There is a Theme system setting variable...but...
You can use the connection kit to take a screengrab and look at the values in image editing software.
|
|||
09-12-2017, 06:19 PM
Post: #6
|
|||
|
|||
RE: There is a Theme system setting variable...but...
I didn't know the connection kit could do that....good idea!!! Thanks. I believe the 6 colors have alpha components to them too....
Thanks -Donald |
|||
09-12-2017, 06:30 PM
(This post was last modified: 09-12-2017 06:31 PM by Didier Lachieze.)
Post: #7
|
|||
|
|||
RE: There is a Theme system setting variable...but...
You can also use the screenshot I posted just above ;-)
|
|||
09-12-2017, 06:38 PM
Post: #8
|
|||
|
|||
RE: There is a Theme system setting variable...but...
Or you can use the HP Prime emulator and do a screenshot on your computer...
|
|||
09-12-2017, 06:44 PM
Post: #9
|
|||
|
|||
RE: There is a Theme system setting variable...but...
Here you go.
Note that the dark theme may have some changes before long with the RGB888 change. That needs a bit of tweaking to make it better since there can visually be more distinction with the increased color palette. Code:
TW Although I work for HP, the views and opinions I post here are my own. |
|||
09-12-2017, 07:06 PM
Post: #10
|
|||
|
|||
RE: There is a Theme system setting variable...but...
(09-12-2017 06:44 PM)Tim Wessman Wrote: Here you go. This is the second recent mention of "the RGB888 change"! I think that the current Prime is RGB555, so does this imply new hardware soon? Nigel (UK) |
|||
09-12-2017, 07:15 PM
Post: #11
|
|||
|
|||
RE: There is a Theme system setting variable...but...
No, the LCD has always supported that. With the shift towards all the various versions on a wide range of platforms, having a non-standard "default" for the color encoding has just gotten very annoying to deal with. Also, memory is less of a concern then it was at launch so taking a bit more isn't a major issue and makes things look better too.
TW Although I work for HP, the views and opinions I post here are my own. |
|||
09-12-2017, 11:50 PM
Post: #12
|
|||
|
|||
RE: There is a Theme system setting variable...but...
Note, I've suggested this somewhere else, but I'll repeat it here. I see the obvious advantage in supporting ARGB8888, as there are color algorithms that people might want to research using the prime to emulate different color models (I've done some work like this in the past, and had I had an HP PRIME it would have been handy).
That being said, I also see a lot of possibilities for lower bitfield counts. e.g. 16 bits or even 4 bits per pixel. I can see a lot of uses for sprites with only 16 colors. Imagine a space invaders game. The invaders could be represented by sprites and no more than 16 colors would be needed for sure. The space they would take up would be much smaller and blitting would be faster. Worth considering. As a sidebar, something that would make our programs versatile enough to still work when you change the firmware would be to allow us to determine which version of the bitfields are being used. It might be as simple as checking the software revision. Just let us know the best way you would recommend that we determine this. Thank you -Donald |
|||
09-13-2017, 05:00 AM
Post: #13
|
|||
|
|||
RE: There is a Theme system setting variable...but...
Hello,
Prime came after the 39GII+ which was extremly memory limited (<256KB). So when we started the prime development, we were in a "memory is rare" mind set. Add to this the fact that we did not know when we started how large the Prime memory was going to be and you will understand the decision of using the RGB555 format. RGB555 is, in lots of ways, slower than 888 because it requires more computations as soon as alpha blending comes in (which is very frequent). Prety much the only time where 555 is faster is when there is a pure erase as pixels can be erased 2 at a time. Windows does support 555 blitting on a window, so it was not an issue. However, most other OS do not support 555 color schemes, especially handhelds, which meant expensive (power wise) conversions all the time as the screen was refresh. QT (which we now use on PC and MAC) does not support 555 either. Add to this the fact that we have reclaimed a lot of memory in Prime and you will understand why we are switching to 888. About sprites and the like. Remember that we have also added jpg and png support to the system. Although I have not tested it with 4 bpp, you will be surprised to see that png (the most appropriate in this case), will compress a 16 color sprite encoded in 888 just as well as it will compress the same picture encoded in 4bpp (which is normal). So there is little extra cost in using 888 here. The only cost is in the memory used when the program is actually running and that the decoded graphic is in RAM. But then, you want speed and 888 to 888 blits go faster than 4 to 888... Cyrille Although I work for the HP calculator group, the views and opinions I post here are my own. I do not speak for HP. |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)