What about Direct3D 11 and 12 api implementation ?!

[Postal86]

I am a new into this repository xray-1.6. I understood DX9 old one is implemented into X-Ray , as i checkes some indications are about DX10 but fully not sure if implemented normally. what about DX11 or DX12 i want contribute :). And on what level is Graphics API i mean with bugs and so forth.

[CrossVR]

DX10 and DX11 are already supported, I'm currently working on an OpenGL backend. The video backends are in need of cleaning, which I'd like to work on after OpenGL is implemented.

If you want to you can attempt a DX12 backend in your own fork of the repository, but it won't be easy. If you have anything that shows promise be sure to let us know.

[Postal86]

@Armada651 i have just downloaded OpenXRay Engine source i need some time to figure out , all of the architecture, but if u will help me to figure out in which part are DX9, DX10 and DX11 implementations , would be easy to follow trend and begin implementation of DX12. I know it wouldn't be easy but i have good knowledge of DX 10 and DX 11 api and rewriting for DX12 wouldn't be too much different for example Microsoft has collected as one from IA(Input Assembler) stage until OMStage(Output Merger) in PSO(Pipeline State Object) , in short i am familiar and ready to contribute but i need some direction. And last one can you tell me, are there any Agile or some code writing styles which i have to follow. Thank you.

[Xottab-DUTY]

Look here for coding conventions: https://github.com/OpenXRay/xray-16/tree/dev/doc/procedure

[CrossVR]

@Postal86 There are currently 5 graphics backends:

• xrRenderPC_R1: DX9 with static lighting
• xrRenderPC_R2: DX9 with dynamic lighting
• xrRenderPC_R3: DX10 with enhanced dynamic lighting
• xrRenderPC_R4: DX11 with enhanced dynamic lighting
• xrRenderPC_GL: OpenGL, still under development

You can find each of these as projects in the visual studio solution.

[nitrocaster]

And last one can you tell me, are there any Agile or some code writing styles which i have to follow.

Contribution requirements are on the front page (search Pull requests). Did you look there?

[Postal86]

@Armada651 Ok thank u i will fetch into.............

@nitrocaster no i didn't i will check it.

[Postal86]

@Armada651 @nitrocaster @Xottab-DUTY Can i build the whole project and run it too see how rendering works , but as i have read i needed some addons, i have downloaded it but where should i put it to build whole project and run it. Or project right now is not run able ?

[nitrocaster]

doc/howto/build.txt

[Postal86]

Setup:

• Install S.T.A.L.K.E.R Call of Pripyat
• Install patch 1.6.02 (only for russian locale, worldwide release should have it included):
  http://cop.stalker-game.ru/?page=patches#2
• Download and unpack archive with libraries
• Run xrbinprep.cmd to initialize new game binary directories and link default gamedata to OpenXRay's:
  $ xrbinprep.cmd "C:\Program Files (x86)\GSC World Publishing\S.T.A.L.K.E.R. - Call of Pripyat"
  Note that this script requires admin rights (in order to execute 'mklink'). Also make sure you pass a
  game installation directory to this script. Once done, you can find .xrbinup_xxx scripts in the reporitory root:
  use them later to install newly built binaries to the corresponding game binary directory.
• Now you can build the engine!

@nitrocaster - Install S.T.A.L.K.E.R Call of Pripyat . Do i need a game or what , without a game Engine won't run ?!

[nitrocaster]

Because GSC never intended to distribute X-Ray as the game engine, there's no 'pure' engine. What we have here is basically S.T.A.L.K.E.R Call of Pripyat source code without resources. So, to get working game, you need take the original game and put new binaries into it (in the specific way described in build.txt).

[Postal86]

@nitrocaster like the Crytek's CryEngine release was(Actually game source code was for public audience not CryEngine ), i guess same case we have got here. Also Unreal Engine 3 Epic Games released Level Editor without source code. but now UE 4 released with full of Engine Source code and u can do everything what u wish, but if u release commercial product u have to pay 5% royalty for each released product and per month i guess 15$ if engine is being used by the company during the development. :)

[ghost]

I wouldn't tackle DirectX12 or Vulkan unless you really know what you're doing. I'm still new to programming, and in my initial naivety I figured adding DX12 would be easy. That is definitely not the case, it's a whole new API, and I further embarrassed myself by announcing that we'd have DX12 on my mod page at the time :P

Honestly, something such as adding DX11 support to Clear Sky or Shadow of Chernobyl would be a lot easier, but still not simple if you're new to things.

[CrossVR]

It may be interesting to try and implement DX12 and Vulkan, but honestly I'm not sure how much of an advantage it would really bring. I think the DX11 backend already has plenty of opportunities for optimizations. Besides, most modern GPUs can already run Stalker at max settings, right?

This may be something I'll pick up as a learning experience once we've ported all the Stalker games and cleaned up the code base, but no promises.

[offizierkoma]

I'd personally go with Vulkan. DX12 wasn't made with anything other than Windows 10 and XONE in mind and Vulkan can help in taking advantage of multi-core processing and that's where I think Stalker needs improvements the most.

[peterclemenko]

Vulkan would help both Linux and rendering performance. Vulkan would be best.

[tamlin-mike]

I'm with @Swartz27 in "unless you really know what you're doing".
DX12 and Vulkan are pretty much "back to basics", to the same tune that assembler is to C. You manually have to create (even command) buffers (if anyone here is old enough to remember DX6 - this is better).
That said, Vulkan is the obvious choice to me. Even Intel (integrated gfx) is now included in Vulkan in Mesa3D. I don't know if they will bother with Windows driver(s), but fingers crossed.
DX12 would limit the renderer to Windows 10 (from now on seemingly simply called "Windows") only, and I for one would like to see portability more important - STALKER (the whole series) is too important a tangent in gaming (not the least from a historical perspective) to be locked in even more.

Disclaimer: I have only had a cursory look at Vulkan API, and have 0% experience with it.

[ghost]

I think what might be better than DX12 or Vulkan, is maybe a bunch of us working together to finish the OpenGL renderer, adding multiple feature levels, and then, in the future, see if it's feasible to port the OpenGL renderer to Vulkan, as there are tutorials, etc. on how to go about it.

[CrossVR]

I'm still planning to get back to working on the OpenGL renderer, I'm just catching up to a bunch of different projects at the moment.

I was hoping to have time again this month, but due to NSight being very unstable on my GPU right now I've been postponing it in favor of other projects.

[ghost]

I understand. I wasn't badmouthing you, I've been wanting to learn OpenGL as well, so it might be a fun side project for me if you don't mind getting help from a beginner.

[CrossVR]

So I've been told that glslang (Vulkan shader compiler) has added HLSL support, which means there's finally a cross-platform way to compile HLSL shaders. This makes it very interesting to write a Vulkan backend instead of an OpenGL one.

I will start an attempt at implementing a Vulkan backend, if that works out I will likely scrap the current OpenGL backend in favor of the Vulkan one.

[ghost]

Badass :) Also: I gave you admin rights. Now you can submit code directly rather than making pull requests.

[looterz]

@Armada651 Any updates on the vulkan backend? I'd be interested in helping where possible. Implementing Physically Based Rendering support is something else that would be nice to look into.

[CrossVR]

@looterz I'm still learning Vulkan and trying to determine what kind of structural changes need to be made to the renderer backend to accommodate it. Since Vulkan requires most of the work to be done up front, it will take longer than the OpenGL backend did to get a functional backend.

On PBR, while definitely interesting, you need to redesign the shaders and materials to fit that model. And that would likely make the scope unmanageable. It may be something we could do once the render backend is done and we actually have artists involved with the project.

[looterz]

@Armada651 Sounds good. I definitely agree PBR is something that is out of bounds until a suitable render pipeline is up that can be experimented with, but its worth mentioning that substance painter and some other toolsets have processes that will accept standard normal, diffuse, specular etc. maps and output PBR maps that can be easily tweaked, so that would hopefully cut down on alot of the work required to start playing with PBR support in the future.

[SC1040-TS2]

@Swartz27 or @Armada651, As a new user and outsider looking into this project, may I ask what variant of the OpenGL API was initially and/or currently being used to develop the still in-progress renderer? I'm assuming at least 4.0 or higher on this one, or at least 3.0 or higher given the engine's existing hardware support and the presumed will or desire to maintain at least some backwards compatibility given what the original gamut of hardware running DirectX 8 and 9-11 onwards was.

[Xottab-DUTY]

@Armada651 there's an OpenGL 4.6 standard, that supports SPIR-V, so with this we could continue to enhance existing OGL renderer.

If you want of course..

[SC1040-TS2]

@Xottab-DUTY Agreed, even though I am not actively contributing to the codebase. At least, as of yet, due to my lack of any real C++ knowledge, but desire to try and contribute anyway.

Back on topic, given this new standard having been released, incorporating it would certainly help enhance and modernize the existing OpenGL renderer, or what currently exists of it in terms of available code. It also helps provide some theoretical parity with Vulkan in some regard, as SPIR-V was a language initially developed and implemented for use in the more recently-developed and implemented rendering API standard.

Though, as was said earlier and paraphrased now, the ability to implement it requires some serious effort-focusing. Not only that, there is also the OpenGL version's hardware support to consider in an admittedly lesser respect given the current state of available PC hardware save for noticeably older machines or otherwise unsupported graphics card series.

[r-a-sattarov]

Try to look at this new render #1620