DrawPixel problem(Weird)

[deltaleeg21]

Hi all,

A problem keeps on bugging me for days:

By implementing these statements

//part one
DirectUtils.getDirectGraphics(s_g).drawPixels(BG, true, 0, Width , BGPosX - s_currentTranslateX, BGPosY, Width - BGPosX, bg1H, 0, DirectGraphics.TYPE_INT_8888_ARGB);

//part two
DirectUtils.getDirectGraphics(s_g).drawPixels(BG, true,Width - BGPosX, Width, - currentTranslateX, BGPosY, BGPosX, bgH, 0, DirectGraphics.TYPE_INT_8888_ARGB);

I split and concate a "looped picture" to show the bg according to current cam's direction

where
bgH is no more than the height of BG
Width equals to the width of BG
and BGPosX is calculated according to cam's looking at matrix

that code block works properly on 6630 6680 n70 n80 and etc EXCEPT 6600
On 6600, it pops up an array out of boundry exception
UNLESS BGPosX is just equal to Width

Waiting for help .......
thanks

[grahamhughes]

This is a previously reported issue on the Nokia 6600.

My recommendation would be: don't use the Nokia API. It's generally unnecessary, unless you need to support MIDP-1 devices. Is there a compelling reason why you want to draw an int[]? Use Graphics.drawImage().

I also notice in your code you have bgH and bg1H, and currentTranslateX and s_currentTranslateX, which looks a bit confusing. You might like to reduce the number of variables you have, if these pairs are supposed to have the same values.

Graham.

[deltaleeg21]

This is a previously reported issue on the Nokia 6600.

My recommendation would be: don't use the Nokia API. It's generally unnecessary, unless you need to support MIDP-1 devices. Is there a compelling reason why you want to draw an int[]? Use Graphics.drawImage().

I also notice in your code you have bgH and bg1H, and currentTranslateX and s_currentTranslateX, which looks a bit confusing. You might like to reduce the number of variables you have, if these pairs are supposed to have the same values.

Graham.

Thanks for that but as I know this machine I mean 6600 has some problems in creating image and this machine has bad supports on drawRegion... So that is why i prefer to use drawpixel.

The prev question helps a lot and i've already fixed it

Thank you all the same for your notes, in fact, they are the same var. Now, I dont know what's the hell i wrote here yesterday. so many typing errors, as you said, it is confusing

[grahamhughes]

The 6600 is a problematic device, and the 6630 and 6680 are not much better. Luckily, Series 60 started to improve after this embarrassing era. I've never needed to use drawPixels() on them, though. I'd worry that writing 24 bits of colour to a 16 bit screen is going to slow things down. But maybe it at least works consistently across all three devices.

Graham.

[deltaleeg21]

The 6600 is a problematic device, and the 6630 and 6680 are not much better. Luckily, Series 60 started to improve after this embarrassing era. I've never needed to use drawPixels() on them, though. I'd worry that writing 24 bits of colour to a 16 bit screen is going to slow things down. But maybe it at least works consistently across all three devices.

Graham.

Amazing you are

But in a big company, sometimes you dont have enough privilege/workTime to modify master sources
The engine just written like that n it's a huge huge work to rewrite them all as you know
What I can do is to make my best to fit the codes into these "Embarrassing" mobiles

Another 3 problem:
1 On Nokia 6600

only 1 drawpixel statement missed its sprites and draw nothing on the screen
What I can make sure is :
1 the data stored in int[]: is abs correct
2 the statement "drawpixel" is executed absolutely without throwing any exception

2 On Nokia 6600

Why my game always freeze when I create Image on this machine.
Same codes works properly on other devices except this

3 On Nokia 6230i

Is it a poor support that nokia 6230i can provide to the function drawpixel();
ref question 1: drawpixel() works with no exception but draw nothing on the screen

just ask
for this device, createImage and drawimage is in high efficiency, I can use another series of settings to configure my codes

Thanks dude

PS: I miss Nottingham a lot, is there some opportunities for mobile game devs in the UK(out of Great London Area)

[grahamhughes]

I've never had a problem with createImage() on the 6600. Which version are you using? I mean, creating from a byte[], a filename, ..?

I don't have experience of using drawPixels() - it was never necessary on the hundred or so commercial games I've worked on. How do you create the int[]?

On the 6600, things failing to draw is sometimes because of clipping. setClip() is broken on older firmwares. However, following a call to setClip() with a call to clipRect() (with the same arguments) seems to fix the problem.

g.setClip(x, y, w, h);
g.clipRect(x, y, w, h);  // add this to fix 6600 clipping

I've never heard anyone say they miss Nottingham! But I understand why you'd want to work outside London. No, there isn't much here any more, most has moved to Eastern Europe, India and China. I may be leaving the country soon too...

Graham.

[deltaleeg21]

