7 ms·

This is pretty cool. Props for doing a massive amount of work and creating something open and extensible. -- I just tried reading the code to learn how MineTe

by dcposch 10y ago

This is pretty cool. Props for doing a massive amount of work and creating something open and extensible. -- I just tried reading the code to learn how MineTest does voxel meshing, and it didn't go so well. (Voxel meshing is about turning blocks into triangles efficiently, and it's surprisingly tricky. Mikola Lysenko wrote a great exposition of the problem and several solutions way back in 2012: https://0fps.net/2012/06/30/meshing-in-a-minecraft-game/ https://0fps.net/2012/06/30/meshing-in-a-minecraft-game/ ) I was curious which approach MineTest chose, and I still don't know. I think I found the files where the meshing happens, mapblock_mesh.h/cpp. The code quality is... less than perfect. There are 200+ line C++ functions. There's commented out code and preprocessor "#if 0" ignored code. There's a struct that looks important, but it's called "MeshMakeData", and I don't know what it represents. The comment above just says "Mesh making stuff": https://github.com/minetest/minetest/blob/0a16e53b40d347db7dcd04cb694d0f8f2ed1a5a7/src/mapblock_mesh.h#L40 https://github.com/minetest/minetest/blob/0a16e53b40d347db7d... The file that seems to run everything, game.cpp, is almost 5000 lines long. -- For an example of really clean game code, check out Quake or Doom 3. Both have: * short and sweet main() methods * comments that guide the reader and explain what does what * clean decomposition * short, readable functions, and... * reasonably small files So far, MineTest, at least in part, took the "big hairy ball of C++" approach. Good luck with future development!

dcposch 10y ago
Man, just a few days ago I was bummed that the top comment on most HN stories is critical or dismissive, and now I'm part of the problem. -- People have made some VERY COOL stuff using MineTest. Check out spheretest: https://www.youtube.com/watch?v=ztAg643gJBA https://www.youtube.com/watch?v=ztAg643gJBA
morganvachon 10y ago
I'm not a programmer so forgive my armchair ignorance, but as a player I've found Minetest to run exceptionally smoothly even on 10+ year old hardware with crappy integrated video. On the other hand, Minecraft on a modernish Haswell based PC with a GTX 960 requires Optifine to run as smoothly as Minetest does on that ancient machine. "(B)ig hairy ball of C++" or not, somehow it's optimized to the point that it feels more modern and advanced than Minecraft, if not as visually polished. My question is, is this purely a C++ vs Java thing? I've played some Java games that look and play awesome on older hardware so I have to wonder what the deal is with Minecraft.
- exception_e 10y ago
  The poster was commenting on the maintainability of the C++ code. Unfortunately, poorly written/structured code can still be as performant as well designed code. As for your C++ vs Java question... put very simply, C++ will be faster than languages like Java when it comes to graphics and any software that is close to the hardware.
  - morganvachon 10y ago
    That's what I figured on both accounts. I guess I'm just bothered by the obvious inefficiency of Minecraft versus practically any other Java game I've played. Even other Java-based voxel games have far better performance.
    - exception_e 10y ago
      Interesting aside: I just installed/ran Minetest and then compared it to Minecraft and Minecraft feels/looks a lot smoother on my basic HP laptop.
  - fail2fail2ban 10y ago
    You had better back that claim up. I've seen slow Assembly programs; operating close to the hardware is not a guarantee of better performance.
    - exception_e 10y ago
      I was keeping it high level because the person asking the question is a non-programmer. To your point though, I should have prefixed "correctly written" in front of C++.
      - morganvachon 10y ago
        > I was keeping it high level because the person asking the question is a non-programmer. Well, I should have been more accurate: I'm not a programmer by trade, but I do understand the basic concepts of computer programming, and I've dabbled with both high level and low level languages. I've even done some assembly programming in the distant past, about 20 years ago, just to learn it, as well as a stint with SQL/400 on the AS/400 about 14 years ago. But these days the closest I come is bash scripting or dabbling in Python or Lua. I've never messed with C/C++ or Java though, hence my questions directed at those languages. All that said, I do appreciate your response!
jeremiep 10y ago
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.

by dcposch 10y ago

dcposch 10y ago

Man, just a few days ago I was bummed that the top comment on most HN stories is critical or dismissive, and now I'm part of the problem. -- People have made some VERY COOL stuff using MineTest. Check out spheretest: https://www.youtube.com/watch?v=ztAg643gJBA https://www.youtube.com/watch?v=ztAg643gJBA

morganvachon 10y ago

I'm not a programmer so forgive my armchair ignorance, but as a player I've found Minetest to run exceptionally smoothly even on 10+ year old hardware with crappy integrated video. On the other hand, Minecraft on a modernish Haswell based PC with a GTX 960 requires Optifine to run as smoothly as Minetest does on that ancient machine. "(B)ig hairy ball of C++" or not, somehow it's optimized to the point that it feels more modern and advanced than Minecraft, if not as visually polished. My question is, is this purely a C++ vs Java thing? I've played some Java games that look and play awesome on older hardware so I have to wonder what the deal is with Minecraft.

exception_e 10y ago
The poster was commenting on the maintainability of the C++ code. Unfortunately, poorly written/structured code can still be as performant as well designed code. As for your C++ vs Java question... put very simply, C++ will be faster than languages like Java when it comes to graphics and any software that is close to the hardware.
- morganvachon 10y ago
  That's what I figured on both accounts. I guess I'm just bothered by the obvious inefficiency of Minecraft versus practically any other Java game I've played. Even other Java-based voxel games have far better performance.
  - exception_e 10y ago
    Interesting aside: I just installed/ran Minetest and then compared it to Minecraft and Minecraft feels/looks a lot smoother on my basic HP laptop.
- fail2fail2ban 10y ago
  You had better back that claim up. I've seen slow Assembly programs; operating close to the hardware is not a guarantee of better performance.
  - exception_e 10y ago
    I was keeping it high level because the person asking the question is a non-programmer. To your point though, I should have prefixed "correctly written" in front of C++.
    - morganvachon 10y ago
      > I was keeping it high level because the person asking the question is a non-programmer. Well, I should have been more accurate: I'm not a programmer by trade, but I do understand the basic concepts of computer programming, and I've dabbled with both high level and low level languages. I've even done some assembly programming in the distant past, about 20 years ago, just to learn it, as well as a stint with SQL/400 on the AS/400 about 14 years ago. But these days the closest I come is bash scripting or dabbling in Python or Lua. I've never messed with C/C++ or Java though, hence my questions directed at those languages. All that said, I do appreciate your response!

jeremiep 10y ago

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.