[rshapes] `DrawRectangleLines()` missing pixel in lower right corner

[Roucou]

• I tested it on latest raylib version from master branch
• I checked there is no similar issue already reported
• I checked the documentation on the wiki
• My code has no errors or misuse of raylib

Issue description

If you draw a rectangle outline using DrawRectangleLines(0, 0, w, h, WHITE) the lower right corner is missing.

Environment

N/A

Issue Screenshot

/

Code Example

#include "raylib.h"
int main(void) {
    InitWindow(150, 150, "DrawRectangleLines bug");
    while (!WindowShouldClose()) {
        BeginDrawing();
            ClearBackground(BLACK);
            DrawRectangleLines(0, 0, 100, 100, WHITE); // FIXME: MISSING LOWER RIGHT CORNER
        EndDrawing();
    }
   CloseWindow();        // Close window and OpenGL context
   return 0;
}

[raysan5]

@Roucou I'm afraid Environment and Screenshot data are required to track this issue

[Roucou]

Running on Linux desktop:

INFO: Initializing raylib 5.6-dev
INFO: Platform backend: DESKTOP (GLFW)
INFO: Supported raylib modules:
INFO: > rcore:..... loaded (mandatory)
INFO: > rlgl:...... loaded (mandatory)
INFO: > rshapes:... loaded (optional)
INFO: > rtextures:. loaded (optional)
INFO: > rtext:..... loaded (optional)
INFO: > rmodels:... loaded (optional)
INFO: > raudio:.... loaded (optional)
INFO: DISPLAY: Device initialized successfully
INFO: > Display size: 1920 x 1200
INFO: > Screen size: 1000 x 800
INFO: > Render size: 1000 x 800
INFO: > Viewport offsets: 0, 0
INFO: GLAD: OpenGL extensions loaded successfully
INFO: GL: Supported extensions count: 232
INFO: GL: OpenGL device information:
INFO: > Vendor: Intel
INFO: > Renderer: Mesa Intel(R) Graphics (ADL GT2)
INFO: > Version: 4.6 (Core Profile) Mesa 24.2.8-1ubuntu1~24.04.1
INFO: > GLSL: 4.60
INFO: GL: VAO extension detected, VAO functions loaded successfully
INFO: GL: NPOT textures extension detected, full NPOT textures supported
INFO: GL: DXT compressed textures supported
INFO: GL: ETC2/EAC compressed textures supported
INFO: PLATFORM: DESKTOP (GLFW - X11): Initialized successfully

Screenshot:

[raysan5]

@Roucou The line with the missing pixel in the screenshot does not seem to be a 1px border line drawn using DrawRectangleLines(), are you scaling it? Are you using some other function?

[Roucou]

Here's a screenshot of the exact above code example. The DrawRectangleLines(0, 0, 100, 100, WHITE) call draws a 1-pixel wide border, starting at 0, 0, and exactly 100 pixels wide x 100 pixels high. Except for the lower right pixel that's missing.

[sleeptightAnsiC]

Cursed...

[sleeptightAnsiC]

I don't see this problem on my end. This might be an issue with underlying OpenGL implementation. Here's how it looks like on my side (Arch Linux x86_64 with Xorg and proprietary Nvidia drivers):

Screenshots

Notice that in my case I'm using proprietary Nvidia drivers while OP is using Mesa Intel drivers which might be the reason why it looks different:

Logs

INFO: Initializing raylib 5.6-dev
INFO: Platform backend: DESKTOP (GLFW)
INFO: Supported raylib modules:
INFO:     > rcore:..... loaded (mandatory)
INFO:     > rlgl:...... loaded (mandatory)
INFO:     > rshapes:... loaded (optional)
INFO:     > rtextures:. loaded (optional)
INFO:     > rtext:..... loaded (optional)
INFO:     > rmodels:... loaded (optional)
INFO:     > raudio:.... loaded (optional)
INFO: DISPLAY: Device initialized successfully
INFO:     > Display size: 2560 x 1440
INFO:     > Screen size:  150 x 150
INFO:     > Render size:  150 x 150
INFO:     > Viewport offsets: 0, 0
INFO: GLAD: OpenGL extensions loaded successfully
INFO: GL: Supported extensions count: 390
INFO: GL: OpenGL device information:
INFO:     > Vendor:   NVIDIA Corporation
INFO:     > Renderer: NVIDIA GeForce GTX 1070 Ti/PCIe/SSE2
INFO:     > Version:  3.3.0 NVIDIA 570.86.16
INFO:     > GLSL:     3.30 NVIDIA via Cg compiler
INFO: GL: VAO extension detected, VAO functions loaded successfully
INFO: GL: NPOT textures extension detected, full NPOT textures supported
INFO: GL: DXT compressed textures supported
INFO: GL: ETC2/EAC compressed textures supported
INFO: PLATFORM: DESKTOP (GLFW - X11): Initialized successfully
INFO: TEXTURE: [ID 1] Texture loaded successfully (1x1 | R8G8B8A8 | 1 mipmaps)
INFO: TEXTURE: [ID 1] Default texture loaded successfully
INFO: SHADER: [ID 1] Vertex shader compiled successfully
INFO: SHADER: [ID 2] Fragment shader compiled successfully
INFO: SHADER: [ID 3] Program shader loaded successfully
INFO: SHADER: [ID 3] Default shader loaded successfully
INFO: RLGL: Render batch vertex buffers loaded successfully in RAM (CPU)
INFO: RLGL: Render batch vertex buffers loaded successfully in VRAM (GPU)
INFO: RLGL: Default OpenGL state initialized successfully
INFO: TEXTURE: [ID 2] Texture loaded successfully (128x128 | GRAY_ALPHA | 1 mipmaps)
INFO: FONT: Default font loaded successfully (224 glyphs)
INFO: SYSTEM: Working Directory: /home/korn/rlspr

[sleeptightAnsiC]

I believe this is one of those super annoyances with OpenGL...

• https://stackoverflow.com/questions/4532342/opengl-gl-lines-endpoints-not-joining
• https://community.khronos.org/t/lines-one-pixel-too-short/56367
• https://gitlab.freedesktop.org/mesa/mesa/-/issues/1898
• https://graphics-software-engineer.blogspot.com/2012/04/rasterization-rules.html

It seems that DrawRectangleLines depends on unspecified/undefined behavior which does not guarantee that lines would join in all cases.

[EDIT] Current implementation of DrawRectangleLines tries to mitigate the problem by using glVertex2f with 0.5f offsets, but this still seems not enough. Also related to #3884 and #4670

CC @raysan5

[sleeptightAnsiC]

This might a problem with more shapes than RectangleLines.

Out of curiosity, does this issue also occurs with DrawTriangleLines or DrawCircleLines on your side? @Roucou

[orcmid]

I believe this is one of those super annoyances with OpenGL...

I have been wondering if the FP rounding settings on float to int have an impact on these cases,, especially across (target) platforms and build systems.

[sleeptightAnsiC]

I have been wondering if the FP rounding settings on float to int have an impact on these cases

I played a bit with DrawRectangleLines() inside of debugger and don't really see where it could loose precision or cause rounding error. It does int-to-float cast (not float-to-int) and values from DrawRectangleLines(0, 0, 100, 100, WHITE) are too small to cause this issue (I think).

Maybe it happens somewhere deeper in rlVertex3f()

[Roucou]

Am doing some business travel the following days, will do some tests over the weekend. I did play around with switching to float instead of int earlier on, but that resulted in the same missing pixel. Also tried drawing the four lines individually using DrawLine(...) but that gave even weirder results.

@sleeptightAnsiC is probably right, it might very well be basic OpenGL incompatibility issues. So, for my game I'll probably have to switch to textures as a workaround. But many thanks for the investigation!

[raysan5]

@Roucou @sleeptightAnsiC I'm afraid this is a recurrent issue and unfortunately it's platform dependant, it depends on the OS, the GPU and the drivers. If solved for a specific case it can break for other cases. Already worked on it many many times...

As a solution, you can use DrawRectangleLinesEx() tha uses QUADs instead of LINES and should work as expected.

Related issues: #4386, #3973, #3884, #3931...

[sleeptightAnsiC]

@Roucou despite that issue is closed, make sure to answer my questions when you'll have some opportunity, please. I may take a look at fixing/forwarding this anyway.