Want to help with SDL 1.3?

A number of people have asked what they can do to help with SDL 1.3.

You can always look at the TODO file and see if there’s anything there
you’d like to work on, and contact me at @slouken to coordinate
working on it.

For example, here’s a good quick project for someone from the TODO list:

  • Add diagonal line clipping to SDL_IntersectRectAndLine()

A big need that we have is good documentation and examples using the new
style API. You can take a look at the test code in testsprite2.c and
testdraw2.c if you’d like to see some of the new features. It would be
really helpful to have a full set of unit tests to cover all the new API
functions, blit combinations, blend mode combinations, etc.

Thanks!
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

On it.

There are just two things I think need clearing up, though.

  1. Does the line segment (*X1,*Y1)(*X2,*Y2) have direction? If it does
    not, that would mean SDL_IntersectRectAndLine() can swap those two
    points.

  2. Should this function return integer values? As I just noted in the
    source code…

/* The task of clipping a line with finite dx/dy ratios in a fixed-

  • precision coordinate space is not as immediately simple as it is
  • with coordinates of arbitrary precision. If the ratio of ratios
  • (dx1/dy1) / (dx2/dy2) is not integral, you must in fact move the
  • line a bit in order to clip it.
    */On Thu, Jan 1, 2009 at 2:08 PM, Sam Lantinga wrote:

For example, here’s a good quick project for someone from the TODO list:

  • Add diagonal line clipping to SDL_IntersectRectAndLine()


http://codebad.com/

I should have rephrased that. dx1/dy1 is supposed to be the slope of
the line passed into the function, dx2/dy2 is the slope of the output
line (after it’s been intersected with the rect.) The slopes can’t
always match is all I’m saying, and that will make a viewable
difference to many line drawing algorithms.On Thu, Jan 1, 2009 at 7:04 PM, Donny Viszneki <@Donny_Viszneki> wrote:

/* The task of clipping a line with finite dx/dy ratios in a fixed-

  • precision coordinate space is not as immediately simple as it is
  • with coordinates of arbitrary precision. If the ratio of ratios
  • (dx1/dy1) / (dx2/dy2) is not integral, you must in fact move the
  • line a bit in order to clip it.
    */


http://codebad.com/

For example, here’s a good quick project for someone from the TODO list:

  • Add diagonal line clipping to SDL_IntersectRectAndLine()

On it.

Great!

There are just two things I think need clearing up, though.

  1. Does the line segment (*X1,*Y1)(*X2,*Y2) have direction? If it does
    not, that would mean SDL_IntersectRectAndLine() can swap those two
    points.

No, it does not.

  1. Should this function return integer values? As I just noted in the
    source code…

/* The task of clipping a line with finite dx/dy ratios in a fixed-

  • precision coordinate space is not as immediately simple as it is
  • with coordinates of arbitrary precision. If the ratio of ratios
  • (dx1/dy1) / (dx2/dy2) is not integral, you must in fact move the
  • line a bit in order to clip it.
    */

Yes, it should return integer values. Ugh. Just round to the nearest
pixel for now. We don’t currently support sub-pixel precision.

Thanks!
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC> On Thu, Jan 1, 2009 at 2:08 PM, Sam Lantinga wrote:

JEEZ, Sam, what the heck’ve you been doing all this time, then? :wink:

Plus, I want CMYK support. Oh wait, I’m thinking of GIMP now.On Fri, Jan 02, 2009 at 02:36:39AM -0800, Sam Lantinga wrote:

Yes, it should return integer values. Ugh. Just round to the nearest
pixel for now. We don’t currently support sub-pixel precision.


-bill!
“Tux Paint” - free children’s drawing software for Windows / Mac OS X / Linux!
Download it today! http://www.tuxpaint.org/

Donny Viszneki <donny.viszneki gmail.com> writes:

For example, here’s a good quick project for someone from the TODO list:

  • Add diagonal line clipping to SDL_IntersectRectAndLine()

On it.

There are just two things I think need clearing up, though.

  1. Does the line segment (*X1,*Y1)(*X2,*Y2) have direction? If it does
    not, that would mean SDL_IntersectRectAndLine() can swap those two
    points.

  2. Should this function return integer values? As I just noted in the
    source code…

/* The task of clipping a line with finite dx/dy ratios in a fixed-

  • precision coordinate space is not as immediately simple as it is
  • with coordinates of arbitrary precision. If the ratio of ratios
  • (dx1/dy1) / (dx2/dy2) is not integral, you must in fact move the
  • line a bit in order to clip it.
    */

Donny,

If one is concerned about the clipped line segment matching exactly the
unclipped line segment, one cannot simply reduce the clipped line segment to a
pair of coordinates.

To retain consistency with the original line, you must also retain the
Bresenham parameters (slope ratio and the current error value) at the start
pixel. With these values in hand, your clipped segment will exactly match the
unclipped segment.

