Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cryengine Source Code

github.com

Post reply on HN
Print view View original

91–100 of 149 posts

Re: Cryengine Source Code

#91

Post by qeternity »

gameswithgo wrote: post #51
Nican wrote: post #13

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... 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 (?)

inside a bunch of nested loops is where you need a goto, if the language doesn’t have labeled breaks (which is just a fancy goto) most of your points are things people notice any time real actual big software with performance constraints gets posted. so along with questioning the wisdoms in that function, also question your own wisdom. maybe some of what you think you know is wrong.

Code like this actually always makes me feel better about my own code when I’ve ultimately had to make a trade off between abstraction/organization and performance. I wonder who all these engineers are that see code like this, especially in hot paths, and can’t understand how it came to be and that there was a deliberate choice made.

Re: Cryengine Source Code

#92

Post by comex »

artifact_44 wrote: post #85
oever wrote: post #28

Earlier quoted context omitted.

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.

function calls push registers, allocate a stack frame, and push a return address. By breaking your inner loops into more functions you've now generated megabytes of pointless memory thrash... on a console. Additionally, at the time this stuff was written, compilers and toolchain weren't neccessarily standardized, or were customized to accomodate certain use cases, so they needed more hand-holding to generate performa…

Function calls do none of those things if they’re inlined, and compilers have been able to inline functions for a long time. Perhaps this code is even older than that.

Re: Cryengine Source Code

#93

Post by TravHatesMe »

naikrovek wrote: post #87
oever wrote: post #28

Earlier quoted context omitted.

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.

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.

The compiler does a lot of optimizing, including inlining function calls so that they do not have overhead. My opinion is to favour readable and maintainable code. If there is a performance issue, then profile it, measure and then optimize. No need to prematurely optimize at the cost of code quality.

Re: Cryengine Source Code

#94

Post by bufferoverflow »

Nican wrote: post #13

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... 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 (?)

And

* magic numbers

    m_iSimClass = 3;
    return 1E10;
    m_timeSmooth*(1/0.3f)
    sqr(0.0001f)
    m_pos.len2()>1E18
    helper.pos.len2()
* Very few comments explaining what's going on

When I was getting my CS degree, my professors required, at the very least, to describe what each method does, what each argument is, and a possible range of values of each, and the same for the return value.

I hate this "self-documenting" nonsense, which obviously doesn't work. This piece of code is a good example of that.

Re: Cryengine Source Code

#95

Post by djmips »

mhh__ wrote: post #39
gentleman11 wrote: post #6

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.…

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 wi…

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.

Re: Cryengine Source Code

#96

Post by phreack »

skohan wrote: post #58
christoph wrote: post #56

Earlier quoted context omitted.

I have a feeling you may have been approaching this problem in UE4 the wrong way. Adding a double jump can be done in numerous ways, but one simple way is with Blueprints. See below link where the exact functionality is implemented with a really simple blueprint. https://m.youtube.com/watch?v=hFAr7gYV1rA

Oh I am certain I was not approaching the problem in the UE4 way. But the issue is that the way UE4 expects me to do things is not the way I would like to approach game development. UE4 has a strong bias about the way things should work. If I am making something which is fairly well aligned to that bias, then it's fairly easy to make it work. But if I want to achieve something which is quite far from what the engine…

I know what you mean. One of the first things I looked into when trying out Unreal was Version Control. The amount of hoops I had to jump through just to get things on git made me reach the exact same conclusion you did.

Re: Cryengine Source Code

#97

Post by cheerlessbog »

pm90 wrote: post #72
ConcernedCoder wrote: post #67

Earlier quoted context omitted.

...which is NOT high on the list of concerns for a game title, what you want instead is massive performance gains, so you can do more with less, and in the end produce a better experience than your competitor. -- function calls/indirection/making your code 'easy' to understand, all have a RUNTIME cost, and many small costs add up to a large cost, the reasoning is really that simple.

I struggle to see how composing into functions adds a runtime cost when using modern compilers; as others have pointed out the compiler will inline it if the function is only used once. This rationalization doesn’t make sense to me, especially for game engines which I assume are not limited to a release or 2 but are used to power multiple titles. If the software artifact is going to live for a long time, it’s probabl…

> the compiler will inline it if the function is only used once.

There may be other criteria, eg is the function likely to be called.

Re: Cryengine Source Code

#98

Post by gentleman11 »

naikrovek wrote: post #88
Jasper_ wrote: post #42

Earlier quoted context omitted.

Underlying helper libraries like math utilities are often extracted and put under independent test. A physics engine often has so much state (and isn't always guaranteed to be deterministic!) that doing any sort of unit testing at the functional level is not worth it. To those that reply with "use less state", I encourage you to show how. Often times the unit tests I've seen from junior game programmers are worse tha…

Game development problems are often large global state manipulation problems. If you don't write games you will never realize this. Almost everything taught in academia and in the enterprise about software development "best practices" are absolutely the wrong things for a game. (They're wrong for enterprise and academia, too, but I'm not willing to get into that fight on this site.)

Is there an industry-wide set of concepts and best practices that is applicable for large scale games? What sorts of things do hiring managers worry about at night?

Re: Cryengine Source Code

#99

Post by mhh__ »

djmips wrote: post #95
mhh__ wrote: post #39

Earlier quoted context omitted.

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 wi…

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.

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.

Re: Cryengine Source Code

#100

Post by MauranKilom »

Nican wrote: post #13

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... 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 (?)

This is what draws my attention more:

> //FIXME: There's a threading issue in CryPhysics with ARM's weak memory ordering.

https://github.com/CRYTEK/CRYENGINE/blob/6c4f4df4a7a092300d6...

Translation: "We have race conditions in our C++, but x86 is lenient enough and current MSVC not aggressive enough to make it crash and burn constantly on our main platform."

Coincidentally, I finished Crysis 1 today. That involved the first four crashes I had with the game, three of which were in the final battle.

Post reply on HN