Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Discussion / @latch image rotation

Author
Message
pictionaryjr
11
Years of Service
User Offline
Joined: 12th Mar 2009
Location:
Posted: 28th Dec 2010 20:33
would you still happen to have that image rotation function you made a while back?

Libervurto
14
Years of Service
User Offline
Joined: 30th Jun 2006
Location: On Toast
Posted: 29th Dec 2010 13:46
I have it bookmarked
http://forum.thegamecreators.com/?m=forum_view&t=140077&b=6


Everything worthwhile requires effort.
pictionaryjr
11
Years of Service
User Offline
Joined: 12th Mar 2009
Location:
Posted: 29th Dec 2010 18:27
thank you obese. thats handy but oddly enough i don't think i'm going to use it now

pictionaryjr
11
Years of Service
User Offline
Joined: 12th Mar 2009
Location:
Posted: 2nd Jan 2011 07:24
Okay. I got the image to rotate correctly the first time, but for some reason the image ends up with holes in it and when i try to rotate it a second time, it won't work. Help please? :\

I'm tryin to prevent from having to use 3 different images and just one image because with the program i'm making. A lot of images may be used and i don't want that to slow the performance.

Here's what i've got so far:


Libervurto
14
Years of Service
User Offline
Joined: 30th Jun 2006
Location: On Toast
Posted: 2nd Jan 2011 19:08 Edited at: 2nd Jan 2011 19:11
I haven't tested it but it seems like you are losing data when you rotate the image. Perhaps you could try re-writing latch's function so that it makes a copy of the original image every time and rotates the copy instead of overwriting the original.

If you do this I would suggest making the image number to copy to a parameter, that way the programmer can specify the image number and you wont have to check for free image numbers or accidentally overwrite other images.


Everything worthwhile requires effort.
pictionaryjr
11
Years of Service
User Offline
Joined: 12th Mar 2009
Location:
Posted: 3rd Jan 2011 18:30
thing is i don't want to use a bunch of images. with the menu maker. after a while could slow down the processor. so i'm tryin to get it to turn the image and remember how much it turned and continue rotation off of that one image

Latch
14
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 4th Jan 2011 20:54
@pictionaryjr
I like your idea of resizing the image based on rotation so that black areas (matting) changes. Very nice!

I know your desire is to use a single image and just update that. Here's a couple of things just to keep in the back of your mind:

1. Cos and Sin are only accurate to a certain amount. If you rotate an image, and then use that rotated image to calculate another rotation, over multiple rotations, little errors will start to add up and creep in; your image can become distorted. This also happens because 2d locations are integer values. Cos and sin calculate floats. This also lends itself to small differences and inaccuracies over time. One of the main reasons I never alter the original image and use a second image as the final rotated image, is to avoid accumulated discrepancies.

2. If you delete an image that a sprite is using before deleting the sprite, you can run into some memory problems - even a system crash. So if you are deleting and recreating the same image, if a sprite is using it, you may want to also pass the sprite to your function so that it can be deleted, the image can then be deleted and recreated, then the sprite can be recreated.

Now about your code:



I don't really see a need for all those arrays. And since the maximum image number is 65535, you are wasting a lot of memory by dimensioning the arrays up to 99999. In my opinion, the only information you may want to store is the original images width and height, the cumulative angle of rotation, and maybe a flag that indicates the original image dimensions have changed:



I added the maximg variable just so that it was clear that the imageinfo() array is dimensioned to the maximum number of images that can be stored/used. You can change this based on the application. It may even be a variable that is passed to the function. That way, you could directly control your storage overhead depending on the actual needs of the program. I'm also assuming that you only want to use integer values for the angle - therefore imageinfo() stores only integers.

The values to be stored are:
imageinfo(id,0)=a flag indicating whether the width and height need to be added
imageinfo(id,1)=current angle + new angle
imageinfo(id,2)=unrotated image width
imageinfo(id,3)=unrotated image height

You use this information to calculate your corners. You keep track of the total rotation angle in imageinfo(id,1). However, the rotated image will be based on only the angle passed to the function because you will be rotating a rotated image. The flag prevents you from having to assign the width and height to the array again, but if you change the original image (not by rotation but by loading a new one or something) you can use the flag to reset the width and height to new values and the angle to 0.

Like Obese was saying, you are losing data in the rotation. It's not so much that you are losing data, I think that your positions in the memblocks are off. Once you get your corners and calculate the new memblock size to write your data too, you need to verify that the memblock is the right size. A test for your calculations would be to take a rectangular image, rotate it 45 degrees, calculate the new corners with the formulas in your function, and compare it to values you know. You can get the values that you know by rotating the image in a paint program and saving that as a separate image, loading that into a memblock, and comparing the size values (memblock size, image width and height)