This was one of the first graphics related code bits I worked on about 15 years
ago. The need was a software algo that would match the hardware accelerator
algo in use (this was for a “generic” windows display driver). My code could be
easily configured to match whatever rounding or directional rules the hardware
used. It was a fun bit of coding. Obviously overkill for this project, unless
you need that same sort of functionality.

I haven’t looked at the 1.3 stuff, so I don’t know if it allows more than just
the endpoints to be specified. If it doesn’t then this whole post is pointless.
:slight_smile:

If there is a need, I can see if I have this in my archives somewhere. It is
encumbered though (the project is long dead and probably written off by it’s
current owner Labtec) so if I do it’s just for examples sake - you can’t use
it.

MrPeach> On Thu, Jan 1, 2009 at 2:08 PM, Sam Lantinga <slouken devolution.com> wrote:

Just wanted to point out that the patch is available at
http://codebad.com/rect-line-ix.patch

I hereby grant Sam Lantinga an irrevocable non-exclusive distribution
license to this patch to do with as he wishes.On Fri, Jan 2, 2009 at 5:36 AM, Sam Lantinga wrote:

On Thu, Jan 1, 2009 at 2:08 PM, Sam Lantinga wrote:

For example, here’s a good quick project for someone from the TODO list:

  • Add diagonal line clipping to SDL_IntersectRectAndLine()
    On it.
    Great!


http://codebad.com/

Just wanted to point out that the patch is available at
http://codebad.com/rect-line-ix.patch

I hereby grant Sam Lantinga an irrevocable non-exclusive distribution
license to this patch to do with as he wishes.

Thanks! This is in subversion.

It’s hard for me to tell, but it looks like lines intersecting the upper
corners of the rect are being completely clipped out. Can you take a quick
look?

Thanks!
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

Thanks for noticing this too, MrPeach, but I brought this up before
writing the patch. Sam made the decision to go with imprecise clipping
for the time being.On Fri, Jan 2, 2009 at 1:18 PM, MrPeach wrote:

If one is concerned about the clipped line segment matching exactly the
unclipped line segment, one cannot simply reduce the clipped line segment to a
pair of coordinates.


http://codebad.com/

I believe the patch below fixes the issue, but when I built with
–disable-video-x11-xinput my mouse seemed to stop working, so I
didn’t test as thoroughly as I might like to. Any advice about what to
do for that? Should I install some other Xorg header package?

Index: src/video/SDL_rect.cOn Sun, Jan 4, 2009 at 2:36 PM, Sam Lantinga wrote:

It’s hard for me to tell, but it looks like lines intersecting the upper
corners of the rect are being completely clipped out. Can you take a quick
look?

===================================================================
— src/video/SDL_rect.c (revision 4356)
+++ src/video/SDL_rect.c (working copy)
@@ -150,7 +150,7 @@

 /* Check to see if entire line is to one side of rect */
 if ((x1 < rectx1 && x2 < rectx1) || (x1 > rectx2 && x2 > rectx2) ||
  •    (y1 < recty1 && y2 < recty2) || (y1 > recty2 && y2 > recty2)) {
    
  •    (y1 < recty1 && y2 < recty1) || (y1 > recty2 && y2 > recty2)) {
       return SDL_FALSE;
    
    }

I hereby grant Sam Lantinga an irrevocable non-exclusive distribution
license to this patch to do with as he wishes.


http://codebad.com/

I believe the patch below fixes the issue, but when I built with
–disable-video-x11-xinput my mouse seemed to stop working

This is fixed in subversion, thanks!

Index: src/video/SDL_rect.c

— src/video/SDL_rect.c (revision 4356)
+++ src/video/SDL_rect.c (working copy)
@@ -150,7 +150,7 @@

 /* Check to see if entire line is to one side of rect */
 if ((x1 < rectx1 && x2 < rectx1) || (x1 > rectx2 && x2 > rectx2) ||
  •    (y1 < recty1 && y2 < recty2) || (y1 > recty2 && y2 > recty2)) {
    
  •    (y1 < recty1 && y2 < recty1) || (y1 > recty2 && y2 > recty2)) {
       return SDL_FALSE;
    
    }

Thanks, this fixes it.

There are some conditions where the test program stops drawing lines,
but the intersection of the top corners looks good.

Thanks!
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

I just chose an arbitrary number for the max number of lines and
rects. I wasn’t even sure you’d feel like including the test program
anyway! (Though it may be useful if anyone wants to write some SIMD
routines to speed things up.) Once you hit 16, you have to erase them
all before adding any more :6On Mon, Jan 5, 2009 at 2:09 AM, Sam Lantinga wrote:

There are some conditions where the test program stops drawing lines,
but the intersection of the top corners looks good.


http://codebad.com/