• Advertisement
  • entries
    2
  • comments
    13
  • views
    674

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.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 (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.

 

 

Entries in this blog

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.

 

  • Advertisement