Crash on some nVidia cards

[markgardyfy]

This is my error please help i want to play this game

Code: Select all

java.lang.RuntimeException: haven.GLProgram$ProgramException: Failed to link GL program
Log:
Fragment info
-------------
0(14) : error C6013: Only arrays of texcoords may be indexed in this profile, and only with a loop index variable

   at com.jogamp.common.util.awt.AWTEDTExecutor.invoke(AWTEDTExecutor.java:58)
   at jogamp.opengl.awt.AWTThreadingPlugin.invokeOnOpenGLThread(AWTThreadingPlugin.java:100)
   at jogamp.opengl.ThreadingImpl.invokeOnOpenGLThread(ThreadingImpl.java:205)
   at javax.media.opengl.Threading.invokeOnOpenGLThread(Threading.java:172)
   at javax.media.opengl.Threading.invoke(Threading.java:191)
   at javax.media.opengl.awt.GLCanvas.display(GLCanvas.java:483)
   at haven.HavenPanel.uglyjoglhack(HavenPanel.java:391)
   at haven.HavenPanel.run(HavenPanel.java:423)
   at java.lang.Thread.run(Unknown Source)
Caused by: haven.GLProgram$ProgramException: Failed to link GL program
Log:
Fragment info
-------------
0(14) : error C6013: Only arrays of texcoords may be indexed in this profile, and only with a loop index variable

   at haven.GLProgram$ProgOb.link(GLProgram.java:99)
   at haven.GLProgram.apply(GLProgram.java:142)
   at haven.GLState$Applier.apply(GLState.java:435)
   at haven.GOut.apply(GOut.java:194)
   at haven.FastMesh$Compiler.get(FastMesh.java:91)
   at haven.FastMesh.draw(FastMesh.java:317)
   at haven.RenderList.render(RenderList.java:219)
   at haven.RenderList.render(RenderList.java:231)
   at haven.PView.draw(PView.java:180)
   at haven.MapView.draw(MapView.java:800)
   at haven.Widget.draw(Widget.java:510)
   at haven.Widget.draw(Widget.java:515)
   at haven.GameUI.draw(GameUI.java:469)
   at haven.Widget.draw(Widget.java:510)
   at haven.Widget.draw(Widget.java:515)
   at haven.RootWidget.draw(RootWidget.java:61)
   at haven.UI.draw(UI.java:139)
   at haven.HavenPanel.redraw(HavenPanel.java:277)
   at haven.HavenPanel$1.display(HavenPanel.java:91)
   at jogamp.opengl.GLDrawableHelper.displayImpl(GLDrawableHelper.java:588)
   at jogamp.opengl.GLDrawableHelper.display(GLDrawableHelper.java:572)
   at javax.media.opengl.awt.GLCanvas$7.run(GLCanvas.java:1054)
   at jogamp.opengl.GLDrawableHelper.invokeGLImpl(GLDrawableHelper.java:1034)
   at jogamp.opengl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:909)
   at javax.media.opengl.awt.GLCanvas$8.run(GLCanvas.java:1065)
   at java.awt.event.InvocationEvent.dispatch(Unknown Source)
   at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
   at java.awt.EventQueue.access$200(Unknown Source)
   at java.awt.EventQueue$3.run(Unknown Source)
   at java.awt.EventQueue$3.run(Unknown Source)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
   at java.awt.EventQueue.dispatchEvent(Unknown Source)
   at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
   at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
   at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
   at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
   at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
   at java.awt.EventDispatchThread.run(Unknown Source)


[loftar]

I know some time has passed, but I split this post off from its original thread (since it described a completely different error than what the thread was about anyway) because I've seen a couple of error reports of this same problem lately.

The problem is related to some older models of nVidia cards (those before the GeForce 8xxx series, without unified shaders) having incomplete GLSL implementations and therefore being unable to compile certain programs. This is hard to detect in advance other than by completely heuristic means, so I can't think of a good way to work around the error in the client.

For now, therefore, if you get this error, you'll have to work around it by manually turning off GLSL use completely by issuing the following console command in the client:

Code: Select all

:gl progmode n

If your client crashes because of this error as soon as you enter the game world, you'll have to issue the command before that, such as at the character selection screen. You may also have to restart the client after issuing the command in order for it to reset all other dependent settings to match, but that may not always be necessary.

For the record, this particular error condition is identifiable by the following message in the traceback:

Code: Select all

Only arrays of texcoords may be indexed in this profile, and only with a loop index variable

[ZtyX]

Thanks. It's great to see that you still come up with a solution rather than just telling people to get a newer graphics card.

[MagicManICT]

[...] rather than just telling people to get a newer graphics card.

It's not so much this. The problem is support of and for OpenGL by the graphic chip manufacturers since only a handful of major commercial packages use it. In the case of your 3D modelling software (AutoCAD, Maya, etc.), OpenGL is preferred because the high-end cards that are used to power those things (at $1000 and up for entry level cards) ONLY support OpenGL. When it comes to consumer level cards, though, OpenGL is almost an afterthought on Windows machines.

With the OpenGL spec used, cards that came out 10 years could, in theory, run Salem. I had an old Athlon 64 here with a nVidia 5200 256MB built in 2005 that ran Salem at around 10-12 fps. That was one of the very first DirectX 9.0 cards on the market.

In the cases of developers that tell you to buy a new card, odds are the old card you have isn't going to support the commands the game requires. The only time I've said "get a new card" is when there isn't a known driver that properly supports OpenGL (which is the case for some of the early Intel 3D GPUs).

[loftar]

The problem is support of and for OpenGL by the graphic chip manufacturers since only a handful of major commercial packages use it. In the case of your 3D modelling software (AutoCAD, Maya, etc.), OpenGL is preferred because the high-end cards that are used to power those things (at $1000 and up for entry level cards) ONLY support OpenGL. When it comes to consumer level cards, though, OpenGL is almost an afterthought on Windows machines.

I wouldn't really say that. OpenGL support from nVidia and AMD is actually rather good (Intel is another question however, though they're getting better), but in cases such as those covered by this thread they are faced with, I think, a rather real dilemma, since the hardware in question is simply too specialized to support the operations I ask for (note that they don't support them on DirectX either, which is why most modern games require at least a GeForce 8xxx or newer card, whether they're graphics-intensive or not). They have to choose between either returning this error condition, or implement an entire alternative OpenGL implementation that runs on the CPU to be used whenever the card doesn't support the requested shader. Since noone would actually want to use that alternative rasterizer anyway because of how slow it would be, I can see why they opt for the former solution even though OpenGL technically requires them to do the latter.

The problem for me is just that it's hard to detect in advance in the client whether the card it runs on supports certain operations or not. I only see it once I actually try to use a given shader program (and even then, it's hard to map the error back to a certain operation, since it's just given in natural language that the client can't really parse in any good way), and at that point it's kinda hard to recover from the error.