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

131–140 of 149 posts

Re: Cryengine Source Code

#131

Post by rowanG077 »

bitcharmer wrote: post #120
userbinator wrote: post #80

Earlier quoted context omitted.

I'd rather work with this than Enterprise Java. At least the logic is all there and you only need to scroll to see it, instead of jumping around between a dozen or more different files. Math-heavy code tends to look dense to those who are accustomed to more "mundane" LOB type applications.

Being a Java dev (not enterprise any more) I agree that some enterprise software is an abomination for exactly the reason you mention. However, can you imagine how bad an enterprise C++ project would look like?

A gameengine is as enterprise as it gets.

Re: Cryengine Source Code

#132

Post by myspy »

barrkel wrote: post #38
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 (?)

If the code was separated out into functions that are only ever called once, I'd find it harder to read. Analysing code I'm not familiar with often consists of manually tracing through calls, producing documentation that inlines all the single use function calls. Ideally function names act as shorthand for the body of the function, but if they only have one caller they have nothing to keep them honest. In older codeb…

Nested ifs in for loops, with lots of things going on here, I don‘t know but that‘s the definition of hard to maintain and to read code.

Plus the Hungarian notation and whitespaces are not helping either.

When there is a test class to accompany this thing it would maybe help to faster make sense of it. But that‘s still no fun.

Splitting it up and using functions to extract use cases would help tremdendiously.

Re: Cryengine Source Code

#133

Post by user5994461 »

Nextgrid wrote: post #78
user5994461 wrote: post #70

Earlier quoted context omitted.

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…

Was ammo in Crysis controlled client-side? I've always assumed such counters were stored server-side and thus a server won't apply a "fire" event if the player's ammo counter is at zero until it receives a "reload" event to reset the counter.

Almost everything was controlled client side, including collisions and kills. There was one cheat for sale for example that ruined the game, you'd join a server and all players would be automatically killed every 10 seconds.

Re: Cryengine Source Code

#134

Post by [deleted] »

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…

[deleted]

Re: Cryengine Source Code

#135

Post by Nextgrid »

user5994461 wrote: post #133
Nextgrid wrote: post #78

Earlier quoted context omitted.

Was ammo in Crysis controlled client-side? I've always assumed such counters were stored server-side and thus a server won't apply a "fire" event if the player's ammo counter is at zero until it receives a "reload" event to reset the counter.

Almost everything was controlled client side, including collisions and kills. There was one cheat for sale for example that ruined the game, you'd join a server and all players would be automatically killed every 10 seconds.

I remember experiencing that actually. Just random damage every few seconds. Is there any reason why the "don't trust the client" mindset is not used in games despite it being accepted in web development?

Re: Cryengine Source Code

#136

Post by ensiferum »

skohan wrote: post #44
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 (?)

As a hobbyist who likes to tinker with game and interactive media development, a sentiment I often come across is that in 2020 it makes no sense to implement a game engine, and that I should just use something which already exists to avoid re-inventing the wheel. Code like this is one thing which helps me to calmly ignore than sentiment. I came across the same kind of thing when I was kicking the tires on the Unreal…

Well to be honest UE4 codebase is one of the biggest garbage dumps I've ever had the displeasure to work with. I think the biggest problem is that it's just been accumulating 20 years worth of code and features without anything ever being refactored. And because of the current status you'd never actually want to modify any existing functionality because you're bound to break something. It's also super badly documented and riddled with bugs and really bad and confusing design deductions such as using instances of your UClasses to represent the "types" and and then having to use flags at runtime to see if "this" is archetype or not.

Re: Cryengine Source Code

#137

Post by westmeal »

Jasper_ wrote: post #112
jfkebwjsbx wrote: post #106

Earlier quoted context omitted.

> C has no pattern for breaking out of multiple for loops at the same time. True, but it is cleaner to reorganize the code into several functions and use the return value to propagate across layers if needed. Performance should be the same. > it's not applicable here Why? If there is a new/delete pair anywhere, it should have been an object. > Game developers have a long-seated distrust of std::vector, and for good r…

> True, but it is cleaner to reorganize the code into several functions and use the return value to propagate across layers if needed. I disagree. Having to jump to another function definition which is inline is a bigger mental block than following a goto. The large amount of arguments you'd need to pass might also be a barrier, as is the mental overhead of checking to see if this function might be called from elsewh…

unfortunately MSVC produces hot garbage asm, clang and gcc produce pretty much the same asm output using your example.

Re: Cryengine Source Code

#138

Post by ensiferum »

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

Volatile in c++ has nothing to do with threading.

Re: Cryengine Source Code

#139

Post by user5994461 »

Nextgrid wrote: post #135
user5994461 wrote: post #133

Earlier quoted context omitted.

Almost everything was controlled client side, including collisions and kills. There was one cheat for sale for example that ruined the game, you'd join a server and all players would be automatically killed every 10 seconds.

I remember experiencing that actually. Just random damage every few seconds. Is there any reason why the "don't trust the client" mindset is not used in games despite it being accepted in web development?

The game was released in 2007, Windows XP era. The very idea of security was being discovered.

Re: Cryengine Source Code

#140

Post by jfkebwjsbx »

Jasper_ wrote: post #112
jfkebwjsbx wrote: post #106

Earlier quoted context omitted.

> C has no pattern for breaking out of multiple for loops at the same time. True, but it is cleaner to reorganize the code into several functions and use the return value to propagate across layers if needed. Performance should be the same. > it's not applicable here Why? If there is a new/delete pair anywhere, it should have been an object. > Game developers have a long-seated distrust of std::vector, and for good r…

> True, but it is cleaner to reorganize the code into several functions and use the return value to propagate across layers if needed. I disagree. Having to jump to another function definition which is inline is a bigger mental block than following a goto. The large amount of arguments you'd need to pass might also be a barrier, as is the mental overhead of checking to see if this function might be called from elsewh…

> Having to jump to another function definition which is inline is a bigger mental block than following a goto.

Local lambdas are ideal for this.

> Are you suggesting that the code should have done something like this?

Yes, but you can manage the array inside too.

> I mean, sure, it's a very minor cleanup. It changes like, two lines though

The point is that TempArray can be reused everywhere. This is a typical class that many projects use (stack if small, heap is bigger than threshold).

> Here's modern MSVC. Let's play "spot the difference"

The optimizer has been asked to leave everything as it is, so that is the expected result.

BTW, MSVC is not what you should be using if you want performance.

> Don't just say "should be"... test it yourself!

I always test codegen for all abstractions I use! So I agree.

Post reply on HN