CadBerry Devlog 2: VS Code, Modules, and Viewports
Wow, so much progress!
Wow. Just wow. This time last week, I was scrounging for any tangible progress on CadBerry. This week I almost did too much. I left off last week hoping I’d get a project creation screen set up. That was done by Monday 🤯.
I started by adding my code to manage ImGui. I mentioned last week that I was following The Cherno’s game engine series, and this was the last part before I’d strike out on my own. I added layers, a project creation window, and ImGui viewports.
At this point, it was FINALLY time to leave the safety of a tutorial and start making things on my own 🥳. Since I started planning CadBerry, I wanted to make it as simple as possible to modify. CadBerry will be open source, but you shouldn’t have to recompile the entire editor to add a window. With that in mind, I created modules.
Modules are my solution to making CadBerry modular (see what I did there 😃). When you start the CadBerry editor, it will look for any DLLs in the Modules folder which contain an extern c function to get the module. The module itself is a class that defines a couple of windows and a function to create those windows based on their name. This way, you can write an add-on that’s completely separate from CadBerry. Users can download any combination of add-ons — they’re completely modular.
With that in mind, it was time to test my module system. This very first version of CadBerry has two parts; the text editor and the build engine (more on that later). Since it would take me years to write a text editor as good as something like VS Code, I decided to just integrate it. I wrote a module (VSCodeIntegration.dll) that opens a VS Code window in your current project directory. The downside of this is that you have to have VS Code installed for this module to do anything, but VS Code is so much better than anything I could make in a couple of months and this lets me work on more important parts of CadBerry.
Speaking of more important things, I’m currently working on the CadBerry GIL build engine. I also want CadBerry’s build engine to be modular, but it’s designed to use an updated version of GIL that I plan to start writing this week in C++. Build engines will specify a couple of file extensions that they can compile and a couple of output types. Every 30 seconds, GIL will check if any files with those extensions have been modified, and if they have it will start a separate thread (using std::async) to precompile the file in the background. Later, when the user starts a build, CadBerry will get the build engine to build to the target file type using these precompiled files. Right now the GIL build engine will compile .gil files and .rzyme files (a textual file format I created to specify ribozymes) to .gb files (the GenBank file format), .cgil files (compiled GIL), and probably FASTA files.
With that said, I should probably get working on that build engine. Hopefully, I’ll have a basic GIL compiler in a week or two. Either way, see you next week 🙂
