Advertisement Jump to content
  • Advertisement
  • entries
    4
  • comments
    14
  • views
    1620

About this blog

My C++ game engine from scratch

 

Hello there.  I'm not really the blogging type.  This is my first ever blog.  So I'll do my best. 

 

I've been trying to showcase my video game engine from scratch in different professional forums with scant mixed results. 

 

I’m currently a happily employed 3D Graphics Programmer in the medical device field who also loves creating graphics programs as a side hobby.

 

It's been my experience that most people who aren't graphics programmers simply don't appreciate how much learning goes into simply being able to code a small fraction of this from scratch.  Most viewers will simply compare this to the most amazing video game they’ve ever seen (developed by teams of engineers) and simply dismiss this without considering that I’m a one-man show.

What I’m hoping to accomplish with this:  I’m not totally sure.  I spent a lot of my own personal time creating this from the ground up using only my own code (without downloading any existing make-my-game-for-me SDKs), so I figured it’s worth showing off.

My design: Oct Tree for scene/game management (optimized collision-detection and scene rendering path) from scratch in C++. 

 

1.      All math (linear algebra, trig, quaternion, vectors), containers, sorting, searching from scratch in C++.

2.      Sound system (DirectSound, DirectMusic, OpenAL) from scratch in C++.

3.   Input System based implemented in C++ via DirectInput.

4.      Latest OpenGL 4.0 and above mechanism (via GLEW on win32/win64) (GLSL 4.6).  Very heavy usage of GLSL.

 

Unusual/skilled special effects/features captured in video worth mentioning:

1.       Volumetric Explosions via vertex-shader deformed sphere into shock-wave animation further enhanced with bloom post-processing (via compute shader).

2.       Lens Flare generator, which projects variable edge polygon shapes (dynamically created with pixel shader and point-sprite particle system) projected along screen-space vector from center of screen to light-position (again, in screen-space: size and number of flares based on intensity and size of light source).

2.      Real-time animated procedural light ray texture (via fragment shader) additively blended with Volumetric explosions.

3.      Active camouflage (aka Predator camouflage).

4.      Vibrating shield bubble (with same sphere data in Volumetric explosion) accomplished using a technique very similar to active camouflage

5.      Exploding mesh: When I first started creating this, I started out using fixed-function pipeline (years ago).  I used one vertex buffer, one optimized index buffer, then another special unoptimized index buffer that traces through all geometry one volume box at a time.  And each spaceship “piece” was represented with a starting and ending index offset into this unoptimized index buffer.  Unfortunately, the lower the poly-resolution, the more obvious it is what I was doing.  Unfortunately, as a result, when the ship explodes you see the triangle jaggies on the mesh edges.  My engine is currently unfortunately somewhat married to this design—which is why I haven’t redesigned that part yet (It’s on the list, but priorities).  If I were to design this over again, I’d simply represent each piece with a different transform depending upon whether or not the interpolated object-space vertex (input to the pixel shader) was in-front of or behind an arbitrary “breaking plane”.  If the position was beyond the breaking point boundary planes, discard the fragment.  This way, I can use one vertex buffer + one optimized index buffer and achieve better looking results with faster code.

5. Post-process Bloom workflow: compute-shader Gaussian-blurred luminance bloom texture up-sampled and added to tone-mapped, contrast-corrected gamma-corrected scene. 

Entries in this blog

 

My Latest Game Engine From Scratch Demo: HDR bloom workflow improved

I've been tweaking the bloom workflow ( luminance calculation, outputting threshold values to texture fraction size of main target, then recombining the original target with gaussian-blurred luminance target, tone-mapping, contrast reduction, gamma correction to final main device) for awhile now.  I've finally got it right.  Tonemapping is not an exact workflow.  There are many different variations of tonemapping operators to choose from.  I've been experimenting with several different tonemapping workflows.  Some are very complex, explicitly using White and Exposure variables, others are much simpler and get a pleasing result. The tonemapping operator I wanted to use works great--the explosions are HDR and very bright, with lots of definition--but the background (everything that's not an explosion) looks comparatively very dark.  Varying contrast reduction and gamma correction doesn't quite fix it.  So this video output represents a visually pleasing tonemapping fallback operator--that is also a breakthrough result.  Bright explosions, and easy to see the background.

frankoguy

frankoguy

 

My C++ Game Engine from scratch

Hello there.  I'm not really the blogging type.  This is my first ever blog.  So I'll do my best.    I've been trying to showcase my video game engine from scratch in different professional forums with scant mixed results.    I’m currently a happily employed 3D Graphics Programmer in the medical device field who also loves creating graphics programs as a side hobby.   It's been my experience that most people who aren't graphics programmers simply don't appreciate how much learning goes into simply being able to code a small fraction of this from scratch.  Most viewers will simply compare this to the most amazing video game they’ve ever seen (developed by teams of engineers) and simply dismiss this without considering that I’m a one-man show. What I’m hoping to accomplish with this:  I’m not totally sure.  I spent a lot of my own personal time creating this from the ground up using only my own code (without downloading any existing make-my-game-for-me SDKs), so I figured it’s worth showing off. My design: Oct Tree for scene/game management (optimized collision-detection and scene rendering path) from scratch in C++.    1.      All math (linear algebra, trig, quaternion, vectors), containers, sorting, searching from scratch in C++. 2.      Sound system (DirectSound, DirectMusic, OpenAL) from scratch in C++. 3.      Latest OpenGL 4.0 and above mechanism (via GLEW on win32/win64) (GLSL 4.4).  Very heavy usage of GLSL.   Unusual/skilled special effects/features captured in video worth mentioning: 1.       Volumetric Explosions via vertex-shader deformed sphere into shock-wave animation further enhanced with bloom post-processing (via compute shader). 2.       Lens Flare generator, which projects variable edge polygon shapes projected along screen-space vector from center of screen to light-position (again, in screen-space: size and number of flares based on intensity and size of light source). 2.      Real-time animated procedural light ray texture (via fragment shader) additively blended with Volumetric explosions. 3.      Active camouflage (aka Predator camouflage). 4.      Vibrating shield bubble (with same sphere data in Volumetric explosion) accomplished using a technique very similar to active camouflage 5.      Exploding mesh: When I first started creating this, I started out using fixed-function pipeline (years ago).  I used one vertex buffer, one optimized index buffer, then another special unoptimized index buffer that traces through all geometry one volume box at a time.  And each spaceship “piece” was represented with a starting and ending index offset into this unoptimized index buffer.  Unfortunately, the lower the poly-resolution, the more obvious it is what I was doing.  Unfortunately, as a result, when the ship explodes you see the triangle jaggies on the mesh edges.  My engine is currently unfortunately somewhat married to this design—which is why I haven’t redesigned that part yet (It’s on the list, but priorities).  If I were to design this over again, I’d simply represent each piece with a different transform depending upon whether or not the interpolated object-space vertex (input to the pixel shader) was in-front of or behind an arbitrary “breaking plane”.  If the position was beyond the breaking point boundary planes, discard the fragment.  This way, I can use one vertex buffer + one optimized index buffer and achieve better looking results with faster code.  

frankoguy

frankoguy

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!