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

Developer

Forums

Forums:

I'm sorry for bringing this up out of a previous post, but no one was responding, and I'm afraid that that may be becuase I got way too wordy (and cody) and forced people to the back button.

So... as succinctly as possible...

loaded a bmp (successfully, from resource file)

want to run it through CONVERTBMP()

use standard technique of looking at first byte to see size of header.
byte claims that header is 152 bytes.
pass that info in... bubkis.

start at 0 and count 1 byte at a time (added to inital bmp pointer) passing in the address as I go.
Image is found (successfully) at imagePointer + 112th byte.

I guarantee that I'm doing everything by the book. I'll glady paste the code if anyone is curious.

Is it possible that the bmp header has the wrong info? Could this be a result of my having created the bmp in Photoshop?

I REALLY don't want to try to put somthing into production with this bizarre kludge, so, if anyone has seen this before, I would appreciate any and all advice.

Alternatively, throwing your hands in the air and waving them like you just don't care will also be acceptable.

Thanks in advance.

to load a BMP from resource file use LoadResImage()
if you do, no need to call CONVERTBMP()
if you load the image using LoadResData() you will need CONVERTBMP()
unless you are modifying the file you loaded, I suggest you use LoadResImage()

to load a BMP from resource file use LoadResImage()
if you do, no need to call CONVERTBMP()
if you load the image using LoadResData() you will need CONVERTBMP()
unless you are modifying the file you loaded, I suggest you use LoadResImage()

wait... I get a BitBlt reference from LoadResImage()? I thought that for BitBlt I have no choice but to use CONVERTBMP(). At least that's what the documentation seems to imply.
That's the reason I'm using it, I need a BitBlt. And as I said... it's working, it's just not working as documented and finding the image much farther in the memory than the header supposedly reports.
Thanks for answering btw! I was beginning to think that I smell bad! :)

wait... I get a BitBlt reference from LoadResImage()? I thought that for BitBlt I have no choice but to use CONVERTBMP(). At least that's what the documentation seems to imply.
That's the reason I'm using it, I need a BitBlt. And as I said... it's working, it's just not working as documented and finding the image much farther in the memory than the header supposedly reports.
Thanks for answering btw! I was beginning to think that I smell bad! :)

Ronin,
That information is not correct. no matter how you load the bitmap you will always have to call CONVERTBMP on it if you want to draw it using the IDISPLAY class.
However, I am not sure, Dr.Dre'del, what makes you believe the first byte of the native bitmap contains the header size, because that is definitely not the case. The native bitmap format is undocumented but I can tell you that the first byte is NOT the length of the header. I wish it were...

Ronin,
That information is not correct. no matter how you load the bitmap you will always have to call CONVERTBMP on it if you want to draw it using the IDISPLAY class.
However, I am not sure, Dr.Dre'del, what makes you believe the first byte of the native bitmap contains the header size, because that is definitely not the case. The native bitmap format is undocumented but I can tell you that the first byte is NOT the length of the header. I wish it were...

so please forgive my wrong info
but I always loaded the image using LoadResImage() without making a call to CONVERTBMP()
I didn't have any problems so far, it returns a valid IImage *
I may be wrong
anyway, from the docs
Quote:
ISHELL_LoadResImage()
...
This function uses SHELL_LoadResObject
....
ISHELL_LoadResData()
...
...If nType is RESTYPE_IMAGE, then the first
byte indicates the offset where the actual image data begins. The
second byte is zero. Starting from the third byte, the string indicates the
mime type followed by the actual image data.

so please forgive my wrong info
but I always loaded the image using LoadResImage() without making a call to CONVERTBMP()
I didn't have any problems so far, it returns a valid IImage *
I may be wrong
anyway, from the docs
Quote:
ISHELL_LoadResImage()
...
This function uses SHELL_LoadResObject
....
ISHELL_LoadResData()
...
...If nType is RESTYPE_IMAGE, then the first
byte indicates the offset where the actual image data begins. The
second byte is zero. Starting from the third byte, the string indicates the
mime type followed by the actual image data.

