A few months ago, I decided to start learning C and I finally got around to completing a project - Here's my noob attempt at a Minecraft clone

• LearnOpenGL

  624 10,317 3.8 C++

  Code repository of all OpenGL chapters from the book and its accompanying website https://learnopengl.com

I started with the tutorials on learnopengl.com with zero knowledge of graphics programming or C / C++. I tried my best to follow along, and I eventually had a basic understanding of C++, but there was still a lot of things that I didn't understand, so I went back to C to learn the basics. I'm definitely a lot more confident with C++ now, and I probably could have created a better Minecraft clone with it.

• minecraft-c

  2 58 0.0 C

  Minecraft clone made with C and OpenGL

Would love some feedback :) https://github.com/c6dy/minecraft-c

• InfluxDB

  www.influxdata.com featured

  Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  

• welcube

  1 - -

You can read my code here: https://gitlab.com/welcube/welcube. I just have a cube drawn with OpenGL 2 and am currently working to translate it to 3, but those changes have not been pushed yet. Since I'm taking the project quite seriously I've created a sub for it (r/welcube) where I'll start posting updates and hope to see people enjoying the game :) There's also a Discord link in the sidebar, different from the one in the README, which I have to update. HMU if you want to discuss how I've handled some things!

• opengl-skydome

  2 45 10.0 GLSL

  A fragment-shader skydome implementation

Having written my own voxel engine back in the days (circa 2015), some advices if you want to push this further : * Yep, your hashmap to store block information per chunk is not going to scale up at all. Since there is fixed amount of blocks in a chunk, ... simply use some big tables. This is what Minecraft does: 4096 bytes for the block Ids, 2048 bytes for data values, 2048bytes for skylight, 2048 for blocklight, ... accessing those values will be very quick, since everything will be close in memory. Block updates will also need (very) quick access to nearby voxels: everything in Minecraft depends on this: meshing, skylight, blocklight, redstone, water, lava, ... * You used the same sub-chunk size as Minecraft: 16x16x16, but used one draw call per sub-chunk: again, this is not going to scale up: Minecraft terrain is the textbook example for instanced rendering. OpenGL 4 has a draw call for this: glMultiDrawArraysIndirect, PITA to use, but performances you get from this call are fantastic. It is possible to emulate this draw call with OpenGL 3, but it is pretty hardcore (not recommended for beginners). * You didn't do any frustum culling: I remember struggling a lot implementing this one. Never ending parade of edge cases. Also pretty costly to run: on the CPU I had back then (core i7 from 2013), it took 2 to 4ms per frame (with a 16 chunks render distance): 20% of the time budget at 60FPS, yikes! Given all the optimization I tried, I was quite disappointed by this. But, if you want a decent rendering distance, with a decent amount of blocks below the sea level, it is pretty much required. I also remember implementing the cave culling algorithm; it was actually surprisingly easy to do, with a decent amount of chunk being culled. * Your lighting is obviously way too simplistic (well, there is none): Skylight is extremely important, this is what will allow you to do day/night cycle, especially if you also have BlockLight information. Updating Skylight values is a major PITA, I struggle way more than I care to admit to get this right (and so did Mojang: those black patches in the world were due to bad SkyLight values). * Dynamic skydome (ie: sky color with day/night cycle) was also not that trivial to implement. I tried various PBR rendering techniques back then (Rayleigh/Mie scattering), but the results were kind of meh (and took way too much GPU power back then). I remember using the techniques from this project: very cheap and not bad looking (with better textures though). * User interface: you'll be for one hell of ride with this one. So many bad memories... * Careful with your floating point usage: I did the same mistake and uses floats everywhere: they do not have a lot of precision. This is particularly bad when you start playing with huge coordinates (>10000): on the GPU, you will be multiplying those coordinates by the MVP matrix, which will give even bigger intermediate numbers: the loss of precision will quickly stack up. Especially when doing collision detection/correction: this is particularly sensitive, if you use an algorithm like the swept AABB. So many times I fell into the void of gone through blocks because of this. Extremely annoying to debug. * The biggest PITA was handling entities: I massively under-estimated the complexity of these, and this is what killed the project back then. Not much pixels on screen, but massive amount of tedious, boring and unrewarding code behind the scenes.

Suggest a related project