| Summary: | SDL_RenderDrawLine end-point behavior broken on Linux | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Richard Russell <rtrussell> |
| Component: | render | Assignee: | Ryan C. Gordon <icculus> |
| Status: | RESOLVED DUPLICATE | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | CC: | sylvain.becker |
| Version: | 2.0.5 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Attachments: | Test case to demonstrate end-point behavior on Linux | ||
More end of line drawing issues with various drivers... duplicate because the test case draw lines of 1 pixel *** This bug has been marked as a duplicate of bug 3162 *** I am sorry, but declaring this bug to be a duplicate of #3162 because the Test Case only draws single pixels is ridiculous. The bug affects lines of arbitrary length, and it remains a serious problem for my application. Perhaps the Test Case was a poor choice - I wanted something that would be obvious - but the bug should be reopened (and fixed!) in my opinion. It doesn't mean it won't be fixed! I meant by marking it as a duplicated, that it would be fixed in bug 3162, by the patch I submitted. But more likely, it will be fixed if we switch to texture instead of points. It's helpful to consolidate bugs for tracking purposes. Don't worry, we are aware of the issue and will be addressing it. Thanks! *** This bug has been marked as a duplicate of bug 3162 *** This bug is specific to Linux/OpenGL and I have listed the code in sdl_render_gl.c which appears to be responsible (it deliberately draws the line differently when neither __MACOSX__ nor __WIN32__ is defined). Bug #3162 makes no reference to this code so I cannot see on what basis it has been concluded that it is the same problem. However Bug #3162 links to Bug #2796 (in the context of it being "another problem") which indeed appears to be a duplicate of this one; it explicitly refers to the same piece of code in the same module, and proposes the same solution. I didn't find it in a search because it talks about 'dropping pixels' but not that they are endpoint pixels. So please mark this as a duplicate of Bug #2796, not Bug #3162. I wonder why the trivial solution proposed in 2014 has not been adopted in any of the releases since. |
Created attachment 2702 [details] Test case to demonstrate end-point behavior on Linux SDL_RenderDrawLine is documented as drawing the line "to include both end points". Whilst this works correctly on Windows and Mac OS-X, it does not work on Linux (in all cases using the OPENGL renderer). In particular, specifying the same coordinates for both end-points results in nothing being drawn at all! This appears to be due to the following code in sdl_render_gl.c: #if defined(__MACOSX__) || defined(__WIN32__) /* Mac OS X and Windows seem to always leave the last point open */ data->glVertex2f(0.5f + points[count-1].x, 0.5f + points[count-1].y); #else /* Linux seems to leave the right-most or bottom-most point open */ x1 = points[0].x; y1 = points[0].y; x2 = points[count-1].x; y2 = points[count-1].y; if (x1 > x2) { data->glVertex2f(0.5f + x1, 0.5f + y1); } else if (x2 > x1) { data->glVertex2f(0.5f + x2, 0.5f + y2); } if (y1 > y2) { data->glVertex2f(0.5f + x1, 0.5f + y1); } else if (y2 > y1) { data->glVertex2f(0.5f + x2, 0.5f + y2); } #endif It seems to me unlikely that OPENGL works differently on Linux by design, so I am doubtful that this code is any longer required (if it ever was). I have attached a test case to demonstrate the issue. It should draw a white square on a blue background, but on Linux draws just the horizontal lines.