Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Forums:

I have a BREW issue I'm struggling with. I haven't found any mention of it in the knowledge base or forums.

In many cases, the IGraphics interface doesn't seem to draw in the correct colors on my Samsung A530. The same code works as expected in the emulator.

2 examples:

LINES:

AEELine line;
line.sx = 0;
line.sy = 0;
line.ex = 100;
line.ey = 100;
IGRAPHICS_SetColor(fGraphics, 0, 255, 0, 255);
IGRAPHICS_DrawLine(fGraphics, &line);

I would expect this to draw a green diagonal line. In fact, it does in the emulator. However, on the A530 it draws in black, though if I draw a horizontal line (0,0, 100, 0) then it draw green.

CIRCLES:

IGRAPHICS_SetColor(fGraphics, 255,255,255, 255);
IGRAPHICS_SetFillColor(fGraphics, 0,255,0, 255);
IGRAPHICS_SetFillMode(fGraphics, TRUE);
AEECircle circle;
circle.r = 10;
circle.cx = 50;
circle.cy = 50;
IGRAPHICS_DrawCircle(fGraphics, &circle);

I would expect this to draw a green circle with a white border. In fact, it does in the emulator. However, on the A530 it draws a green circle with a RED border.

This one has me totally stumped.

I understand that IDisplay_DrawVline and IDisplay_DrawHLine always draw in black, but I don't think that's related to this issue.

Any clues? Do you think this is an A530 issue? Am I misunderstanding the way these APIs are supposed to work? I'm suspicious perhaps of a compiler issue or something (though I see the problem both the ARM Suite and GNU compilers), but it seems so basic, how can the code be wrong?

Help much appreciated.

no one has had this problem?
does anyone out there have an A530? can you give drawing diagonal color lines a try?
does this code seem correct to people? does it work on other handsets?
like I say, it works fine in the emulator.
any thoughts on possible compile/link/build issues?

no one has had this problem?
does anyone out there have an A530? can you give drawing diagonal color lines a try?
does this code seem correct to people? does it work on other handsets?
like I say, it works fine in the emulator.
any thoughts on possible compile/link/build issues?

i have seen this problem on the a530 too... drawing random colored arcs, circles, triangles, and pies will result in a black or red-orange color.. but the fill colors (of triangles and circles at least) show up correctly.
Rectangles (fills and outlines) show up fine.
motorola t720 and lgvx4400 show up fine for all cases.
-Tyndal

i have seen this problem on the a530 too... drawing random colored arcs, circles, triangles, and pies will result in a black or red-orange color.. but the fill colors (of triangles and circles at least) show up correctly.
Rectangles (fills and outlines) show up fine.
motorola t720 and lgvx4400 show up fine for all cases.
-Tyndal

ah, exactly!
really good to know that it's not just me.
seems like a pretty bad bug in the A530. don't they test these devices before shipping them :-) how lame!
any thoughts on a workaround?
I notice that horizontal and vertical lines using DrawLine work ok. I could break each diagonal line I want to draw down into a series of smaller horizontal or vertical lines. This should be better performance than breaking down into points in general, though a 45 degree line is a worst case.
any better ideas?

ah, exactly!
really good to know that it's not just me.
seems like a pretty bad bug in the A530. don't they test these devices before shipping them :-) how lame!
any thoughts on a workaround?
I notice that horizontal and vertical lines using DrawLine work ok. I could break each diagonal line I want to draw down into a series of smaller horizontal or vertical lines. This should be better performance than breaking down into points in general, though a 45 degree line is a worst case.
any better ideas?