Dragon, the first byte containing the size of the header is described thusly in Ralph Barbagallo's book. He also includes a way (albeit somewhat kludgy) to get to the position in the image where the actual image begins... it lookslike this...
byte * pDataBytes = (byte*)MyImage + *((byte*)MyImage);
I have seen this line used in other posts where posters had different problems from mine, and it would seem that this line isn't giving them problems, however, as I said, the byte size reported in MY bmps does not represent the actual size of the header... however, with the amount of detail that the book goes into on how to do this, I can't imagine that it's all just entirely wrong, so I am assuming that either I'm doing something wrong, or, somehow, Photoshop is encoding the BMP differently than whatever was used to encode the BMPs that Ralph used in his examples (though the example image provided with the book, in the accompanying files also doesn't work in this manner).
Seeing as you claim that it doesn't work like that, I'm curious about what technique you use to pass a valid pointer to CONVERTBMP(). Do you go through it one byte at a time until you get something other than NULL as a return value from the method? Or do you have a less ugly solution?
Rubin... thanks for posting that quote from the docs. Indeed, the docs and the book both indicate the the info I'm after SHOULD be in the first byte of the image data... but for some reason, that's not what I'm seeing.

Dragon, the first byte containing the size of the header is described thusly in Ralph Barbagallo's book. He also includes a way (albeit somewhat kludgy) to get to the position in the image where the actual image begins... it lookslike this...
byte * pDataBytes = (byte*)MyImage + *((byte*)MyImage);
I have seen this line used in other posts where posters had different problems from mine, and it would seem that this line isn't giving them problems, however, as I said, the byte size reported in MY bmps does not represent the actual size of the header... however, with the amount of detail that the book goes into on how to do this, I can't imagine that it's all just entirely wrong, so I am assuming that either I'm doing something wrong, or, somehow, Photoshop is encoding the BMP differently than whatever was used to encode the BMPs that Ralph used in his examples (though the example image provided with the book, in the accompanying files also doesn't work in this manner).
Seeing as you claim that it doesn't work like that, I'm curious about what technique you use to pass a valid pointer to CONVERTBMP(). Do you go through it one byte at a time until you get something other than NULL as a return value from the method? Or do you have a less ugly solution?
Rubin... thanks for posting that quote from the docs. Indeed, the docs and the book both indicate the the info I'm after SHOULD be in the first byte of the image data... but for some reason, that's not what I'm seeing.

Ronin,
Dr.,
Okay, we need to clarify a few things here because both of you are seriously mixing up information here.
Ronin...
Of course, LoadResImage returns an IImage pointer. That's the entire purpose of the function. However, CONVERTBMP does not return a pointer to IImage. It returns a pointer to the native bitmap, which is something entirely different and these two are not interchangeable. API calls you can make using an IImage pointer will not work using a native bitmap pointer. There is a lot of documentation available on the difference between these two formats, including the actual Brew documentation, in case you want to learn more about it.
Dr...
In his book Ralph is referring to the length of the MIME header that is at the beginning of the data returned from the resource loading function. It is not part of the actual data and needs to be skipped, and it most certainly will not make it through a CONVERTBMP call. There has been a lot of discussion about loading data from BAR files in the forums, the skipping of the MIME header and other issues, so please do a quick search to read up on the full subject. The important thing to understand is that not all resource loading functions return the MIME header, so depending on which function you are using you may not find the header info, which seems to be your problem.

Ronin,
Dr.,
Okay, we need to clarify a few things here because both of you are seriously mixing up information here.
Ronin...
Of course, LoadResImage returns an IImage pointer. That's the entire purpose of the function. However, CONVERTBMP does not return a pointer to IImage. It returns a pointer to the native bitmap, which is something entirely different and these two are not interchangeable. API calls you can make using an IImage pointer will not work using a native bitmap pointer. There is a lot of documentation available on the difference between these two formats, including the actual Brew documentation, in case you want to learn more about it.
Dr...
In his book Ralph is referring to the length of the MIME header that is at the beginning of the data returned from the resource loading function. It is not part of the actual data and needs to be skipped, and it most certainly will not make it through a CONVERTBMP call. There has been a lot of discussion about loading data from BAR files in the forums, the skipping of the MIME header and other issues, so please do a quick search to read up on the full subject. The important thing to understand is that not all resource loading functions return the MIME header, so depending on which function you are using you may not find the header info, which seems to be your problem.

Dragon,
I'm sorry if I'm not making myself clear, and I have ready through both the documentation and all the posts that were returned when I searched the term CONVERTBMP, and nothing I have read suggests to me that I'm doing anything wrong... so let me explain to you how I understand it, and you tell me if I'm missing something (please).
When I load an image from resource or just via file system I get a pointer to an image (which I can use as is to display the image... and that works).
Now... here's where matters get confusing. The first byte of the image supposedly represents a number which expresses the length of the header (I'm not clear on whether this length includes the byte itself or just the content that follows it). So, since CONVERTBMP doesn't want this header info, but rather, just the image data, we need to pass it a pointer to the first byte where the image actually begins (right behind the header).
In Ralph's book, he says to get this address by using the code I posted above... which makes perfect sense. However, when I try this approach, CONVERTBMP returns null. So, then, in an alternate (crappy) solution, I throw CONVERBMP into a while loop and pass it pointers starting at the very first byte of my image and moving forward until it stops returning null.
This works! but it finds the image at an entirely unpredicted (and seemingly wrong) location.
When I print the content of the first byte it always tells me that the number stored in there is 66. However, it's finding the image at byte 112. Since these aren't null values, and they're not random numbers (because they are always the same) I must be misunderstanding something about the nature of the bmp or the nature of how I'm calling CONVERTBMP().
So... what am I doing wrong? Or what am not understanding correctly?
I greatly appreciate your help.

Dragon,
I'm sorry if I'm not making myself clear, and I have ready through both the documentation and all the posts that were returned when I searched the term CONVERTBMP, and nothing I have read suggests to me that I'm doing anything wrong... so let me explain to you how I understand it, and you tell me if I'm missing something (please).
When I load an image from resource or just via file system I get a pointer to an image (which I can use as is to display the image... and that works).
Now... here's where matters get confusing. The first byte of the image supposedly represents a number which expresses the length of the header (I'm not clear on whether this length includes the byte itself or just the content that follows it). So, since CONVERTBMP doesn't want this header info, but rather, just the image data, we need to pass it a pointer to the first byte where the image actually begins (right behind the header).
In Ralph's book, he says to get this address by using the code I posted above... which makes perfect sense. However, when I try this approach, CONVERTBMP returns null. So, then, in an alternate (crappy) solution, I throw CONVERBMP into a while loop and pass it pointers starting at the very first byte of my image and moving forward until it stops returning null.
This works! but it finds the image at an entirely unpredicted (and seemingly wrong) location.
When I print the content of the first byte it always tells me that the number stored in there is 66. However, it's finding the image at byte 112. Since these aren't null values, and they're not random numbers (because they are always the same) I must be misunderstanding something about the nature of the bmp or the nature of how I'm calling CONVERTBMP().
So... what am I doing wrong? Or what am not understanding correctly?
I greatly appreciate your help.

