It's official, Sun's Opengl pipeline is blown

This is how the image is SUPPOSED to look. It’s using software renderer.

http://members.optusnet.com.au/ksaho/gayPorn/noOpengl.JPG

Now with OpenGL pipeline Sun implemented in Java 5.

http://members.optusnet.com.au/ksaho/gayPorn/opengl.JPG

I’ve said it before and I will say it again.

WHAT THE &*^$?

I solved the problem.
After modifying my code to use accelerated images, the GL pipeline works as the software one does.

http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=2D;action=display;num=1106190472

I’m assuming that you’re testing on an ATI board on Windows (based on your previous posts). I believe there is an existing bug in ATI’s Windows drivers that causes the red/blue swapping problem you’re seeing (usually when rendering a software surface). The bug is in their driver code, not in our OpenGL pipeline code. We can try to make them aware of this issue, but first I’ll need to know which board you’re using (exact model) and which driver version.

Thanks,
Chris

The bug does occur in the way you suggested to get a managed image but the bug doesn’t exist if you copy pixel to pixel unmanaged image to a managed one.

So I guess I found a walkaround for the bug.

I have a Powercolor Radeon 9700 Pro.
Catalyst 5.1.

“It’s official” that ATI’s OpenGL drivers tend to always deliver problems.
Whenever you encounter an OpenGL related problem on an ATI card (let) test the same software on an Nvidia card and voila: no problem at all.

PS: Some time ago there’s been an official statement from ATI that they’re about to totally re-write their entire (Winblows) OpenGL driver thing. No idea when this will be finished or if it’s already there.

I’ve never actually seen or felt a bug in an OpenGL game though with my Radeon.

A few hours ago I was playing Doom 3 quite perfectly.

[quote]I’ve never actually seen or felt a bug in an OpenGL game though with my Radeon.
[/quote]
Well, watching a finished OpenGL game is another thing than developing an OpenGL game and ecounter driver problems. :slight_smile:
A finished game usually includes workarounds for known problems with certain drivers, OS’es, etc.
When you’re developing a game you’re supposed to find all these workarounds. :frowning:

Most commercial (C++) OpenGL games use a sort of ID’s OpenGL engine. So if these engines have nice ATI bug workarounds (render paths… :-), all the games will benefit. Carmack stated during his Doom3 development that Nvidia’s OpenGL drivers have got gold status for him (what’s concerning OpenGL spec conformity), but no other drivers.

About Java OpenGL games:
° Alienflux uses hacks/workarounds for ATI driver bugs.
° In former times Agent9’s game didn’t run on my ATI PC at all. On a Nvidia PC it did.
° Some time ago Wurm-Online produced BSoDs on my ATI PC while it run perfectly on a Nvidia PC.
° My own little OpenGL 2d game can’t use some very nice official OpenGL extensions (related to 2d texture sprite stuff) because they run on Nvidia but not on ATI. :frowning:
° Please scan the forum to see how long it took JOGL to run in a solid way on most ATI cards. And it’s “just” an OpenGL binding, so if OpenGL is OpenGL why does the same binding run perfectly on Nvidia but not on ATI?

ATI’s desktop OpenGL drivers today are much better than a few years ago. Their mobile 3d card drivers still deliver many OpenGL problems, though.

1.) Well DOOM 3 is quite a popular game often used as benchmark, so you can bet there were many developers just optimizing the drivers for this game.

2.) ATI is known to not have the best dirvers. - The Java OpenGL pipeline just prooves this. The reason why its so problematic on many boards is, that it uses OpenGL very different than most 3d games, copying much memory between system and video-memory and so on.
NVidia also had big problems with their old drivers - I wrote them and it took about 3 weeks and it worked like expected.

3.) Just speaking about NVidia, they have splitted driver-teams. One team only does DirectX and one does only OpenGL. This parts are platform-independent settlet upon a platform-specific layer that is done by unix, mac and windows driver team.
This ensures that all developers are professionals in their area and do not have to know nothing and everything at the same time.
If you just look at the ATI linux dirvers you can see why this team-approach is better g

lg Clemens

Just one bug which I got rid of on my own doesn’t mean Ati’s drivers are buggy beyond use.

From my experience as a gamer Ati’s drivers are far more solid than nVidia’s and I’ve always upgraded to nVidia cards until recently.

I’ve not had a single issue in any game, popular games or not.

Having worked (and often working even these days) on C++ (other than Java) OpenGL games and apps I can just confirm what was said.

I can also add that even Nvidia drivers have their bunch of bugs, even if they are more sided on the cutting edge 3D features (expecially extensions) and so for hackers and hobbysts are almost inexistant.

Flux only has 1 workaround for ATI bugs, and that’s on an ancient laptop driver for the Rage Mobility which simply crashes in glDrawRangeElementsEXT. The rest of my GL usage is so trivially simple it’d be hard for anything to go wrong.

Cas :slight_smile: