3 ms·

Nothing unusual there. It looks like its built on top of irrlicht which probably brings in its own framework view of the world to begin with. 200+ lines funct

Nothing unusual there. It looks like its built on top of irrlicht which probably brings in its own framework view of the world to begin with. 200+ lines functions happen MUCH MORE than you think in AAA code; why split a function if there's going to be a single static caller. John Carmack himself wrote about it a few years ago: http://number-none.com/blow/john_carmack_on_inlined_code.html http://number-none.com/blow/john_carmack_on_inlined_code.htm... All the traits you list are superficial compared to getting the thing working and performing well in the first place :) Heck these are the sort "clean code" practices which make your debug build run at 5 FPS (I've seen worse :). Indirections and conditionals and noise everywhere. These get stripped in release (hopefully) but the catch is that you end up stepping in optimized code cause 5FPS can't get you where you want to test. Having all that nice cleanliness in a debug build you won't use isn't a great way to end up developing after 5 years of piling stuff up :) Besides, you can design your systems so that they're both fast and simple; data-driven design is one such approach. Mike Acton talked about it a lot as well: https://www.youtube.com/watch?v=rX0ItVEVjHc https://www.youtube.com/watch?v=rX0ItVEVjHc

dcposch 10y ago
> Heck these are the sort "clean code" practices which make your debug build run at 5 FPS No. Quake and Doom were both extremely performance optimized, and still had clean code. Avoiding commented-out or otherwise dead code; naming things well; writing concise but thorough comments that explain what's going on: none of those habits hurt performance. Great code is not just meant to compile, it's meant to be read. Inlining code manually should almost never be necessary today. Modern compilers inline automatically. If you do feel the need to uglify code for performance, it should only happen after profiling, not as a habit. There is no reason, performance or otherwise, to have the main entry point of your program or the render loop for your game be in a 5000 line spaghetti file.
- jeremiep 10y ago
  Why is length automatically associated to spaghetti? I've seen way too much spaghetti clean code to agree. Soon everything is its own 20 lines class file and you're buried in well documented technical debt and drowning in files; locked inside your own pretty cage. It also doesn't have to be ugly; beauty should be in how it works not how it looks anyways. I would much, much rather focus on simplicity and let beauty emerge naturally. I've seen many projects fail even while following best practices all over the place. Get its inner workings pretty first, then make the appearances pretty. Its incredibly harder if not outright impossible to do it in the opposite order. If you think of performance after profiling for the first time, you've probably already wasted 90% of it without even realising it - the CPU is just that fast. Optimising at the macro level should be an habit; its the micro-level you want to optimise after profiling. Most software today could easily be orders of magnitude faster. Doom and Quake just happen to be built on top of very well engineered foundations, which they then made pretty before releasing it to the world - it most likely wasn't that nice during development.

dcposch 10y ago

> Heck these are the sort "clean code" practices which make your debug build run at 5 FPS No. Quake and Doom were both extremely performance optimized, and still had clean code. Avoiding commented-out or otherwise dead code; naming things well; writing concise but thorough comments that explain what's going on: none of those habits hurt performance. Great code is not just meant to compile, it's meant to be read. Inlining code manually should almost never be necessary today. Modern compilers inline automatically. If you do feel the need to uglify code for performance, it should only happen after profiling, not as a habit. There is no reason, performance or otherwise, to have the main entry point of your program or the render loop for your game be in a 5000 line spaghetti file.

jeremiep 10y ago
Why is length automatically associated to spaghetti? I've seen way too much spaghetti clean code to agree. Soon everything is its own 20 lines class file and you're buried in well documented technical debt and drowning in files; locked inside your own pretty cage. It also doesn't have to be ugly; beauty should be in how it works not how it looks anyways. I would much, much rather focus on simplicity and let beauty emerge naturally. I've seen many projects fail even while following best practices all over the place. Get its inner workings pretty first, then make the appearances pretty. Its incredibly harder if not outright impossible to do it in the opposite order. If you think of performance after profiling for the first time, you've probably already wasted 90% of it without even realising it - the CPU is just that fast. Optimising at the macro level should be an habit; its the micro-level you want to optimise after profiling. Most software today could easily be orders of magnitude faster. Doom and Quake just happen to be built on top of very well engineered foundations, which they then made pretty before releasing it to the world - it most likely wasn't that nice during development.