Quote:Original post by The Alchemist

Quote:Original post by _nomad_
unfortunately, that is not an option. :(

why not?

well, while it'll probably a whole lot faster (in rendering) when i use opengl ES, i really don't need all that added 3D speed. i'm only doing my own GUI library. :)

using ES for specific phones would make the code double its size (one path for 16bit screen w/out ES support, and the other for phones w/ES support) and make me create different .sis files for different phones...

if i can find out how to plot a pixel in 18bit screen, then i could just check the screen depth of the phone and choose which pixel plotter to use. :)

*bump*

me still don't know solution to this...:(

Quote:Original post by The Alchemist
u better ask in forum nokia or somewhere else :pp

i already did....weeks ago....no one knows also....even nokia experts aren't replying (considering it's nokia's website/forum, it is odd nobody knows??? )

Don't expect too many answers from experts on the Nokia boards. There are very few of those and a lot of people asking questions.

shmoove

well, even non-nokia experts there don't know... :(

I'm having the same problem as you guys... After some tinkering with working code for 12-bit and 16-bit buffers, it seems that they are using 666 format aligned on 24-bit in memory. Don't quote me on this, it also seems it's GBR as well, so for those developers accessing the hardware directly, it seems we gotta figure all this by ourselves. Here's a little paragraph which pretty much sums things up from the Nokia perspective:

Direct Screen Access API

The Direct Screen Access API (RDirectScreenAccess and CDirectScreenAccess classes, defined in w32std.h) is meant for very low-level operations with display hardware, and is not supported by the compatibility mode. Applications working correctly in earlier Series 60 devices using this API may behave unexpectedly in FP3 devices (with varying display characteristics) that, for example, have better resolution and different color depth (18-bit colors) than previous Series 60 devices. Applications using this API to access the display buffer (memory) directly may encounter different problems depending on how the applications have been implemented. Some applications render their screen only to one quarter of the screen. Some may fill the screen with garbage, have incorrect colors, or exit when they notice that the display attributes are not what they assume. In essence this means that possible changes in resolution between Series 60 devices must be taken into account when developing applications.