11 ms·

Wow. https://github.com/CRYTEK-CRYENGINE/CRYENGINE/blob/release/Code/CryEngine/CryPhysics/livingentity.cpp#L1300 https://github.com/CRYTEK-CRYENGINE/CRYENGINE/

by zx2c4 10y ago

Wow. https://github.com/CRYTEK-CRYENGINE/CRYENGINE/blob/release/Code/CryEngine/CryPhysics/livingentity.cpp#L1300 https://github.com/CRYTEK-CRYENGINE/CRYENGINE/blob/release/C... Intensity.

georgiev 10y ago
That could totally fit on my screen
Derpdiherp 10y ago
My God. I would've been panned for that in university. Break it up with meaningful comments, rip some of it out into functions where possible, if you're leaving code in source which is commented out - at least leave a comment on why it's commented out. I suppose this is the result of deadlines and lax code reviews.
- AlexeyBrin 10y ago
  > I suppose this is the result of deadlines and lax code reviews. This is usually the result of years of changing/updating the code. Any living code base tends to grow and accumulates cruft over time. Just because it doesn't fit the ideal you learned in university doesn't mean it is bad code, this is real life code.
  - Derpdiherp 10y ago
    I've worked in the Games industry with age old engines, I currently work in embedded development with a code base over 10 years old - I'm fully aware of what "real life" code is like. There is no excuse for not writing well commented code - or even code with well named variables and functions that reduce the need for as much commenting. If you suffer from code like this in your workplace, perhaps actively comment it as you reach an understanding of what it does.
- stuxnet79 10y ago
  The fact that you are using university requirements as an exemplar is very telling. The moment I graduated and started hacking away in the real world is when I discovered that there was a lawless wild-wild-west of coding conventions out there.
  - Derpdiherp 10y ago
    Seems as you've picked up on the same thing - "I've worked in the Games industry with age old engines, I currently work in embedded development with a code base over 10 years old - I'm fully aware of what "real life" code is like. There is no excuse for not writing well commented code - or even code with well named variables and functions that reduce the need for as much commenting. If you suffer from code like this in your workplace, perhaps actively comment it as you reach an understanding of what it does." Relatively experienced 6 year C++ dev - I mainly mentioned university because things where much stricter - but having an environment with decent code reviews and maintaining a little self discipline goes a long way with the sanity of your co-workers.
    - sillysaurus3 10y ago
      You're a C++ dev, not a gamedev. They use different coding conventions. You'll find a lack of refcounted pointers, for example, whereas university teaches you to use them. 6 years is significant, but it's not a long time. There's much to learn, particularly about the cultural aspects of various segments of the industry. This is excellent code that was produced on a tight timeline.
      - Derpdiherp 10y ago
        I was a game dev for 3 of my 6 years. I just got sick of the layoffs after project ends - and my university tuition was in fact games development specific. *Edit - Yes though - by no means do I think I'm some big shot know it all. But I do have strong feelings about readability after having had to deal with code which is awful to grok.
        10y ago
- whatever_dude 10y ago
  Colleges normally stress perfect code against some theoretical metric. Real-world work stresses getting stuff done. And in this case parts of the code can also take a life of their own. Ideally both ideologies meet somewhere in between and you get code that works and is maintainable. But sometimes you can get bad code that is shipped... or an unhealthy obsession with polished code that never ships. One is infuriating, the other makes businesses slowly unfeasible.
- bryondowd 10y ago
  This reminded me of my last place of employment. We didn't use any form of version control system. Instead, every time we changed a piece of code, we commented out the existing code and left it there, next to our revised code, along with a START and END comment including the coder's initials, date, and the ticket or project the change related to. Frequently changed parts of the code were a hideous mess of 90% comments to 10% code. And then occasionally we'd just rename an entire file by prepending 'old' to it and starting fresh with a new file. That place was such a learning experience on the concept of technical debt. But at least I got a fun talking point for my resume. "x++, is that a typo?" "No, sir..."
