
Cryengine Source Code - TiccyRobby
https://github.com/CRYTEK/CRYENGINE/
======
Nican
This is on the front page again. Please take some time to read this wonderful
function:
[https://github.com/CRYTEK/CRYENGINE/blob/release/Code/CryEng...](https://github.com/CRYTEK/CRYENGINE/blob/release/Code/CryEngine/CryPhysics/livingentity.cpp#L1300)

EDIT: That whole function is a minefield. Just taking a quick look:

* 814 lines of code

* goto inside 3 nested for-loops

* macros

* commented out code

* new/delete, with no RAII

* thread specific variables and locks (?)

~~~
gentleman11
800 lines long. The movement component class in ue4 is about 10k lines. Why do
game engines separate their code so much less than in other software?

~~~
Trasmatta
Here's a good article from John Carmack on why that can be a good approach in
game development: [http://number-
none.com/blow/john_carmack_on_inlined_code.htm...](http://number-
none.com/blow/john_carmack_on_inlined_code.html)

I feel like this Cryengine example may be a bad example of that, though.

~~~
smaddox
Not just in game development. If you have a function that is only called once,
it shouldn't be a function yet. Make it a function when you have a second or
third use for it. Then, and only then, you will know what the parameters
should be.

~~~
oever
I disagree. Splitting a function up can help with readability and testability.
The parent function becomes shorter and the child function can have a
descriptive name. The parameters to a function are the fields that are needed
for the function to perform its function.

~~~
naikrovek
Function calls have an overhead, and if the function is only used once it
makes no sense to break it out.

It also makes no sense to have a rule on the maximum number of lines for a
function. These rules are often created by people who don't write software
that needs to have high performance.

~~~
kryptiskt
A function that is called once will always be inlined. Trust the compiler.

~~~
MauranKilom
> A function that is called once will always be inlined.

That is objectively false. Even though I agree with the spirit. For starters,
unoptimized builds won't have that. Second, exceptions tend to inhibit
inlining. Compare [https://godbolt.org/z/c8Jayf](https://godbolt.org/z/c8Jayf)
with [https://godbolt.org/z/Uoo2YA](https://godbolt.org/z/Uoo2YA). Third, it's
easy enough to push one of the heuristics used for inlining high enough in the
wrong direction (e.g. function size). I recommend the clang optimizer view on
godbolt.

Also note that it can be hard for a compiler to prove that a function is not
used outside the current translation unit (although anonymous namespaces help
with that). Number of calls is only one of the heuristics for inlining though
anyway.

------
ebg13
Many of the filed issues are "X not work" and not very interesting, but this
one...this one is a real gem.
[https://github.com/CRYTEK/CRYENGINE/issues/763](https://github.com/CRYTEK/CRYENGINE/issues/763)

~~~
duncan-donuts
I’m gonna go with this is a feature not a bug

------
misnome
Would it be an overreaction to not want to touch this licence with a barge
pole?

Even ignoring the “We may change this licence at any time and it applies to
you” parts, there seem to be serious restriction on usage and basically have
to ask them to do _anything_ beforehand.

Maybe it makes sense if you are already in a project that is using this
Licenced? Is this intended as a general engine licence rather than viewing the
source code?

~~~
_bxg1
Unreal shares its source purely for the sake of people who already license it
and need to know how something works/fix something/customize something.
Wouldn't be surprised if the same is true here.

------
gentleman11
I considered using cryengine recently but there was an almost total lack of
learning resources: I could barely find a tutorial that was newer than 5
years, especially one that involved it’s c++ APIs.

I suspect that lumberyards greatest advantage over cryengine in the future
will simply be usable documentation provided by amazon. Cryengine is simply
not usable without better docs or else an incredible amount of time. Crytek is
having financial troubles but I bet their engine would have 10x adoption if
they hired a team technical writers

Unreals docs are fairly bad also, but at least there are some third party
resources to turn to

~~~
mhh__
Unreal docs are fairly good for making games but if you want to modify the
structure of the engine it's quite annoying/nonexistent.

Case in point: Vehicle physics is no where near as good as the docs imply (not
a toy but still 20 year old vintage), but there is almost no documentation of
how PhysX interacts with the Unreal engine proper i.e. you can get the
PxRigidWhatever handle but you can't easily replace PhysX with a proper MB
package. Epic seem to be transitioning to Chaos but it's not documented yet.

If I ever get good Vehicle physics working I'll write it up (it's definitely
possible but I'm not sure how ACC does it)

~~~
djmips
People customizing the UE4 engine professionally or on large projects put a
lot of work into the areas they are interested to the point where it's not
really UE4 anymore in that area. Gears of War is a good example where areas of
the rendering system would be almost unrecognizable as they have put in
countless man years of work diverging from the base engine.

~~~
mhh__
I'm sure it's possible I'd just rather not read thousands of lines of code to
find the nitty gritty.

I want to make the basics of an open source (sim)racing game (as a test bed
for writing tyre models), without using the fairly lacklustre offerings
included by default (e.g. no sprung mass, no carcass stiffness etc., idealized
suspension etc.). I have no need to go into the bowels of the rendering engine
but it struck me that the interactions between PhysX and the actual actor
model for the vehicle is almost not documented at all. I assume it's possible
to do it solely with PhysX (proper suspension) but I cannot find any case
studies of people doing it with the possible exception of their drive project
which is under $$$ and NDA I'm guessing.

I was also slightly surprised that I had to go looking for the option to
connect to the PhysX debugger. It wasn't hard to find but I was half expecting
it to be included with the engine.

------
reykjavik
Used to work with cryengine some time ago. That is by far the worst c++
codebase i've ever seen.

~~~
Roritharr
Interesting sentiment, I sometimes wonder if a "messy" codebase can have
advantages for performance.

Many very highly performance tuned applications I saw in the wild would fall
into the category of "horrible codebase" when looked at through that lens.

~~~
nocturnial
It falls more in the category of having a lot bugs which could've been caught
if they used static code analysis, code review, etc...

I understand that you might think that messy could mean it's fine tuned for
performance. In this case, I highly doubt it and think it's more reasonable to
think it's messy because they had deadlines.

The messy part isn't about performance optimizations. It's more about things
that got crammed in there and only works for a very specific subset of
parameters. And even then you can't be sure it'll work...

I don't blame the programmers, it feels they had deadlines to uphold from
managment.

~~~
gentleman11
What sorts of static code analysis tools do people here use in their game
projects? I know carmack is a big fan of them

~~~
nocturnial
Here are the results for cry engine specifically:

[https://www.viva64.com/en/b/0417/](https://www.viva64.com/en/b/0417/)

[https://www.viva64.com/en/b/0495/](https://www.viva64.com/en/b/0495/)

[https://www.viva64.com/en/b/0574/](https://www.viva64.com/en/b/0574/)

I'm not endorsing pvs studio nor am I saying it's bad. Try out some tools and
see what works best for you.

~~~
projektfu
It's funny because many of these are the exact possible errors you expect when
someone is swimming in a large code block doing lots of copy and paste. Large
blocks of code are very hard to test thoroughly, so I imagine the testing was
mostly looking to see if things look right followed by play-testing.

------
zamalek
That license looks like a minefield. Any lawyers able to chime in on the
reality of becoming tainted? Given their recent history, this is one codebase
you really wouldn't want to risk becoming tainted by.

~~~
gear54rus
What is their recent history?

~~~
zamalek
Crytek v. Cig, which the court ruled largely in favor of Cig, and even called
out Crytek's behavior (which was an absolute circus). Crytek will prosecute
given even the most questionable grounds.

The consequences of taint are a very real risk here.

------
dang
If curious see also from 2016:
[https://news.ycombinator.com/item?id=11760298](https://news.ycombinator.com/item?id=11760298)

Related significant threads:
[https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...](https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=Cryengine%20comments%3E10&sort=byDate&type=story)

------
rurban
The real issue is clear from their announcement post.

master (now main) was not always stable (of course, stable code are in the
stable and release branches) so silly people complained, and the silly PM
reacted by closing down pushes to main, and hereby closing down issues and
PR's. He clearly has no idea how open source code development works. Now they
have to maintain two repos, the internal one and thd public one, and get no
feedback from outside. Well, feedback on one year old code.

