Clipping doesn't work with DirectGraphics?

[jengstro]

Hi everyone!

I have been doing some testing using images created with DirectGraphics-methods and found out the following:

1. The transparency of images created with DirectGraphics is lost when drawing through an ordinary Graphics-object. Drawing through a DirectGraphics-object fixes the problem.

Ok, this i can live with, BUT:

2. Clipping does not work when drawing an image through DirectGraphics into a mutable image. Instead of a clipped image the whole image is drawn. The clipping only seems to work when drawing directly to the screen in the paint-method.

For example (in FullCanvas paint-method):

a)

g.setClip(0, 0, 60, 60);
DirectGraphics dg = DirectUtils.getDirectGraphics(g);
dg.drawImage(directGraphicsImage, 0, 0, Graphics.LEFT|Graphics.TOP, 0);

b)

// earlier I've initialized an image background and gotten
// the Graphics-object for it via getGraphics
backgroundGraphics.setClip(0, 0, 60, 60);
DirectGraphics dg = DirectUtils.getDirectGraphics(backgroundGraphics);
dg.drawImage(directGraphicsImage, 0, 0, Graphics.LEFT|Graphics.TOP, 0);
g.drawImage(background, 0, 0, Graphics.LEFT|Graphics.TOP);

So of these two examples a) clips properly into a 60x60 rectangle and b) does not (but draws the entire image).

Clipping has been a very convenient way to draw animated sprites until now, but it seems I cannot do it any more with DirectGraphics-images? The alternative would be to create a separate image for each of the sprite's frames which would cause a lot of unnecessary memoryloss.

Is there any workaround for this problem? Am I doing something wrong? I already tried creating the background-image using DirectGraphics createImage-method - did not help.

Johan

[wesbiggs]

FWIW, I have the same issue. Look forward to a response from Nokia on any possible workarounds.

[albech]

>>Clipping has been a very convenient way to draw animated
>>sprites

>>The alternative would be to create a separate image for each
>>of the sprite's frames which would cause a lot of unnecessary >>memoryloss.

There's another and better option to that problem.

First, you should forget about using drawImage at all - its slow, unflexible, and on some devices it simply does not work like expected.
Use drawPixels() instead - its way faster and works across all devices (at least, the currently available ones...

For animated sprites, we've created a class ("ImageStrip") that loads an image containing all animation frames vertically aligned, allocates (direct) pixel data, and renders the image into the pixel data. ImageStrip is given the number of "cells" (= animation frames) either from the file itself or by parameter, and thus knows the height per cell.
When you want to draw a specific cell, the drawing method has the offset into the pixel data (cell number * cell height) and simply calls drawPixels() with that info.
To avoid the multiplications, ImageStrip creates an array of cell pixel data offsets upon initialization.

As an additional benefit, you can even manipulate the pixel data on the fly, e.g. change colors. In our case, we have additional functionality for doing scaled blits for zoom-sprites.

[EvilCartman]

Are there any details anywhere on how to grab the pixel data from an image and manipulate colours etc?

[albech]

You can find everything necessary in the Nokia UI API / DrectGraphics section.

Here's a small excerpt from our code doing just that with a standard Image object.

// get a graphics context
Graphics gc;
DirectGraphics dg;

gc = inImage.getGraphics();
dg = DirectUtils.getDirectGraphics(gc);

// allocate and retrieve the pixel data
m_pixels = new short[m_width * image_h];
dg.getPixels(m_pixels, 0, m_width, 0, 0, m_width, image_h, m_type);

where 'm_type' is set to either DirectGraphics.TYPE_USHORT_4444_ARGB or DirectGraphics.TYPE_USHORT_4444_RGB, depending on the transparency setting of the animation.

now poke around in 'm_pixels' and blast them on the screen with drawPixels()....

[EvilCartman]

thanks, will have a good look.

[jengstro]

>Use drawPixels() instead - its way faster and works across
>all devices (at least, the currently available ones...

Thanks for the tip. I will try to do it with drawPixels. You said that this technique is faster than drawImage - have you tested how much faster?

BR,

Johan

[albech]

>>You said that this technique is faster than drawImage -
>>have you tested how much faster?

drawPixels() turned out to be approx. 5 times faster than drawImage() in our tests.

[EvilCartman]

Just tried that method above and i get an IllegalStateChangeException.

any suggestions?

[albech]

Then I guess your image is immutable.

for:

gc = inImage.getGraphics();

you need a mutable image, of course.

[EvilCartman]

Ah i see, so something like this then:




Image copy = Image.createImage(img.getWidth(), img.getHeight());
Graphics g = copy.getGraphics();
DirectGraphics dg = DirectUtils.getDirectGraphics(g);
g.drawImage(img, 0, 0, Graphics.TOP|Graphics.LEFT);

pixels = new int[width * height];
dg.getPixels(pixels, 0, width, 0, 0, width, height, type);

to get the image mutable, that a good way tho?

[albech]

>>pixels = new int[width * height];

should read:

pixels = new short[width * height];

>>Image copy = Image.createImage(img.getWidth(), img.getHeight());

works, but why not load a stream and do:

DirectUtils.createImage(data, 0, data.length);

saves you overhead of havin the image in memory twice...

[EvilCartman]

yeh i know about the short. was just trying an int type


load a stream from what? a png or a file? I dont quite get what your saying. where's data come from?

[albech]

>> load a stream from what? a png or a file?

yep, from a png file for example.

[EvilCartman]

I have to say, i'm well confused now.

I tried what i think your trying to say, but i'm probably doing it wrong.

I also want to be able to change the palette as i'm loading the image in.

I'm totally new to all this so i've got no idea how to go about it.

any help would be great.