Batolemaeus

Members
  • Content Count

    439
  • Joined

  • Last visited

Community Reputation

101 Good

About Batolemaeus

  • Rank
    Villager

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Oh, well that's annoying. Guess you'd have to use Sysinternals Process Explorer to drill down into the Java environment instead. Might be worth doing, might be a complete red herring. The Nvidia control panel used to have game-specific override as an option when I last had to interact with Nvidia on Windows. Anything that interferes with the rendering process is a bit suspect, i.e. things like the Steam Overlay. Unrelated, but curious: In %userprofile%\wurm\console.*.log, there's a block that begins with "=== OpenGL information ===", can you post the OpenGL vendor, renderer, and version strings?
  2. Alright, nothing egregious as far as I can see. The problem with your described symptoms is that it could be basically anything. So I'll have to take total stabs in the dark. The 15 fps cap is suspicious since it's 60/4, and clean values are always suspicious. Could be the graphics driver interfering, like imposing the cap outright or doing some particularly screwed up vsync. Check in the control panel if there are any overrides for Wurm. Any kind of overlay is also immediately suspect. The other thing is the long pause every 1 second. That screams of a severe memory limit on Java, which would force it to aggressively reclaim memory often. Since that is costly, it would tank performance. How are you launching Wurm? Are you using the "lowmem" preset from the launcher? If yes: don't. With Wurm running, open Task Manager, go to the Details tab, right click on the name of any of the columns and choose "Select columns". Check "Command Line" and confirm with "Ok". You may have to expand the Command Line column a bit, but you should be able to see what Parameters Wurm is running with. Of interest are the values of "-Xmx" and "-Xms".
  3. Post the file gamesettings.txt from %userprofile%\wurm\configs\$YOUR_PROFILE\ Some information on your computer also wouldn't go amiss, specifically the graphics card used and whether your computer is actually a laptop with both an integrated and dedicated graphics card.
  4. Well, "works". The shader is broken and I suspect the math inside doesn't work out as intended on any driver.
  5. It just occurred to me that this probably should be outside of the Linux issues forum as well, since it's a Wurm/OpenGL issue. In terrain_light.multipass.fragment.shader, the variable _worldpos is used without being initialised. Some drivers will zero-init it, some will throw an error. On those that throw an error, Wurm will crash. Having read the shader code, I strongly suspect that terrain lighting isn't quite working as intended if the driver zero-initialises the variable. (But my knowledge of GLSL is a bit rusty, so that's just a hunch) See also
  6. Added workaround for the broken terrain lighting shader
  7. Workaround: since Wurm is using an uninitialised variable, we can force this variable to zero by running Wurm with glsl_zero_init=true: glsl_zero_init=true ./WurmLauncher
  8. Here's what lwjglx-debug says about that one: Preloading builtin materials [error][1] OpenGL debug message ID: 0x2 Source: SHADER COMPILER Type: OTHER Severity: HIGH Message: 0:33(22): warning: `_worldpos' used uninitialized Stacktrace: org.lwjgl.opengl.GL20C.glLinkProgram(Native Method) org.lwjgl.opengl.GL20.glLinkProgram(GL20.java:408) class.cbvNayZq8l.FZOk5L6Gfy(SourceFile:2309) class.cbvNayZq8l.FZOk5L6Gfy(SourceFile:159) class.MSNI8ZZrqn.iHOS3zg1KL(SourceFile:158) class.MSNI8ZZrqn.FZOk5L6Gfy(SourceFile:86) class.MSNI8ZZrqn.XwhlvVTrl(SourceFile:1068) com.wurmonline.client.WurmClientBase.run(SourceFile:37361) java.base/java.lang.Thread.run(Thread.java:833) [error][1] OpenGL debug message ID: 0x3 Source: SHADER COMPILER Type: OTHER Severity: HIGH Message: 0:33(54): warning: `_worldpos' used uninitialized Stacktrace: org.lwjgl.opengl.GL20C.glLinkProgram(Native Method) org.lwjgl.opengl.GL20.glLinkProgram(GL20.java:408) class.cbvNayZq8l.FZOk5L6Gfy(SourceFile:2309) class.cbvNayZq8l.FZOk5L6Gfy(SourceFile:159) class.MSNI8ZZrqn.iHOS3zg1KL(SourceFile:158) class.MSNI8ZZrqn.FZOk5L6Gfy(SourceFile:86) class.MSNI8ZZrqn.XwhlvVTrl(SourceFile:1068) com.wurmonline.client.WurmClientBase.run(SourceFile:37361) java.base/java.lang.Thread.run(Thread.java:833) [error][1] OpenGL debug message ID: 0x4 Source: SHADER COMPILER Type: OTHER Severity: HIGH Message: 0:40(38): warning: `_worldpos' used uninitialized Stacktrace: org.lwjgl.opengl.GL20C.glLinkProgram(Native Method) org.lwjgl.opengl.GL20.glLinkProgram(GL20.java:408) class.cbvNayZq8l.FZOk5L6Gfy(SourceFile:2309) class.cbvNayZq8l.FZOk5L6Gfy(SourceFile:159) class.MSNI8ZZrqn.iHOS3zg1KL(SourceFile:158) class.MSNI8ZZrqn.FZOk5L6Gfy(SourceFile:86) class.MSNI8ZZrqn.XwhlvVTrl(SourceFile:1068) com.wurmonline.client.WurmClientBase.run(SourceFile:37361) java.base/java.lang.Thread.run(Thread.java:833) [error][1] OpenGL debug message ID: 0x5 Source: SHADER COMPILER Type: OTHER Severity: HIGH Message: 0:42(13): warning: `_color' used uninitialized Stacktrace: org.lwjgl.opengl.GL20C.glLinkProgram(Native Method) org.lwjgl.opengl.GL20.glLinkProgram(GL20.java:408) class.cbvNayZq8l.FZOk5L6Gfy(SourceFile:2309) class.cbvNayZq8l.FZOk5L6Gfy(SourceFile:159) class.MSNI8ZZrqn.iHOS3zg1KL(SourceFile:158) class.MSNI8ZZrqn.FZOk5L6Gfy(SourceFile:86) class.MSNI8ZZrqn.XwhlvVTrl(SourceFile:1068) com.wurmonline.client.WurmClientBase.run(SourceFile:37361) java.base/java.lang.Thread.run(Thread.java:833) [error][1] Program [45] did not link successfully: 1 error: fragment shader varying _worldpos not written by vertex shader 2 .error: fragment shader varying _worldpos not written by vertex shader 3 . Failed linking program: program.terrain_light.multipass Execution aborted at connection 0, iteration 0 Run time 0s, local time Thu Sep 22 11:12:06 CEST 2022 Destroying game window
  9. Note: Same problem with the normal runtime. Mesa 22.2.0 was just released and it looks like the crash that was reported earlier made it into the full release. I may dissect it if I can find the time, but just as a heads up: Wurm is broken on Mesa 22.2.0
  10. The 1px-width windows are a bug in JavaFX. I haven't had them running with OpenJavaFX 17, but to run Wurm with a different runtime is a can of wurms. Keenan announced some movement on that front, so it should get better. And honestly, the GTK dependency is weird. Dynamic linking a game launcher is just not a good idea. Also yes, Wurm on Linux runs really well if you get past the bugs caused by the woefully outdated runtime. Even with the weird controller mouse emulation Steam does.
  11. Try replacing the Steam launch options with: GDK_BACKEND=x11 MESA_GL_VERSION_OVERRIDE=4.2 %command% The NullPointerException is probably from the ambient occlusion shader using a thoroughly deprecated OpenGL function.
  12. You don't have much choice there. The Wurm client installed by Steam uses Steam accounts, the standalone one uses original Wurm accounts. So the account you use determines what client you have to use. You can make the standalone Wurm client open in "steam" mode, but the required invocations are pretty arcane. I don't have the N-Gabe (yet), but the workarounds I posted in the tech issues forum should apply on the Deck as well.
  13. Something is disrupting the network connection and then blocks address resolution of the login server's address. That is most likely an issue on your side if it persists for more than a few minutes or hours. The most likely culprit for something like this is "security" software, the next likely culprit is your ISP.
  14. Well, don't do that. That option probably shouldn't exist in the first place. FWIW, the same crash happens with OpenGL renderer: AMD Radeon RX 6700 XT (navy_flounder, LLVM 14.0.6, DRM 3.47, 5.19.3-gentoo-x86_64) But as far as I know, the GLSL dropdown hasn't been useful in ages. It used to help on some broken drivers if I remember correctly.
  15. The Nvidia OpenGL driver is known to be trash, that's not related to the problem in the OP. The problems in the OP are fixed by simply using a version of Java that isn't unsupported upstream and many years old. I've helped a few people run Wurm with updated versions of Java, and it fixes the problem. The wurm devs simply need to get off their asses and finally update the runtime.