If anyone had been aware of the long hiatus on this blog, they wouldn’t mind, cause this would be worth waiting for. I didn’t think I would ever see anything quite like this. But after spending most of my life typing into syntax highlighted code editors, it’s inevitable that I would wind up making my own. And I’m going all the way with it, just like Visual Studio. It will have Auto-Complete, Code Generation, and hopefully I can even get the ToolTip help through Reflection.
The farther I get with this, the more ideas I have of my own, rather than just cloning Visual Studio. At the same time, I’m slightly intimidated by my own high standards. After so much time using the most over-engineered IDE in the world, and still feeling it’s not good enough, it’ll take a little effort to get this to the point where I prefer it over Visual Studio. But I don’t see why not, it will be worth it.
Loading and compiling code went easier than I expected. I don’t know why I was worried, other than that it was unfamiliar territory. But thanks to Visual Basic’s excessively intuitive code, I can grasp these engineering-level concepts without the syntax getting in the way.
In order to load multiple files of code into a Dot Net Assembly, they have to be “compiled” into one file. This gets complicated for several reasons. All of the Import Statements need to be at the very top, you have to collect them and pull them out so they don’t wind up in the middle of the Big Code File.
The second complication is Partials. I love being able to split a Module or Class into multiple files, to keep things organized. But to get that code into the VBCodeProvider, all the code inside each file’s Public Module / End Module codeblocks needs to be concatenated. So as the JEOZ CodeCompiler tears through the files, it makes it seem to the compiler as if they were originally one.
And since this could get intense with a much bigger project, I made sure to keep DateTime stamps of the code files. When the FileSystemWatcher detects that you’ve saved changes, it only loads the files that have been modified. Everything else is kept in memory so it can recompile as fast as possible. I’m still kinda surprised that I can do all of this in a background thread, so the game keeps right on ticking while it completely rebuilds part of itself.
So far I’ve moved all of the User Interface setup, input handling, and game logic into the external code. There’s a small tradeoff in that you can’t debug the code while it’s running. You can only get Stack Traces to find out what happened. But for the most part it’s even more amazing than I expected. Dot Net is able to just merge and adopt another part of code into itself. Using Reflection you can find and bind to all of the functions in the compiled Assembly.
It’s probably because I’ve been using Visual Basic since I was a teenager that I got so used to how convenient everything is. Things like AutoComplete and Edit-And-Continue have completely spoiled me with their convenience. It kept me from being able to tolerate harder C-style languages long ago, but at the same time, it forced me to make my own system that works exactly the way I know that it can.
So the result is that coding in the JEOZ Engine is going to be as easy and lazy as I can possibly make it. Any time something can be made automatic, I go out of my way to do it. That’s the kind of “laziness” Bill Gates was looking for in the 80’s.