Rotating an image in BREW? | developer.brewmp.com Rotating an image in BREW? | developer.brewmp.com

Developer

Rotating an image in BREW?

Forums:

If you have a bmp image stored in a resource file, say, and you load it in, is there a way to draw it to the screen rotated by some number of degrees (at 90 degrees, flipped upside down, etc)?

I know that a lot of people do games in BREW, and flipping an image seems like an obvious thing to want to do. Still, I don't see anything that seems appropriate in either IIMAGE or IGRAPHICS. Help?

Thanks!

I don´t think rotation is possible, you could use different frames of the same image with the rotation you´ll use..

I don´t think rotation is possible, you could use different frames of the same image with the rotation you´ll use..

Right, I know I could just rotate each image and store them separately, but I was hoping to save space in my resource file by being able to rotate them on the fly. Thanks, though.
If there's no function that does it for you, is there a way to do it yourself, maybe after you've done a CONVERTBMP and you've just got the raw data? I'm out of my league here - has anyone tried anything like this?

Right, I know I could just rotate each image and store them separately, but I was hoping to save space in my resource file by being able to rotate them on the fly. Thanks, though.
If there's no function that does it for you, is there a way to do it yourself, maybe after you've done a CONVERTBMP and you've just got the raw data? I'm out of my league here - has anyone tried anything like this?

working with raw data after you did a CONVERTBMP() would require to write a different code for each device, so if you´re thinking in working with the data yourself I guess you should stick to the bmp format, change it and then CONVERTBMP()
I took I look at the api, and I don´t think that there´s anything to help you to do this..

working with raw data after you did a CONVERTBMP() would require to write a different code for each device, so if you´re thinking in working with the data yourself I guess you should stick to the bmp format, change it and then CONVERTBMP()
I took I look at the api, and I don´t think that there´s anything to help you to do this..

I just asked my Co-worker who took some DSP courses. A raw 24 bit bitmap is just RGB values in an array. [[r,g,b],[r,g,b],[...]...]. So to rotate a square bitmap you just have to do some fancy moving of the values to different parts in the array. If its a rectangle you have to change the Width with the Hieght in the header as well.
it shouldn't be too hard to do yourself. Search online im sure you could find some sample code.
theres a link he gave me....
http://www.fortunecity.com/skyscraper/windows/364/bmpffrmt.html

I just asked my Co-worker who took some DSP courses. A raw 24 bit bitmap is just RGB values in an array. [[r,g,b],[r,g,b],[...]...]. So to rotate a square bitmap you just have to do some fancy moving of the values to different parts in the array. If its a rectangle you have to change the Width with the Hieght in the header as well.
it shouldn't be too hard to do yourself. Search online im sure you could find some sample code.
theres a link he gave me....
http://www.fortunecity.com/skyscraper/windows/364/bmpffrmt.html

If you want to rotate a bitmap you'll have to do it yourself. There are a good number of routines avilable on the Internet that use fixed point math to do this and that are reasonably fast. These are for rotations at any angle.
If you want to rotate and flip them in 90 degree steps, that's just some trivial data shuffling on your bitmap data, swapping data from left to right or from top to botoom.

If you want to rotate a bitmap you'll have to do it yourself. There are a good number of routines avilable on the Internet that use fixed point math to do this and that are reasonably fast. These are for rotations at any angle.
If you want to rotate and flip them in 90 degree steps, that's just some trivial data shuffling on your bitmap data, swapping data from left to right or from top to botoom.

Thanks. Would a rotation technique that worked on a bmp work, say, for a png? I'm under the impression that it would not.
Rotating a bmp would be a good start, but I was sort of hoping for a general-purpose image rotation - but I guess that's really not going to happen.
Does the bmp rotation algorithm depend on the bit depth of the bmp? I.e., would the same code work for a 4-bit image as for an 8-bit image?

