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

Developer

Forums

Forums:

I am having a very strange occurence of CONVERTBMP failing - on a t720 right now

I'm loading various bitmaps from my bar file and convert them to native bitmaps. It works perfecty for all but two of them. I'm using ISHELL_LoadResData for read my images from the BAR file and to obtain a pointer ot the bitmap data that I can then pass into CONVERTBMP.
The bitmaps in question load fine, and checking the memory contents also reveals that they have indeed been correctly loaded. The image header info is correct. However, the call to CONVERTBMP fails and the imageInfo block for ConvertBMP shows negative width, and height numbers, as well as negative colors...

It is definitely not a memory problem, and I have also already saved the image in 4-bit and 8-bit BMPs respectively to see if it makes any difference, but the application continues to fail on those specific two bitmaps.

Did anyone ever see this sort of problem before?

never had those problems... maybe you can try to have a even nb of pixels per line?

never had those problems... maybe you can try to have a even nb of pixels per line?

I managed to solve the problem this morning. It appears as if somthing was wrong with the actual file format, I suppose. I took both images, copied-and-pasted them into new ones and saved them out anew, and all of a sudden it was working.

I managed to solve the problem this morning. It appears as if somthing was wrong with the actual file format, I suppose. I took both images, copied-and-pasted them into new ones and saved them out anew, and all of a sudden it was working.

i had a similar problem with a t720,
and oddly enough it was only corrected when i copy pasted the image to another one and saved again
exactly the same behaviour, weird!!!

i had a similar problem with a t720,
and oddly enough it was only corrected when i copy pasted the image to another one and saved again
exactly the same behaviour, weird!!!

Hey y'all, heads up on a T720 bug (not other phones afaik)
If you do a CONVERTBMP where the src img is 16 bit, it fails on the T720 (returns NULL). Never mind that this is clearly bullshit, you're used to that by now.
You've probably found this failure out for yourself (and is documented somewhere on these forums), but betcha didn't know that although it fails, it leaves a suitable-sized fricking destination buffer MALLOC'd!
You may well ask why I'm doing a CONVERTBMP that I know fails, well it's because on other handsets it doesn't fail and I detect the failure and do something else instead. Alas I wasn't expecting it to eat my RAM and not even give me a pointer to FREE it.
Also beware BMP format wallpapers on a specific firmware revision of the VX6000 - I think firmware V6 is bugged - in some cases (never really tracked it down) you can save BMP wp's ok, and they view ok in the phone OS, but when you set them as wallpaper the phone simply does nothing (says it has set the new image as WP, but it hasn't). PNG works fine, JPG has other problems to do with white bars and other crap bugs that would be laughable if they hadn't caused me such pain.
Sigh.

Hey y'all, heads up on a T720 bug (not other phones afaik)
If you do a CONVERTBMP where the src img is 16 bit, it fails on the T720 (returns NULL). Never mind that this is clearly bullshit, you're used to that by now.
You've probably found this failure out for yourself (and is documented somewhere on these forums), but betcha didn't know that although it fails, it leaves a suitable-sized fricking destination buffer MALLOC'd!
You may well ask why I'm doing a CONVERTBMP that I know fails, well it's because on other handsets it doesn't fail and I detect the failure and do something else instead. Alas I wasn't expecting it to eat my RAM and not even give me a pointer to FREE it.
Also beware BMP format wallpapers on a specific firmware revision of the VX6000 - I think firmware V6 is bugged - in some cases (never really tracked it down) you can save BMP wp's ok, and they view ok in the phone OS, but when you set them as wallpaper the phone simply does nothing (says it has set the new image as WP, but it hasn't). PNG works fine, JPG has other problems to do with white bars and other crap bugs that would be laughable if they hadn't caused me such pain.
Sigh.

FryingLizard wrote:If you do a CONVERTBMP where the src img is 16 bit, it fails on the T720 (returns NULL). Never mind that this is clearly bullshit, you're used to that by now.
AKAIK, 16 and 24 bits bitmaps are not supported, huh?

