Direct screen write - 9200, 9500

i dont know the answer but u might want to post this in the devoleper section

Oops, you're right! thanks!

Stewe

anytime

Hi, I am trying to do direct screen access too, how is bScreen, dScreen,cScreen,pBuf used in __WINS__ mode? what about in __ARMI__ mode? was this taken from an example that I can follow? Can you show me how dScreen, cScreen,pBuf is used and how they work together?

THanks,!

redshift wrote:Hello!

I'm just porting our game, Legacy, for the Communicator (www.redshift.hu). I used this code in the past to access 9200's screen directly:

#ifdef __WINS__
bScreen=new(ELeave) CFbsBitmap();
bScreen->Create(TSize(640,200),EColor4K);
pbScreen=(Uint8 *)bScreen->DataAddress();
dScreen->CreateContext(cScreen);
pBuf=new(ELeave) TUint8[640*200];
#else
pBuf=new(ELeave) TUint8[640*200];
TScreenInfoV01 iScreenInfo;
TPckg<TScreenInfoV01> sI(iScreenInfo);
UserSvr::ScreenInfo(sI);
pScreen=(Uint8 *)(iScreenInfo.iScreenAddress)+32;
#endif

So... that was 9200 series. 4r/4g/4b, 2 bytes for each pixel, only 12 bits used. What about the 9500? How can I access the pixels, and what are the bit mapping? With 5/5/5, then it would 32768 colors.

Another question: I have the Nokia 9200 SDK, and the Series 80 SDK for 9500. Can I use only the 9200 SDK to compile our game for both 9200 and 9500 ?
I won't use too many APIs, we have a strong engine, with system-independent routines.

Thank you!

Stewe/Redshift

same answer as the one i said up
ask in the devolpoer section

Hi!

Yea.

In our display.h:

CFbsScreenDevice *dScreen;

CFbsBitmap *bScreen;
CFbsBitGc *cScreen;
TUint8 *pbScreen;
TUint8 *pBuf;

#ifndef __WINS__
TUint8 *pScreen;
#endif

in display.cpp:

Init function (the example you saw)

dScreen=CFbsScreenDevice::NewL(_L(""😉,EColor4K,TRgb(255,255,255));
dScreen->ChangeScreenDevice(NULL);
dScreen->SetAutoUpdate(EFalse);

pBuf=new(ELeave) TUint8[640*200];

#ifdef __WINS__
bScreen=new(ELeave) CFbsBitmap();
bScreen->Create(TSize(640,200),EColor4K);
pbScreen=(TUint8 *)bScreen->DataAddress();
dScreen->CreateContext(cScreen);
#else
TScreenInfoV01 iScreenInfo;
TPckg<TScreenInfoV01> sI(iScreenInfo);
UserSvr::ScreenInfo(sI);
pScreen=(TUint8 *)(iScreenInfo.iScreenAddress)+32;
#endif

update function:

RThread().SetPriority(EPriorityRealTime);

#ifdef __WINS__
TUint8 *b=pBuf;
TUint16 *s=(TUint16 *)pbScreen;
TUint16 *ends=s+128000;

while(s<ends)
*s++=cPalette[*b++];

cScreen->BitBlt(TPoint(0,0),bScreen);
dScreen->Update();
#else
TUint8 *b=pBuf;
TUint16 *s=(TUint16 *)pScreen;
TUint16 *ends=s+128000;

while(s<ends)
*s++=cPalette[*b++];
#endif

RThread().SetPriority(EPriorityNormal);

Note: Legacy uses 8bpp. So the cPalette points to a 256 word buffer, contains EColor4K values of the palette items.
It's not Nokia 9500 - compatible. I have the routines for that, just I didn't have chance to check it (yet).

earamsey wrote:Hi, I am trying to do direct screen access too, how is bScreen, dScreen,cScreen,pBuf used in __WINS__ mode? what about in __ARMI__ mode? was this taken from an example that I can follow? Can you show me how dScreen, cScreen,pBuf is used and how they work together?

THanks,!

Thread moved to the developers section.

You can access the screen of the 9500 directly in the same way, but it uses a 16 bit graphics mode. The pixel format is 5/6/5, but since you're using a palette the only thing you need to do is to generate a new one for the 9500. You might also want to stop drawing if your program loses focus or if a system menu pops up, but this you probably already know 😊

Yeah, I already have the 9500 defines/code. And the 5/6/5 since (lucky thing) the palm, ppc and symbian uiq Redshift engine use this.

I just need testers 😊
And some "bumm" on the communicator market. If we compare the Legacy sales for Nokia Communicator, Symbian UIQ, PPC, Palm, well the Communicator version is the far worst. 68 sold pieces since 30th april.
Palm means thousands.

Stewe

Hello,

I am still having problems with my program, inside my display.h

private:
    TUint8* iScreenAdr;
    CFbsBitmap* iOffScreenBmp;
    CFbsScreenDevice* iScreenDevice;
    CFbsBitGc* iGc;
#endif

void Test::Setup()
{
    iOffScreenBmp = new (ELeave) CFbsBitmap;
    iOffScreenBmp->Create(TSize(176,208), EColor4K);
    iScreenDevice = CFbsScreenDevice::NewL(_L(""😉, EColor4K, TRgb(255,255,255));
    iScreenDevice->ChangeScreenDevice(NULL);
    iScreenDevice->SetAutoUpdate(EFalse);
    iScreenAdr = (TUint8*)iOffScreenBmp->DataAddress();
    iScreenDevice->CreateContext(iGc);
}
void Test::TryIt()
{
    TUint16* ptr = (TUint16*)iScreenAdr;
    for(TInt k = 0; k < 208*176; k++)
    {
        *ptr++ = 0x0afe; // it crashes in here because it seems like iScreenAdr points
                                    //  to TUint8 [208*176] instead of 
                                    // TUint16[208*176];   :icon13: 
    }
// It never reaches here.
    CConsoleBase*cons=Console::NewL(_L("a"😉, TSize(-1,-1));
    cons->Printf(_L("here"😉);
    cons->Getch();
    delete cons;
}

------------------- I made the following changes to the code ------------------------

void Test::Setup()
{
    iOffScreenBmp = new (ELeave) CFbsBitmap;
    iOffScreenBmp->Create(TSize(4*176,4*208), EColor4K);    
    iScreenDevice = CFbsScreenDevice::NewL(_L(""😉, EColor4K, TRgb(255,255,255));
    iScreenDevice->ChangeScreenDevice(NULL);
    iScreenDevice->SetAutoUpdate(EFalse);
    iScreenAdr = (TUint8*)iOffScreenBmp->DataAddress();
    iScreenDevice->CreateContext(iGc);
}
void Test::TryIt()
{
    TUint16* ptr = (TUint16*)iScreenAdr;
    for(TInt k = 0; k < 2*208*2*176; k++)
    {
        *ptr++ = 0x9afe; // this does NOT crash now!! unless I change loop to
                                    // 4 * 208 * 4 * 176. strange
    }
}

What do you think is going on here? Why don't you have to go through all this on your software?

I'm running Symbian 7.0s SDK on windows 2000 pro.

Thanks,
Erica

Hello!

My example is for Nokia Communicator... on Series 60, I do this:

// init

iScreenMode=iEikonEnv->DefaultDisplayMode(); // from appui

dScreen=CFbsScreenDevice::NewL(_L(""😉,iScreenMode);
dScreen->ChangeScreenDevice(NULL);
dScreen->SetAutoUpdate(EFalse);
dScreen->CreateContext(cScreen);

bScreen=new(ELeave) CFbsBitmap();
bScreen->Create(TSize(176,208),iScreenMode);
// doesn't matter: pbScreen=(TUint16 *)bScreen->DataAddress();

pBuf=new(ELeave) TUint8[176*208];

// update

pbScreen=(TUint16 *)bScreen->DataAddress(); // !!!!!!! the ptr can change!!!!

TUint16 *s=(TUint16 *)pbScreen;
TUint8 *p=pBuf;

TUint8 *endp=pBuf+176*208;

while(p<endp)
*s++=cPalette[*p++];

cScreen->BitBlt(TPoint(),bScreen);
dScreen->Update();

------------------------------------------------------------------

you could use the various "directdraw" examples you found. However, I had problems using them, and they weren't so faster.

check it: I always ask again the ptr to the offscreen bitmap!!! It can be changed, beceuase of heap modifications!

Stewe

Well, since I'm looking at three 9500 mobiles sitting on my desktop I'm thinking I should help you. Since I'm also looking at a deadline approaching really fast for my own project I can't stress test it though. But firing it up just to see if the graphics and audio etc is working on a real device would be no problem. Just let me know if you need that kind of help.

Regarding the communicator market I think that it will get a real boost with the introduction of the 9300, so you might just get exactly what you need 😊

Cool!!!
Thanks.
Please gimme a mail at [email][email protected][/email]

Btw could you please check the currently released version? http://www.redshift.hu/redshift/Legacy.sis

Stewe

movax wrote:Well, since I'm looking at three 9500 mobiles sitting on my desktop I'm thinking I should help you. Since I'm also looking at a deadline approaching really fast for my own project I can't stress test it though. But firing it up just to see if the graphics and audio etc is working on a real device would be no problem. Just let me know if you need that kind of help.

Regarding the communicator market I think that it will get a real boost with the introduction of the 9300, so you might just get exactly what you need 😊

Hi,

I got it working! I have another question now. The series60 is has 12bit resolution that gives me 4096 colors, what kind of tool are you using to convert 16bit or 24bit graphics down to 12bit graphics?

do you mean design-time or run-time?

design-time:
personally I would use an own compression, and convert rgb to 12 bit, using rrrrrrrr-gggggggg-bbbbbbbb to 000rrrr-ggggbbbb.
Legacy uses 8bit source images, with a modified png/zlib-like compression.

run-time.
the same, bitmasking. from rgb (above) or 64k (rrrrrggg-gggbbbbb) to 12bit.

I like the 64K colors as inner buffer, since easy to convert (even to 4K, even in real-time), and for example alpha blending, ...

Stewe

what do you mean by 64K colors as inner buffer and convert to 4K I don't understand what you mean by that. I converted my bitmaps to 0000rrrrgggbbb but the pixels are not displaying at the proper color. I ripped of the leading for bites from each color.

Also, can I have a namespace in symbian and can I insert static data in it, or should I place the static data in a class?

Thank you!
Erica

redshift wrote:do you mean design-time or run-time?

design-time:
personally I would use an own compression, and convert rgb to 12 bit, using rrrrrrrr-gggggggg-bbbbbbbb to 000rrrr-ggggbbbb.
Legacy uses 8bit source images, with a modified png/zlib-like compression.

run-time.
the same, bitmasking. from rgb (above) or 64k (rrrrrggg-gggbbbbb) to 12bit.

I like the 64K colors as inner buffer, since easy to convert (even to 4K, even in real-time), and for example alpha blending, ...

Stewe

This should work... I mean if you use a device with 4K color display.
I use this in Legacy Symbian UIQ, Legacy Nokia Communicator, and Dragonfire Series 60.

I simply like the 64K buffer, because contains more info about colors, but easy to convert to 4K, even getting the r,g,b.
If you plan to work with blending, later, 4K colors won't be enough as intermediate buffer.

Stewe

earamsey wrote:what do you mean by 64K colors as inner buffer and convert to 4K I don't understand what you mean by that. I converted my bitmaps to 0000rrrrgggbbb but the pixels are not displaying at the proper color. I ripped of the leading for bites from each color.

Also, can I have a namespace in symbian and can I insert static data in it, or should I place the static data in a class?

Thank you!
Erica

So, I should use EColor64K, instead of EColor4K? Should all of my bitmaps be 64K palette then? I thought that once you set the rrrrgggbbb that was all there's to it; it can only be one color. Do you have any idea why i'm not getting the right colors? for example 0x9C0 is green on pc but's it's darkblue on emulator. Are you saying that I should set the bitmap buffers to EColor64K? When do I do this conversion from 64K to 4K runtime?

Thank you,
I Appreciate your input. By The Way, do you have any infomation on Fixed Point Math on ARM4?

OH yeah, I'm getting my technical publications straight from ARM processor maker for free, goto arm.com and check it out.

redshift wrote:This should work... I mean if you use a device with 4K color display.
I use this in Legacy Symbian UIQ, Legacy Nokia Communicator, and Dragonfire Series 60.

I simply like the 64K buffer, because contains more info about colors, but easy to convert to 4K, even getting the r,g,b.
If you plan to work with blending, later, 4K colors won't be enough as intermediate buffer.

Stewe

Hello!

The emulator can use 64K color, while on the device, you may have to use 4K color. Can you set the color depth in the emulator? Maybe ini file?

I always get the current color depth, before doing anything.
iEikonEnv->DefaultDisplayMode()
what I use.
if it's EColor4K, then I use the 4K macro, while with EColor64, of course I use the 64K macro.

I can't imagine how could "9c0" mean a darkblue color. You can see the lower bits are all 0, and the blue component always the lowest part.
the "9c0" should mean a strong green in 64K, but a yellow (a greener yellow) in 4K. No blue at all.
If you list some other combinations (I mean XXX looks like blue in emulator but red on pc) we would be able to find a rule 😊

The real-time conversion isn't the best idea, use it when you have to. For example our project: the inner buffer is in 8bit, so I *have* to use a real-time conversion. Slow - would be better in 4K or 64K.

Fixed point math: I don't have too much experience. Now we have a new, full 3D logical game, written by my friend - for Arm. For palm, ppc and symbian. I can't see any special solutions in his code, except the pre-generated sin/cos list and the tricky sqrt.

Stewe

earamsey wrote:So, I should use EColor64K, instead of EColor4K? Should all of my bitmaps be 64K palette then? I thought that once you set the rrrrgggbbb that was all there's to it; it can only be one color. Do you have any idea why i'm not getting the right colors? for example 0x9C0 is green on pc but's it's darkblue on emulator. Are you saying that I should set the bitmap buffers to EColor64K? When do I do this conversion from 64K to 4K runtime?

Thank you,
I Appreciate your input. By The Way, do you have any infomation on Fixed Point Math on ARM4?

OH yeah, I'm getting my technical publications straight from ARM processor maker for free, goto arm.com and check it out.

redshift wrote:Hello!

My example is for Nokia Communicator... on Series 60, I do this:
dScreen=CFbsScreenDevice::NewL(_L(""😉,iScreenMode);
[..skipped..]
------------------------------------------------------------------
Stewe