Small bug in clipping rect behaviour

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello everyone!

First of all, I’d like to thank every person in the SDL staff, for such a
great piece of work. SDL is incredibly simple and straightforward to use in
comparison to other APIs. Yes, it’s pretty low-level, but that gives more
room to learning :).

BTW, I have been checking this list for a few months, but I didn’t have
anything to say, until now, you see.

Anyway, I’ve noticed that clip rects don’t work like they should when you blit
something which is to the left or above the clipping rect. Instead of
clipping (which is what it should do), it moves the destination rect towards
the left/top edges, respectively.

I have attached a tarball with a small SDL program which shows the bug, a
makefile and a small BMP for it. Ah, I’m using 1.2.3 to compile it. Has this
bug been fixed yet in SDL1.2.4 or the CVS version? I’m using SDL1.2.4 in
win32 and SDL1.2.3 (because that’s what Mandrake 8.2 brings. I’m too lazy

  • -.-) in linux.

Thanks in advance!


Firma GPG: BB92 C1C2 D709 AC41 CBF1 DB79 784D 7A4E DF10 C2D5
Antonio Garcia
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD4DBQE9b7vneE16Tt8QwtURAlmSAKCH3pyyRTUdADm+DJIiHVRBRx6u+ACYtZss
7WH92i0/8FOPnrpHf1bVnw==
=iurV
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed…
Name: cliptest.tar.gz
Type: application/x-tgz
Size: 841 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020830/e7a0950e/attachment.bin

Anyway, I’ve noticed that clip rects don’t work like they should when you blit
something which is to the left or above the clipping rect. Instead of
clipping (which is what it should do), it moves the destination rect towards
the left/top edges, respectively.

Oh, this isn’t actually a bug. The destination rectangle is clipped, and
the final clipped rectangle is stored in the rect you pass in, so that you
can pass the resulting rectangle directly to SDL_UpdateRect(). This means
that you need to initialize the destination rectangle each time you pass it
to SDL_BlitSurface().

Here is the relevant fix for your code:
while (loop)
{
SDL_Rect destRect;
SDL_FillRect(s,NULL,SDL_MapRGB(s->format,0,0,0));
SDL_FillRect(s,&clipRect,SDL_MapRGB(s->format,255,255,255));
destRect = destRect1;
SDL_BlitSurface(pic, NULL, s, &destRect);
destRect = destRect2;
SDL_BlitSurface(pic, NULL, s, &destRect);

	...
}

Note that the width and height of the destination rectangle is ignored
as inputs, and set to the actual blit width and height as outputs.

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

Sam Lantinga wrote:

Oh, this isn’t actually a bug. The destination rectangle is
clipped, and
the final clipped rectangle is stored in the rect you pass in, so
that you
can pass the resulting rectangle directly to SDL_UpdateRect().
This means
that you need to initialize the destination rectangle each time
you pass it
to SDL_BlitSurface().

Ah! Yes, I already thought of that, and that fix worked, but I thought
that this was a bug, lol. Silly me.

Anyway, thanks Sam! Keep it up!–
Antonio Garcia