I decided today to take another look at how the build technique I’ve implemented for the engine is stacking up. Earlier in the project I setup CMake, and made it compile using the i686 – 32bit version of GCC Compiler, which works great in VSCode with the CMake extension, however it doesn’t do so well when trying to open the project in Visual Studio.
Visual Studio & Cmake Woes
From what I can tell, CMake should work great with Visual Studio too, however fails at last minute with warnings that it cannot open file mingw32.lib
I suspect this indicates that the libraries that I am linking too are trying to force MSVCC to link to MinGW/GCC, meaning I need to make CMake pick MSVCC compatible equivalents in my lib folder. Either that or Microsoft doesn’t want to support a Windows variant of GCC, though I doubt that is the case as the CMake tool in Visual Studio mentions many other setups (even including Clang).
Considering that, tomorrow I am going to attempt to swap out the libraries with MSVCC compliant ones to see if that solves the problem. I love using VSCode, but it would be massively beneficial to be able to boot the project in Visual Studo too, as the debugger is obviously better.
Debugging
Speaking of which, today when opened the project folder in Visual Studio, it actually highlighted a few issues that I was completely oblivious too. The toml library for example had an issue where the gmtime_r was missing. So I did the stupid thing and commented it out without reading further into it.
So apparently on line 233 the developer of the library actually explains what to do, and has commented out a solution using ifndef’s. So I’ll fix that tomorrow as well.
The more interesting issue was how I had setup the indices in the Batch.hpp file. Visual Studio alerted me to an issue where I am casting a long (or size_t) to an unsigned int.
Although it’s just a warning, and it’s worked for the last few months. I suspect this means that either the compiler optimizes this away, or there is actually data loss, however as I’ve not tested with large meshes yet, the problem wasn’t triggered. For now I have removed the cast, and forced the indices to use size_t, however I want to revisit this as I think the patch may have just moved the problem down water.
Previous Two Days
I have not written dev logs for the last 2 days, however I did also carry out work of note during them:
The Sprite class is now fully working making the code to render graphics much easier to read and use.
I finally got font rendering working correctly, by adding a code to work out how large the glyphs should be when drawing. A basic text wrap has been implemented, and an approximation for line height has also been added. On this end I believe I should really now add a Font class too to allow things like line height and letter spacing to be specified once, instead of constantly in the render event.