Thanks. Would a rotation technique that worked on a bmp work, say, for a png? I'm under the impression that it would not.
Rotating a bmp would be a good start, but I was sort of hoping for a general-purpose image rotation - but I guess that's really not going to happen.
Does the bmp rotation algorithm depend on the bit depth of the bmp? I.e., would the same code work for a 4-bit image as for an 8-bit image?

Well, you should make a big difference between an algorithm and the way a data is stored for rendering purposes.. Why should an algo be different for a bmp, a jpg, or a png?? Of course there will be some differences in the implementation, but not in the algo..
Rotating is quiet easy, let say you want rotate a width x height picture by alpha radians.. The easiest way, to start, is to assume that the result will be of the size width x height (which is false, but it's ok for an example).
the algo would look like this (pseudo example)
ca = cos(-alpha);
sa = sin(-alpha);
for( y = 0; y < height; ++y )
for( x = 0; x < width; ++x)
{
realX = x - rotCenterX;
realY = y - rotCenterY;
orgX = (realX * ca - realY * sa); //+ rotCenterX;
orgY = (realY * ca + realX * sa); //+ rotCenterY;
if( orgX >= 0 && orgX < width && orgY >=0 && orgY < height)
destination[x][y] = source[orgX][orgY]; // THIS IS NOT THE SAME FOR 4/8 BITS
else
destination[x][y] = black;// THIS IS NOT THE SAME FOR 4/8 BITS

createBmp/PNG(destination); // THIS IS NOT THE SAME FOR 4/8 BITS
Hope that would help to clarify, and note that they might be alot of different way of achieving this..
/kUfa

Well, you should make a big difference between an algorithm and the way a data is stored for rendering purposes.. Why should an algo be different for a bmp, a jpg, or a png?? Of course there will be some differences in the implementation, but not in the algo..
Rotating is quiet easy, let say you want rotate a width x height picture by alpha radians.. The easiest way, to start, is to assume that the result will be of the size width x height (which is false, but it's ok for an example).
the algo would look like this (pseudo example)
ca = cos(-alpha);
sa = sin(-alpha);
for( y = 0; y < height; ++y )
for( x = 0; x < width; ++x)
{
realX = x - rotCenterX;
realY = y - rotCenterY;
orgX = (realX * ca - realY * sa); //+ rotCenterX;
orgY = (realY * ca + realX * sa); //+ rotCenterY;
if( orgX >= 0 && orgX < width && orgY >=0 && orgY < height)
destination[x][y] = source[orgX][orgY]; // THIS IS NOT THE SAME FOR 4/8 BITS
else
destination[x][y] = black;// THIS IS NOT THE SAME FOR 4/8 BITS

createBmp/PNG(destination); // THIS IS NOT THE SAME FOR 4/8 BITS
Hope that would help to clarify, and note that they might be alot of different way of achieving this..
/kUfa

Jken,
In general, JPG, PNG, BMP or whatnot are only file formats that specify the dimensions and technical aspects of an image. Ultimately each of these formats will have to create a memory representation of the image data in in most cases you will end up have an array of data that ends up looking the same way - that is for most standard image formats.
With that in mind, once you have a rotating algorithm - or nay other image manipulation algorithm - you apply it to that array of data, regardless of the format is was originally stored in. However, you will always be familiar with the implementation details of that format and the array, so reading up on all these things is essential before doing anything in the graphical realms.
The algorithm will remain the same, but depending on the color depth and other factors, the actual implementation of the algorithm has to change to accommodate these technical details.

Jken,
In general, JPG, PNG, BMP or whatnot are only file formats that specify the dimensions and technical aspects of an image. Ultimately each of these formats will have to create a memory representation of the image data in in most cases you will end up have an array of data that ends up looking the same way - that is for most standard image formats.
With that in mind, once you have a rotating algorithm - or nay other image manipulation algorithm - you apply it to that array of data, regardless of the format is was originally stored in. However, you will always be familiar with the implementation details of that format and the array, so reading up on all these things is essential before doing anything in the graphical realms.
The algorithm will remain the same, but depending on the color depth and other factors, the actual implementation of the algorithm has to change to accommodate these technical details.

I was able to rotate a 4-bit bitmap image correctly. Phew! I used the URL jOrd posted, it was really helpful.
I would like to find out more about the PNG format so I can successfully manipulate PNG images, also. I'm sure there's stuff online, but if anyone knows of a good source for the PNG format, I'd love to hear about it!
Thanks for all the advice and pointers!

I was able to rotate a 4-bit bitmap image correctly. Phew! I used the URL jOrd posted, it was really helpful.
I would like to find out more about the PNG format so I can successfully manipulate PNG images, also. I'm sure there's stuff online, but if anyone knows of a good source for the PNG format, I'd love to hear about it!
Thanks for all the advice and pointers!

I recommend wotsit.org as a good source for file formats information.

I recommend wotsit.org as a good source for file formats information.

looks like a cool site, thx for heads up.

looks like a cool site, thx for heads up.

Please could any one suggest a good website for fixed point bitmap rotation? :confused:

Please could any one suggest a good website for fixed point bitmap rotation? :confused:

I'm not aware of such site, though I think you can find plenty of them using google. Or at least, you can find them as two separate items - fixed-point math and bitmap rotation routines. However, I'd like to ask you why do you need to have arbitrary rotation of bitmap on handset? Since arbitrary rotation without good anti-aliasing algorithm (as post-process) will give you terrible results. So, if you're trying to, say, compute some additional phases for you sprite on the fly, then probably results will be just horrible. And anti-aliasing by itself is significant problem especially for palette-based bitmaps.

I'm not aware of such site, though I think you can find plenty of them using google. Or at least, you can find them as two separate items - fixed-point math and bitmap rotation routines. However, I'd like to ask you why do you need to have arbitrary rotation of bitmap on handset? Since arbitrary rotation without good anti-aliasing algorithm (as post-process) will give you terrible results. So, if you're trying to, say, compute some additional phases for you sprite on the fly, then probably results will be just horrible. And anti-aliasing by itself is significant problem especially for palette-based bitmaps.

why?
simple answer, size limitations on handsets, games have used 1,4,8 rotations with flips and then arbritrary rotates to generate all the stages of animation you'd need, with no post process for as long as games have been around. some games have a staggering amount of sprites, which would be insane to store each rotation.
kufa's code is pretty simple to convert to a fixed point rotation, you can just use sin/cos lookup tables too, then just change the very simple math to fixed point, if you don't know how fixed point works, you might find it easier to research that first, its really quite simple and i find its easier to work with fixed point that floating point sometimes, try decoding a floating point value in hex in a debugger with no float support, for instance ;)
robert/bob pendleton had a little doc on fixed point i seem to recall, though it used assembler for the intermediates, as most people do for 16.16, at least unless you have native qword(64) for fixed point in dword(32) in C (which is usually either long long or __int64, these will pull in the 64 bit math routines of the compiler though. of course you can always use a 16bit fp type.

why?
simple answer, size limitations on handsets, games have used 1,4,8 rotations with flips and then arbritrary rotates to generate all the stages of animation you'd need, with no post process for as long as games have been around. some games have a staggering amount of sprites, which would be insane to store each rotation.
kufa's code is pretty simple to convert to a fixed point rotation, you can just use sin/cos lookup tables too, then just change the very simple math to fixed point, if you don't know how fixed point works, you might find it easier to research that first, its really quite simple and i find its easier to work with fixed point that floating point sometimes, try decoding a floating point value in hex in a debugger with no float support, for instance ;)
robert/bob pendleton had a little doc on fixed point i seem to recall, though it used assembler for the intermediates, as most people do for 16.16, at least unless you have native qword(64) for fixed point in dword(32) in C (which is usually either long long or __int64, these will pull in the 64 bit math routines of the compiler though. of course you can always use a 16bit fp type.