Jump to content
  • 0

Triple monitor setup dark zone lag


frogski

Question

hi there, 


 


I'm running the [iwillbackupmysave] version with the following specs:


I7 4790K


GTX 780TI 3Gb


16Gb Ram


5670 x 1080 resolution


 


The game runs properly on 1920 x 1080 but as soon as I switch to my triple monitor setup it seems to create some sort of lag with the blackened area. It doesn't clear right away so you end up walking in the dark for quite a bit before it finally appears.


 


Same goes with entering and leaving a closed room. I've asked on reddit and someone said that they used to be able to run it without a problem with the previous version but now they do encounter the same problem.


 


PS: I've also posted it in the bug tracker


Link to comment
Share on other sites

Recommended Posts

As I understand it, the workload must increase exponentially with resolution so Harakka may well be right.

 

I was actually going to mention it might be worth trying to set the lighting updates to fastest, because it directly influences how quickly the lighting updates. If you're having darkness that doesn't go away very quickly it might be because you've got the lighting set too low and it's just slow because it's set slow. Try setting it all the way to the fastest setting and see if that helps?

Link to comment
Share on other sites

Here is what happens when I'm trying to close the game in 5760x1080

It's an infinite loop. My only way out is to kill the game. 

 

I can exit fine in normal resolution

STATE: exit zombie.gameStates.IngameStateSep 04, 2014 9:55:33 AM zombie.GameWindow runSEVERE: nulljava.lang.NullPointerException	at zombie.core.textures.MultiTextureFBO.destroy(MultiTextureFBO.java:147)	at zombie.gameStates.IngameState.exit(IngameState.java:586)	at zombie.gameStates.GameStateMachine.update(GameStateMachine.java:105)	at zombie.GameWindow.logic(GameWindow.java:641)	at zombie.GameWindow.run(GameWindow.java:1156)	at zombie.GameWindow.maina(GameWindow.java:983)	at zombie.gameStates.MainScreenState.main(MainScreenState.java:147)	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)	at java.lang.reflect.Method.invoke(Method.java:606)	at com.exe4j.runtime.LauncherEngine.launch(Unknown Source)	at com.exe4j.runtime.WinLauncher.main(Unknown Source)-------------------------------------------------------------attempted index: getDir of non-table: null-----------------------------------------STACK TRACE-----------------------------------------function: update -- file: ISInventoryPage.lua line # 212attempted index: getDir of non-table: null-----------------------------------------STACK TRACE-----------------------------------------function: update -- file: ISInventoryPage.lua line # 212-------------------------------------------------------------attempted index: getDir of non-table: null-----------------------------------------STACK TRACE-----------------------------------------function: update -- file: ISInventoryPage.lua line # 212attempted index: getDir of non-table: null-----------------------------------------STACK TRACE-----------------------------------------function: update -- file: ISInventoryPage.lua line # 212Sep 04, 2014 9:55:33 AM zombie.gameStates.IngameState updateSEVERE: nulljava.lang.NullPointerException	at zombie.iso.IsoChunkMap.ProcessChunkPos(IsoChunkMap.java:798)	at zombie.gameStates.IngameState.update(IngameState.java:1093)	at zombie.gameStates.GameStateMachine.update(GameStateMachine.java:101)	at zombie.GameWindow.logic(GameWindow.java:641)	at zombie.GameWindow.run(GameWindow.java:1156)	at zombie.GameWindow.maina(GameWindow.java:983)	at zombie.gameStates.MainScreenState.main(MainScreenState.java:147)	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)	at java.lang.reflect.Method.invoke(Method.java:606)	at com.exe4j.runtime.LauncherEngine.launch(Unknown Source)	at com.exe4j.runtime.WinLauncher.main(Unknown Source)STATE: exit zombie.gameStates.IngameStateSep 04, 2014 9:55:40 AM zombie.GameWindow runSEVERE: nulljava.lang.NullPointerException	at zombie.iso.LightingThread.stop(LightingThread.java:227)	at zombie.gameStates.IngameState.exit(IngameState.java:584)	at zombie.gameStates.GameStateMachine.update(GameStateMachine.java:105)	at zombie.GameWindow.logic(GameWindow.java:641)	at zombie.GameWindow.run(GameWindow.java:1156)	at zombie.GameWindow.maina(GameWindow.java:983)	at zombie.gameStates.MainScreenState.main(MainScreenState.java:147)	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)	at java.lang.reflect.Method.invoke(Method.java:606)	at com.exe4j.runtime.LauncherEngine.launch(Unknown Source)	at com.exe4j.runtime.WinLauncher.main(Unknown Source)-------------------------------------------------------------attempted index: getDir of non-table: null-----------------------------------------STACK TRACE-----------------------------------------function: update -- file: ISInventoryPage.lua line # 212attempted index: getDir of non-table: null-----------------------------------------STACK TRACE-----------------------------------------function: update -- file: ISInventoryPage.lua line # 212-------------------------------------------------------------attempted index: getDir of non-table: null-----------------------------------------STACK TRACE-----------------------------------------function: update -- file: ISInventoryPage.lua line # 212attempted index: getDir of non-table: null-----------------------------------------STACK TRACE-----------------------------------------function: update -- file: ISInventoryPage.lua line # 212Sep 04, 2014 9:55:40 AM zombie.gameStates.IngameState updateSEVERE: nulljava.lang.NullPointerException	at zombie.iso.IsoCell.update(IsoCell.java:4987)	at zombie.iso.IsoWorld.update(IsoWorld.java:2098)	at zombie.gameStates.IngameState.update(IngameState.java:1097)	at zombie.gameStates.GameStateMachine.update(GameStateMachine.java:101)	at zombie.GameWindow.logic(GameWindow.java:641)	at zombie.GameWindow.run(GameWindow.java:1156)	at zombie.GameWindow.maina(GameWindow.java:983)	at zombie.gameStates.MainScreenState.main(MainScreenState.java:147)	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)	at java.lang.reflect.Method.invoke(Method.java:606)	at com.exe4j.runtime.LauncherEngine.launch(Unknown Source)	at com.exe4j.runtime.WinLauncher.main(Unknown Source)
Link to comment
Share on other sites

