I'm porting a game to the Series 60 platform. One thing that the game does on the original platform is load image data from a custom storage format into a raw 16-bit pixel array (unsigned short *guiImage), instantiate a pixmap object passing in the raw pixel data as its storage buffer, and then whenever any changes are made to the information in the guiImage array, the next screen update reflects those changes.
What I'm wanting to know is how much of a change to that process I need to make for the Symbian platform. i.e. is it possible at all to create a CFbsBitmap with the already-loaded 16-bit pixel array such that any changes made in the array are reflected on-screen when next that bitmap is blitted?
Yes, I've looked at the API docs for the class in question.
The DataAddress() method looks promising, but I'll still have to change the fundamental way the code works in order to use it.
What I was hoping to be able to do was after the raw image data was loaded then all I would have to do is pass the pixel buffer into a bitmap object when it is created, and have that bitmap object use that pixel buffer rather than an internally created one, but there doesn't seem to be any methods to support that kind of thing.
I'll give it some more thought and see what I come up with (and I'll be sure to document my solution here).
Well, I had a brainwave and realised it was a lot simpler than I thought it would be. What I did was instead of trying to fit the loaded image buffer into the bitmap object, I did this instead:
1. Find out the target size of the bitmap that is going to be loaded from the custom file store.
2. Create a CFbsBitmap with display mode EColor64K
3. use DataAddress() to get the bitmap pixel data buffer pointer
4. Invoke the custom load routine, passing the buffer pointer
5. Changed the custom load routine, so instead of malloc()ing a new buffer, just used the existing buffer passed in, and read the 16bit pixel data straight into the buffer
6. Displayed the bitmap, and hey presto! it worked :-) Now that ported C code can manipulate the pixel buffer directly :-)
I don't know why I didn't think of it earlier. Still thinking too much in the paradigm of the other OS (Tao's intent) I think.
Still got a few issues to iron out from other related points in the part of the C application I'm porting, but so far so good.
Emulator = fine, Real device = issues
Well, things are working fine with this part of the ported app on the emulator (btw, I'm targetting the 1.2 SDK).
However, when I create the .SIS file and run on a real device (in my case, I'm testing with an N-Gage) I'm experiencing issues.
When the image is first loaded, a number of patch areas are also loaded, which can be switched in/out (thus making certain regions on the bitmap "dynamic").
I first construct the base pixmap in the constructor of a view class, and reset all the dynamic bits to the default. When the view is displayed, the graphic is perfect.
However, when I subsequently change some of the dynamic bits, it seems as if all the patch regions have shifted down the screen by 80 pixels or so (no X displacement, as far as I can tell), so everything is now out of sync. Nothing of the sort occurred on the emulator, so I'm rather puzzled.
Could it be that the bitmap pixel buffer has actually shifted in memory by some amount after I first construct the view (i.e. DataAddress() returns a different value sometime after initial construction?), or is there likely to be some other side-affect in my code that only shows up on a real device and not the emulator?
Re: Emulator = fine, Real device = issues
Originally posted by ghauber Could it be that the bitmap pixel buffer has actually shifted in memory by some amount after I first construct the view (i.e. DataAddress() returns a different value sometime after initial construction?)
I've just confirmed experimentally on my phone that this is the case... now just not exactly sure what to do with it.
Do I assume that the address will continue to shift, or is it only a one-time thing?
i think after your experiments you have now quite a lot experionce with raw bitmaps. Basically what you do seems to be not a problem. I mean
1) create blank bimtap wiht proper size and color depth
2) use DataAddress() to move the content into
I do exactlu the same for fade effect and other graphic manipulaqitons...It's surely ok, there are just two thinks you must count into:
a) locking heap during pixel manipulaton
b) keep in mind that size of scan lines is computed by Symbian
I'm a newbie to Symbian. I am working with SDK 3.0 and CodeWarrior for Symbian 3.1 (Eval version). I tried to set up the code using the "CFbsBitmap" for displaying a blank screen using one of the project templates available in examples. My question is, Can we run this on the emulator and see the results ? If yes, what is the output that we expect to see(I mean can we actually see the screen going black on the emulator too?)? Ultimately I would like to use this setup to display decoded frames from my H.264 decoder. I realise that I now need to work on a small YUV to RGB converter, after which I can try displaying the pixels from the decoded image. Any pointer/related source codes are welcome with gratitude.