Transparency issues

Java on Mobile Devices J2ME
#1

Hi ,

I am trying to build an image in the fly using createImage()
what I want to do is have the background of the image filled with transparency and
then draw my image onto this transparent image, and then use this as a sprite if you like.

(it has to be done this way for the project I am working on)

but for some reason the transparency will not work - i keep getting the image on a non transparent background

  • see example code?

spriteImage=Image.createImage(getWidth(), getHeight());
Graphics gf = spriteImage.getGraphics();
gf.setColor(0xff0000); // seems to fille the image with a red background???
gf.fillRect(0,0,getWidth(),getHeight());

     // should fill with transparent,right?

    // and then draw my sprite on to this image   thus giving a sprite on a transparent background.

Please help, Pretty please,

Cheers

Rmdire

#2

createImage(width,height) creates an opaque image, and anything you draw on it will be on an opaque white background. You are drawing a red rectangle on it (ff0000 is red).

shmoove

#3

ok - thanks for that - so how can I create
a transparent image?

Anybody?

cheers

Rmdire

#4

Why are you doing this?

gf.setColor(0xff0000); // seems to fille the image with a red background Huh?
gf.fillRect(0,0,getWidth(),getHeight());

This does exactly what you’re complaining about…fills the image with a red background.

Anyway…

First off, what MIDP version are you using? If you’re using MIDP1.0, you can’t use transparencies with memory-created images (Image.createImage()). Since you’ve not provided much information, I’ll assume this is the problem.

#5

I guess that Rmdire was actually trying to fill the whole rectangle with ‘transparent-colour’. But Images created with Image.createImage(width,height) are initially completely white, and even if it was possible to set the drawing colour to transparent, drawing on white with transparent would have no effect, rather like drawing on white paper with a pen that contained no ink.

In MIDP 1.0 there’s no way to create a mutable (modifyable) Image with a non-opaque background.

In MIDP 1.0 with Nokia UI API extension (all Nokia MIDP 1.0 phones) you can use the DirectUtils class to create a mutable image whose background is initially any ARGB colour, where A is alpha, i.e. opacity (so 00 is fully transparent, and FF is fully opaque).

In MIDP 2.0 you can use method Image.createRGBImage to create an immutable Image with alpha from an array of ARGB values, which with a little programming can be used to create new transparent sprites.

I’ll be asking for MIDP 3.0 to include transparency support similar to that in the Nokia UI API, but there’s no guarantee they’ll agree.

#6

This may be relevant:
Tip for windows gui programmers (e.g. delphi) trying to do J2ME:
Windows developers can use something like an TImage component and then set the transparent colour to any value - this is normally purple for button icons etc, but this does not apply to J2ME images. In J2ME transparency (so far) only has one value: 0x000000 in RGB mode or 0x00000000 in ARGB, etc.
I though I could get away with this (i.e. set the transparent colour value to anything I wanted) when I first started learning J2ME, but obviously not.
Just a random thought which may help prevent future confusion.

#7

Indeed, the graphic shortcomings in j2me are extremely frustrating, and quite ridiculous.

I started having a preliminary look at jsr184 yesterday, and have already found 1 fundamental limitation - which basically results in procedural texturing being hugely inefficient.

Basically, the only functionality that needs adding is Image2D.getGraphics().

However, because this method is not present - you have to :-

  1. render to an offscreen image. (necessary operation)
  2. getRGB on the offscreen image. (1st unnecessary blit)
  3. Convert the packed TYPE_INT_RGB pixels into TYPE_3BYTE_RGB. (2nd unnecessary slow blit)
  4. pass this TYPE_3BYTE_RGB into Image2D.set(…) (3rd unnecessary copy)

3 Completely unnecessary memory copies.

If a getGraphics() method haad been included in Image2D, you would be able to bind your Graphics3D context directly to the texure, and eliminate all 3 blits!

All they put in, was a set(x,y,width,height, TYPE_3BYTE_RGB byte[]);

What purpose does exposing this method serve!
Whatever happened to encapsulation and OO!!

The only conclusion I can make, is that the ‘expert’ group behind the development of jsr184 arn’t realy all that ‘expert’ afterall.

#8

Thanks for your comments

I solved it myself.

Rmdire