com.nokia.mid.ui.DirectGrap hics.fillPoly trouble

[autoexec]

Hello,
I have troubles with fillPoly function in DirectGraphics interface.

I'm testing my application on 7650 MIDP Emulator, it works fine.

Having done the first good version of application I tried it on the actual Nokia 7650 device.
And it seems like DirectGraphics.fillPoly(...) function is not iplemented on the actual device.
It works without any exceptions, but does not draw polygons at all

Could you help me with this trouble ? Why does it not draw polygons ?


ADDITIONAL INFO :
I've tried different values for alpha component for colors.
If alpha equals F(4 bits for 7650), then it is visible neither on the emulator nor the actual device.
If alpha equals 0(4 bits for 7650), then it is visible on the emulator, but invisible on the actual phone.

Do you have any other ideas how to solve this problem ?

[atomictag]

Hi.
I could not find the code in your message.
I try to guess where the problem resides.

Remember that the COLOR you set in the fillPolygon is in alpha-red-green-blue format, i.e. when you call the method

fillPolygon(int[] xPoints, int xOffset, int[] yPoints, int yOffset, int nPoints, int argbColor)

you have to set the arbColor value to a non-transparent value (e.g. 0x00000000 is transparent black and 0xFF000000 is opaque black)
Please notice that the Nokia Series 60 Concept Beta emulator totally ignores the transparency value (0x00000000 is still a visible, fully opaque black color in the emulator, while it's not visible in the real device).

Hope this helps
cheers

davide
<AtomicTag.com/>

[atomictag]

Uhm... maybe i don't get it.

Did you try:

int argbColor = 0xFFFF0000; // non-tranparent RED 0xAARRGGBB
fillPolygon(..., argbColor);

ans still doesn't work?

The 0xAARRGGBB is the correct way to express the color and it should work (VISIBLE) on both the emu and real device.
Let me know

davide
<AtomicTag.com/>

[atomictag]

Hi.
I thought over the color system on Nokia devices this morning and I realized that the fact you have to set the ARGB color in 0xAARRGGBB (TYPE_USHORT_8888_ARGB) has quite a big sense in the general purpose of UI API for portability issues (screens have now a screen depth up to 12bit, but devices in the near future will surely support higher depths - 65k or 16m colors - iPaq was a 12bit device in its first releases, now it supports 65k colors...).

Of course, when you relate with the actual pixels of your screen, i.e. when using methods like drawPixels(...) or getPixels(...) you have to specify the right pixel format of your device (here comes the "famous" TYPE_USHORT_4444_ARGB&quot because you deal with the implicit structure of real-life data-pixel (you gotta tell your method how it can "decode" the pixel values, i.e. what type of format has been/will be used to rapresent them on screen).

This can be quite ambiguous, I rekon, but still seems quite functional.
The problem? Well... you probably won't be able to display correctly all the range of colors you suppose: an RGB color like [A4 18 D3] will probably displayed "differently" (e.g. [99 11 CC]) simply because that color doesnt exist at all in your device's colour table!

Please note that the Nokia Series 60 Concept Beta SDK displays (incorrectly) 16 millions colors while the real device can afford only a mere 4096! (the 7210 SDK displays only the "possible" colors -as far as I know =).
You can find my ICQ number in this page http://wap.atomictag.com/3d.

Hope this can help

cheers
davide