[SOLVED] Purple and Green Lines/Stripes on All JOGL Windows

I have a JOGL project that used to work perfectly. I moved to a new PC and now it doesn't. Not even the old builds that were packaged using Launch4J and function perfectly on other people's computers without any other downloadswork on mine anymore.

The issue I'm facing is whenever I attempt to draw any color that is between white and black, my screen shows horizontal green and purple lines. I compiled a very basic project wherein all I did was create a window and then display said window with glClearColor(0.5f,0,0.5f,1) and instead of magenta, I received horizontal green lines. So, no project works.

At first I thought it was my graphics card - I'm using an HP Spectre x360 15.6" (2020) with a 1650 Ti card. I updated the drivers and nothing. It shouldn't be this because games (Destiny 2, Civilization VI) work fine.

I tried updating to 2.4.0-rc as well, as using 2.3.2 was dropping an error in the console about an "illegal reflective access" which I could not find any good solutions to with a Google search (except "downgrade from Java 11," which was useless to me as this was an issue occurring while using Java 8). This warning/error seems to be completely suppressed/bypassed with 2.4.0-rc but I don't know that it's not happening so much as just not appearing. I never saw that issue running it on my older device.

To ensure that I was not going insane, I even went back to my roots with a JOGL tutorial that originally got me using it (https://www.youtube.com/watch?v=hh6wr6oEeOs&list=PL9a_05IxzbrctpcWdVyVaF9AO0vn4WD4J&index=4). I made it about halfway through the video where he sets the color the same as I did. Again black and white appear fine, but any color in between those extremes is just horizontal lines (my game itself looks a mess; all the logic works, you can hazily make out the gameplay and all audio cues and cutscenes but the color is destroyed and even the size of the window seems too small).

Please help!! I would love to provide code but it seems to be any program I run with JOGL - even a fresh one, following isntructions and all - that causes the issue.

Hello

We're not responsible for unofficial tutorials. Please try this example:
https://jogamp.org/wiki/index.php/Rudimentary_standalone_example_using_the_fixed_pipeline_by_Julien_Gouesse

I stated that this happens regardless of program, even with a fresh one with no other code but creating the window and a GLEventListener, but fine. I copy-pasted the exact code from the official tutorial and this is a screenshot from what happens. I hadn't seen blue before, but this is what shows up - very similar phenomenon from my OP.

I notice that both examples here are using the (ancient) immediate mode.

Is this also true of you main project? If so, perhaps Nvidia's driver for your card has a bug with that type of rendering...

Maybe try a simple triangle using more modern OpenGL calls. (third party tutorial here for very basic vertex buffer + shader, should translate into Java-JOGL very easily)

This would at least narrow down if the issue is in the JOGL library in general, or specific to the drawing mode.

Please try Xerxes' example too:
https://gist.github.com/xranby/ccbcfcaef341f5bd1ba8

I haven't tried the example before, but Xerxes' example seems to be outputting properly (if this is what it's supposed to look like). From my understandin, this is immediate mode as well so I'm kinda confused on what the issue might be when I just use GL2.

The Xerxes example is using an `ImmModeSink` It's essentially emulating immediate mode, but buffers the data from all of the fixed commands, and sends a modern set of data buffers + shader to the actual GPU.

Might wish to try printing out the results of `glAvailabilityToString()` just to see what JOGL thinks it's working with.

Natives[GL4bc true [4.6 (Compat profile, arb, compat[ES2, ES3, ES31], FBO, hardware)], GL4 true [4.6 (Core profile, arb, compat[ES2, ES3, ES31], FBO, hardware)], GLES3 false, GL3bc true [4.6 (Compat profile, arb, compat[ES2, ES3, ES31], FBO, hardware)], GL3 true [4.6 (Core profile, arb, compat[ES2, ES3, ES31], FBO, hardware)], GL2 true [4.6 (Compat profile, arb, compat[ES2, ES3, ES31], FBO, hardware)], GLES2 false, GLES1 false, count 5 / 8], Common[, GL4ES3 true, GL2GL3 true, GL2ES2 true, GL2ES1 true], Mappings[GL3bc GLProfile[GL3bc/GL4bc.hw], GL2ES1 GLProfile[GL2ES1/GL4bc.hw], GL4ES3 GLProfile[GL4ES3/GL4.hw], GL2ES2 GLProfile[GL2ES2/GL4.hw], GL4bc GLProfile[GL4bc/GL4bc.hw], GL2 GLProfile[GL2/GL4bc.hw], GL4 GLProfile[GL4/GL4.hw], GL3 GLProfile[GL3/GL4.hw], GL2GL3 GLProfile[GL2GL3/GL4bc.hw], , default GLProfile[GL4bc/GL4bc.hw], count 9 / 12]

This is the output from GLProfile.glAvailabilityToString().

Please try this example too:
https://jogamp.org/cgit/jogl-demos.git/tree/src/demos/es2/RawGL2ES2demo.java?id=HEAD

Well now that's interesting. The output from that says it's using the integrated graphics (Intel UHD Graphics) to render, not the dedicated graphics (1650 Ti). I'm going to try and find drivers for the integrated graphics & also find how to prioritize the dedicated card.

The output looks fine (I scaled the window down to 720x480 because it was filling my screen before).

Problem solved! After seeing that the renderer was relying on the integrated graphics, I updated my Intel UHD Graphics drivers and now my game and all other JOGL stuff is appearing properly. Thank you so much! My next step will be trying to prioritize the dedicated graphics card over the integrated one.

On a windows system, prioritizing a graphics card is done from outside of the program. There is an "NVidia control panel" that sets this on a system-wide scale, or you can do "Program Settings" for each application.

You might want to consider leaving it at the default, though. Windows is supposed to switch seamlessly between the two, based on the graphics load. (The dedicated NVidia card will pull down a lot more power, and have to dump all of that heat - which might limit run-time under load, and reduce battery life, if you're on the go.)

Generally, the only reasons to lock the big card "on" are:

- To test configurations & code)
- When you *know* that the onboard card can't handle your workload, eg doing very heavy GPU compute work, or if the driver update *hadn't* fixed your issue.