Rotation problem in Blt()

[efortier]

Drum roll please: I believe I have found a bug!

[snip snip]

Left side, correct rendering from my editor. Right side, image rendered in GapiDraw.

There is two wall graphics in this image. A corner which is rotate to create four, and a wall, which is also rotated.

I didn't believe it was a bug until I noticed the doubled line at the left of the red marker. Since this corner was blitted in a single shot, and a line in the middle of the graphic was doubled, I suppose it's a bug in GD 1.04. (zoom on it to see what I mean)

Also, all graphics are 32x32, yet once rotated most are drawn with one less line of pixels, as you can see in the image.

If it's a problem in GD, I suppose it's also related to the other AlphaBltFast() problem I mentionned earlier.

Here's the call I use for the rotation in this image:

if (Surface->Blt(&r,BS,&rt,BlitFlags_b,&eFX_b) != GD_OK) return false;

I verified all parameters before blitting, and they are valid. Simply removing "GDBLT_ROTATIONANGLE" from the flags gets rid of the problem...

So, is this a bug, do I win a prize?

--Eric

[ppcStudios]

[Johan]

[efortier]

[Blacky]

This is nice, I came here to say the same as efrontier. Good to know how to do.

And as eFrontier said, would be nice if there would be an internal 90° rotation in a future GD version.

Greets,
Michael Ritter

[efortier]

I easily implemented 90/180/270 degrees rotations, but having it separate from the actual blit force me to have extra stuff which reduce the overall speed.

As a note, on a screen filled with 32x32 tiles, where 80% of the tiles are rotated, the speed in release mode reaches 30 FPS without problems, even while the sound mixer is playing.

Square surface rotation such as these are simply a matter of copying pixels from one plate to another, so it's pretty fast and easy to do.

As a funny sidenote, when trying to optimize my rotate function, I ended up with code that was faster in debug mode than release mode... That, I had never done before!

--Eric

[ppcStudios]

Eric, is it possible for you to do your tile rotations at startup time to separate surfaces? This way you only rotate the images one time, then all BLTs will be the same speed.

Oh, and what sound mixer do you use, if I may ask?

-- GR

[efortier]

The way I am set-up is that I have several square tiles reused to display walls under different orientation. I don't use secondary surfaces for all the tiles since that would take as much memory as different source surfaces, which is exactly what I want to avoid.

What I do is I have a single free surface which I use as a buffer between the surface to be rotated and the back buffer. I take the source data to be rotated, translate its position, and place the pixels in the buffer. I then blit from this buffer.

My rotation code is pretty well optimized, and is faster than pre-calculated pitch look-up tables.

As for the mixer, I use my own. My mixer is very powerful and I'm very proud of it. Vorbis, adpcm, pcm, mods, C-64 playback, multithreaded, stream play, sound injection for ultra fast sfx, very low latency, highly optimized mix loop, etc, etc. It has only been tested on iPaq 3850 and Toshiba e330.

I was about to publicly release it, but I have no time to prepare docs, samples, web pages, etc, for now.

Anyone interested?

--Eric

[ppcStudios]