[Official] Technical Engine Development faq / blog

[vadiolive]

Q: how bad/god effect to X-rebirth if i call Windows API to CLEAN Workspace in memory each 20s?

[timon37]

Sometimes when I turn around things get "re-painted" and sometimes when I use highways or in other situations I notice hiccups, which I assume it is the game loading resources.

Actually surprisingly often the hiccups aren't due to asset loading, but scripts/AI, pathing, or other universe management code.
Loading and rendering assets is quite well decoupled so it usually doesn't stall but of course then you get popping/repainting.

* Can you guys "make" the game use more memory when available to pre-cache stuff that will be used later to avoid hiccups at most times or this is unavoidable?

In general yes that is a good idea, and the game isn't doing that very well at the moment. It's mostly a case of do you "improve this" or "fix that other broken thing".
Besides the OS normally caches the file system so technically all of the game files should already be in memory, and when we read them it's just mem-copy/decompress.

Q: how bad/god effect to X-rebirth if i call Windows API to CLEAN Workspace in memory each 20s?

Honestly I have no idea what that does, but I don't think there's much good it could do. If you're running low on memory your best bet is making sure less stuff is running in the background, maybe doing that clean once at the beginning and then just play without alt+tabbing out.

[edqe]

Could you tell us a bit what tools you are using; gcc/clang, git, etc. ?
I have read that some developers prefers using clang during the development process because of faster compiling times but uses gcc for production code.

I can imagine that Linux game development tools are still far behind Windows because Windows' 30 year head start. What kind of tools Linux needs most and has things changed better since Valve jumped to support Linux gaming?

[timon37]

@edqe (post above)

We use svn, though I locally use git. Right now gcc, but actually thanks for reminding me about trying clang;p

On the subject of compilation time, it's horrible... C++ is horrible... and it'll never get any better. I had to change my habits since I'm used to about 2-7 sec compilation-link-launch-start_testing time.

For general programming gnu/linux is much better, build tools and general methods for the development process are (most of the time) simply superior by design. VS project configuration is... beyond words. When I started with opengl on windows I simply said to myself "nope, not doin' that" and used cmake, which helped me a lot:)

But of course the main thing is graphics debugging, there it gets tricky, and actually I don't entirely know yet. I have really high hopes for vogl which I couldn't compile on windows and *spoiler alert* I'm not yet rendering on linux:( But I have vogl compiled on linux so it's prepared for the glorious day;)

Up to now for opengl debugging I've mostly used gdebugger/codexl, that mostly worked on linux same as on windows, which is so-so, crashes often, fails to display many things etc.
Intel's gpa: is kinda good, but not great, in general it's been quite helpful for DX9 debugging.
Apitrace: didn't use it much.
Gpu perfstudio: also hasn't been the most useful though not useless, used it mostly for debugging the command stream.
Finally as painful as it is, I have to admit nvidia nsight is currently the best for profiling or debugging a frame when there aren't any basic opengl errors.
There's a version for eclipse and linux but I'm guessing it's only for CUDA.

I'll be able to say more once things start rendering on linux;)

P.S. I also have really high hopes for valgrind, mostly for performance profiling ironically;p

[ezra-r]

@timon37 about the linux compiling and linux version of Rebirth, I'd love to have any kind of updates in here too..

Also, why don't you guys just "STICKY THIS THREAD" and the "Behind the Scenes" thread so it is not going up and down and people know where to look for specific insight info instead of gluing the two threads together which imo would just confuse things more, at least I see the behind the scenes thing as a graphics insight, and this is clearly programming insight.

Really enjoying this thread!

[edqe]

@timon37: Thanks for the information.

As you mentioned the GPU debugging is one of the biggest problems at the moment. Good to see Valve has started to work tackle that problem as well.

How do you see Linux GPU driver situation at the moment? Worries ahead?

Since containers (systemd-nspawn, Docker, ...) are quite hot topic in Linux field at the moment I was wondering if you are using them on your development work. I guess Valve SDK supports/requires some sort of sandboxing like chroot at least.

It would be great to hear time to time how things are progressing. Exciting times

Edit: Oh, for some reason I misread your post and you had mentioned VOGL already. Comments about it removed

[Sam L.R. Griffiths]

@timon: With all due respect, I have developed on both *NIX and Windows and IMO although EMACS is probably still my favourite text editor (and IDE for some programming languages) I must bow to the superiority of the Visual Studio IDE for C/C++/C# programming. I would say though that IMO Microsoft's IDE (and Office Tools) has got worse as it got newer, my favourite version of Visual Studio has to be either 6 or .NET 2003 - the latter versions are too quirky in some respects IMO.

In my early days as a software engineer, I heavily relied upon real-time debugging but over the years I have come to realise there is no real substitute for using runtime logging to track down issues with modern software. The latter has a lower impact on runtime timing issues and real-time debugging often can cause problems tracking down the root cause of issues IME (even if the software is designed/written appropriately).

@CBJ: My personal point was primarily to do with being unable to script AI to respond to key/controller presses (c/f MCSI scripting in the X-Trilogy) - may be possible with certain modder developed libraries but it should be part of the vanilla capability IMO. The other side of it is being able to do custom menu screens for input, perhaps just for in-game configuration of mods/scripts.

I actually agree with your approach of using the XML based scripting language, but IMO we are missing key functionality from it (or sufficient documentation for how LUA is to be used by modders in tandem with it).

[rboerdijk]

@timon: With all due respect, I have developed on both *NIX and Windows and IMO although EMACS is probably still my favourite text editor (and IDE for some programming languages) I must bow to the superiority of the Visual Studio IDE for C/C++/C# programming. I would say though that IMO Microsoft's IDE (and Office Tools) has got worse as it got newer, my favourite version of Visual Studio has to be either 6 or .NET 2003 - the latter versions are too quirky in some respects IMO.

Concerning Timons comment on the msvc-"project configuration"-dialog, I do have to agree with him, it is kind of annoying - at least for a project our size. We have 11 configurations (debug, release, master, master-profile, viewer, ... ) and each of those in both 32 bit and 64 bit. It's way too easy to mess up something. I personally like msvc, especially the debugger is quite good. Linux guys just like screens of scrolling text, Timon is no different

I do have to say that I like the newer Xcode versions quite a lot, though.

[CBJ]

My personal point was primarily to do with being unable to script AI to respond to key/controller presses (c/f MCSI scripting in the X-Trilogy) - may be possible with certain modder developed libraries but it should be part of the vanilla capability IMO. The other side of it is being able to do custom menu screens for input, perhaps just for in-game configuration of mods/scripts.

Those are jobs that would, and should, be done using the UI-related languages and other configuration tools, i.e. Lua and the XML files used to define controls, because they lie outside the domains of the domain-specific XML languages. Cross-domain "leakage" is a really great way to destroy the advantages brought to the table by using domain-specific languages in the first place!

I actually agree with your approach of using the XML based scripting language, but IMO we are missing key functionality from it (or sufficient documentation for how LUA is to be used by modders in tandem with it).

We are well aware that the ability for modders to change or add to the UI easily via Lua and Anark is a weakness of the modding capability of the game at the moment. However, the solution to this is not to work around it by adding UI modding capability to some other part of the system; clearly what is needed is better accessibility to the existing Lua and Anark tools, so that modders can work on it in the same way that our own UI developers do it.

[hourheroyes]

Where'd Matthias get that sweater from last year's release photo? And will one be made available on the Egosoft store?

edit: referencing this post http://forum.egosoft.com/viewtopic.php? ... sc&start=0

[rboerdijk]

Sometimes when I turn around things get "re-painted" and sometimes when I use highways or in other situations I notice hiccups, which I assume it is the game loading resources.

* Can you guys "make" the game use more memory when available to pre-cache stuff that will be used later to avoid hiccups at most times or this is unavoidable?

Asset-loading runs on a separate thread and is unlikely to cause framerate-hickups. Occasionally people here in the office people come to me after they observed some stuttering with the same suspicion "it's probably asset loading" - and my usual reply is "no, it's not".

If an object isn't loaded in time, you might see it popping (the moment it is loaded) - but generally asset-loading will not cause framerate hickups.

In 3.0 rc3 we fixed several causes of jitter. As an example, we had an expensive physics-update in highways (ironically introduced in 3.0 rc 1 - to fix a bug related to mass-traffic), which we replaced by a much cheaper partial update.

[dmk]

Small jitter (0.1 sec) still there, when new zone appears, while skunk in highway, it's enough to bump to some slow traffic.

question is: when gate view becomes beautiful as rest of game?
i.e. like portal(see though) and without "black" 1 sec after passing (it's enough to bump on boost to some "invisible for 1 sec" ship outside of the gate)

i.e. I understand performance issues, but they could be handled using same way as was in gothic 1 with caves, while you X meters away only static texture is rendered, less - it's becomes transparently and appears world behind it.
for simplicity sake any weapon fire should not pass though gate (but may cause water like splash ( http://madebyevan.com/webgl-water/ ).

try to ride balor or lepton from omicron to albion though TO space and watch for gates .

[BigBANGtheory]

Egosoft obviously receives an awful lot of feedback and requests for new features and changes (in an often very unorganised way), I'm sure the development team have their own opinions on this also... How do you decide which ones to take forward vs. which ones to shelve?

I guess from a technical point of view you have to make some kind of assessment as to how many man hours such a change will consume and if it will incur a performance hit after some kind of shortlist..

and thanks for the earlier answers btw

[Meme Turtle]

Egosoft obviously receives an awful lot of feedback and requests for new features and changes (in an often very unorganised way), I'm sure the development team have their own opinions on this also... How do you decide which ones to take forward vs. which ones to shelve?

I guess from a technical point of view you have to make some kind of assessment as to how many man hours such a change will consume and if it will incur a performance hit after some kind of shortlist..

and thanks for the earlier answers btw

I would like to hear about Egosoft's roadmap or development plan as well. It'd be a nice idea to understand how players can influence developers' decisions. Some of the new features in 3.0(crafting for example) are though useful and add to the gameplay level are not as important as some really critical fixes/features.

What I really want to see is an organized sticky thread with priority sorted list of new features/extensions based on players' feedback.

[BigBANGtheory]

Egosoft obviously receives an awful lot of feedback and requests for new features and changes (in an often very unorganised way), I'm sure the development team have their own opinions on this also... How do you decide which ones to take forward vs. which ones to shelve?

I guess from a technical point of view you have to make some kind of assessment as to how many man hours such a change will consume and if it will incur a performance hit after some kind of shortlist..

and thanks for the earlier answers btw

I would like to hear about Egosoft's roadmap or development plan as well. It'd be a nice idea to understand how players can influence developers' decisions. Some of the new features in 3.0(crafting for example) are though useful and add to the gameplay level are not as important as some really critical fixes/features.

What I really want to see is an organized sticky thread with priority sorted list of new features/extensions based on players' feedback.

I'd like that too (as would most I'm sure) though in fairness I think the purpose of this thread wasn't to go there so I was asking more about the how i.e. the decision making process rather than the what if that makes sense. Somethings are tough to do, others totally impractical someone somewhere along the way has to say what is technically achievable with the game engine with a good degree of success.

There is no point for example the community raging on about a feature lets say planet landing for arguments sake if it is wholly impractical with the current engine or would require 1000's of development hrs to achieve.

btw on a separate matter there is quite a bit of press emerging on dx12 no doubt ahead of the Win10 release, looks like it has some functions potentially very useful to a game like XR (more so than dx11) with the user-mode GPU driver being multi-threaded and taking on more of the work:
http://blogs.msdn.com/b/directx/archive ... tx-12.aspx

[rboerdijk]

btw on a separate matter there is quite a bit of press emerging on dx12 no doubt ahead of the Win10 release, looks like it has some functions potentially very useful to a game like XR (more so than dx11) with the user-mode GPU driver being multi-threaded and taking on more of the work:
http://blogs.msdn.com/b/directx/archive ... tx-12.aspx

As you guys know we are aiming for multiplatform support, specifically windows, linux and osx. In that context DirectX is not the obvious choice, especially in the context that a rewrite from dx9 to dx12 would be quite an effort and with our existing effort on openGL we already make a jump to a more recent graphics API.

[Tamina]

btw on a separate matter there is quite a bit of press emerging on dx12 no doubt ahead of the Win10 release, looks like it has some functions potentially very useful to a game like XR (more so than dx11) with the user-mode GPU driver being multi-threaded and taking on more of the work:
http://blogs.msdn.com/b/directx/archive ... tx-12.aspx

As you guys know we are aiming for multiplatform support, specifically windows, linux and osx. In that context DirectX is not the obvious choice, especially in the context that a rewrite from dx9 to dx12 would be quite an effort and with our existing effort on openGL we already make a jump to a more recent graphics API.

That is interesting.
While OpenGL is platform independant that doesn't mean the whole other code is.
Are you aiming for a single general platform independant version for XR?
So Windows version is going to run with OpenGL 4.5?

While DirectX is bundled to the operating system, OpenGL isn't and that would be great.

PS: Happy Holidays!!!!

[edqe]

btw on a separate matter there is quite a bit of press emerging on dx12 no doubt ahead of the Win10 release, looks like it has some functions potentially very useful to a game like XR (more so than dx11) with the user-mode GPU driver being multi-threaded and taking on more of the work:
http://blogs.msdn.com/b/directx/archive ... tx-12.aspx

As you guys know we are aiming for multiplatform support, specifically windows, linux and osx. In that context DirectX is not the obvious choice, especially in the context that a rewrite from dx9 to dx12 would be quite an effort and with our existing effort on openGL we already make a jump to a more recent graphics API.

It is great to see that Khronos started finally push OpenGL forward on gaming side with OpenGL NG. As far as I know OpenGL 4 series stays in use on industry (CAD, etc.)

https://www.khronos.org/news/press/khro ... -ecosystem

timon37 said he is going to talk about this more later but I guess OpenGL 3.3 should be enough for XR for now since it is more or less par with D3D9(?)

So Windows version is going to run with OpenGL 4.5?

OpenGL 4.5 version would be great but as far as I know latest OSX supports OpenGL 4.3 and only NVIDIA has OpenGL 4.5 support on their beta drivers.

Most of the Linux games uses still OpenGL 3.3. Metro Redux -versions are rare ones that uses some OpenGL 4.x version.

[BigBANGtheory]

btw on a separate matter there is quite a bit of press emerging on dx12 no doubt ahead of the Win10 release, looks like it has some functions potentially very useful to a game like XR (more so than dx11) with the user-mode GPU driver being multi-threaded and taking on more of the work:
http://blogs.msdn.com/b/directx/archive ... tx-12.aspx

As you guys know we are aiming for multiplatform support, specifically windows, linux and osx. In that context DirectX is not the obvious choice, especially in the context that a rewrite from dx9 to dx12 would be quite an effort and with our existing effort on openGL we already make a jump to a more recent graphics API.

I have no allegiance or axe to grind with dx it was the multi-threading that caught my interest and the resulting frame render times.

If MS restrict dx12 to Win10 that's sod all use to most PC gamers/devs for the next 4yrs anyhow. If you are looking at OpenGL can I put in a vote for multi-window rendering and that you go for one of the 'multithreading-friendly' versions

If you are going to invest the time in upgrading the engine to a new API you surely won't want to pick one that bottlenecks performance i.e. wait for OpenGL NG and do it once?

[timon37]

Disclaimer: anything that relates to future events or even "we're doing a/b" isn't set in stone, in programming failure isn't just an option... it's a monster looming over your shoulder getting a millimetre closer with each passing day;p

We choose to go the prudent way of first making an opengl renderer on windows alongside dx9. Then after it is Super-Awesome, start doing the actual porting to other systems. The current plan slightly changed and we're skipping the "Super-Awesome" requirement.

I started writing opengl about 6 months ago, it went as usual which is to say "quite a bit slower than I'd like":(
Unfortunately it's still unfinished, but there isn't that much left and some of the todo things aren't strictly necessary.
I foolishly didn't make screenshots from the start so I can't show you how it evolved from the "spinning red-green-blue triangle", through a kaleidoscope of random triangles, then some recognizable but wholly pink shapes, to something actually looking like the game if you stay in the right parts of the universe. But I made screenshots of some accidental results, bugs and/or purposeful debug code. It's amazing how many different pictures are possible with the exact same assets and scene setup.

We're sticking to the core-profile with version 3.x (which is roughly equivalent to dx10) as the "minimum requirement", mainly because of the open-source drivers on linux. That doesn't mean that we won't be using anything newer, it just means that we won't "require" it for the game to run.
As Roger mentioned because we have a very small team the plan is to completely transition to opengl also on windows. Once that's done we can start to more seriously use the new features and completely phase out the dx9 renderer.
I'll make a separate post about ogl/dx9-12, the difference between "using" and "seriously using" stuff, and why dx9 is a Schrödinger's cat that both is and isn't a problem at the same time;)

Whether we'll actually release X Rebirth with opengl on windows is an open question which depends on a bunch of factors. But it almost definitely won't happen before the linux/mac release.

As I hinted already the main good news is that I already started working on actual linux code. It compiles, then executes and then it is very quickly executed by the system with an "Aborted (core dumped)" message.
Of course I can't give any estimates on when it'll be ready for a public beta, but at least I can honestly say it's "actual-physical-work in progress directly on porting";)
Hmm now that I think about it based one the tone of this thread you probably expected me to say it'll be ready in month? Ehm sorry about that, I have a talent for softly but surely misimplying stuff.

While OpenGL is platform independant that doesn't mean the whole other code is.
Are you aiming for a single general platform independant version for XR?

Well of course it's currently impossible to create a "single binary file" that runs on everything.
So what happens is the same source code gets compiled for each platform separately and when doing that there are parts that get compiled only for certain platforms, e.g. windows specific code for handling mouse input or window resizing.
Now the funny thing is no one ever said you can't use directx on linux... http://www.phoronix.com/scan.php?page=n ... px=MTgxNzU.
So the question of using APIs like directx/opengl, xaudio/openal, sdl2/winapi/x11 is actually separate from the question of "am I compiling for windows or gnu/linux". It just tends to correlate very strongly.
Bah no one said you couldn't use both at the same time, initially that's what I did and I had rebirth create two windows one rendering the game with directx and the other rendering a test-triangle with opengl.
We even joked that we should just release that and say "we're now rendering with opengl";p