Yeah, you have misunderstood something entirely here and that's why your code doesn't work.
As I pointed out in my previous post, this header you are referring to is the MIME header. The MIME header is only loaded up if you use certain LoadRes functions - namely LoadResData() and LoadResDataEx()
If you load your image using LoadResImage() or if you load it directly through the file system your data DOES NOT CONTAIN the MIME header!
That's all there is to it, really.
So, if you want to load an image through a regular file read operation, just open it, read it and then feed it into CONVERTBMP() without any modifications.
If you want to load it using LOADRESIMAGE() just do that and once again, feed it into CONVERTBMP() without any modification.
If you are loading your image using LoadResData() or LoadResDataEx() you will have to skip the MIME header with a quick instruction such as
dataPointer = (char *) dataPointer + *((char *)dataPointer);
and then pass the new dataPointer to CONVERTBMP()
I hope this makes it a bit clearer.
---------------------------------------------------------------------
Note to Qualcomm: Give us Direct Frame Buffer Access!

Yeah, you have misunderstood something entirely here and that's why your code doesn't work.
As I pointed out in my previous post, this header you are referring to is the MIME header. The MIME header is only loaded up if you use certain LoadRes functions - namely LoadResData() and LoadResDataEx()
If you load your image using LoadResImage() or if you load it directly through the file system your data DOES NOT CONTAIN the MIME header!
That's all there is to it, really.
So, if you want to load an image through a regular file read operation, just open it, read it and then feed it into CONVERTBMP() without any modifications.
If you want to load it using LOADRESIMAGE() just do that and once again, feed it into CONVERTBMP() without any modification.
If you are loading your image using LoadResData() or LoadResDataEx() you will have to skip the MIME header with a quick instruction such as
dataPointer = (char *) dataPointer + *((char *)dataPointer);
and then pass the new dataPointer to CONVERTBMP()
I hope this makes it a bit clearer.
---------------------------------------------------------------------
Note to Qualcomm: Give us Direct Frame Buffer Access!

Dragon,
First let me say that I appreciate greatly that you take the time to help.
Second, let me argue with you :)
Obviously the first thing I tried when the pointer shifting technique from the book failed was to pass the image pointer in unchanged, to see if the LoadResImage() method was getting me nothing but image data. However, that failed too. That's when I started wandering through the data looking for where the image starts and coming up with the bizarre offset of 112. I can paste the code in to show you what I'm doing, as well as the printout it generates, if you're curious.
Ultimately, I guess the point is moot, since I did get it to work... I'm just worried that when I move this to an actual device it might cause problems because of my unorthodox approach.
Anyway... thanks again.

Dragon,
First let me say that I appreciate greatly that you take the time to help.
Second, let me argue with you :)
Obviously the first thing I tried when the pointer shifting technique from the book failed was to pass the image pointer in unchanged, to see if the LoadResImage() method was getting me nothing but image data. However, that failed too. That's when I started wandering through the data looking for where the image starts and coming up with the bizarre offset of 112. I can paste the code in to show you what I'm doing, as well as the printout it generates, if you're curious.
Ultimately, I guess the point is moot, since I did get it to work... I'm just worried that when I move this to an actual device it might cause problems because of my unorthodox approach.
Anyway... thanks again.

By "image start", do you mean the beginning of the windows bitmap structure (recognised by the appearance of the characters BM (77 & 66 in decimal)), or the beginning of pixel data?

By "image start", do you mean the beginning of the windows bitmap structure (recognised by the appearance of the characters BM (77 & 66 in decimal)), or the beginning of pixel data?

I think basically what Dragon is trying to say (not to put words in his mouth ;) ) is that if the technique to skip the mime header does not work for you, there is probably something going wrong with your code or your image.. lots of people have used this technique before.. and it is known to work.. your technique might work for now, but possibly (probably?) wont work on a actual device.
perhaps you can provide more info about your environment, and/or share the image that is causing problems for you.
i would not recommend using your hack if you can avoid it.
-Tyndal

I think basically what Dragon is trying to say (not to put words in his mouth ;) ) is that if the technique to skip the mime header does not work for you, there is probably something going wrong with your code or your image.. lots of people have used this technique before.. and it is known to work.. your technique might work for now, but possibly (probably?) wont work on a actual device.
perhaps you can provide more info about your environment, and/or share the image that is causing problems for you.
i would not recommend using your hack if you can avoid it.
-Tyndal

Have you tried saving the BMP images using a different tool?

Have you tried saving the BMP images using a different tool?