In fact our engine fix the problem and provide us a option to solve clipping problems. I've already turn it on but nothing changes. After that I tried your advise by adding setclip/cliprect pairs manually but it doesnt works anyway except slowing down the fps.

In fact, I wrote equal statements with drawRGB instead of drawPixel, but the problem still occurs. Totally no idea.

I createRGBImage from int[] coz our modules and frames are always processed in 8888. Is that have some possibilities to make things wrong?

I am going mad........Our framework or, I'd better say, the engine have some constraints on nokia devices and image processing(e.g. we can only use DirectGraphics.TYPE_INT_8888_ARGB for drawpixel). Even i can touch the source code of the engine, it is not easy to rewrite it systematically&consistently. It is a huge work and the project has a deadline to meet.

But I think, it is possible for me to break it a bit when I have no choice. I'll try them n get in touch with you.


BTW, about Nottingham, I had my post-grad education there n got my master degree. It is a place where I studied and lived for about 2 years. I haven't enjoy any low-speed, peace and happy life like that since i was leaving. I love that, miss that, even it is the most famous Gun City in the UK !

I've never had a problem with createImage() on the 6600. Which version are you using? I mean, creating from a byte[], a filename, ..?

I don't have experience of using drawPixels() - it was never necessary on the hundred or so commercial games I've worked on. How do you create the int[]?

On the 6600, things failing to draw is sometimes because of clipping. setClip() is broken on older firmwares. However, following a call to setClip() with a call to clipRect() (with the same arguments) seems to fix the problem.

g.setClip(x, y, w, h);
g.clipRect(x, y, w, h);  // add this to fix 6600 clipping

I've never heard anyone say they miss Nottingham! But I understand why you'd want to work outside London. No, there isn't much here any more, most has moved to Eastern Europe, India and China. I may be leaving the country soon too...

Graham.

[deltaleeg21]

I found the problem but I dont know why.

The device calculation result to my int[] is not the same with the result on neither emulators nor other nokia mobiles. Do you have any idea about that?

Thanks

I've never had a problem with createImage() on the 6600. Which version are you using? I mean, creating from a byte[], a filename, ..?

I don't have experience of using drawPixels() - it was never necessary on the hundred or so commercial games I've worked on. How do you create the int[]?

On the 6600, things failing to draw is sometimes because of clipping. setClip() is broken on older firmwares. However, following a call to setClip() with a call to clipRect() (with the same arguments) seems to fix the problem.

g.setClip(x, y, w, h);
g.clipRect(x, y, w, h);  // add this to fix 6600 clipping

I've never heard anyone say they miss Nottingham! But I understand why you'd want to work outside London. No, there isn't much here any more, most has moved to Eastern Europe, India and China. I may be leaving the country soon too...

Graham.

[grahamhughes]

The device calculation result to my int[] is not the same with the result on neither emulators nor other nokia mobiles.

Depends how you are calculating. Nothing comes to mind. How is it calculated?

Another common gotcha on the 6600 is the read(byte[]) method when reading from resource files in the JAR, which on most phones will fill the byte[] (if there is enough data). 6600 will read at most 1024 bytes, so you need to use DataInputStream.readFully() instead. Sometimes graphical problems trace back to having failed to read resource data in the first place.

I mention some of these 6600 issues... but there are big firmware differences. If your handset has version 4 or later (like 4.09.1) it probably does not have some of these bugs. If it is 3 or earlier (like 3.42.1), then it probably does. Dial *#0000# to get the version number.

Not aware of problems with createRGBImage(). getRGB() can lose transparency information on the 6680 (and possibly other Series 60s), so that all pixels come out opaque.

Graham.

[deltaleeg21]

Thanks for you help, I got the detailed reason

In that part, the engine draw a frame, which is built on lots of individual pics, on a buffered screen and grab the whole picture from the buffered screen and draw that onto the real one.

rgbTemp = new int[origW * origH];

imageTemp = Image.createImage(origW, origH);
gImageTemp = imageTemp.getGraphics();
dgImageTemp = DirectUtils.getDirectGraphics(gImageTemp);

s_spriteLib[spriteIndex].paintFrame(gImageTemp, frameIndex, -origX, -origY, 0);

dgImageTemp.getPixels(rgbTemp, 0, origW, 0, 0, origW, origH, DirectGraphics.TYPE_INT_8888_ARGB);

In that transformation, because of color depth reason, i cannot get a specified color bigger than 0xF8. For specified color, i mean one of R,G,B. And all alpha channel of colors I catched by using getPixel equals to 0. Seems that the transformation from the pixel format which the machine supports to INT_8888_ARGB leads to the mistake.

So just I wanna know, if the device do not support 8888_ARGB, the method "getPixels" will transform it into DirectGraphics.TYPE_INT_8888_ARGB automatically?
Is the default 16bits color format you mentioned before on 6600 is _1555?
And how does it process the transparency bit "1" when transforming into _8888?

