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

121–130 of 149 posts

Re: Cryengine Source Code

#121

Post by pmalynin »

user5994461 wrote: post #70
Nican wrote: post #35

Earlier quoted context omitted.

Not going to lie, playing Crysis was a lot of fun, and I never knew this was the underneath function running it.

Crysis shipped with a full blow SDK that included most of its source code. You could actually rebuild the game from it, the 50MB dll that controlled the whole game. Old players maybe remember that the crysis multiplayer was the most cheated game in its era. It was totally unplayable due to all the cheating and that killed the game. One way to make cheats. You could load up the SDK in visual studio. Find the code that…

If I can recall it was even easier than that. There were so many "trainers" available that would give you infinite energy etc. Even easier than that, I remember one hack was to basically just drop an XML file in the game directory to give yourself the ol' reliable freezing pistol hack.

Good game though, I think Crysis 1 multiplayer is to this day one of the most fun multiplayer games I have played. After Crysis 1 they really CoD'fied the game, which is a shame. That and BF2142, A-plus games.

Looking forward to Crysis Remastered, hope they don't screw it up.

Re: Cryengine Source Code

#122

Post by ohgodplsno »

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…

UE4 works hard to make you not edit its source code, yes. But the biggest reason for this is allowing you to update through versions, with no struggle.

Games like Valorant are using their own modified version, and from their own admission, every version bump must be carefully considered and takes upwards of a month to reintegrate their changes in a painstakingly slow process.

Re: Cryengine Source Code

#123

Post by kryptiskt »

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.

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

Re: Cryengine Source Code

#124

Post by iforgotpassword »

naikrovek wrote: post #84
Jasper_ wrote: post #76

Earlier quoted context omitted.

That's in a different function, so I wasn't counting it, but sure. I mean, I would write it differently, but it's fairly readable. It's jumping to a common function epilogue once it finds something it can collide with. Seriously -- try reading through it rather than gawking at the goto.

It's funny watching people reply to you without knowing anything about your skill set and experience. Jasper_ is the real deal, people.

I still don't know who he is, but just from the arguments brought up you can tell this guy has experience in this stuff.

Those blanket statements like "never use goto" and "always trust stl" generally make me wary. I started out with gwbasic once, writing horrible goto spaghetti code. When moving through Pascal and C I eventually learned the "never use goto" mantra and naively tried to follow it at all cost. After I while I eventually encountered the "breaking out of nested loops" problem and refrained from using goto since I didn't want to look like a complete dork. I think I ended up with a flag that was set in the inner loop and checked in the outer and a break in each loop. That's what you get from blindly following rules that others try to present you as god-given.

Re: Cryengine Source Code

#125

Post by skohan »

Jasper_ wrote: post #77
skohan wrote: post #71

Earlier quoted context omitted.

I cannot tell if you are joking or not, but needing to place an entity into the world for a single frame to accomplish this rather than simply applying an impulse to the player is precisely the kind of over-complication I'm referring to

Without having read any of the Unreal Engine movement code, there's a complication here, and that is that "jump" might be influenced by the floor that the player is standing on. The force impulse might be related to the slope in some way. You have to figure out what "double jump" means in the context of there being no floor. Placing a floor that has the influences you want under the player is, in a sense, a hack, but…

I think that captures an issue I have with engines like UE4 which I am trying to describe: it has to support virtually every type of game, so even things which could be relatively simple gain complexity because the engine has to cover cases which may be entirely irrelevant to the project I am working on.

Re: Cryengine Source Code

#126

Post by skohan »

ohgodplsno wrote: post #122
skohan wrote: post #58

Earlier quoted context omitted.

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…

UE4 works hard to make you not edit its source code, yes. But the biggest reason for this is allowing you to update through versions, with no struggle. Games like Valorant are using their own modified version, and from their own admission, every version bump must be carefully considered and takes upwards of a month to reintegrate their changes in a painstakingly slow process.

To me this would be an argument against a tightly coupled monolithic engine like UE4. For instance, imagine if Valorant is only interested in a new version of the engine for new post-processing effects introduced into the renderer. Why should they have to migrate gameplay code to get benefits which have nothing to do with gameplay?

Re: Cryengine Source Code

#127

Post by MauranKilom »

361994752 wrote: post #102
MauranKilom wrote: post #100

Earlier quoted context omitted.

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

This is not about race condition. Rather it is something more like why you need volatile keyword. https://stackoverflow.com/questions/72275/when-should-the-vo...

Can you elaborate? volatile and threading in C++ are orthogonal to each other. I don't understand why you consider a C# volatile discussion relevant when talking about C++ race conditions.

Re: Cryengine Source Code

#128

Post by ohgodplsno »

skohan wrote: post #126
ohgodplsno wrote: post #122

Earlier quoted context omitted.

UE4 works hard to make you not edit its source code, yes. But the biggest reason for this is allowing you to update through versions, with no struggle. Games like Valorant are using their own modified version, and from their own admission, every version bump must be carefully considered and takes upwards of a month to reintegrate their changes in a painstakingly slow process.

To me this would be an argument against a tightly coupled monolithic engine like UE4. For instance, imagine if Valorant is only interested in a new version of the engine for new post-processing effects introduced into the renderer. Why should they have to migrate gameplay code to get benefits which have nothing to do with gameplay?

They actually _are_ changing things like the renderer, hence their need to take a long time for migrations. Basic gameplay code is written with blueprints, base classes are in C++ but do not replace the core code.

Re: Cryengine Source Code

#129

Post by MauranKilom »

kryptiskt wrote: post #123
naikrovek wrote: post #87

Earlier quoted context omitted.

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.

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

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

Re: Cryengine Source Code

#130

Post by skohan »

ohgodplsno wrote: post #128
skohan wrote: post #126

Earlier quoted context omitted.

To me this would be an argument against a tightly coupled monolithic engine like UE4. For instance, imagine if Valorant is only interested in a new version of the engine for new post-processing effects introduced into the renderer. Why should they have to migrate gameplay code to get benefits which have nothing to do with gameplay?

They actually _are_ changing things like the renderer, hence their need to take a long time for migrations. Basic gameplay code is written with blueprints, base classes are in C++ but do not replace the core code.

My point is not about what Valorant is doing specifically, it's about the drawbacks of a tightly coupled, opinionated system
Post reply on HN