This is a regularly-occurring status update. More generally-relevant posts can be found under Features (see Creating a Game and Engine from Scratch for context).
This is the beginning of week 9.
What I have done
- The texture is now uploaded using the copy command queue instead of the graphics command queue
- Made a platform-independent interface for vertex buffers
- Made a platform-independent interface for index buffers and am using it now to draw the simple square
- Made a platform-independent interface for constant buffers and am using it now to draw two squares (where it is being treated as a per-draw constant buffer)
- Added the Tracy profiler
- Implemented an interface for CPU profiling that doesn’t require adding anything from Tracy in header files
- Implemented an interface for GPU profiling that doesn’t require adding anything from Tracy in header files
- Modified the PIX for Windows integration to work more like Tracy
- Build system
- Added a Lua function to resolve paths
- This makes it easier and nicer to generate header #include files so that resolving environment variable can be done automatically
- Fixed a tricky bug when adding multiple levels of filters in Visual Studio
- Fixed a bug when several different C++ source files specified different ways of building that were independent of the general way specified for the target
- Found a workaround to help Intellisense give proper x64 suggestions (instead of x86)
- This didn’t affect the actual compiled or linked files, but it was a relief to finally have pointers and struct sizes reported correctly
- Added a Lua function to resolve paths
Next Steps
I am getting stuck (classic “analysis paralysis”) on trying to figure out how I want frame updates to work. This is kind of where I got stuck previously when I was doing the “beam racing” stuff, and even though I finally gave up and moved on I am running into it again with a different context now while I am trying to figure out how to have the application tell the graphics system what to render and when. It would be easy to just do something simple and move on and maybe I should, but one of the personal goals that I’ve wanted to do with this project is to have fixed simulation timesteps that are independent from the fixed display refresh rate, and what I want to accomplish is pretty straightforward even though I’m getting hung up on details.
- Implementing the Tracy profiler has been a big help, and I am now able to better visualize what my code is actually doing. I need to somehow get something in place, even if it’s just rudimentary, so that I can have simulation updates (that can run both slower and faster than the display refresh rate) and then choose the appropriate time to render an interpolation between two of them.
- I still need to implement a way in the build system to compile shaders offline and then a way to load them at runtime, even if very simple
- (Recall that I am avoiding the standard library and general-purpose memory management, which is why some of those seemingly-simple tasks involve more work than might be expected)
- I want to add a camera and 3D transforms