Depends how you are calculating. Nothing comes to mind. How is it calculated?

Another common gotcha on the 6600 is the read(byte[]) method when reading from resource files in the JAR, which on most phones will fill the byte[] (if there is enough data). 6600 will read at most 1024 bytes, so you need to use DataInputStream.readFully() instead. Sometimes graphical problems trace back to having failed to read resource data in the first place.

I mention some of these 6600 issues... but there are big firmware differences. If your handset has version 4 or later (like 4.09.1) it probably does not have some of these bugs. If it is 3 or earlier (like 3.42.1), then it probably does. Dial *#0000# to get the version number.

Not aware of problems with createRGBImage(). getRGB() can lose transparency information on the 6680 (and possibly other Series 60s), so that all pixels come out opaque.

Graham.

[grahamhughes]

You need to call getNativePixelFormat() on the DirectGraphics object on the device.

An Image object stores pixels in the device's native format. This makes it faster to copy data to the screen when you use drawImage(). When you use pixel arrays (as int[] or short[] or whatever), then every pixel has to be converted from one format to the other, unless you use a pixel array in the native format. Not many phones have 24 bit screens, so not many phones use 888 (let's forget alpha for a moment, since the screen hardware itself doesn't have an alpha channel).

The screen hardware itself is, I think, 565. When you ask for 888, the image data has to be padded out with extra bits.

rrrrrggg gggbbbbb  ->  rrrrr000 gggggg00 bbbbb000

Note that if red is 11111 in the original pixel, you will read 11111000 (0xF8). The device could use a cleverer method of converting the data, but it would be slower.

Likewise, when you convert back, some bits will be lost. You probably don't notice this, except that there will be a slight delay.

I said I think the hardware is 565 (16 bits). The image format used by the platform might be something like 1555, losing one green bit in order to add an alpha channel, and still squeeze the complete ARGB value into an exact number of bytes.

Graham.

[deltaleeg21]

You need to call getNativePixelFormat() on the DirectGraphics object on the device.

An Image object stores pixels in the device's native format. This makes it faster to copy data to the screen when you use drawImage(). When you use pixel arrays (as int[] or short[] or whatever), then every pixel has to be converted from one format to the other, unless you use a pixel array in the native format. Not many phones have 24 bit screens, so not many phones use 888 (let's forget alpha for a moment, since the screen hardware itself doesn't have an alpha channel).

The screen hardware itself is, I think, 565. When you ask for 888, the image data has to be padded out with extra bits.

rrrrrggg gggbbbbb  ->  rrrrr000 gggggg00 bbbbb000

Note that if red is 11111 in the original pixel, you will read 11111000 (0xF8). The device could use a cleverer method of converting the data, but it would be slower.

Likewise, when you convert back, some bits will be lost. You probably don't notice this, except that there will be a slight delay.

I said I think the hardware is 565 (16 bits). The image format used by the platform might be something like 1555, losing one green bit in order to add an alpha channel, and still squeeze the complete ARGB value into an exact number of bytes.

Graham.

It's extremelyyyyyyyyyyyyyyyy helpful. To getNativePixelFormat to mask and rebuild the color~

Another problem now I am facing is, the OS warn a java.lang.runtimeException after quitting my game. It is neither coming from the game(My coreEngine catch(Exception e), and handles/hints them inside the game), nor interrupting the game. That warning only appears on the OS screen after exit the game.

Do you have any idea about that?

Thanks

[grahamhughes]

On which device(s)?

Could it be coming from the destroyApp() event? Or could there be a Thread still running?

[deltaleeg21]

On which device(s)?

Could it be coming from the destroyApp() event? Or could there be a Thread still running?

Still Nokia 6600/7610

public void destroyApp (boolean unconditional)
	{
		if (k_verboseMidlet)
		{
			System.out.println("cMIDlet::destroyApp");
		}

		if (s_cGameInstance != null)
		{
			s_cGameInstance.Game_destroy();
		}

		notifyDestroyed ();
		
		if (Debug.k_enableRmsLog)
		{
			Util.RMSLog_close();
		}		
	}

where RMSLog_close() handles all kinds of possible Exceptions and so does Game_destroy()
About thread, i am not sure how to check them on a real machine.

BTW, it happened on mobiles which supports Simplified Chinese.
Firmware V5.27.0ch[6600], V6.0525.0ch[7610]

Meanwhile, on a device which supports only EU5(en es fr de it)
eg firmware 3.42.1, 3.48.0, it works properly.

~~~~~~to some extend, i hate this 6600 a bit now. it started to bug me from the very beginning, and won't stop till the end of the project.......Seems so

[grahamhughes]

First: you should make notifyDestroyed() the last thing you do. There is no guarantee that notifyDestroyed() will return.

Threads... are you doing anything to make sure they stop? How many threads have you created that could still be running?

Graham.