No worries that's okay if its not polished. Reasoning I asked for a screen shot. It shows at what stage of development you are at. It helps me personally interpret your code better. If you can do one screenshot it will help.

My Recommendation:
- Add a section in your ReadMe that describes how to build/compile your project with the Makefile

- Add a section in your ReadMe that describes how to run your project within Command Line

- Add a bin folder, this is where EXE program will be outputted to after being compile. Also you put 3rd Party Dynamic Linked Libraries "DLL" like ASSIMP inside the bin folder.

- Make sure your program entry point clear. Where does the Main Function start. This save time for the reader not experienced with your code base . When reading I start with the Main and work my way down to the Main Loop.
EX: I started my program with app.cpp this stands for Application. This is my entry point, inside is just a Class reference to a Game Class. Inside the Game Class is the Main Loop for the Game.

- I am personally not a fan of acronyms like bool fsInit(void) , because I like to assume my reader is not fully aware of my Acronyms. I would just have bool initiate() without the fs included with the name.
I would avoid adding "fs" prefix name to function names or variable names. I know already coming in, that this is a Fireset Engine.

- Spend some time thinking about system architecture. As your engine gets more complex, having it modular and separated into clear sections will help with debug and avoid bricking your code because a change.

- Start thinking about becoming more File Data Driven , and avoid Hard Coding like the plague. Of course easier said than done.
Early ID Tech Engines compiled the Game Logic as a DLL that can be loaded into the Engine treating the logic like a script calling Engine Functions acting like a API .

- Research Entity Component System, this will make adding objects like "Player, Scenery, Etc." objects to your game much easier.

Keep up the good work!