You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reported in version: HG 2.0 Reported for operating system, platform: Linux, x86_64
Comments on the original bug report:
On 2014-12-01 05:55:24 +0000, Andreas Schiffler wrote:
GL_RenderDrawLines (and similar functions) has custom code that handles the "open point" case differently depending on platform. This seems to cause issues on newer versions of Linux (in my case: Linux Mint 17.1 on x86 with radeon rendered, see version info below).
Detection is easy with the testautomation render suite:
./testautomation --info render --seed 02BZFAAR8A8MQAHA --filter render_testPrimitives
...
Current renderer:
Renderer opengl:
Flags: 0x0000000A (Accelerated | 0x00000008)
Texture formats (5): ARGB8888, YV12, IYUV, NV12, NV21
Max Texture Size: 2048x2048
INFO: 11/30/14 20:11:17: ::::: Test Run /w seed '02BZFAAR8A8MQAHA' started
INFO: 11/30/14 20:11:17: Filtering: running only test 'render_testPrimitives' in suite 'Render'
...
ERROR: 11/30/14 20:11:18: Comparison of pixels with allowable error of 0 failed 1 times.
ERROR: 11/30/14 20:11:18: First detected occurrence at position 50,30 with a squared RGB-difference of 33550.
ERROR: 11/30/14 20:11:18: Surfaces from failed comparison saved as 'CompareSurfaces0001_TestOutput.bmp' and 'CompareSurfaces0001_Reference.bmp'
...
When analyzing the images, the difference is a missing pixel for the last line rendered in the sequence:
test/testautomation_render.c
...
ret=SDL_RenderDrawLine(renderer, 79, 0, 50, 29 );
SDLTest_AssertCheck(ret==0, "Validate result from SDL_RenderDrawLine, expected: 0, got: %i", ret);
ret=SDL_RenderDrawLine(renderer, 79, 59, 50, 30 );
SDLTest_AssertCheck(ret==0, "Validate result from SDL_RenderDrawLine, expected: 0, got: %i", ret);
/* Make current */SDL_RenderPresent(renderer);
/* See if it's the same. */referenceSurface=SDLTest_ImagePrimitives();
_compare(referenceSurface, ALLOWABLE_ERROR_OPAQUE );
...
The cause is the following code (with the invalid code on this platform commented out) in src/render/opengl/SDL_render_gl.c:
data->glBegin(GL_POINTS);
#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/* Standard code fixes test case */data->glVertex2f(0.5f+points[count-1].x, 0.5f+points[count-1].y);
/* Linux seems to leave the right-most or bottom-most point open *//* Original code breaks test case 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); }*/#endifdata->glEnd();
Other rendering platforms were also affected in the same way on this platform.
Linux shuttlebox 3.13.0-37-generic # 64-Ubuntu SMP Mon Sep 22 21:30:01 UTC 2014 i686 i686 i686 GNU/Linux
gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2
OpenGL vendor string: X.Org R300 Project
OpenGL renderer string: Gallium 0.4 on ATI RV350
OpenGL version string: 2.1 Mesa 10.1.3
OpenGL shading language version string: 1.20
On 2014-12-01 05:57:32 +0000, Andreas Schiffler wrote:
Created attachment 1948
Reference image
On 2014-12-01 05:58:00 +0000, Andreas Schiffler wrote:
Created attachment 1949
Test output image
On 2020-02-24 00:18:59 +0000, Juan wrote:
The same here, February 2020.
In Arch Linux with Qt Creator, I followed a tutorial from the LazyFoo site and also encountered this problem.
A pixel appears after drawing a line and that loose pixel is the same color as the last line drawn.
Vendor: Intel Open Source Technology Center (0x8086)
Device: Mesa DRI Intel(R) Ivybridge Desktop (0x152)
Version: 19.3.4
Accelerated: yes
Video memory: 1536MB
Unified memory: yes
Preferred profile: core (0x1)
Max core profile version: 4.2
Max compat profile version: 3.0
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.0
gcc versión 9.2.1 20200130 (Arch Linux 9.2.1+20200130-2)
Qt Creator 4.11.1 - Based on Qt 5.14.1 (GCC 9.2.0, 64 bit)
Makefile, for the command line:
#OBJS specifies which files to compile as part of the project
OBJS = main.cpp
#CC specifies which compiler we're using
CC = g++
#COMPILER_FLAGS specifies the additional compilation options we're using
# -w suppresses all warnings
COMPILER_FLAGS = -w
#LINKER_FLAGS specifies the libraries we're linking against
LINKER_FLAGS = -lSDL2 -lSDL2_image
#OBJ_NAME specifies the name of our exectuable
OBJ_NAME = executable
#This is the target that compiles our executable
all : $(OBJS)
$(CC) $(OBJS) $(COMPILER_FLAGS) $(LINKER_FLAGS) -o $(OBJ_NAME)
Like you I see the last pixel not aligned with the line. Using SDL 2.0.8 on ubuntu 18.04, I will try with the latest sdl and see if it remains the same.
On 2020-04-15 22:13:18 +0000, Florian D wrote:
Created attachment 4308
Scrrenshot of the bug, the last pixel appears shifted
On 2020-04-16 21:25:46 +0000, Juan wrote:
(In reply to Florian D from comment # 6)
Created attachment 4308 [details]
Scrrenshot of the bug, the last pixel appears shifted
I used SDL 2.0.12-1 on Arch Linux. But yes. It is the same behavior.
The text was updated successfully, but these errors were encountered:
This bug report was migrated from our old Bugzilla tracker.
These attachments are available in the static archive:
Reported in version: HG 2.0
Reported for operating system, platform: Linux, x86_64
Comments on the original bug report:
On 2014-12-01 05:55:24 +0000, Andreas Schiffler wrote:
On 2014-12-01 05:57:32 +0000, Andreas Schiffler wrote:
On 2014-12-01 05:58:00 +0000, Andreas Schiffler wrote:
On 2020-02-24 00:18:59 +0000, Juan wrote:
On 2020-02-24 00:26:00 +0000, Juan wrote:
On 2020-04-15 22:11:04 +0000, Florian D wrote:
On 2020-04-15 22:13:18 +0000, Florian D wrote:
On 2020-04-16 21:25:46 +0000, Juan wrote:
The text was updated successfully, but these errors were encountered: