SDL_IntersectRect() behaviour

Hi,

it would be great, if someone could clarify the behaviour of
SDL_IntersectRect(), especially in the documentation of it.

If SDL_IntersectRect (A, B, result) returns SDL_FALSE, is the value of
result udefined?

Reason for this is the attached example, which produces the following
output for me (rev. 6303):

IntersectRect() with
A= { 0, 0, -200, 200 }
B= { -2, -2, -100, 200 }
Result= { 0, 0, 0, 0 } (makes sense, no intersection, result is emptied)

IntersectRect() with
A= { 0, 0, 10, 10 }
B= { -5, -5, 10, 2 }
Result= { 0, 0, 5, -3 } (makes sense or not, no intersection, but a result?)

IntersectRect() with
A= { 0, 0, 10, 10 }
B= { -5, -5, 2, 10 }
Result= { 0, 0, -3, 5 } (makes sense or not, no intersection, but a result?)

For me that’d mean that, if no intersection takes place, the contents of
the result argument are undefined. Is this correct and wanted that way?

Regards
Marcus
-------------- next part --------------
A non-text attachment was scrubbed…
Name: main.c
Type: text/x-csrc
Size: 844 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20120321/7fadc320/attachment.c
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20120321/7fadc320/attachment.pgp

Yes - that is correct. The result is only calculated/modified when there
is actually an intersection. I guess one could add code to fill the
result with (0,0,0,0) but that would not be very useful to the caller
and is therefore an overhead.

Also check out the test code for all the intersection functions here:
SDL/test/test-automation/tests/testrect/testrect.cOn 3/20/12 11:37 PM, Marcus von Appen wrote:

Hi,

it would be great, if someone could clarify the behaviour of
SDL_IntersectRect(), especially in the documentation of it.

If SDL_IntersectRect (A, B, result) returns SDL_FALSE, is the value of
result udefined?

Reason for this is the attached example, which produces the following
output for me (rev. 6303):

IntersectRect() with
A= { 0, 0, -200, 200 }
B= { -2, -2, -100, 200 }
Result= { 0, 0, 0, 0 } (makes sense, no intersection, result is emptied)

IntersectRect() with
A= { 0, 0, 10, 10 }
B= { -5, -5, 10, 2 }
Result= { 0, 0, 5, -3 } (makes sense or not, no intersection, but a result?)

IntersectRect() with
A= { 0, 0, 10, 10 }
B= { -5, -5, 2, 10 }
Result= { 0, 0, -3, 5 } (makes sense or not, no intersection, but a result?)

For me that’d mean that, if no intersection takes place, the contents of
the result argument are undefined. Is this correct and wanted that way?

Regards
Marcus


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On, Wed Mar 21, 2012, Andreas Schiffler wrote:

Yes - that is correct. The result is only calculated/modified when there
is actually an intersection. I guess one could add code to fill the
result with (0,0,0,0) but that would not be very useful to the caller
and is therefore an overhead.

Also check out the test code for all the intersection functions here:
SDL/test/test-automation/tests/testrect/testrect.c

It then must be outlined in the documentation that the result parameter
might be modified, even if there is no intersection, and that the values
written in result then are undefined.

Cheers
Marcus
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20120321/9657b685/attachment.pgp