The crash is due to the game being unable to create a texture large enough for the higher zoom levels.

5760 x 1.5 = 8640 pixels, probably 4096x4096 or 8192x8192 is the largest texture supported.

 

If you want, extract the attached ZIP file into Project Zomboid/zombie/core/textures/, replacing the two files with the same name.  It should fix the crash-on-exit.

zombie_core_textures.zip

Link to comment
Share on other sites

I just accidentally stumbled upon something delightful!  I've continued to deal with the issues discussed earlier in this thread and I've pretty much gotten used to the fact that if I want to play PZ across all three monitors that I have to stick to 2400x600.  Every so often though I'll get an urge to experiment...

 

I decided to try running PZ on max settings, windowed at 1680x1050 just to see if I enjoyed the experience.  Despite running without issues the window still just felt "small" to me.  I knew if I went fullscreen and stayed below my eyefinity resolutions I would just experience the game running low res but mirrored 3x across all my monitors (which drives me crazy every time I've tried it) but I wondered, if I just maximized the window, would the game letterbox?

 

So I double-clicked the top bar and got the shock of my life!

 

The client maximized to what appears to be the visual equivalent of 5760x1200 (minus the space of the top bar and my windows taskbar) and ran like greased lightning but the options screen claims the game is running at 640x480!  I have no real understanding why this occurs but, you can take my word for it, I'm ecstatic!  Here's a screenshot for reference:

 

cyg8ywms9w59h47fg.jpg

Link to comment
Share on other sites

I have had this problem sense the release of the 3D engine. The old engine work perfectly even with my 5 screen setup. The issue may be caused by have a high resolution, but even making the game window tiny doesn't fix it. With lighting updates at 30, and lighting quality at lowest, it takes about 5~10 seconds to see once I enter a building, or turn a corner. This is the same with the game fullscreen at 5400x1920, or in a like 400x400 window.

 

 

Also the game only needing 1GB of RAM isnt accurate at high res.I have mine running with 4G set in the bat file, and it uses about 2~3GB while running. Here is what it looks like right as I load a new game

ldNzrVH.png

Link to comment
Share on other sites

I have had this problem sense the release of the 3D engine. The old engine work perfectly even with my 5 screen setup. The issue may be caused by have a high resolution, but even making the game window tiny doesn't fix it. With lighting updates at 30, and lighting quality at lowest, it takes about 5~10 seconds to see once I enter a building, or turn a corner. This is the same with the game fullscreen at 5400x1920, or in a like 400x400 window.

 

The game determines how much of the world needs to be loaded based on the screen size.  This happens when you first load a save or create a new game.  Making the window smaller after you start playing does not change the amount of the world that is loaded.  So if you load a game at 5400x1920 then make the window smaller, the game will still be dealing with the huge area needed by 5400x1920.

Link to comment
Share on other sites

 

I have had this problem sense the release of the 3D engine. The old engine work perfectly even with my 5 screen setup. The issue may be caused by have a high resolution, but even making the game window tiny doesn't fix it. With lighting updates at 30, and lighting quality at lowest, it takes about 5~10 seconds to see once I enter a building, or turn a corner. This is the same with the game fullscreen at 5400x1920, or in a like 400x400 window.

 

The game determines how much of the world needs to be loaded based on the screen size.  This happens when you first load a save or create a new game.  Making the window smaller after you start playing does not change the amount of the world that is loaded.  So if you load a game at 5400x1920 then make the window smaller, the game will still be dealing with the huge area needed by 5400x1920.

 

 

This is with new saves each time, and even on multiplayer. I have it running in a 850x850 window. I have that set in the options.ini. I can still run straight into a black fog area, and have it take 5~10 seconds to render.

Link to comment
Share on other sites

Ok so after having a chance to play for a couple of hours I've noticed that the darkness does lag inside buildings while outside it's perfect and somehow each time I exit the game it crashes :/ 

The crashes only happen while playing on the triple monitor resolution if I go back to 1920x1080 I can exit without a problem.

Link to comment
Share on other sites

I've made some progress in discovering what may be effecting the reveal time on triple monitor setups.  I tried to do this a couple of builds ago but something apparently didn't like my playing with the settings and it simply crashed everytime I opened the client:

 

I haven't done extensive testing on this yet at higher resolutions but there was a strongly noticable difference in update speed from the lighting renderer on 2400x600 by doing this.  The 64-bit batch file for the PZ client is still restricted to allowing java to only operate in an environment maxxed out at 1024MB.  Obviously this is far below what *any* 64-bit OS Should have available for use at any one time and I assume it was simply left this way from bug testing to ensure the client would launch properly in x64.

 

By opening the file (contained in Steam/steamapps/common/ProjectZomboid) ProjectZomboid64.bat in a text editor and changing the perameters "-Xms1024m -Xmx1024m" to a more appropriate capacity depending on your hardware and lauching the client by double clicking this .bat file instead of letting Steam handle everything for you, I noticed a major increase in client performance and responsiveness all around.

 

I have 8GB of RAM so I changed my settings to "-Xms8192m -Xmx8192m" and things have been running very stable so far.  Just thought I'd throw in what little I could come up with!

Link to comment
Share on other sites

What are your computer specs? A dxdiag posted to pastebin.com would help.

Did you modify the bat file for higher xmx/xmn values? Are you playing with all zombies set to 3D?

 

1090t * 4.4GHz

24GB ram

7970 Lightning

240GB SSD

5 monitors in portrait, 5400x1920 is the final resolution.

 

I am running the bat with 4096 for both values. I have tried 3d models to all and none, no difference.

Link to comment
Share on other sites

Computer looks like it should be fine; unless you're manually setting the resolution to be 5400 x 1920, it more or less matches the system I had 6 months ago.

 

Can you go into Catalyst and set everything to performance? Make sure lighting is also set to 30 FPS and on high in the game. Be sure to press save, and if you've had to change the resolution, exit the game completely and relaunch it. And, set the resolution to the recommended 1024x resolution.

 

If none of this has any effect, then I'm not sure what to tell you. It then becomes a unique issue, unfortunately. :(

At least that explains this:

Also the game only needing 1GB of RAM isnt accurate at high res.I have mine running with 4G set in the bat file, and it uses about 2~3GB while running. Here is what it looks like right as I load a new game

ldNzrVH.png

If you tell it that it can use more, it'll gladly use more. But the game really can run with as little as 480 MB.

Link to comment
Share on other sites

I'm not 100% sure the bat options are dictating the max available RAM; pretty confident the JRE takes what it wants.

At any rate, I'd be surprised if PZ needed much more than 1 GB of RAM at it's current state even with high Rez setups. I don't think mine hits 1 GB with 1440p res.

Link to comment
Share on other sites

I'm not 100% sure the bat options are dictating the max available RAM; pretty confident the JRE takes what it wants.

At any rate, I'd be surprised if PZ needed much more than 1 GB of RAM at it's current state even with high Rez setups. I don't think mine hits 1 GB with 1440p res.

 

I'm honestly not sure.  All I can say with confidence is that I did see a performance increase after making the change I mentioned and I keep full system monitors running on my desktop 24/7 and my RAM and pagefile usage were higher afterward.  I can't recall the exact amount but I know in the past they've hovered around 1/3 usage when I'm running PZ, since the file changes and running the client from the .bat file I'm seeing both my RAM and page file reading usage closer to 2/3 now. :???:

Link to comment
Share on other sites

Interestingly, giving the JRE that much ram can also massively decrease performance, because it has to care for it all.

PZ can be run on as little as 480 MB.

 

Well there is one other interesting factor I've noticed but I can't do any testing on it for a couple days.  Since I bought PZ, every time my client goes through its initial boot phase the console says that "java cannot identify my controller" or some other such nonsense then tells me to add the following information to a "joypad.ini" in my save directory (which doesn't exist).  Then it give a diagnostic style readout of my keyboard showing every key is recognized and functioning.  After that boot continues as normal.

 

The interesting thing is that this no longer occurs when I run the client from the .bat file.

 

I have a new keyboard on order that should arrive in a couple of days so once it arrives i can test to see if having a different brand/model of peripheral affects this odd console behavior.

Link to comment
Share on other sites

I'm not 100% sure the bat options are dictating the max available RAM; pretty confident the JRE takes what it wants.

The -Xmx option indicates maximum JVM heap size, which the JVM will not exceed. In PZ's case this isn't the whole truth since there's also native resource allocation going (which happens outside of the JVM heap) on account of the native graphics libraries and such.

Interestingly, giving the JRE that much ram can also massively decrease performance, because it has to care for it all.

PZ can be run on as little as 480 MB.

Allocating all RAM available isn't automatically terrible if it actually doesn't get used since the memory doesn't need to be swapped and big heap isn't more expensive to GC if only little of it is used. If it was used though, it'd probably lead to massive performance degradation because of the constant swapping and longer GC cycles. That said, too little is necessarily not good either since that forces the GC to be more aggressive. A safe middle ground somewhere around 2GB might be worth trying out.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...