fitzwatermellow 10y ago
I actually kind of find this sort of entity data oriented code easier to grok than when everything is nicely organized into object hierarchies, like they teach you to do in school ;)
dagw 10y ago
Carmack has some interesting comments on this sort of coding: http://number-none.com/blow/john_carmack_on_inlined_code.html http://number-none.com/blow/john_carmack_on_inlined_code.htm...
- partisan 10y ago
  > When it gets to be too much to take, figure out how to factor blocks out into pure functions (and don.t let them slide back into impurity!). This is a great piece of advice and one that has worked for me in the past when refactoring code like the one referenced.
- jdcarter 10y ago
  > "However, if you are going to make a lot of state changes, having them all happen inline does have advantages; you should be made constantly aware of the full horror of what you are doing." Nicely put. :) Thanks for the link.
- gbersac 10y ago
  Really interesting. I already began to inline code with a comment for each block. Didn't knew John Carmack agree with me.
- gknoy 10y ago
  I was quite surprised at how often copy-paste-modify operations resulted in subtle bugs that weren't immediately obvious. I now strongly encourage explicit loops for everything, and hope the compiler unrolls it properly. I found this particularly interesting
- butabah 10y ago
  Seeing Carmack's thoughts on programming always reminds me that I have such a long way to go. When he was my age, he had already created DOOM and DOOM 2 (along with the wtf? r_sqrt trick).
  - corysama 10y ago
    Fun story: both ID and Epic started out making 2D games. When Tim Sweeny saw Quake for the first time, he literally gave up on gamedev because he thought he wouldn't be able to keep up with game tech. But, shortly afterwards a friend of Tim wrote a Quake-like 3D renderer as a fun project. Tim figured if that guy could do it, he could do it and went on the make Unreal.
imaginenore 10y ago
What a wall of code without comments. Not acceptable.
kidmenot 10y ago
14 levels of indentation across 811 lines. Wow indeed. I refactor as soon as my code gets past 3 levels, I don't know how one is supposed to readily understand this block of code. The lack of comments isn't what troubles me. Comments get old and, when they do, they get completely misleading and downright dangerous. As soon as you feel the need to add a comment, it's often because that particular chunk of code should be extracted into its own function/method/whatever and given an intelligent name. Comments should be reserved for really important stuff, like when the code does something totally non-obvious.
- saiya-jin 10y ago
  i think they don't use static code analysis on this part :) generally agree on commenting, but it's also about discipline - method-level commands are rarely updated, but if there is some particular algorithm within method, I don't see a reason to describe it beforehand on a line or two. General rule - if method is longer than my screen, it's time to refactor. very rarely this isn't a good idea.
  - shermanyo 10y ago
    maybe the author got a 4k monitor and set it up in portrait? :P
- webkike 10y ago
  This code is not actually that _complex_, it is just _complicated_, and there are probably several people within the company that understand it completely. If you actually go through the code, I bet you will understand the majority of it. Step functions are annoying and complicated and need to be _fast_, less than half a frame long. And you need to do a lot in them, and all of those things are tightly coupled.
  - damptowel 10y ago
    another such beauty http://hg.icculus.org/icculus/lugaru/file/97b303e79826/Source/GameTick.cpp#l7276 http://hg.icculus.org/icculus/lugaru/file/97b303e79826/Sourc...
fla 10y ago
The perfect example of everything I try to avoid. I'm really surprised to see this type of coding in a triple A grade engine. What can be the rationale behind writing this [1] ? [1] https://github.com/CRYTEK-CRYENGINE/CRYENGINE/blob/release/Code/CryEngine/CryPhysics/livingentity.cpp#L1468 https://github.com/CRYTEK-CRYENGINE/CRYENGINE/blob/release/C...
- shmerl 10y ago
  Looks like they are using some raw pointers there instead of iterators, that's why they loop like that.