FryingLizard wrote:If you do a CONVERTBMP where the src img is 16 bit, it fails on the T720 (returns NULL). Never mind that this is clearly bullshit, you're used to that by now.
AKAIK, 16 and 24 bits bitmaps are not supported, huh?

16-bit BMPs are supported on newer phones. I was mostly pissed off because of the not-freeing-memory bug, which caused substantial delays while finding it (like I say, only happens on T720/T730 afaik) and hence some political difficulties with our publisher.
The reason I'm using 16bpp BMPs is because I detect the native image header format at runtime and thereby get to write pixels directly on Brew 1 devices. I don't use any of the Brew drawing functions apart from a single BitBLT, primarily because they are near useless, especially the concept of OEM-dependent immutable fonts, which manages to make it into firmly into the "I cannot believe someone thought this was acceptable" category. Yes, I know they've done some stuff with it on Brew 2+ but that's no use given the number of Brew 1 handsets out there.
I've been a programmer for 20 years and my opinion on the design, implementation and quality control of the Brew API & platform is best not printed here.
I know things are improving somewhat nowadays (apart from the # of undetected and uncorrected OEM bugs), and some of the new handset hardware is great but until the Brew-1-only market is dead + buried I will still bear grudges against whoever made those dumbass design decisions.

16-bit BMPs are supported on newer phones. I was mostly pissed off because of the not-freeing-memory bug, which caused substantial delays while finding it (like I say, only happens on T720/T730 afaik) and hence some political difficulties with our publisher.
The reason I'm using 16bpp BMPs is because I detect the native image header format at runtime and thereby get to write pixels directly on Brew 1 devices. I don't use any of the Brew drawing functions apart from a single BitBLT, primarily because they are near useless, especially the concept of OEM-dependent immutable fonts, which manages to make it into firmly into the "I cannot believe someone thought this was acceptable" category. Yes, I know they've done some stuff with it on Brew 2+ but that's no use given the number of Brew 1 handsets out there.
I've been a programmer for 20 years and my opinion on the design, implementation and quality control of the Brew API & platform is best not printed here.
I know things are improving somewhat nowadays (apart from the # of undetected and uncorrected OEM bugs), and some of the new handset hardware is great but until the Brew-1-only market is dead + buried I will still bear grudges against whoever made those dumbass design decisions.

I still don't understand why you need 16-bit BMPs in order to do that. I've been doing that in the past as well but I've been using highly compressed propriertary image formats which circumvent all of the BREW API bugs. You just do a quick conversion into the 16-bit native color space at load-time.
I'm no longer doing it becasue I've altogether dropped support for 1.x BREW devices. They are disappearing so fast from the face of the earth that I just no longer care.

I still don't understand why you need 16-bit BMPs in order to do that. I've been doing that in the past as well but I've been using highly compressed propriertary image formats which circumvent all of the BREW API bugs. You just do a quick conversion into the 16-bit native color space at load-time.
I'm no longer doing it becasue I've altogether dropped support for 1.x BREW devices. They are disappearing so fast from the face of the earth that I just no longer care.

Start app. Find display dimensions. Generate a 16-bit BMP of the same size in memory, containing a test pattern and CONVERTBMP it. Scan the result to find the native format pixels and work out device pixel format. From then on just use that buffer as a 16-bpp frame buffer (or for T720 = 12bpp), BITBLT it once per frame (use dirty rectangles for extra performance) and no more Brew draw calls at all. Yay that. Naturally I use my own image compression, blitting, etc. Naturally on Brew 2 there isn't a problem (apart from one or two Brew 2 phones that don't give you framebuffer access).
From what I remember you saying elsewhere, you're doing this also Dragon - I think it's a pretty common trick. I actually have an even better trick than that for Brew 1 handsets.. ;-)
Regards,
FL

