Jump to content

Thurs…weather…shaders….chat!


nasKo

Recommended Posts

holdup-712x423.png

 

Welcome to this week’s Thursdoid! We’re a bit light on the team this week as a few of us (including, as you can probably guess, the developer in charge of Thursdoid punnage) are having a well deserved holiday after the exhausting and mega stressful vehicle push for so many months finally came to an end, and like buses several of those holidays coincidentally happened to come at once, but still a few things to report.

Weather Build Update

We’ve just updated the weather branch. The main addition is the first version of our overhauled multiplayer chat system developed by Stas at General Arcade. The new chat is a bit fancier and more functional and more in line of what you’d expect on an MMO or similar types of games. You can activate the window to chat by pressing T or Enter. Let us know how you get on with it and if there are any problems.

Various fixes include reintroducing the low lighting mode, and an option for disabling the new building hiding system, which will provide better performance on low end machines (more on this subject in a moment), removed the weird sound echoes, various Linux compatibility / java fixes, fixed multiplayer zombie attacking / defending issues, and many more. We’ll try to get you a complete change-list soon.

Work continues apace with animations, nothing flashy to show or talk about, but many fixes have been made to the tool and Martin the animator now has access to regular builds to help integrating all the anims. Steve at BitBaboon nears completion of the new build system overhaul, which will vastly improve our internal organisation of builds, and should allow us quicker testing and releasing of builds. With this we’re making wider changes to the team organisation to help us deal with the bigger team size and the various irons we have in fires.

Shaders & Compatibility

We’ve had a small number of people reporting that cars are invisible on their low end machines. This is due to the fact that the way the vehicles are rendered require shaders to overlay damage and other effects, so cards that are unable to use shaders, as with the 3D characters which use GPU skinning, will not be able to render the vehicles.

We’ve fought for many years to keep our minimum specs where they are, wanting to keep our potato running Zomboiders in the game for as long as possible. However, as the years progress, the numbers dwindle as more people upgrade, and at this point we’re talking about an extreme minority of PCs, bottom end Intel laptops any of them close to or over a decade old, at least in terms of technology, and constituting less than 1% of all our customers – It’s gotten to the point where retaining compatibility with machines mostly over a decade old is starting to hamper development in several ways.

1) For example to add support for vehicles for this minority of machines, including testing and bug-fixing would take a substantial amount of development time, which at this stage could be spent working on the features, optimisations and improvements the vast majority of our customers would benefit from and that would take us toward the fabled 1.0.

2) There are a whole host of avenues for optimisation that we’ve for a long time written off because they would end up raising the minimum spec by requiring shaders to work and would be too fundamental to switch off. Since the game and simulation have become massively complex at this point, optimisation is becoming ever more important. Vehicles at one stage ran so badly on top end machines that we simply had to spend significant time doing extreme and very disruptive optimisation work, and the game still doesn’t run adequately in built up areas on machines that should on the face of it be able to handle it.

However the available routes for optimisation are becoming extremely sparse–there’s only so much blood you can wring out of a stone and we’ve shaved practically every millisecond we can from the game’s frame time, so we really need new directions to be able to explore to keep the game running well particularly when features such as Louisville, the new animations (which will bring performance benefits and pressures, and it’s unclear what the net result will be) and of course the NPCs go into the game.

The way the rendering system works with the lighting, shading and isometric perspective is hugely costly and it’s difficult to see how it can possibly be improved having no guaranteed access to literally any of the rendering advancements developed in the past 13 years.

Having guaranteed shader support will open up many optimisation opportunities in the future, our rendering being far and away the biggest bottleneck, and there comes a point where it becomes unfair to the huge majority of our customer-base not to exploit these. While it’s frustrating the game not running well on an old laptop, it’s certainly much worse for it not to run well on a top of the range gaming PC and that’s something we have more responsibility to fix and avoid in future.

So while we understand this decision will upset a few of you (though it’s a decision we hope you appreciate we did not take lightly, and resisted as long as humanly possible to give as many the opportunity to upgrade as possible), we hope that the few affected by this understand why we’ve come to this decision. In the meantime, build 38 will always be available via the Steam betas, and there are many affordable old laptops with GPUs that have the requisite shader support, so hopefully we’ll see you back in the new builds before long.

This week’s tense disagreement from QwencGames. A general list of stuff added to PZ, and vids of features being worked on, is kept here – so you don’t have to plough through endless dev blogs for info. The Centralized Block of Italicised Text would like to direct your attention to the PZ Wiki should you feel like editing or amending something, and the PZ Mailing List that can send blogs like this and patch notes direct to your mailbox. We also live on Twitter right hereOur Discord is open for chat and hijinks too.

Link to comment
Share on other sites

I am glad you've made the decision to leave away optimization for decade old PCs. It seems that it has used alot of you guy's time to just try and optimize every single thing possible just so a few users can run the game. It should not be a problem to just save up some money and get with the times. With that out of the way, it seems that more work can be done towards other stuff like anims etc... Great job guys.

Edited by Capt.Motty
Link to comment
Share on other sites

I also like to point that there's an option to disable vehicles in sandbox option, so can't you theoretically play on the newer builds with vehicles disabled? At least until something else break at least :).

 

Also, what Intel are you taking about? I suspect nothing further than the 4th generation, i.e. before the HD Graphics (Intel GMA and below), as new intel GPUs, including the ones included in modern lowest-end atoms should be more than capable of handling shaders, and even some more modern GMA should handle them, too. I guess a specified shader model version support is required, if so then which one 4.0? 3.0?

 

I wouldn't stretch too much too, as you already are doing a great service – we live in times where even 32-bit support and things like DX9 are being phased out (in addition to XP being long unsupported) and AFAIK you still support it all, which is good service for the old machines.

 

You also mentioned Linux support improvements, and I'd like to remind to those 1% folks still running a game, that I generally have a good experience with Linux giving second life to the retro machines, especially those with Intel graphics as the intel drivers for Linux are even better than Windows. Heck, maybe I'll even install Zomboid on my wife's old Asus EEE PC 901 to see how it works there. It doesn't even have a 64-bit CPU and single core would bottleneck it the most I guess, but if shaders will work there, then it's really nothing to worry about.

 

Speaking of optimization, I have recently wondered, since the game is based on LUA, I haven't check what executable it currently use, but have you tried LuaJIT compiler? Unfortunately it's fallen behind in development after the mastermind behind it didn't have time for the project and currently only support Lua 5.1, but it is still one of the suggested way to optimize the game for Catalysm CDDA on low end machines, so unless it's being used already, having it an option could help boosting a little more performance for the lowest-end folks here as well? I'll take a look at it.

Link to comment
Share on other sites

The version of OpenGL is 2.1. So, quite old by today's standards. Not sure on the Shader Model. I think that'd be 2.0 from a quick search.

 

HD 2000 and below. Graphics Media Accelerator,  and Express. In the case of GMA, their drivers will report support for certain shaders and functions but fail silently when called. Note that Intel still manufactures certain i3s and Pentiums with the unnumbered HD Graphics variant.

 

Radeons are fine so long as you're on an OS that has published drivers (Generally anything under the 6xxx series is discontinued now). That is, if AMD discontinued support in Vista, you probably can't get the same functionality in Windows 10 (or a more generic driver may fake it with software rendering). It's probably the same with nVidia. I don't believe we've encountered issues with nVidia aside from two updates over the years that'd cause the game to crash on launch.

 

The version of Lua PZ uses is called Khalua2. It's built purely in Java. I assume the only way to "optimize"  it would be to port the heavier stuff back into Java, but then something convoluted would have to be figured out to support modding those elements. Moving to something like JavaLua could also be an option, but I suspect it'd require quite a rewrite. (Khalua isn't true Lua and therefore may have some "gotchas". JavaLua requires a bunch of boilerplate for every exposed class and function that Khalua doesn't).

Link to comment
Share on other sites

6 hours ago, Faalagorn said:

I'd like to remind to those 1% folks still running a game, that I generally have a good experience with Linux giving second life to the retro machines, especially those with Intel graphics as the intel drivers for Linux are even better than Windows.

I second this. My normal PZ machine is a dual boot windows 7 x64 and Debian Linux (Stretch), with a Intel HD 3000.

For ages I was running PZ exclusively in the windows OS..only the 32 bit would work, and performance was meh: no shaders, most settings turned down, and performance still dragged badly.

The Linux OS has none of the issues windows had with PZ. Smooth performance with shaders and all settings at default.

The difference is really night and day.

 

1 hour ago, EnigmaGrey said:

The version of Lua PZ uses is called Khalua2. It's built purely in Java. I assume the only way to "optimize"  it would be to port the heavier stuff back into Java, but then something convoluted would have to be figured out to support modding those elements. 

I can see tons of ways of how to optimize simply by looking at the way the lua was written. Less global namespace usage is often a big help with tweaking lua for performance. And I'm not just talking about sticking variables and functions in the global namespace, but how often its accessed.

For example if you're running a function that gets triggered with the OnPlayerUpdate event, and it has to use a 'ipairs' loop in it...well every time a player updates its searching the global namespace for a variable/function called 'ipairs', then runs it.  Adding to the top of the file:

local ipairs = ipairs

will pull ipairs into the local namespace, thus everytime our OnPlayerUpdate event triggers, it no longer has to search the massively polluted global namespace, it has a quicker shortcut to the function. Its always advised to pull functions and tables/modules into the local namespace when performance optimizing lua, but as you said:

1 hour ago, EnigmaGrey said:

Khalua isn't true Lua and therefore may have some "gotchas".

So mileage may vary, but I suspect conforming to a more standard lua coding style would have a noticeable effect, especially for the more cpu cycle intensive files and functions.

 

Link to comment
Share on other sites

3 hours ago, lemmy101 said:

it's completely overshadowed by the lua->java JNI calls and even moreso rendering.

On this, I have no doubt lol.

The pulling into local namespace works not only for lua defined variables, tables and functions (including built-in's such as ipairs) but also for java exposed functions and classes. I ran some tests earlier to confirm since I wasn't 100% sure on the internal workings of kahlua (mind you, these are not accurate tests done through a profile, but a OnGameBoot event):

 

1000000 table.insert calls, using 'table' as a global module (Time taken: 3644ms)

1000000 table.insert calls, using 'table' as a local module (Time taken: 3467ms)

ipairs on a 1000000 value table, using 'ipairs' as a global function (Time taken: 797ms)

ipairs on a 1000000 value table, using 'ipairs' as a local function (Time taken: 705ms)

 

The built-in function and modules saw a minor performance improvement, however when using the same trick on a java exposed function:

1000000 ZombRand() calls, global (Time taken: 1976ms)

1000000 ZombRand() calls, local (Time taken: 1612ms)

10000 ZombRand() calls, global (Time taken: 193ms)

10000 ZombRand() calls, local (Time taken: 81ms)

 

I'm sure other areas are probably more in need of optimizing, and this trick would probably need to implemented 'across the board' to have a noticeable effect...not a easy task. But that drop from 193 to 81ms for 10000 ZombRand calls is defiantly nothing to sneeze at.

I've actually spent the last week and a half redoing ORGM for optimization using this method (and other tricks)

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...