# Gravitational Tetris

> The game now uses a custom engine! Original game jam version can be found on the [`original-fna`](https://github.com/Exanite/GravitationalTetris/tree/original-fna) branch of the Github repo.

This game was made for the [DevLUp 2023 Wargames game jam](https://itch.io/jam/devlup-fall-23-wargames) and can be found here on [Itch.io](https://exanite.itch.io/gravitational-tetris)!

The theme was **Upside-Down**.

![image](https://github.com/Exanite/GravitationalTetris/assets/42710136/407e4860-7a90-4bf4-a3a5-243797ff57c2)

## How to play

Instead of directly controlling the Tetris shapes, you control them by moving your character. \
Additionally, clearing tiles is done by **matching colors** instead of creating a full row of tiles.

WASD to move. \
QE to rotate. \
Space to reverse gravity *and* place block.

## 3rd party assets

Custom game engine, gameplay code and art was created by me (Exanite).

Diligent Engine - Rendering Framework: https://github.com/DiligentGraphics/DiligentEngine

SDL2 (C) - Windowing Library: https://github.com/libsdl-org/SDL

SDL2-CS (C#) - Windowing Library: https://github.com/flibitijibibo/SDL2-CS

Arch ECS: https://github.com/genaray/Arch

Aether.Physics2D: https://github.com/nkast/Aether.Physics2D

Myra UI: https://github.com/rds1983/Myra

Fiery Turk - Font: https://www.dafont.com/fiery-turk.font

### Sounds

`abs-popdown-2.mp3`: https://hitrison.itch.io/menu-sfx-pack

`African2.mp3`: https://ellr.itch.io/universal-ui-soundpack

`Minimalist6.mp3`: https://ellr.itch.io/universal-ui-soundpack

`Swishes - SWSH 17, Swish, Combat, Weapon.wav`: https://makotohiramatsu.itch.io/swishes

`Swishes - SWSH 19, Swish, Combat, Weapon.wav`: https://makotohiramatsu.itch.io/swishes

`Swishes - SWSH 20, Swish, Combat, Weapon.wav`: https://makotohiramatsu.itch.io/swishes


A weird mix of Tetris and the gravitation potion from Terraria. Made using my custom game engine.

Gravitational Tetris

Exanite

Gravitational Tetris is now using Avalonia to render its UI! Previously I was using Myra, which is a simpler, but still very powerful UI library.
I decided to switch over to Avalonia because it was more fully featured and had a much bigger community.

The integration took a while though. Myra took me about a day to integrate. Avalonia took almost a week.
I still have a lot more to implement, namely input handling, but I didn't implement that in Myra either.

I also implemented UI scaling. I had this in the Myra implementation, but it was restricted to manual font scaling. Avalonia allows you to scale the entire UI, similar to how the zoom function works in web browsers.

Today I implemented mouse input into my game engine!

Gravitational Tetris never needed mouse input so I never bothered implementing it, but now that I'm moving onto a top-down shooter type of game, mouse input is going to be needed.

Today I reimplemented shader hot reloading... well technically, shader pipeline hot reloading.

I already had hot reloading working for resources that require individual files. This meant individual shaders were already being hot reloaded. However, because shader pipelines are a combination of multiple shaders (eg: fragment + pixel shaders), my existing hot reloading solution didn't work.

Therefore, I had to check if the shaders the shader pipeline depend on have changed and reload the shader pipeline accordingly.
To do this, I added a "Reloadable" class which allows a resource to be reloaded if its dependencies have changed.

In the video, you can see the results of me changing the shader code as the game is running. As the shader code changes, the shader is reloaded and compiled into a shader pipeline.

Today I mainly focused on researching tonemapping and color spaces.
Also, apparently it's possible to set the swapchain texture format used by Diligent Engine.

The first image is RGBA8_UNorm_sRGB (8 bits per value, unsigned, normalized, sRGB color space). sRGB is the most common color space and is natively used by monitors.
The second image is RGBA8_UNorm (same as before, but in linear RGB color space). This causes the image to be darker because the values are lower than what monitors expect. sRGB ~= linear^(1/2.2).

Today I made it possible to set a fixed resolution for the bloom texture. This allows me to control the quality of the bloom, but more importantly ensure that different resolution monitors will show the exact same bloom effect. This prevents the problem where, for example, 4k monitors will have a much smaller bloom compared to a 1080p monitor.

Today I added the option to turn down the bloom intensity. It's now set to 1% of what it was before, making it a very subtle glow effect.

Today I got my bloom effect working. I still need to do quite a bit more polish, such as making the bloom configurable, but it looks quite cool already.

Today I began to implement bloom in my game engine.

Bloom is typically implemented as a blur effect that gets added on top of the rendered scene.
Additionally, the blur effect is typically limited to only the brightest parts of the scene. This makes it so that only bright objects get bloomed.

To blur the scene, the rendered scene is iteratively downscaled, then upscaled.
Technically, simply downscaling it once will cause the output to be blurred, but it doesn't result in the best quality.

So far, I have the downscaling steps done. The upscaling steps should make the blur more pronounced and higher quality.

Today I implemented my first post processing effect into Gravitational Tetris.
While I don't need post processing at all for this game, I'll need it for future projects so I decided to use Gravitational Tetris as a test bed for new rendering features.

This effect is done by first rendering the world to an offscreen texture (called a render target), then using a post processing shader to copy and modify the offscreen target to the on screen texture (the main render target). The UI is then rendered directly to the main render target, bypassing the post processing step.

I've finally added sound effects to Gravitational Tetris!

This involved integrating FMOD into the game and creating an FMOD project (it's why I had the FMOD DLLs in my previous showoff post 😁).
The FMOD project contains sound effects and a list of events that cause the sounds to be played.

I can then trigger those events and have the sounds automatically play.

Today I spent way too long attempting to create a NuGet package that contains all of the native libraries (C++ DLL's/dynamically linked libraries) that my game engine needs.

To be honest, I could have just manually dragged and dropped the DLLs that I needed, but I was really interested in .NET/C#'s runtimes folder feature.
The runtimes folder contains folders corresponding to different runtimes (OSes, CPU architectures, etc) and C# can be configured to get the right DLLs from the correct folder.
It's unfortunately not documented anywhere and I spent the whole day reverse engineering it 😫 (it's not as straightforward as just moving the DLL into the folder).

I did get it working though!

Image 1: Structure of the runtimes folder.

Image 2: Local NuGet feed that I copy built NuGet packages into. I'm using a local feed because I don't want to publish my packages publicly.

Image 3:
- Built project. No runtimes folder is needed because this project was only built for win-x64. This lets C# remove the DLLs for the other platforms.
- For projects that target multiple platforms, C# will keep the runtimes folder and load the correct DLLs dynamically.

Also, to celebrate the holiday season, I added a winter themed version of the game's textures!

I ended up just starting a new draw call whenever the texture changes for sake of simplicity.
This reduces the number of draw calls by a fairly significant amount, but isn't dropping it to single digits numbers.

This change is especially noticeable with the UI, which already uses a font atlas generated by FontStashSharp.
The UI gets draw in a single draw call, rather than a draw call per character (which adds up *very* quick).

In the future, I plan to implement sprite atlasing and texture arrays. These both reduce the number of texture changes, thus reducing the number of draw calls.

Today I began implementing sprite instancing for my game engine, along with some other optimizations.

So far I've reduced the number of draw calls from around a thousand per frame to just 3. I can reduce it to just 1, but there's not really any point in doing so.
Downside is that I can only display one texture, so the entire game is a magnificent green color.

Image 1:
- Render doc showing the different commands that Diligent Engine sends to Vulkan.
- Of those commands, 3 of those are draw calls for the sprites on the screen.
- The right shows the rendered image. RenderDoc is pretty amazing about this and actually lets you step through each command to see the image being constructed.

Image 2:
- Shader code with uniform, per vertex, and per instance data.
- I would use float4x4 for the World matrix, but Diligent Engine doesn't let me do so. bgfx had a similar restriction, leading me to believe this is a GPU restriction. Does anyone know why this is the case?

Image 3:
- Method that submits an instanced draw call.
- The per instance data is copied into a buffer on the GPU based on how many sprites were drawn.
- The data is then mapped to the shader Input struct based on the ATTRIB# semantics (the exact mapping is defined in a separate file).

Today I implemented the UI which was the last feature I needed to re-implement.
This means that the version of Gravitational Tetris in my own game engine has the exact same features as the version made using FNA.

Since I'm still using Myra and FontStashSharp for the UI, most of the code used to create the UI remained the same.
The main difference is that Myra and FontStashSharp come with integrations for FNA, but since I'm not using FNA, I had to manually integrate them into my engine.

This involved handling font atlas creation and forwarding Myra's draw calls to my engine's sprite renderer.

For font atlas creation, FontStashSharp provides an ITexture2DManager interface that I have to implement. You can see the SetTextureData method in the third image and the resulting font atlas in the second image.

Similarly, for forwarding Myra's draw calls, Myra provides an IMyraRenderer interface, which you can see in the fourth image.

Today I reimplemented the fading effect for the placeholder tiles.
This involved adding a "Color" value to the vertex shader's cbuffer (aka uniform buffer), passing it to the pixel shader, and passing in the alpha from C#.

For context, vertex shaders can have values set per draw call (usually called uniforms), per instance (in case of GPU instancing), and per vertex (Diligent calls these attributes). The last two can also be called "varyings". Using instancing lets you efficiently draw multiple objects per draw call.
For example, if you want to render a forest efficiently, time can be a uniform, mesh and tree position can be varying per instance, and vertex position and UVs can be varying per vertex.

Another way I could have done this is to pass in a Time value to the shaders and have the shaders calculate the correct alpha. This moves the calculation from the CPU to the GPU.
I didn't do this since I originally did the calculation on the CPU during the game jam and it also requires creating another set of shaders (one that fades and one that doesn't).

Doing this calculation on the CPU is very light since it's one calculation *per sprite*, but with more complex effects, it might take multiple calculations *per pixel*, which makes it much more efficient to do things on the GPU.

Today I began rewriting Gravitational Tetris to work inside my own game engine.

First thing you'll notice is that the game jam theme, **upside-down**, strikes again! The game is upside down, or rather, is no longer upside down — however you see it.
So far I have simple sprite rendering implemented. It's very inefficient right now (1 draw call per sprite + a lot of allocations), but the game technically is playable.

My next step is to reimplement the fading effect of the tiles and make the game upside down / not upside down again.
I'll then look into reimplementing the UI, which honestly scares me, but I might be able to make it work without too much pain.

Today I implemented input handling, player movement, and adjusted my renderer to render a single player sprite.
The next step is to optimize and generalize the sprite rendering process so I can render multiple sprites with different textures.

Both yesterday and today, I've been working on refactoring my game engine code.

This setup is based off the two FNA games I'm working on, making it very easy to reuse code from them.
Additionally, new features can be simply added by creating new systems and registering them.

For example, I converted Diligent Engine's 3rd example to use my Game class.
The WindowSystem creates a window, the TimeSystem updates the game time, and the RenderSystem renders a rotating cube.

Today I mostly focused on organizing my ECS related code into it's own package/project and ensuring that my dependencies are up to date.
I've been trying to keep everything non-Unity C# gamedev related in one repo so it's been interesting having to manage so many projects.

Today I worked on refactoring my game engine code and making so that my Game base class can be subclassed, similar to how XNA/FNA/MonoGame works.
The images below show Diligent Engine's (the rendering framework I'm using) sample code and the scene that it renders. I've heavily modified the sample to use my Game class, SDL instead of Windows Forms, my resource manager, and a bunch of other smaller changes.

So I ended up not liking bgfx due to its lack of documentation and my struggles with switching to graphics APIs other than OpenGL (shaders kept failing to compile/load properly for some reason).

I'm now using Diligent Engine as my rendering framework.
Compared to bgfx, Diligent Engine is lower level and allows the use of more modern APIs. Diligent also provides much better official C# bindings.
The biggest difference I'm noticing right now is that I can now access Pipeline State Objects (PSOs).
More types of shaders are supported and the shader language is HLSL, rather than a custom language with little to zero documentation and tooling.

So far, I got a triangle to render. I'm also close to getting textures working again.

I got textures working yesterday! I started by only supporting DDS files since that's the format natively supported by bgfx, but since I'm now using an image processing library (Magick.NET), I should be able to import most image formats into my engine.

Today I implemented mesh importing and UV support.
Mesh importing is done using the Assimp library (<https://github.com/assimp/assimp>), which made it surprisingly easy.

Here's Suzanne (the Blender monkey) imported into my custom engine.
I was lazy with UV unwrapping so each face is it's own UV island, causing the checker-like pattern in the video.

Today I got instancing to work. If you take a look at my last post, you'll see that the number of draw calls has down from 16255 to 2.

I got a cube! 😛 

This was fun to implement, but it's currently tanking my FPS down to around 57. Not that great, but I am submitting 16k draw calls.
It should be possible to optimize this so that I only need to submit one draw call, but I'm not sure of the exact API I need to use just yet.

Also, it looks like C# matrices can directly marshal to bgfx's matrix format. It was just hard to tell if it was working because of the many other things that weren't working yet.

I got my first triangle to render in my custom engine late yesterday night (or should I say, early this morning).
I switched over to using OpenGL now since that's what worked (bgfx lets me switch rendering backends very easily), but I hope to make my renderer work with the other backends as well.

I'm still trying to get something to render in bgfx (it's rendering a black screen right now 😅), but in the meantime, here's a Shader class that I wrote.

Using unsafe C# has been pretty interesting since it allows me to do a lot of what C++ allows you to do, but with the exception of managed references (eg: classes).
Any time I need a pointer to a managed object, I have to first pin/fix it so the GC doesn't move the object. This ensures that the pointer is valid within the "fixed" block of code.

Today I did some experimentation with SDL (windowing library) and bgfx (graphics API abstraction).
Building and making the two libraries work together took forever, but I got a basic window to render. The text is a debug feature built into bgfx.

Today I did some research on the different types of shader languages and worked on getting my first shader in FNA working.
This is a simple shader that just draws the uv positions at 50% opacity.

Today I worked on testing and making sure the Mac builds of GravitationalTetris worked.

Terry helped out a lot by testing my game and helping me understand how Mac users expect programs to be packaged.
Apparently, MacOS expects your program to be packaged in a .app folder. This app folder also needs to have a specific structure.

It's been an interesting process since usually game engines will package your game for you and you simply don't need to think about it.
However, since I'm not using a game engine, I have to manually package the game.

This is my first attempt at creating the .app folder that MacOS expects.
MacOS contains the game files that C# creates and Info.plist contains information about the game, such as where the executable is.

Today I worked on creating Linux and Mac builds for Gravitational Tetris, the game I made for the Wargames jam.

Today I got my resource/asset management system for my FNA game working. I haven't tested everything though and there's definitely missing features.

At its core, it allows for loading "Resources" and "Files". These both can come from anywhere (from disk, zip archives, the internet, DLLs, memory, etc).
Resources can be any type of object, but files are strictly byte streams.

During the process, I referenced 4 other similar systems (Unity Addressables, my resource system for Codename Prototype, and 2 open source libraries for FNA/Monogame).
The core of the system actually comes from GlaireDaggers's [ResourceCache](https://github.com/GlaireDaggers/ResourceCache) library, but I've heavily modified it to implement the features I want.

Today, I added player rotation and a movement penalty based on the direction the player is moving relative to the direction they are facing.
If the player is moving forwards, the player isn't penalized.
If the player is moving backwards, the player moves at 50% speed.
If the player is moving sideways, the player moves at 75% speed.

This is done by taking a dot product and remapping the result from the [-1, 1] range to the [0.5, 1] range.

Today I switched to using velocity based movement instead of directly setting each entity's position.
This makes the collision detection much more reliable. If you compare today's video to yesterday's video, the player in yesterday's video would clip into the square entities.

Physics! I implemented physics using the Aether Physics engine.

The 2D physics engines available natively in C# are a bit interesting, mainly because they are all forks of each other.
Aether Physics is based on Farseer Physics, which is based on a C# port of the C++ Box2D engine.
There's also Box2D.NetStandard, which is also a port of the C++ Box2D engine.

I honestly don't know if there's much of a functional difference between each of them.
The biggest difference is probably which Vector library they are using (custom vs XNA vs System.Numerics).

Today I experimented more with my camera code and eventually found out that FNA does allow for floating point positions when drawing sprites.
Because of that, the player can now smoothly move across the screen, instead of being locked to integer/tile positions.

I implemented a simple player and camera controller today.

One issue that you may notice though is that the player snaps to the tile positions.
That's an oversight in my camera code. FNA seems to only allow for integer positions when drawing the sprite itself, which means I can't simply provide a transformation matrix when I begin drawing the sprites. This is because FNA expects the positions to be in pixels, not in meters, which is what I'm trying to use.

Today I got the rotation part of the camera implemented and cleaned up the rendering code by quite a bit.
I noticed after my post yesterday that the draw function takes in a world to screen matrix. This simplifies my code a lot because I can just set the transformation matrix once instead of per sprite I draw.

I've been messing around with FNA/Monogame and ECS the past few days. Today, I got a basic camera set up.

Gravitational Tetris

Dev Logs

Gravitational Tetris

How to play

3rd party assets

Sounds