Start app. Find display dimensions. Generate a 16-bit BMP of the same size in memory, containing a test pattern and CONVERTBMP it. Scan the result to find the native format pixels and work out device pixel format. From then on just use that buffer as a 16-bpp frame buffer (or for T720 = 12bpp), BITBLT it once per frame (use dirty rectangles for extra performance) and no more Brew draw calls at all. Yay that. Naturally I use my own image compression, blitting, etc. Naturally on Brew 2 there isn't a problem (apart from one or two Brew 2 phones that don't give you framebuffer access).
From what I remember you saying elsewhere, you're doing this also Dragon - I think it's a pretty common trick. I actually have an even better trick than that for Brew 1 handsets.. ;-)
Regards,
FL

Which 2.0 handsets don't give you framebuffer access? (I'm assuming through IDIB)?
Tom

Which 2.0 handsets don't give you framebuffer access? (I'm assuming through IDIB)?
Tom

I haven't found any yet. So far all that I've worked with gave me framebuffer access through an IDIB.

I haven't found any yet. So far all that I've worked with gave me framebuffer access through an IDIB.

FryingLizard wrote:16-bit BMPs are supported on newer phones.
...and they use Brew versions >1.1 and this is v1.1 forum. Could be confusing for newbies.
Just 2 cents

FryingLizard wrote:16-bit BMPs are supported on newer phones.
...and they use Brew versions >1.1 and this is v1.1 forum. Could be confusing for newbies.
Just 2 cents

Hey you know I really do think I found one at one point. Was definitely Brew 2 but just wouldn't throw me an IDIB when I asked (returned 'NOPE!' when I asked for, and the code works on every other device under the sun.
if (SUCCESS == IDISPLAY_GetDeviceBitmap( pDm->oApplet.m_pIDisplay , &pBm))
{
if (SUCCESS==IBITMAP_QueryInterface( pBm , AEECLSID_DIB , (void**)&pDIB))
..basically it failed on the QueryInterface.
..Now I'm going to really annoy you by not remembering which one it was.. Will come back and edit this post as soon as I remember.
BTW all you Brew 2 framebuffer-hitters out there - you are all aware there is an 18-bit phone out there, the Motorola 710C, which uses a 32-bit per pixel display? Good.
It returns you
#define IDIB_COLORSCHEME_666 18
which isn't in the Brew 2 header files (is in Brew 3 I think) although the handset is still Brew 2.something.
The display is formatted exactly how you would expect a 666 format display to be, and just to reiterate it's stored as 32-bit per pixel.
Ya so that tip is in the wrong thread. Sue me. Everyone uses the search function anyway. ;-)
Hugs,
FL

Hey you know I really do think I found one at one point. Was definitely Brew 2 but just wouldn't throw me an IDIB when I asked (returned 'NOPE!' when I asked for, and the code works on every other device under the sun.
if (SUCCESS == IDISPLAY_GetDeviceBitmap( pDm->oApplet.m_pIDisplay , &pBm))
{
if (SUCCESS==IBITMAP_QueryInterface( pBm , AEECLSID_DIB , (void**)&pDIB))
..basically it failed on the QueryInterface.
..Now I'm going to really annoy you by not remembering which one it was.. Will come back and edit this post as soon as I remember.
BTW all you Brew 2 framebuffer-hitters out there - you are all aware there is an 18-bit phone out there, the Motorola 710C, which uses a 32-bit per pixel display? Good.
It returns you
#define IDIB_COLORSCHEME_666 18
which isn't in the Brew 2 header files (is in Brew 3 I think) although the handset is still Brew 2.something.
The display is formatted exactly how you would expect a 666 format display to be, and just to reiterate it's stored as 32-bit per pixel.
Ya so that tip is in the wrong thread. Sue me. Everyone uses the search function anyway. ;-)
Hugs,
FL

Thanks for the heads-up, Lizard. Good to know.

Thanks for the heads-up, Lizard. Good to know.