Game stuttering issue

[ghost]

It seems like we've all tried just about everything to eliminate stuttering in Stalker. I think some of us felt that luajit/luabind being updated would fix this but it doesn't unfortunately. However, I feel I know the main cause.

Stalker does not appear to stream in assets properly. A good example of this is in a mod like Call of Chernobyl, which uses a modified Open Xray engine. After adding "-dbg" to the shortcut, and when in the game going to the menu and pressing "S" to bring up the debug spawner, try to spawn an NPC.

What will happen every single time is as soon as you enter the game, it will hang for a bit as it loads the NPC, before the NPC is fully configured. Try spawning multiple NPC's at once and you'll get a longer wait time followed by some stuttering at first as the various NPC's are brought online.

Apparently GSC does not know how to properly stream in assets, and if you think about the fact that new elements are brought online whenever the switch distance is hit and something new is coming online, which is often, that is often the same time the game begins stuttering.

As for a solution, I am a beginning programmer so this may not be best something suited to me, but I do know I would like to help where I can as I know Nitrocaster and Armada already have a ton of great work that they're doing. I think we should try and recruit some fresh talent to work on Open Xray. My best guess would be trying out people on gamedev.net

So basically, if we could properly stream assets into the game rather than loading the entire asset in all at once, I feel stuttering could be an issue of the past.

[ghost]

To add to this: I'm going to do a partial release of the code for "Radium" as a branch from Avotishin's branch of the repo. I am absolutely terrible with proper coding conventions, but I feel I have a lot of good stuff that should be added to Open Xray. So, once it is up, I hope you guys feel free to add it to the main repository after cleaning it up.

I would try a merge on my own, but due to the fact that I am not currently using the main branch, it would be pretty complicated.

[alexgdi]

We need to do quite a lot of work to organize a good multithreading...

[ghost]

I'm not talking about multithreading, I am talking about streaming assets. They have nothing to do with each other.

[CrossVR]

Stuttering was never really a problem for me, but that's probably because I installed Stalker on my SSD.

[TYoung86]

You say "I am a beginning programmer", and then you assert that "streaming" and "multithreading" have nothing to do with eachother... Perhaps you are unaware that streaming an asset will require dedicating a thread context to loading the asset?

You can confirm that disk utilization is the cause of the stutter by profiling your disk utilization and processor utilization. I don't know if streaming is the real problem.

Then you have to find out if the blocking call that's accessing the disk is halting a render thread, a physics thread, or (most likely) a Lua thread... or if it's just decompressing that causes a starvation of processor time... If it's IO blocking, you have to find out if you can continue working without blocking - you might not be able to do so reasonably...

My interest in OpenXRay is in passing at the moment, but it looks like a fun project. :+1:

[ghost]

I do admit that I fumbled with that, it wasn't until a new programmer came onto my mod team that he corrected me :P

I have not learned C++ in a normal way at all, so it is indeed best to take what I say with a grain of salt at times, though I still feel I may state my opinion at times since I did help start OpenXray ;)

However you are right, it may not be what I think it is. However even though I'm an amateur programmer at best, I do know a lot about the X-Ray engine due to the many years of modding I do.

Anyway, I have someone with a degree in computer science taking a look at the asset loading in the game, as I do suspect it has something to do with object loading and switch_distance. He will either be able to verify it or knock it down and try and solve stuttering in a different fashion. Regardless we will all benefit as he has agreed to make any improvements open-source.

Oh, and if you happen to be passing because you don't want to work with a novice, don't worry, I don't actively contribute here as I'm busy with a mod, and the rest of the people here all know what they're doing :) OpenXray could use as much help as possible, so if you change your mind I'm sure you could be a big help.

@Armada651 I run COP on an SSD as well, but unfortunately still experience stuttering. However, my mod has lots of extra assets to load and uses a higher switch_distance, so it's likely a lot more noticeable for me than others.

[tamlin-mike]

@Swartz27 Did you manage to get any info from your contact?

Meanwhile, I have what I think could be an interesting case. In the underground going to Pripyat, before the first "Press the button" nagging, in a debug build I have something like 2-4 FPS. Once the door is opened and we have moved past some threshold point into this next area, FPS goes back to pretty much release-build speeds!

I haven't run it under a profiler yet, so I don't know what it's about.

I'm also not at all convinced this is related to the frequent "hiccups" in STALKER, but it could be worth investigating. I have a save when the problem is in effect, so I can repro my case.

[ghost]

@tamlin-mike He ended up having trouble understanding Xray as he had never worked with a game engine before, so it didn't work out. However I have noticed that on the Shadow of Chernobyl Xray repo found at xp-dev, for a mod called NLC they have done quite a few things to help the process of asset loading, unloading, and streaming. Might be worth looking at.

My statement before where I said I think I know the cause was a bit arrogant of me. Upon further understanding of the engine, there are many, many things that it could be.

[Xottab-DUTY]

Duplicate of #62