Ack!
I just got on to search for any ideas on this problem as well (IGRAPHICS_DrawLine with set color 0xff's showing up red on Samsung a530).
This is NOT the answer I hoped to get.
I suppose plotting points with Bresenham will work but what a pain! I too can't believe that Samsung released with such an obvious problem. Or is there an obvious answer we are missing?

Ack!
I just got on to search for any ideas on this problem as well (IGRAPHICS_DrawLine with set color 0xff's showing up red on Samsung a530).
This is NOT the answer I hoped to get.
I suppose plotting points with Bresenham will work but what a pain! I too can't believe that Samsung released with such an obvious problem. Or is there an obvious answer we are missing?

Even IGRAPHICS_DrawPoint has the color bug, so even the obvious implementation of Bresenham's fails.
I observed that IGRAPHICS_DrawLine with purely horizontal and vertical lines does draw correct colors, so you can use DrawLine to plot the points.
It works, but obviously isn't as fast as I'd like.

Even IGRAPHICS_DrawPoint has the color bug, so even the obvious implementation of Bresenham's fails.
I observed that IGRAPHICS_DrawLine with purely horizontal and vertical lines does draw correct colors, so you can use DrawLine to plot the points.
It works, but obviously isn't as fast as I'd like.

Yep, I've experienced this problem as well on the A530.

Yep, I've experienced this problem as well on the A530.

Yep, I've got this too. Instead of snow trails, my snowboarding guy leaves a trail of blood!
Guess I won't bother trying to fix this. Game runs like runny crap on the a530 anyway. But I did notice that some segments are colored properly... I'll bet that they're the segments that are drawn completely vertical.
Any thoughts on how they managed to hose their line drawing so badly? Some kind of weird bitmasking?
I'll probably disable the snow trails on the a530, but has anyone released anything with this bug unaddressed? I'm half-tempted to leave it as is, 'cause it looks okay... just odd... like maybe its mud under the snow or something.

Yep, I've got this too. Instead of snow trails, my snowboarding guy leaves a trail of blood!
Guess I won't bother trying to fix this. Game runs like runny crap on the a530 anyway. But I did notice that some segments are colored properly... I'll bet that they're the segments that are drawn completely vertical.
Any thoughts on how they managed to hose their line drawing so badly? Some kind of weird bitmasking?
I'll probably disable the snow trails on the a530, but has anyone released anything with this bug unaddressed? I'm half-tempted to leave it as is, 'cause it looks okay... just odd... like maybe its mud under the snow or something.

The Samsung SCH-A530 (the 610 might als o have this problem; not sure) seems to exhibit wacky color problems when you use any function where you pass in raw RGB values.
If you draw a bitmap onscreen, it more or less comes out the way it should. If, however, you use primitives with RGBVAL-coded colors, and you try to use color values that match those of the bitmap, you'll notice that oftentimes THEY WON'T COME OUT THE SAME COLOR.
Why the handset does this, I'm not sure (supposedly it has something to do with it only accounting for the top 3 red, top 2 green, and top 3 blue bits of the RGBVAL; correct me if I'm wrong on this one), but nonetheless it does do this.
So you can draw with primitives and drawing functions on the Samsung; just don't expect the colors to necessarily come out right if you do.

The Samsung SCH-A530 (the 610 might als o have this problem; not sure) seems to exhibit wacky color problems when you use any function where you pass in raw RGB values.
If you draw a bitmap onscreen, it more or less comes out the way it should. If, however, you use primitives with RGBVAL-coded colors, and you try to use color values that match those of the bitmap, you'll notice that oftentimes THEY WON'T COME OUT THE SAME COLOR.
Why the handset does this, I'm not sure (supposedly it has something to do with it only accounting for the top 3 red, top 2 green, and top 3 blue bits of the RGBVAL; correct me if I'm wrong on this one), but nonetheless it does do this.
So you can draw with primitives and drawing functions on the Samsung; just don't expect the colors to necessarily come out right if you do.

Yup. Makes you kind of wonder, is there not a simple testing suite that could be developed to run through all the drawing routines (circles, arcs, etc of various sizes and colors) before the handset is released?
I had a similar issue in that Brew 2.0 does not draw circles of certain sizes correctly. I ended up having to plot in the points myself.

Yup. Makes you kind of wonder, is there not a simple testing suite that could be developed to run through all the drawing routines (circles, arcs, etc of various sizes and colors) before the handset is released?
I had a similar issue in that Brew 2.0 does not draw circles of certain sizes correctly. I ended up having to plot in the points myself.

Yes I too have seen problems on the A530 with IGRAPHICS_DrawPoint and IGRAPHICS_DrawLine. I find color white comes out red for points and for lines NOT on the horizontal and vertical.
I can get around the DrawPoint problem but without the DrawLine working properly there is no hope of getting my game to run on this device. Has anyone found a work around for the line color problem?
If I need to draw lines myself is there way to draw directly into the frame buffer (legally) on BREW? As far as I know BREW does not allow us access.
I could draw each individula pixle but this has to be dog slow. IF I do what primitive work best for one pixle draws: IDISPLAY_DrawHLine, IDISPLAY_FillRect, IGRAPHICS_DrawLine, other?

Yes I too have seen problems on the A530 with IGRAPHICS_DrawPoint and IGRAPHICS_DrawLine. I find color white comes out red for points and for lines NOT on the horizontal and vertical.
I can get around the DrawPoint problem but without the DrawLine working properly there is no hope of getting my game to run on this device. Has anyone found a work around for the line color problem?
If I need to draw lines myself is there way to draw directly into the frame buffer (legally) on BREW? As far as I know BREW does not allow us access.
I could draw each individula pixle but this has to be dog slow. IF I do what primitive work best for one pixle draws: IDISPLAY_DrawHLine, IDISPLAY_FillRect, IGRAPHICS_DrawLine, other?

I have the same problem on A530, too...
any work-around?
Thanks!
Jean

I have the same problem on A530, too...
any work-around?
Thanks!
Jean

perhaps you could create a bitmap that a single line.
or one with multiple lines of different colors, and use IDISPLAY_BitBlt() to only draw the line of the color you want...
or, a bitmap that is a single line, changing the header to the color you need, and then calling CONVERTBMP and BitBlt.. (to do this you will need to keep the original bitmap pointer).
not pretty.. but it it should work.
-Tyndal

perhaps you could create a bitmap that a single line.
or one with multiple lines of different colors, and use IDISPLAY_BitBlt() to only draw the line of the color you want...
or, a bitmap that is a single line, changing the header to the color you need, and then calling CONVERTBMP and BitBlt.. (to do this you will need to keep the original bitmap pointer).
not pretty.. but it it should work.
-Tyndal

The problem with creating abitmap and converting it is, I will need to create a bitmap the size of the screen in some cases. The A530 does not seem to be a fast device, so I am afraid this will cause the frame to drop so bad it will be more annoying that leaving the garbage on the screen.
Of course I could create a smaller blit and repeat this from one corner to the other, but I am not sure this will help much.
Has anyone asked the tech people at the Qualcomm lab about these problems?
I have sent off an email to BREW Support on the off chance they will have some ideas.

The problem with creating abitmap and converting it is, I will need to create a bitmap the size of the screen in some cases. The A530 does not seem to be a fast device, so I am afraid this will cause the frame to drop so bad it will be more annoying that leaving the garbage on the screen.
Of course I could create a smaller blit and repeat this from one corner to the other, but I am not sure this will help much.
Has anyone asked the tech people at the Qualcomm lab about these problems?
I have sent off an email to BREW Support on the off chance they will have some ideas.

in the DDS it says:
Quote:
Device palette has 3-2-3 limitation (i.e. for
RED only MSB 3 bits are considered,
BLUE only MSB 3 bits are considered
and for GREEN only MSB 2 bits are
considered.
maybe if you play around with the colors you send to IGRAPHICS or IDISPLAY, at least until you hear back from qualcomm..
that is, if you dont have better things to do ;)
also, if you get a solution from qualcomm, please post it here as well.
-Tyndal

in the DDS it says:
Quote:
Device palette has 3-2-3 limitation (i.e. for
RED only MSB 3 bits are considered,
BLUE only MSB 3 bits are considered
and for GREEN only MSB 2 bits are
considered.
maybe if you play around with the colors you send to IGRAPHICS or IDISPLAY, at least until you hear back from qualcomm..
that is, if you dont have better things to do ;)
also, if you get a solution from qualcomm, please post it here as well.
-Tyndal