shmerl 10y ago
Yeah, this sort of declaration[1] (inherited from C) is horrendous and prone to nasty errors. Consder this: char* p1, p2; You could erroneously think that char* is a type, and p1 and p2 are variables of that type. That's not correct however, since p1 is indeed char*, but p2 is char. Such declarations therefore should be strongly avoided for clarity. [1]: https://github.com/CRYTEK-CRYENGINE/CRYENGINE/blob/release/Code/CryEngine/CryPhysics/livingentity.cpp#L1309 https://github.com/CRYTEK-CRYENGINE/CRYENGINE/blob/release/C...
- zanny 10y ago
  I always think it is inappropriate to type declare like char* p1 in the first place. Yes, you want to be saying "I'm declaring an 8 bit integer pointer" but since in reality the pointer declaration is bound to the name in C, you should do it everywhere. So I always do char \p1. Yes, for a non-C programmer its not as intuitive, but C isn't intuitive a lot of the time (cough, char p1[] what?). But you avoid making these mistakes altogether. Note in function declarations I use char, because you cannot do statement expansion with a comma there, and because in headers the variable name is optional anyway.
  - shmerl 10y ago
    You mean char *p; ? I prefer to use char* p; as well as std::string& s; and etc. rather than attaching the type syntax to the name, since in essence that's part of the type. But yes, it's a mess that this inherited C logic doesn't treat it that way clearly. To avoid such mistakes, it's better not to use comma declarations altogether, you can perfectly avoid them. It's a good feeling when working with new languages like Rust which avoid such mess.
    - zanny 10y ago
      Yes, the banes of markdown reap their ugly head again. The point is, though, that while in a developers mental model you attach ref or ptr to the type, the language itself does not, and writing it out like it does can easily drive newer developers who do not understand the nuance to make hard to recognize mistakes as a result of it.
segfaults 10y ago
Wow, that is a hardcore function... Have no idea what is going on there... Probably some/a lot refactoring needs to be done there.
tdsamardzhiev 10y ago
There are some parts of video games, where if the thing works, nobody would dare to call your code bad :)

by zx2c4 10y ago

Wow. https://github.com/CRYTEK-CRYENGINE/CRYENGINE/blob/release/Code/CryEngine/CryPhysics/livingentity.cpp#L1300 https://github.com/CRYTEK-CRYENGINE/CRYENGINE/blob/release/C... Intensity.

georgiev 10y ago

That could totally fit on my screen

Derpdiherp 10y ago

My God. I would've been panned for that in university. Break it up with meaningful comments, rip some of it out into functions where possible, if you're leaving code in source which is commented out - at least leave a comment on why it's commented out. I suppose this is the result of deadlines and lax code reviews.

AlexeyBrin 10y ago
> I suppose this is the result of deadlines and lax code reviews. This is usually the result of years of changing/updating the code. Any living code base tends to grow and accumulates cruft over time. Just because it doesn't fit the ideal you learned in university doesn't mean it is bad code, this is real life code.
- Derpdiherp 10y ago
  I've worked in the Games industry with age old engines, I currently work in embedded development with a code base over 10 years old - I'm fully aware of what "real life" code is like. There is no excuse for not writing well commented code - or even code with well named variables and functions that reduce the need for as much commenting. If you suffer from code like this in your workplace, perhaps actively comment it as you reach an understanding of what it does.
