Display Colors - Best Approach ?

[LYRIXX]

Hi All,
Before I jump into PF I have a question about
displays and color depths.

1. Can all Pocket PCs realize a custom 256 color palette?
If so How? via DIB Sections?

2. If I did go 256 color for speed will PF convert
this to 16bit when blitting to such devices?

3. If i'm forced to use 16bit how is this converted
by PF on PDAs limited to 256 color display?

I would think with the current speed of PDAs that for
the absolute best speed 256 color would be the best.
But I don't want to go that route if I can't set a
custom palette.

Bare in mind I attend to right custom 3D routines
that operate heavily at the pixel level.

I've done 256 color DIB sections before on the
Desktop PC but I'm unsure if the same approach
can be achieved on the PocketPC

Any insight would be much appreciated.
~Chris

[refractor]

You might want to do a bit more research on bit-depths of PocketPC devices before writing an 8-bit engine. The large majority of current devices (if not all) have 16-bit frame-buffers/displays, or at least 16-bit pixel formats that the hardware display chops down to get what it needs.

Also bear in mind that on a machine with a non-performant memory bus, 256-colour palette matching (and lookups) are probably slower than working in 16-bit and using "proper" 5.6.5 colour intensities.

To sum up:

use 16-bit.

(I'm not talking specifically about PocketFrog here - I don't know much about it).

[LYRIXX]

I would prefer to use 16bit color but
wanted to ask around first. I'm new to the
platform as well as all the different hardware.
Thanks for the advice.

~Chris

[Guest]

im a newbie,,and i would like to know how i would get different shades of colors in 16 bit so that i could create a gradient fill.

i can do this in 256 by just creating a palette of sixteen shades of the colors,but i dont know how in 16 bit

please help

[refractor]

Ok. Try looking at it this way.

When you deal with 256-colours, you're normally dealing with a palette. When you deal with 16-bit, you're not, you're dealing with the colours directly.

For this example, let's take the "normal" representation of 16-bit and say that the 16-bits are composed of:

5 bits red intensity
6 bits green intensity
5 bits blue intensity

Ok. Now for a gradient fill, you want to go from one colour to another. To do this, you need to find out your deltas for each colour (i.e. the difference in intensity).

Say we're going from full red to full blue:

Code: Select all

1  2  3  4	(binary) RRRRR GGGGGG BBBBB 11111 000000 00000 (red) 00000 000000 11111 (blue)
	4 lines; 0 keywds; 6 nums; 6 ops; 0 strs; 0 coms    Syntactic Coloring v0.4 - Dan East

The difference in red is -31
The difference in green is 0
The difference in blue is +31

Say we're going to perform this gradient over a length of 100 pixels, you could do something like this (just think of the theory; ignore the accuracy issue for now and pretend that it'll work (it won't as it's written below - if you don't see why post and somebody will tell you)):

Code: Select all

1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17	(integer)red=11111 (integer)green=0 (integer)blue=00000 (int16)colour (float) red_delta=(-31/100) (float) green_delta=(0/100) (float) blue_delta=(31/100) for x=0 to 99 { red+=red_delta green+=green_delta blue+=blue_delta colour=(red<<11)|(green<<5)| blue }
	17 lines; 4 keywds; 13 nums; 50 ops; 0 strs; 0 coms    Syntactic Coloring v0.4 - Dan East

HTH,
Ref.

[Guest]

THANK YOU!!

So if i create a color cube i should be able to use this principle to extrapolate the color i require

once again thanks

[masCh]

hehe, I have no idea what that code is supposed to do and where it can be applied.

I do all of my graphics using microsoft paint. And yeah sometimes it looks really nice on the desktop but quite crappy on the pocketPC. I know I dont use all 16 bit and I have no idea how to create a palette of colors so I can call it from my program