This week I fixed the threading issue with the profiler, but haven't gotten around to testing it yet because I got distracted by putting tasks into Quire.
I also found out that I have over 60 tasks planned as part of working on this engine, just the engine. Those tasks range from things like porting 3d code from my previous engines, setting up the UI, to adding VR support and global illumination support later down the line. And animation support at some point.
Also started throwing some stuff together in sprytile, and discovered that sprytile doesn't really work in Blender 2.91 for some reason, got the LTS version of blender and did some light modeling stuff in there with a quick tileset I made in pyxel.
Nothing to show there yet, maybe I'll have a screenshot once i get the 3d working on the engine.
The other work I've been doing is adding some more Lua bindings, but that's been boring and slow work, I tend to get distracted by gaming and other things when I'm working on something boring for the engine.
Theoretically, I have UI buttons working and all that, its just untested right now.
My main focus is to finish up all the Lua bindings I'd need right now to be able to have complete control over the ECS, then I should be able to start getting some sort of editor going. Maybe with buttons, we'll see.
Might update this thread or edit this post later today or in a couple days if I get more of the bindings working and have some screenshots or something.
Time again for another update.
First I wanted to show off the Unicode text rendering, since it took me ages to figure out how to store and render Unicode. I've yet to fully test unicode input. My Japanese keyboard input just defaults to Alpha-numeric. The chinese keyboard input sort of works, but I got a crash from trying to input a couple things with it, I guess I need to work on getting test automation set up for this thing since it likes to crash so often and so randomly.
One of the reasons that Unicode rendering took so long, is that it's impossible to pre-load all of the characters that could be used, so I needed to figure out how to load them on the fly. I still need to work out how to dynamically load extra fonts if needed, currently rendering is limited to the characters supported by the current font. I also should probably figure out how to unload characters if they haven't been used for a while, since GPUs do tend to have a memory limit.
On to what's new. I've started working on a profiler to help measure performance for the rendering and update threads, this was prompted by noticing how much of a stutter happened every time a screenshot was taken, and realizing that I may need to still be careful with how things are loaded, possibly even loading the images to the GPU in DXT format.
The profiler I made basically tracks the timestamp of each frame, as well as the deltaTime with the last frame to a couple really long arrays. Then a simple console command can be run to output that data as CSV.
I haven't quite figured out how to graph it to make the most sense yet, on the left you see both the frame timestamp and the deltaTime graphed on the same graph, with the x axis being just what cell it was in. This actually makes more sense to me, since a screenshot was taken in the middle of the capture, so big drop in frame performance was seen, which can be seen by the large disconnect in the recorded frame time.
On the right we see just the deltaTime being measured, which doesn't seem to make as much sense as I thought it would, I would have expected to see a large spike in that as well, but I don't, I just see a large gap in the frame timestamp. I might need to research this more to see why that would be, or maybe there's an error with how the graph is done.
Edit: found the spot with the discrepancy, I'm confused on what could cause this:
The deltaTime on the right doesn't match with the wide variance in the timestamp on the left. So that's fun.
I have a theory it could be a bug related to threading, I'll probably have to add either locks or make it export that from the render thread, since in this case it was exported from the update thread, not the render thread.
In the future I hope to be able to show a realtime graph of performance as part of the UI in engine, but I think this will do for now, even if it is a little bit janky. It works great for all the Power Point presentations I'm sure are in the future of this engine!
So in-between when I wrote that post and now, I've fixed my crashing, split the textures and fonts to load the data in the update thread, but load the textures to the GPU in the render thread, and added screenshot functionality to my engine.
So behold, I have an FPS counter which keeps track of how often the render thread runs per second, as well as a TPS (Ticks Per Second) counter which counts how often the update thread runs per second, locked at about 60TPS.
Also I have a console that has working text input.
I promise the texture rendering works too, I just was too excited from getting both my crashing issue and the new screenshot feature working that I decided I didn't feel like throwing a texture in there.
I'd say today has been a productive day
Maybe next week I'll have buttons and graphics to show off more of.
I guess there's this Gruedorf thing, may as well participate and hopefully have motivation/accountability on this project.
I'm not working on a game yet, just a game engine that I have code named "Nebula 3" which is my 3rd complete re-write that I've named Nebula, probably my 10th rewrite of a game engine in total, over the course of something like 7 years or so, but this one is the final rewrite I'm sure.
Basically Nebula 3 is a 3D game engine that uses an ECS(Entity Component System) under the hood this time, which I got pre-canned in the form of Flecs. Flecs lets me focus less on how to store objects in the world and more on functionality, which is great because all my previous iterations had 3d functionality working, but not a very good method of storing entities in the world.
Currently in addition to the ECS, I have Lua scripting working, and I've implemented a basic OpenGL renderer for now, and I even have input binding, and text input working. With a working console even.
There is a separate rendering and update loops, with all Lua calls for the input being handled in the Update loop due to some quirks with the ECS system not liking things changing while it is running the systems.
In addition, Unicode support is a thing that actually sort of works too, character input is given as UTF-32, converted to UTF-8, then back to UTF-32 to render the text, tested with Japanese, only issue is switching fonts to support the characters needed.
I can't show any screenshots as I found out that for some reason my full screen OpenGL window doesn't show up in screenshots, so I guess I'll need to implement in engine screenshotting capabilities, which was already planned, just moves the timeline up a bit.
Plus before the screenshots can be captured, I have another segfault to deal with, this time I believe caused by attempting to load things onto the GPU in the update thread, I need to queue items that need to be loaded to the GPU to be done on the render thread instead of the update thread. This was caused by re-arranging things to be done completely from Lua scripts instead of hardcoded C++.
Next steps include: fixing above mentioned bugs, working further on UI elements, and porting over old 3d rendering and model loading code from older projects,
The UI is planned to be "done" with an in-engine editor in a working state by the end of March 2021. With an in-engine console with console commands counting as an editor.