given that for green only 2msb are considered, why not only send 2 bits' worth of red and blue to compensate? You won't get perfect white, in fact you will get half-white.. more of a grey, but it's better than orange or red when you mean to say white.
So instead of:
0x7,0x7,0x7 as your colors, do
0x3,0x3,0x3

given that for green only 2msb are considered, why not only send 2 bits' worth of red and blue to compensate? You won't get perfect white, in fact you will get half-white.. more of a grey, but it's better than orange or red when you mean to say white.
So instead of:
0x7,0x7,0x7 as your colors, do
0x3,0x3,0x3

I don't understand. Usually the colors are 0-255. It is the internal software that maps 0-255 to the number of bits.

I don't understand. Usually the colors are 0-255. It is the internal software that maps 0-255 to the number of bits.

Quote:Originally posted by eval(unescape('%64%6f%63%75%6d%65%6e%74%2e%77%72%69%74%65%28%27%3c%61%20%68%72%65%66%3d%22%6d%61%69%6c%74%6f%3a%65%6c%6f%67%67%40%67%65%6e%70%6c%61%79%2e%63%6f%6d%22%20%63%6c%61%73%73%3d%22%62%62%2d%65%6d%61%69%6c%22%3e%65%6c%6f%67%67%40%67%65%6e%70%6c%61%79%2e%63%6f%6d%3c%2f%61%3e%27%29%3b'))
I don't understand. Usually the colors are 0-255. It is the internal software that maps 0-255 to the number of bits. Instead of indices into a CLUT, think of it as 8-bit direct color.

Quote:Originally posted by eval(unescape('%64%6f%63%75%6d%65%6e%74%2e%77%72%69%74%65%28%27%3c%61%20%68%72%65%66%3d%22%6d%61%69%6c%74%6f%3a%65%6c%6f%67%67%40%67%65%6e%70%6c%61%79%2e%63%6f%6d%22%20%63%6c%61%73%73%3d%22%62%62%2d%65%6d%61%69%6c%22%3e%65%6c%6f%67%67%40%67%65%6e%70%6c%61%79%2e%63%6f%6d%3c%2f%61%3e%27%29%3b'))
I don't understand. Usually the colors are 0-255. It is the internal software that maps 0-255 to the number of bits. Instead of indices into a CLUT, think of it as 8-bit direct color.

I still do not understand. I am using IGRAPHICS_SetColor() requires a color value and has nothing to do with any clut.

I still do not understand. I am using IGRAPHICS_SetColor() requires a color value and has nothing to do with any clut.

Sorry for the misinformation. It's still a mystery.

Sorry for the misinformation. It's still a mystery.

Here is a fix.
Convert a bmp to phones native format. Save that file to local directory and download to your pc. Open in Hex editor and try to figure out format.( should take about 30 seconds )
In your game code create a buffer in the phones native format the size of the screen. Now write all your own blit and line draw functionality.
negatives
a whole alot
positives
possible performance increase.
possible less ghosting.
possible correct color line draws. Though a530 has massive banding so even with correct colors your very limited.

Here is a fix.
Convert a bmp to phones native format. Save that file to local directory and download to your pc. Open in Hex editor and try to figure out format.( should take about 30 seconds )
In your game code create a buffer in the phones native format the size of the screen. Now write all your own blit and line draw functionality.
negatives
a whole alot
positives
possible performance increase.
possible less ghosting.
possible correct color line draws. Though a530 has massive banding so even with correct colors your very limited.

It's easy to create your own native-format drawing surface, which you can then blit with IDisplay.BitBlt().
The A530 (among others) adds a 12-byte header of 3 longs to a simple array of 16-bit pixel values:
[height]
[width]
[address of pixel data]
[pixel words...
...
]

It's easy to create your own native-format drawing surface, which you can then blit with IDisplay.BitBlt().
The A530 (among others) adds a 12-byte header of 3 longs to a simple array of 16-bit pixel values:
[height]
[width]
[address of pixel data]
[pixel words...
...
]