I agree that I'm probably doing something wrong, or the image is not formatted correctly... but for the life of me I can't figure out what the problem is.
I have tried saving the image in Paintshop Pro, it seems
here's the code snippet... with comments detailing the printouts
do{
i++; //i starts out at 0, pDataBytes is a byte *
pDataBytes = (byte*)app->alphabet + i;
app->app_graphics[GREEN_FONT_DS] = CONVERTBMP(pDataBytes , app->alphabetInfo, &app->alphabetRealloc);
if(app->app_graphics[GREEN_FONT_DS] != NULL){
DBGPRINTF("!!!!!Alphabet BITBLT CONVERSION SUCCESSFUL!!!!!!!");
SPRINTF(asciiString,"header was %d bytes, but claimed to be %d bytes. ",i, *((byte*) app->alphabet) /*this is the prescribed method of getting to the right spot in the image data*/ , app->alphabetRealloc);
DBGPRINTF(asciiString);
/*the printout here is...
!!!!!Alphabet BITBLT CONVERSION SUCCESSFUL!!!!!!!
header was 112 bytes, but claimed to be 152 bytes. realocBool = 0
*/
}
}while(app->app_graphics[GREEN_FONT_DS] == NULL);
I just tried resaving the image in Paintshop Pro... no difference.
I agree that it is very unsettling to build this into a working app... knowing that something is just not right... but I'm fresh out of ideas as to what I'm doing wrong here.

I agree that I'm probably doing something wrong, or the image is not formatted correctly... but for the life of me I can't figure out what the problem is.
I have tried saving the image in Paintshop Pro, it seems
here's the code snippet... with comments detailing the printouts
do{
i++; //i starts out at 0, pDataBytes is a byte *
pDataBytes = (byte*)app->alphabet + i;
app->app_graphics[GREEN_FONT_DS] = CONVERTBMP(pDataBytes , app->alphabetInfo, &app->alphabetRealloc);
if(app->app_graphics[GREEN_FONT_DS] != NULL){
DBGPRINTF("!!!!!Alphabet BITBLT CONVERSION SUCCESSFUL!!!!!!!");
SPRINTF(asciiString,"header was %d bytes, but claimed to be %d bytes. ",i, *((byte*) app->alphabet) /*this is the prescribed method of getting to the right spot in the image data*/ , app->alphabetRealloc);
DBGPRINTF(asciiString);
/*the printout here is...
!!!!!Alphabet BITBLT CONVERSION SUCCESSFUL!!!!!!!
header was 112 bytes, but claimed to be 152 bytes. realocBool = 0
*/
}
}while(app->app_graphics[GREEN_FONT_DS] == NULL);
I just tried resaving the image in Paintshop Pro... no difference.
I agree that it is very unsettling to build this into a working app... knowing that something is just not right... but I'm fresh out of ideas as to what I'm doing wrong here.

sorry... left out the part in the beginning where I load my image... just in case it's not clear what I'm doing above...
IImage * app->alphabet = ISHELL_LoadResImage(app->a.m_pIShell,"myResources.bar", GREEN_FONT_DS );

sorry... left out the part in the beginning where I load my image... just in case it's not clear what I'm doing above...
IImage * app->alphabet = ISHELL_LoadResImage(app->a.m_pIShell,"myResources.bar", GREEN_FONT_DS );

is it a bitmap image? are you using RLE? is it indexed or RGB?
info like this, or the actual image would be helpful...
i have one post here on using convertbmp code here:
http://brewforums.qualcomm.com/showthread.php?p=6326#post6326
and i know there are others if you search the forums..
(edit)
actually, here is an image that works for me.. try it and see if you have the same results:

is it a bitmap image? are you using RLE? is it indexed or RGB?
info like this, or the actual image would be helpful...
i have one post here on using convertbmp code here:
http://brewforums.qualcomm.com/showthread.php?p=6326#post6326
and i know there are others if you search the forums..
(edit)
actually, here is an image that works for me.. try it and see if you have the same results:

Dr.
As far as I can see from your code there are a number of mistakes you're making.
Your loading the image using LoadResImage() and yet you are trying to skip the MIME header. If I remember correctly - and it's been some time since I last touched any code using LoadResImage() - there is no MIME header after using LoadResImage(). I pointed that out in my previous posts twice already.
Secondly the way you are calcualting the dataPointer seems not only toally weird, from what I can see it's plain wrong. Your doing this...
i++; //i starts out at 0, pDataBytes is a byte *
pDataBytes = (byte*)app->alphabet + i;
You are not even reading out the length from the MIME data. You are adding an arbitrary offset "i" to the pointer. So, I'm not sure what exactly you are trying to do and your code looks a bit obscure. If that's what's happening, of course it won't work.
The easiest way to find out what's happening is if you could load the file and then post a quick memory hex dump of the first 64 bytes here - just copy it out of the debugger window. I can immediately tell you if there is a MIME header, what the length is, where your 112 bytes come from etc. But my assumption is that you're just not treating your data properly. I do nto think it is a file format problem at all.

Dr.
As far as I can see from your code there are a number of mistakes you're making.
Your loading the image using LoadResImage() and yet you are trying to skip the MIME header. If I remember correctly - and it's been some time since I last touched any code using LoadResImage() - there is no MIME header after using LoadResImage(). I pointed that out in my previous posts twice already.
Secondly the way you are calcualting the dataPointer seems not only toally weird, from what I can see it's plain wrong. Your doing this...
i++; //i starts out at 0, pDataBytes is a byte *
pDataBytes = (byte*)app->alphabet + i;
You are not even reading out the length from the MIME data. You are adding an arbitrary offset "i" to the pointer. So, I'm not sure what exactly you are trying to do and your code looks a bit obscure. If that's what's happening, of course it won't work.
The easiest way to find out what's happening is if you could load the file and then post a quick memory hex dump of the first 64 bytes here - just copy it out of the debugger window. I can immediately tell you if there is a MIME header, what the length is, where your 112 bytes come from etc. But my assumption is that you're just not treating your data properly. I do nto think it is a file format problem at all.

Dragon is right. LoadResImage() gives you an IImage interface. It does not give you the raw image data, which is what CONVERTBMP() requires. The BMP image viewer uses CONVERTBMP internally, which explains why you are finding the raw bitmap data in memory at all. Use LoadResData(), which simply returns a pointer to the raw resource data (which includes the MIME type header if the resource is RESTYPE_IMAGE).

Dragon is right. LoadResImage() gives you an IImage interface. It does not give you the raw image data, which is what CONVERTBMP() requires. The BMP image viewer uses CONVERTBMP internally, which explains why you are finding the raw bitmap data in memory at all. Use LoadResData(), which simply returns a pointer to the raw resource data (which includes the MIME type header if the resource is RESTYPE_IMAGE).

markb, you're saying "dragon is right", yet if you read carefully what he said, you will note that you contradict him! He says LoadResImage gives me a pointer to the image data WITHOUT a header, (which I understand to mean that I can just pass that pointer into CONVERTBMP() without modifying it and that should work... Dragon, correct me if I'm wrong). You're saying that there IS a header (and you're right... there is... dragon is remembering this method incorrectly.
Dragon, the reason I'm adding an arbitrary amount (i) is because when I use the prescribed way to get the info out of the first byte, it gives me a size that is incorrect. If you look at my loop, I'm incrementing i as I walk the whole piece of data and when I find the byte that actually starts the image data the return value from CONVERTBMP is no longer null, and I print out BOTH where the image was found in the byte count and where the prescribed method would have me look.
Note also that when it is found, it isn't at 0 (which is where it would be if LoadResImage gave me raw image data) but rather at 112.
I'll try to load the image that was posted above and see if that changes anything... thank you all again for looking at this.

