Just added flares to the blog site so now I can select which post belongs to which project. Currently, I only have two projects that I am working on personally. Battles and this blog. There are only two flares as a result. The list may explode over time but until then, this flare solution is pretty basic and easy to use.
Aside from that project. I am going to be revamping this website in just a second here. I made some changes to the style of the site and fixed some bugs on my end (admin center). Unfortunately, my site does not support screenshots or videos just yet so whenever this new version goes live, its pretty much the version anyone will see from then on. There will be no history other than my private git commits of this UI theme. I kind of hate it though, which is why I changed it. Originally, it was supposed to be a retro modern theme. Now, its just a regular flat and modern site. I think its easier on the eyes. Lastly, I want to eventually implement...
I didn't work on the project too much today but I did start on something interesting. I was kind of tired of seeing a little red box moving around since that was the players bounding box and there was no way to use an animation or sprite sheet yet. I decided to start working on that today. I just finished up creating a player state component and system that simply checks the players current velocity to determine which state its in. It can either be idle, walking, or jumping. There is no falling but there isn't a falling animation either on my sprite sheet. So I will just use jumping as anything where the players velocity does not equal zero. ...
I have migrated towards using ImGui. Took less than 15 minutes on my break to get done. Very quick and easy with the Raylib backend provided by "raylib-extras/rlImGui" on GitHub.
I've been heavily procrastinating developing this UI framework because in all honesty, it doesn't seem fun. I will undoubtedly need proper UI in my game engine at some point but trying to get this to work at the quality that I expect is just a lot of wasted time. No other progress has been made on the game and each time I load up the codebase, I want to instantly close it. For now, I think its safe to put it on the back burner. If needed, I can use the console window for commands such as joining servers or executing certain actions. If visual representation of data is absolutely required then maybe I can use RayGUI.
I decided that I should probably work on the UI for my engine since its hard to see data in real time without it. Also, implementing multiplayer will probably heavily rely on UI. I could just have the user use the console window that opens up but I think that is a little hacky. Could work temporarily because I am not looking forward to input fields and advanced event management with my own UI system. I'm not really sure where to start with this system. I don't know what goes into making a UI system. I guess the easiest thing to start with is creating the JSON definition of an example debug UI. Then I can use that JSON file to structure the au...
Now that I have JSON reading and writing in place, I think its time to work on some of the major "refactorings" that are needed. Here are some of the things I want to work on next:
Finally finished the recording playback system. It was quick but fun. Here is kind of a rundown on how it works. Assuming we start with no existing recordings, the system adds a "RecordPositionComponent" to any entity with a "PlayerTagComponent". The "RecordPositionComponent" only has an unordered map where the key is the tick that is recorded and the value is the "PositionComponent" at that tick (simple X and Y floats). The recording system loops through all entities that have a position component, record position component, and the player tag component. We emplace the current tick as the key and the current data inside the entities position...
Managed to switch over to clang and it works well. I was successfully able to read a file using Raylib's file system functions and slap the data into my own struct using Glaze to read from my JSON config file (aka the buffer created by Raylib's functions).
One of the important things to get the playback system working is parsing JSON. I decided to go with Glaze since I have never used it before and I also heard its stupidly fast so I thought it would be interesting to get into. I came across an issue when trying to compile it. I'm not well versed in compilers or the issues that keep coming up but from what I see its something to do with some bugs that MSVC has that breaks compatibility with Glaze. I think I could downgrade what version of Glaze I am using to fix it but I am not happy with this solution. I'm thinking of going with clang-cl instead.
Jumping has now been added to the player. I had gotten it to work initially but I noticed that it would only work half the time. I attach an "IsGrounded" tag component to the player whenever it is grounded. When tracking down the issue, I noticed that the component would stay removed when the player is grounded (which is desired) but when the player is supposed to be grounded it constantly adds and removes the component each tick. As it turns out, my grounded check was running inside the wrong tile loop for physics checking. It would be written to and then overwritten constantly because of the mixed input. After fixing that issue by moving th...
Managed to get my custom frame timing working. I'd say its a lot more elegant than what I was doing before. With Raylib doing half the work and my engine doing the other half, you had a lot of stuff piled up everywhere. Now that I have my own frame time controller, I can combine both rendering/frame time with tick time. Technically, you can separate the two. But I'd rather it be contained all in one spot.
Now to see if input polling works as expected.
I just started to implement jumping again since before the ECS migration I did have jumping. Typically, you'd just check if the jump button was pressed in the current frame and then apply your jump force and whatnot. However, my engine works a little differently and I didn't take into consideration that polling input events during the frame update loop instead of the simulation update loop causes a pretty big issue. At this point, I am fighting Raylib when I could just do my own frame management. Raylib does provide the methods for you but by default the library handles it. Since I am doing my own simulation tick, I'm thinking about rewriting...
Next thing to implement is jumping and add back block breaking/placing mechanics. I also want to dive into more debug/cheat components for the player.
I've just implemented gravity again but this time through the ECS. I can tell you that ever since switching to EnTT for my ECS system, it has been a breeze reimplementing stuff. ECS kind of forces you to decouple your systems. I used to hate the way that things were setup using an ECS. I tried many times to use Unity DOTS but I was just so used to the original Unity workflow of GameObjects and components that are also themselves systems. I think it helps a lot that its partially my own system/engine and EnTT is very simple to use.