A way to rotate an image
A Logo programming environment for Microsoft Windows
Brought to you by:
david_costanzo
Hello,
My Suggest:
Add a new (GIF-) BITLOAD (maybe BITLOAD int, or BITLOADH) , which depends on the HEADING or on a given number. This is useful if you want to rotate a picture. This can be useful for an example games.
Jan
Can you describe a specific use case?
To me, GIFLOADH would be useful in games if, once loaded, the rotation never changed. And if that's the case, why just rotate the picture on disk? I think what you're really after is a sprite library, a way to map a picture to a turtle and that, once mapped, the picture turns and moves with the turtle.
Is that correct? Or do you really want to load images and not rotate them after they are loaded.
I thought about the first.
Check out the screenshot in the attachment.
The aim of the game is to get as quickly as possible over the bridges to the finish.
The player does not move forward, but the background does. The player can move only to the right and to the left. The whole game consists of a 100 by 100 pixel grid of bitmaps. And for that I had to create four images, because otherwise I can not rotate the player to the left or to the right. But that's largely irrelevant and unimportant, forget about that.
But maybe there is something useful, if you wish to rotate an image not only in 90-degree-steps, but in 1-degree-steps, for an example.
But the second point you've called, sounds very good and useful! That would be great if you could implement it, because then you can easily create a player for a game. For an example, in games like Asteroid Miner, imagine, the player would be a bitmapturtle. It would be super easy to rotate the player.
The ability to rotate a bitmap that's attached to a turtle already exists and supports transparency, so I think it should cover your use case (even if you never move the turtle). From the way you've described the game, the background images don't need to rotate, they need to translate, which you can do with BITLOAD.
When you run BITMAPTURTLE, pass an optional "true flag input to indicate that it should rotate.
You can use white as the transparent color so that you don't need different bitmaps for when the person is over grass or over a bridge. If you want to use a non-transparent white in your bitmap, use a very light grey.
Thank you! That's very great. But why isn't this listed in the index?
It would be better if you would add this to the index. ;-)
Jan
But it's very laggy. See the video in the attachment. What a bad update effect whilst rotating!
And also see this one..
Hmm, that's worse than I remember. And now you know why I didn't document it. I added this support for two reasons: one for game sprites and another to support a SETSHAPE feature request. The performance was fine, but the image looked terrible when rotated, so I added bilinear interpolation anti-aliasing. This made the picture look better, but made it too slow to use in realtime for medium-sized or large-sized sprites.
The code I added supports any zoom, any rotation, and source format, and any target format. I may be able to add special cases for 0,90,180,270 degree rotations and zoom=1, which would fix your game, but not the rotating gear.
There's already a bug on the flashing effect. I think I can fix this by doing the zoom and rotation in a back-buffer, then doing a transparency-aware blit to the screen. If I cache the rotated image, then FD and BK will be faster next time. This will require completely rewriting the feature.
Ideally, I would enlist some hardware support where available, but I cannot do this without dropping support for older operating systems, which I had planned on doing when I also dropped support for the OWL version--after the wxWidgets version could be a drop-in replacement for it.
I've added code to copy the image and sprites to a back buffer before blitting them to the screen. This removed the flicker as well as the need to do scaling within the bitmap pasting code.
I discovered that the Win32 GetPixel() function is MUCH too slow to use in real-time. The code now reads the bitmap pixels once and keeps it around for future use to avoid this cost. This resulted in a very large speedup that I hope will be sufficient for your game. If not, then I can still try special-casing 0/90/180/270 degree headings.
I've attached an untested pre-release version of the FMSLogo executable, which you can copy into the FMSLogo directory. This still has some off-by-one bugs in the rendering part and it clips the sprite at the screen boundry, but I don't think it's any worse than it was in 6.32.0.
Thanks a lot!
The rotation feature works fine (see video in the attachment)
But there is still the problem after changing the turtle (see video in the attachment). After changing the turtle, you can only see 25 % from the lower left corner of the bitmap.
It should look like it was when the turtle was active (=Complete Bitmap, aligned in the middle).
But thank you for sending me the pre-release version! It is very nice of you!
Have a nice day
Jan
I think I fixed that just before posting the attachment, but in my haste to get to sleep, I attached the wrong version. The bug was that the "rotating-ness" was defined by the current turtle, instead of the turtle being rendered. As a result setting a new turtle turned all of the "sprite" turtles back into regular bitmap turtle. This would have been more obvious if you minimized then restored the window (forcing a full repaint of the screen).
Try this one.
I have fixed a few more bugs with the rotating bitmap feature and added documentation. As of FMSLogo 6.33.0, this will be an officially supported feature.
I have also update Asteroid Miner to use this feature, which made the game playable on my 90 Mhz Pentium Windows 95 machine. This will be included in the next "extras" release, which will follow FMSlogo 6.33.0.
Attached is the final form of the rotating bitmap feature. I forget the exact state when I attached the previous version, but I think this has some performance fixes that sped it up and some functional fixes that slowed it down. I expect that this will still be fast enough for your purpose.