Project for my non-Unity C# game dev work.

Exanite.GameDev

Exanite

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.

Exanite.GameDev

Dev Logs