Once you know your rotation formulas are matching or at least doing what you expect, you should address the position calculations so that you are sure you are grabbing and placing the correct pixels. X and Y values should be from 0 to width-1 or height-1. The positional data in the memblocks are actually pointers to memory locations (you knew that already). So it's important that the data gets written to the correct places. If data gets written beyond the bounds of the memblock, it can be written into other areas of the operating system that can cause a major crash.

The basic formula to use for memblock pixel positions is based on bitdepth bytes:

xwidth=memblock dword(mem,0)
yheight=memblock dword(mem,4)
dpbytes=memblock dword(mem,8)/8

pixelpos=12+((x+(y*width))*dpbytes)

The above formula will allow you to access pixel data at any screen bitdepth from a memblock.

Overal, I think your problem lies in your positional calculations for the pixels. Instead of using single colored images to test your rotation, it's better to use some kind of picture or something that can see where the pixels have been placed after rotation. I use the potted plant in my example because It has a definite orientation.

When I looked back at my own code, I could see that it lacks tons of optimizations. Rereading it, I can see it was made to "just work". All the bitmap creating and deleting, the multiple memblocks, multiple images (I could've used just 2 instead of 3 for my goals) are really overkill.

A simple optimization that should really boost your function's speed is to create sin and cos lookup arrays. Something like:



Now in all of your formulas, just use the arrays instead of the sin and cos functions.

Enjoy your day.
pictionaryjr
11
Years of Service
User Offline
Joined: 12th Mar 2009
Location:
Posted: 5th Jan 2011 04:42
Lol This is why i wish i had a friend who coded with me so we could double check eachothers flaws we see in it. otherwise it just takes time by yourself. I hate looking back and being like man what was i thinking lol. but anyways. I ended up just using your function. i got it to work in my program. although it limited the images used to half as much. i'm pretty sure no one will using 30000+ images for a menu lol. elsewise they might not have much room for the rest of the game lol.

The tip with using cos and sin arrays is a really handy tip tho that i'll be able to use elsewhere in all other projects from now on.

Thanks for all the time you took and explanation. it really helped clear up a lot of things i was doing wrong and understand why i was loosing image data. Btw you have very proper typing which you don't see too often.

Latch
14
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 5th Jan 2011 20:52
Quote: "but anyways. I ended up just using your function. i got it to work in my program. although it limited the images used to half as much. i'm pretty sure no one will using 30000+ images for a menu lol."


I'm gonna try and get your function to work the way you intended it. There shouldn't be much degradation with rotating a rotated image - maybe only a negligible amount. I like your idea of finding the corners for each rotation - that helps limit the image size.

Enjoy your day.
pictionaryjr
11
Years of Service
User Offline
Joined: 12th Mar 2009
Location:
Posted: 6th Jan 2011 00:28
haha yea i tried to be hard headed and figure it out on my own and make my own function, but i eventually caved.

Latch
14
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 7th Jan 2011 03:27 Edited at: 7th Jan 2011 03:29
Quote: "haha yea i tried to be hard headed and figure it out on my own and make my own function, but i eventually caved."


You almost had it! In fact, you should keep at it until it makes sense to you.

Well, I went ahead and rewrote it. I actually modeled it after your code, I changed the variable names so the code was easier for me to follow. I added a bunch of comments and a few more variables to pass to the function including handling existing sprites.

The function seems to work the way I think you wanted it to: with just a single image. I noted in the comments what I think could improve it. Take a look at it, play around with it; like I said, it's basically the same code you posted - just a little streamlined with a few things added and a few things removed. The tough part was figuring out how to write from 1 size of an image to a different sized image (after the rotation). I think I got it, but the way I did it may be contributing to small rotation errors over time - I think it's ok though.



Enjoy your day.
pictionaryjr
11
Years of Service
User Offline
Joined: 12th Mar 2009
Location:
Posted: 7th Jan 2011 04:54 Edited at: 7th Jan 2011 05:10
I'm not sure how you're calculating the predicted corners, but it seems like ur calculating sides of the image instead of the corners. I tried to go through and figure out where the problem is, but your code blows my mind . I'll post and image of what i mean.

EDIT:

Nevermind it suddenly stopped. not sure what was going on. and i see what you mean by loss of pixel data now

Login to post a reply

Server time is: 2020-08-12 01:32:49
Your offset time is: 2020-08-12 01:32:49