markb, you're saying "dragon is right", yet if you read carefully what he said, you will note that you contradict him! He says LoadResImage gives me a pointer to the image data WITHOUT a header, (which I understand to mean that I can just pass that pointer into CONVERTBMP() without modifying it and that should work... Dragon, correct me if I'm wrong). You're saying that there IS a header (and you're right... there is... dragon is remembering this method incorrectly.
Dragon, the reason I'm adding an arbitrary amount (i) is because when I use the prescribed way to get the info out of the first byte, it gives me a size that is incorrect. If you look at my loop, I'm incrementing i as I walk the whole piece of data and when I find the byte that actually starts the image data the return value from CONVERTBMP is no longer null, and I print out BOTH where the image was found in the byte count and where the prescribed method would have me look.
Note also that when it is found, it isn't at 0 (which is where it would be if LoadResImage gave me raw image data) but rather at 112.
I'll try to load the image that was posted above and see if that changes anything... thank you all again for looking at this.

Not exactly...what Mark is saying is that the raw BMP data is stored within the IImage, but you shouldn't be calling CONVERTBMP on an IImage. This isn't a header per se, just the fact that the raw data is stored within the IImage. Use ISHELL_LoadResData() and the previously mentioned method for finding the raw image data from the MIME header...don't rock the boat. :p

Not exactly...what Mark is saying is that the raw BMP data is stored within the IImage, but you shouldn't be calling CONVERTBMP on an IImage. This isn't a header per se, just the fact that the raw data is stored within the IImage. Use ISHELL_LoadResData() and the previously mentioned method for finding the raw image data from the MIME header...don't rock the boat. :p

mohlendo wrote:what Mark is saying is that the raw BMP data is stored within the IImage
And that's not even always the case. The BMP viewer internally calls the equivalent of CONVERTBMP(). On 1.1 version of the simulator, CONVERTBMP() doesn't actually do any conversion, so the BMP viewer holds on to the raw Windows bitmap. This is not the case on 2.0 or later versions of the simulator, and it was never the case on real devices.

mohlendo wrote:what Mark is saying is that the raw BMP data is stored within the IImage
And that's not even always the case. The BMP viewer internally calls the equivalent of CONVERTBMP(). On 1.1 version of the simulator, CONVERTBMP() doesn't actually do any conversion, so the BMP viewer holds on to the raw Windows bitmap. This is not the case on 2.0 or later versions of the simulator, and it was never the case on real devices.

mohlendo!!! You're my hero!!! If ever anyone builds a large bronze statue in your honor, and later the american military machine overthrows your monarchy and helps the masses drag that statue down with the help of some rope and a tank, I WILL NOT BE PARTICIPATING!!!
So... LoadResData fixed the issue. The header size is reported correctly when I use that method.
However, can someone (you perhaps) please explain to me what LoadResImage is returning? Clearly there IS some info prior to the actual pixel data, but it's of a different size than what you get from LoadResImage... so what is it? I don't see any details on this in the documentation... I guess it's probably not releveant.
Anyway... thanks again, and I'm not rocking the boat!

mohlendo!!! You're my hero!!! If ever anyone builds a large bronze statue in your honor, and later the american military machine overthrows your monarchy and helps the masses drag that statue down with the help of some rope and a tank, I WILL NOT BE PARTICIPATING!!!
So... LoadResData fixed the issue. The header size is reported correctly when I use that method.
However, can someone (you perhaps) please explain to me what LoadResImage is returning? Clearly there IS some info prior to the actual pixel data, but it's of a different size than what you get from LoadResImage... so what is it? I don't see any details on this in the documentation... I guess it's probably not releveant.
Anyway... thanks again, and I'm not rocking the boat!

guys, my offer still stands. Instead of lamenting off here forever, post a hexdump of the first 64 bytes of your data and I'll take a look. If not, I'd recommend you forget what you think you know about the subject and re-read the Brew documentation on the subject of sprite graphics and maybe that time you will see where your error is. I posted the answer three times for you now and I'm not going to repeat myself yet again.

