| Summary: | OpenGL SDL_RenderDrawLine (& Rects) some lines too short or long | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Anthony @ POW Games <ant> |
| Component: | video | Assignee: | Ryan C. Gordon <icculus> |
| Status: | RESOLVED DUPLICATE | QA Contact: | Sam Lantinga <slouken> |
| Severity: | critical | ||
| Priority: | P2 | CC: | icculus |
| Version: | HG 2.0 | Keywords: | target-2.0.12 |
| Hardware: | x86 | ||
| OS: | Windows 10 | ||
| Attachments: | Example of bug | ||
On closer inspection, it seems like some lines are being shifted a pixel forward? so the starting pixel is skipped and an extra pixel is drawn on the end. Hmm, I think we might have to pull the fix for Bug #3182, ship 2.0.12, and then revisit this. Clearly different renderer drivers have different ideas of what the line's range should be (for example, a line from 0,0 to 0,10: should it be 10 pixels long or 11?). The patch I made the other day made that test case match the software renderer, but it's not clear to me what corner cases there are and if other renderers match (or even if the software renderer is what we _should_ match), and a closer examination of all the renderer drivers is necessary for that. --ryan. It looks like the diamond exit rule isn't quite what we need... |
Created attachment 4207 [details] Example of bug Just tested the very latest mercurial; the recent changes to the OpenGL line drawing has regressed into an old bug where some lines are too short and some are too long, depending on the direction of the line. Direct3D & software lines are perfect, it only affects OpenGL. Hard to describe, so I've uploaded a PNG to demonstrate and compare between OpenGL & Direct3D. It even affects the lines of a SDL_RenderDrawRect call. Image is scaled up x3. I made a vector font renderer that draws letters using lines, which also demonstrates the added and missing pixels.