stuxnet79 10y ago
The fact that you are using university requirements as an exemplar is very telling. The moment I graduated and started hacking away in the real world is when I discovered that there was a lawless wild-wild-west of coding conventions out there.
- Derpdiherp 10y ago
  Seems as you've picked up on the same thing - "I've worked in the Games industry with age old engines, I currently work in embedded development with a code base over 10 years old - I'm fully aware of what "real life" code is like. There is no excuse for not writing well commented code - or even code with well named variables and functions that reduce the need for as much commenting. If you suffer from code like this in your workplace, perhaps actively comment it as you reach an understanding of what it does." Relatively experienced 6 year C++ dev - I mainly mentioned university because things where much stricter - but having an environment with decent code reviews and maintaining a little self discipline goes a long way with the sanity of your co-workers.
  - sillysaurus3 10y ago
    You're a C++ dev, not a gamedev. They use different coding conventions. You'll find a lack of refcounted pointers, for example, whereas university teaches you to use them. 6 years is significant, but it's not a long time. There's much to learn, particularly about the cultural aspects of various segments of the industry. This is excellent code that was produced on a tight timeline.
    - Derpdiherp 10y ago
      I was a game dev for 3 of my 6 years. I just got sick of the layoffs after project ends - and my university tuition was in fact games development specific. *Edit - Yes though - by no means do I think I'm some big shot know it all. But I do have strong feelings about readability after having had to deal with code which is awful to grok.
      - 10y ago
whatever_dude 10y ago
Colleges normally stress perfect code against some theoretical metric. Real-world work stresses getting stuff done. And in this case parts of the code can also take a life of their own. Ideally both ideologies meet somewhere in between and you get code that works and is maintainable. But sometimes you can get bad code that is shipped... or an unhealthy obsession with polished code that never ships. One is infuriating, the other makes businesses slowly unfeasible.
bryondowd 10y ago
This reminded me of my last place of employment. We didn't use any form of version control system. Instead, every time we changed a piece of code, we commented out the existing code and left it there, next to our revised code, along with a START and END comment including the coder's initials, date, and the ticket or project the change related to. Frequently changed parts of the code were a hideous mess of 90% comments to 10% code. And then occasionally we'd just rename an entire file by prepending 'old' to it and starting fresh with a new file. That place was such a learning experience on the concept of technical debt. But at least I got a fun talking point for my resume. "x++, is that a typo?" "No, sir..."

fitzwatermellow 10y ago

I actually kind of find this sort of entity data oriented code easier to grok than when everything is nicely organized into object hierarchies, like they teach you to do in school ;)

dagw 10y ago

Carmack has some interesting comments on this sort of coding: http://number-none.com/blow/john_carmack_on_inlined_code.html http://number-none.com/blow/john_carmack_on_inlined_code.htm...

partisan 10y ago
> When it gets to be too much to take, figure out how to factor blocks out into pure functions (and don.t let them slide back into impurity!). This is a great piece of advice and one that has worked for me in the past when refactoring code like the one referenced.
jdcarter 10y ago
> "However, if you are going to make a lot of state changes, having them all happen inline does have advantages; you should be made constantly aware of the full horror of what you are doing." Nicely put. :) Thanks for the link.
gbersac 10y ago
Really interesting. I already began to inline code with a comment for each block. Didn't knew John Carmack agree with me.
gknoy 10y ago
I was quite surprised at how often copy-paste-modify operations resulted in subtle bugs that weren't immediately obvious. I now strongly encourage explicit loops for everything, and hope the compiler unrolls it properly. I found this particularly interesting
butabah 10y ago
Seeing Carmack's thoughts on programming always reminds me that I have such a long way to go. When he was my age, he had already created DOOM and DOOM 2 (along with the wtf? r_sqrt trick).
- corysama 10y ago
  Fun story: both ID and Epic started out making 2D games. When Tim Sweeny saw Quake for the first time, he literally gave up on gamedev because he thought he wouldn't be able to keep up with game tech. But, shortly afterwards a friend of Tim wrote a Quake-like 3D renderer as a fun project. Tim figured if that guy could do it, he could do it and went on the make Unreal.

imaginenore 10y ago

What a wall of code without comments. Not acceptable.

kidmenot 10y ago

14 levels of indentation across 811 lines. Wow indeed. I refactor as soon as my code gets past 3 levels, I don't know how one is supposed to readily understand this block of code. The lack of comments isn't what troubles me. Comments get old and, when they do, they get completely misleading and downright dangerous. As soon as you feel the need to add a comment, it's often because that particular chunk of code should be extracted into its own function/method/whatever and given an intelligent name. Comments should be reserved for really important stuff, like when the code does something totally non-obvious.

saiya-jin 10y ago
i think they don't use static code analysis on this part :) generally agree on commenting, but it's also about discipline - method-level commands are rarely updated, but if there is some particular algorithm within method, I don't see a reason to describe it beforehand on a line or two. General rule - if method is longer than my screen, it's time to refactor. very rarely this isn't a good idea.
- shermanyo 10y ago
  maybe the author got a 4k monitor and set it up in portrait? :P
webkike 10y ago
This code is not actually that _complex_, it is just _complicated_, and there are probably several people within the company that understand it completely. If you actually go through the code, I bet you will understand the majority of it. Step functions are annoying and complicated and need to be _fast_, less than half a frame long. And you need to do a lot in them, and all of those things are tightly coupled.
- damptowel 10y ago
  another such beauty http://hg.icculus.org/icculus/lugaru/file/97b303e79826/Source/GameTick.cpp#l7276 http://hg.icculus.org/icculus/lugaru/file/97b303e79826/Sourc...

fla 10y ago

The perfect example of everything I try to avoid. I'm really surprised to see this type of coding in a triple A grade engine. What can be the rationale behind writing this [1] ? [1] https://github.com/CRYTEK-CRYENGINE/CRYENGINE/blob/release/Code/CryEngine/CryPhysics/livingentity.cpp#L1468 https://github.com/CRYTEK-CRYENGINE/CRYENGINE/blob/release/C...

shmerl 10y ago
Looks like they are using some raw pointers there instead of iterators, that's why they loop like that.

shmerl 10y ago

Yeah, this sort of declaration[1] (inherited from C) is horrendous and prone to nasty errors. Consder this: char* p1, p2; You could erroneously think that char* is a type, and p1 and p2 are variables of that type. That's not correct however, since p1 is indeed char*, but p2 is char. Such declarations therefore should be strongly avoided for clarity. [1]: https://github.com/CRYTEK-CRYENGINE/CRYENGINE/blob/release/Code/CryEngine/CryPhysics/livingentity.cpp#L1309 https://github.com/CRYTEK-CRYENGINE/CRYENGINE/blob/release/C...

zanny 10y ago
I always think it is inappropriate to type declare like char* p1 in the first place. Yes, you want to be saying "I'm declaring an 8 bit integer pointer" but since in reality the pointer declaration is bound to the name in C, you should do it everywhere. So I always do char \p1. Yes, for a non-C programmer its not as intuitive, but C isn't intuitive a lot of the time (cough, char p1[] what?). But you avoid making these mistakes altogether. Note in function declarations I use char, because you cannot do statement expansion with a comma there, and because in headers the variable name is optional anyway.
- shmerl 10y ago
  You mean char *p; ? I prefer to use char* p; as well as std::string& s; and etc. rather than attaching the type syntax to the name, since in essence that's part of the type. But yes, it's a mess that this inherited C logic doesn't treat it that way clearly. To avoid such mistakes, it's better not to use comma declarations altogether, you can perfectly avoid them. It's a good feeling when working with new languages like Rust which avoid such mess.
  - zanny 10y ago
    Yes, the banes of markdown reap their ugly head again. The point is, though, that while in a developers mental model you attach ref or ptr to the type, the language itself does not, and writing it out like it does can easily drive newer developers who do not understand the nuance to make hard to recognize mistakes as a result of it.

segfaults 10y ago

Wow, that is a hardcore function... Have no idea what is going on there... Probably some/a lot refactoring needs to be done there.

tdsamardzhiev 10y ago

There are some parts of video games, where if the thing works, nobody would dare to call your code bad :)