guys, my offer still stands. Instead of lamenting off here forever, post a hexdump of the first 64 bytes of your data and I'll take a look. If not, I'd recommend you forget what you think you know about the subject and re-read the Brew documentation on the subject of sprite graphics and maybe that time you will see where your error is. I posted the answer three times for you now and I'm not going to repeat myself yet again.

As Dragon and Mark pointed out, the call to ISHELL_LoadResImage() is returning an IImage pointer. The fact that the raw BMP image data is present at all is entirely a fluke specific to the 1.1 Emulator.
markb wrote:The BMP viewer internally calls the equivalent of CONVERTBMP(). On 1.1 version of the simulator, CONVERTBMP() doesn't actually do any conversion, so the BMP viewer holds on to the raw Windows bitmap. This is not the case on 2.0 or later versions of the simulator, and it was never the case on real devices.
For this reason, the fact that it was working at all was just a random stroke of luck, and you wouldn't see the same behavior on a device or other versions of the Emulator. The CONVERTBMP() method is expecting the raw image data -- the proper way to retrieve this is through the ISHELL_LoadResData() method, but this sticks a MIME header at the front. For this reason, you need to use the
imagePtr = (char *)dataPtr + *(char *)dataPtr, which gives the address of the actual location of the raw image data.

As Dragon and Mark pointed out, the call to ISHELL_LoadResImage() is returning an IImage pointer. The fact that the raw BMP image data is present at all is entirely a fluke specific to the 1.1 Emulator.
markb wrote:The BMP viewer internally calls the equivalent of CONVERTBMP(). On 1.1 version of the simulator, CONVERTBMP() doesn't actually do any conversion, so the BMP viewer holds on to the raw Windows bitmap. This is not the case on 2.0 or later versions of the simulator, and it was never the case on real devices.
For this reason, the fact that it was working at all was just a random stroke of luck, and you wouldn't see the same behavior on a device or other versions of the Emulator. The CONVERTBMP() method is expecting the raw image data -- the proper way to retrieve this is through the ISHELL_LoadResData() method, but this sticks a MIME header at the front. For this reason, you need to use the
imagePtr = (char *)dataPtr + *(char *)dataPtr, which gives the address of the actual location of the raw image data.

I understand completely. My mistake was in assuming that loadResData and loadResImage did the same thing (with one being slightly more general use than the other).
The last question I have here is regarding freeing the momory.
The documentation says that if the realloc boolean is true then I need to free the original IIMAGE interface pointer seperately from the CONVERTBMP resulting pointer... makes sense.
However, what if the boolean is false? Do I just have to do a SYSFREE on the resulting pointer from CONVERTBMP? or do I just do a IIMGAGE_Release? I don't think I can do both (in fact, the emulator crashes when I try, so it's pretty clear I can't).
The question is... which free method takes presendence (and should be used) in cases where memory was not reallocated... and does it make a difference?

I understand completely. My mistake was in assuming that loadResData and loadResImage did the same thing (with one being slightly more general use than the other).
The last question I have here is regarding freeing the momory.
The documentation says that if the realloc boolean is true then I need to free the original IIMAGE interface pointer seperately from the CONVERTBMP resulting pointer... makes sense.
However, what if the boolean is false? Do I just have to do a SYSFREE on the resulting pointer from CONVERTBMP? or do I just do a IIMGAGE_Release? I don't think I can do both (in fact, the emulator crashes when I try, so it's pretty clear I can't).
The question is... which free method takes presendence (and should be used) in cases where memory was not reallocated... and does it make a difference?

You shouldn't be calling IIMAGE_Release() on the converted bitmap, as it is not an IImage pointer. If there was no reallocation performed, you don't need to call SYSFREE() at all.

You shouldn't be calling IIMAGE_Release() on the converted bitmap, as it is not an IImage pointer. If there was no reallocation performed, you don't need to call SYSFREE() at all.

excellent... thanks!

excellent... thanks!