Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multi-threading #8

Open
ghost opened this issue Aug 29, 2014 · 13 comments
Open

Multi-threading #8

ghost opened this issue Aug 29, 2014 · 13 comments

Comments

@ghost
Copy link

ghost commented Aug 29, 2014

Any thoughts about making the project multi-threaded as well as possibly moving to a 64-bit exe?

@nitrocaster
Copy link
Member

Moving to 64-bit - almost no serious problems.

As for multithreading - I have no idea for now. First priority is to fix bugs (lots of them), move original libraries out of the repository, organize includes and subdivide xrGame into multiple modules.

@ghost
Copy link
Author

ghost commented Aug 30, 2014

I understand. Multithreading is a big project, I just thought I'd throw it out there since CS is single-core mostly.

@fagoatse
Copy link

But is that really a bottleneck on modern CPUs? I think majority of slowdowns come from a very unoptimized renderer. MT might be difficult to achieve since xray was mostly written with a monolithic design in mind.
@nitrocaster is there any chance of seeing SoC code @ github? I'm aware that there's a very active Russian project out there but it uses svn and all commits/docs seem to be written in Russian so unfortunately potential contributors are deterred. CoP is also said to follow, any news on that?

@andrew-boyarshin
Copy link

@fagoatse Rendering is always bottleneck in all games I've ever seen. SoC sources, as far as I remember, present at BitBucket, but I don't remember repo name. But username is "stalker".
@Swartz27 CS is not multithreaded - but it is not good - when we will complete all current tasks, we, I hope, will try to make it multicore and multithreaded.

@nitrocaster
Copy link
Member

@fagoatse Don't think, profile it.
As for 'very active Russian project', here are two public SoC repos:
1] https://xp-dev.com/sc/204486/HEAD
2] https://bitbucket.org/stalker/x-ray
I nave no plans to mess with old SoC code - there were too many changes in CS and any work on SoC code is just wasting time.

Also there's a public CS repo: https://bitbucket.org/stalker/clearsky
But I don't see any serious work there (just reckless mega-commits without any plans)
(another thing is that I don't like bitbucket :) )
In fact, I haven't seen any good docs about x-ray sources.

@nitrocaster
Copy link
Member

  • Rendering is always bottleneck in all games I've ever seen.

You'r wrong. Stalker has pretty complicated AI but pretty simple r1 renderer that runs so fast that GSC released a special patch that slows it down (to prevent some artefacts and GPU overheating).
Another good example is Minecraft - really simple renderer but very complicated game logics.

@andrew-boyarshin
Copy link

@nitrocaster because nobody wants to dig deep in code, that was written in 2003-2004... :) And C++ is much harder and bigger than modern langs, like C# or Java, so, there aren't many coders, who understand XRay sources.
I also think, that SoC is too old and featureless platform for editing and modding.

@andrew-boyarshin
Copy link

@nitrocaster

You'r wrong.

I don't think so. S.T.A.L.K.E.R. has r3 and r4 - they aren't so fast. I'm not talking about r1 - because it is really simple. Rendering on r3 is much more slow than on r1. AI runs fast enough - thanks to LuaJIT.
Minecraft:

  1. Java(VM and other "cookies")
  2. Shitcode(written by one person at the beginning of dev)
  3. Huge number of additional libs(LWJGL and other 4+ libs)
  4. Renderer is not simple, as it is highly customizable.

@nitrocaster
Copy link
Member

    1. Renderer is not simple, as it is highly customizable.

'Simple' means 'simple for hardware', that's it.

@fagoatse
Copy link

@nitrocaster I'll try to hook up https://github.com/CyberShadow/verysleepy and do some profiling when I find some time but without proper docs and actual comments its difficult to navigate through such a large codebase. At this point cleaning up and organizing things is more important than worrying about threading and such. And then again there are those rumours about CoP source getting leaked which might be even a better codebase to work on. However, working on 3 versions of the same engine seems like an even bigger waste of time and resources. The main goal should be to turn xray into equivalent of ioquake and loading SoC, CS and CoP as assets.

@nitrocaster
Copy link
Member

  • At this point cleaning up and organizing things is more important than worrying about threading and such.

Exactly. Complicated and long-term modifications will be easier once we have organized codebase.

  • And then again there are those rumours about CoP source getting leaked which might be even a better codebase to work on.

Rumours. Loxotron (a user that published leaked sources) wrote (literally) "CoP sources will be later on".

  • The main goal should be to turn xray into equivalent of ioquake and loading SoC, CS and CoP as assets.

Honestly, I planned to fix bugs and tweak multiplayer, but ... whatever :) Another reasonable task is to get editors compiled completely in MSVC.

@nitrocaster
Copy link
Member

Also, for profiling: you can use Visual Studio profiler.

@ghost
Copy link
Author

ghost commented Aug 30, 2014

"Rumours. Loxotron (a user that published leaked sources) wrote (literally) "CoP sources will be later on"."

I sent him a PM about the COP source and he told me that his NDA with GSC ends in the Fall and he plans on an October release most likely.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants