Community: Developer Discussion Boards

vikrambk

Hi!

I am working on a J2ME game where I have a lot of images due to which the file size is exceeding 64kb, I tried putting all the images in a single png file and then clipping the required object, but on the phone I get a white patch where the image is transparent. Can someone tell me how to set the transparency while clipping the image, if this is not possible what other method can be used to reduce the image size.

Thanks

Vikram

shmoove

I've had the same problem.
My solution wasn't pretty, but it worked:
I keep all the images in the one original png. Then when I want to draw the a frame from this png onto some background whose Graphics object is g, I set the clip region of g to the size of the frame and then I draw the big image onto g with an offset of
(-xPos,-yPos)
where (xPos,yPos) are the coordinates of the frame inside the big image.
For example:
I want to draw a frame that is on (0,10) on the png, and whose size is 8x8 onto a Graphics context "g" on the coordinate (30,50):
<code>
// get current clipping coordinates, so we can reset them when
// we are finished
int clipX = g.getClipX();
int clipY = g.getClipY();
int clipH = g.getClipHeight();
int clipW = g.getClipWidth();
// set the new clip region for g
g.setClip(30,50,8,8);
// let's say the png is in imgGraphics
// we draw the image with an offset of (-0,-10) from the
// desired coordinates
g.drawImage(imgGraphics,30-0,50-10,Graphics.TOP|Graphics.LEFT);
// set the old clip region back
g.setClip(clipX,clipY,clipW,clipH);
</code>
Hope I made myself clear enough, but if there is anything you don't understand just ask...

shmoove

iecomdev

hi shmoove!

thats works fine and solved my transparent problem!

did you know if there is a performance problem to draw a large image using setClip instead of drawing smal images?

i think my font draw routine is now slower than bevor

any experiance

andreas

Chris_23

Hi!

Another, more resource and performance friendly way would be
using Nokias UIAPI (package com.nokia.mid.ui ) - but that will
only work on Nokia devices...

But it provides, besides some other very useful tools for game developement, a way to initialize images with a transparent
background:
( See Nokia UI API Programmer's guide for more details)

image FontImage = Image.createImage("font.png");
image Character[] = new Image[num_characters]
for( int i=0; i<num_characters; i++ ) {
Character[i] =
DirectUtils.createImage( character_width, character_height, 0x00000000 );
Graphics g = Character[i].getGraphics();
g.DrawImage( -character_width * i, 0, Graphics.TOP | Graphics.LEFT );
}

DirectUtils.createImage() takes a color value as third parameter, which is not 'rgb' but 'argb', (0xaarrggbb) - the most significant byte specifies the 'Alpha'-value: 0xFFrrggbb is fully opaque and 0x00rrggbb is fully transparent. (Most phones won't support alpha-blending, so values greater than 0 will be treated as fully opaque on the most devices)

ChrisK

iecomdev

hi chris!

yes, thats true but on the series60 phones it doesnt work
the AA param in AARRGGBB schould be 00 for fully transparent but thist doesnt work - i dont know why
some told me that the alphaparam on series60 is inverted but if i use FF instead of 00 i got the same problem - fully opaque images.

any solutions?

see also tread:
http://discussion.forum.nokia.com/fo...threadid=17567

andreas

Chris_23

Hi andreas!

mmmh - you're right, sorry didn't try that on the s60 Emulator
before...
Tried some variations (used DirectGraphics.DrawImage instead of Graphics.DrawImage etc.) but that didn't solve the problem either...

ChrisK

tobe@tobe.demon.co.uk

Had the same problem this morning.. nice solution, Shmoove.

An alternative approach which comes to mind but only really works for tiled games might be:

create a tile sized image (the cache)

for each tile on the screen:

copy tile to cache

for each sprite on the tile:

copy to cache from strip using -ve x offset to select image

copy tile to screen

if tile (original) not opaque, blank the cache

This approach avoids setting clip regions at the expense of the 1 extra drawImage (the tile to the cache first instead of the screen or the cache to the screen last, however you prefer to look at it) and perhaps the blank at the end if your background tiles are not opaque.

I'll do some tests on the emulators to get a rough idea if either approach is significantly better. Note though that this alternative approach get's a lot more complicated if any sprite can span 2 or more tiles.

t o b e

tobe@tobe.demon.co.uk

Did some timings on the draw routines with clip regions set and they seemed to be about 2/3 as fast as without.. time to do 10,000 redraws went up from 15 to 21 seconds.

So I developed a different approach to this. It essentially involves keeping the images as PNGs, many images to a single PNG, but storing them uncompressed (deflate type 0). JAR compression gives you the same squeeze down when you add them to the archive but you can then extract and build new individual images *with* transparency retained from the original strip.

Loads of great advantages to this. You've got direct pixel access to raw image data, so you can do mirror, flip, change colour etc etc before you generate the new image plus you save on heap space because you don't have to keep the strip hanging around in memory to draw. And you still get simplicity of drawImage().

Source code for sale.. :-) Semi-serious about that, actually...

t o b e