I'm sitting on a 3-D engine that originally had a dual purpose.
In the beginning, I set out to create not only a 3-D game engine, but one that could theoretically be rolled into all different types of software. At one point I had thought about incorporating it into a version of Linux, with the idea of building a sort of subsystem underneath the main desktop like Vista eventually implemented. During my initial research, I also came across Project Looking Glass and Compiz/Beryl.
After looking at loads of screenshots, web pages, demos, and articles, I realized Looking Glass wasn't going anywhere fast, unfortunately. I didn't know what I could really add to Compiz/Beryl that had not already been implemented, so I decided to focus more on game development. As time passed the engine developed into a sizable framework, with a few functions related to window management. I even implemented my own basic canvas feature, with buttons, sliders, image containers, etc. that could be spun around fully in 3-D. You can see some of my earliest posts on this blog for examples of that.
Despite all the work put into this project, it is still a little directionless right now. As a result, I'm going to take a brief detour and learn some Flash programming in order to get another, smaller game project done. This should, in theory, only take a few months at most. In the meantime, however, I am going to start posting some other semi-related ideas here that I'm not really seeing in use anywhere else.
You see, one of the other projects I've worked on over the years is my own programming language. It has never been fully implemented, and right now occupies thirty pages of a notebook as a bunch of sketches, thoughts, and ideas. It would nice at some point to incorporate some of those ideas into a scripting language that would plug in to the engine, but I need to better understand parsers in order to pull that off.
Speaking of parsers, I would like to come up with a better method of parsing a line of programming code. Numerous examples I've seen over the years that attempt to teach a developer how to build a parser tend to follow a similar process. With certain languages such as C++, I feel that learning the language is often made much more difficult because of having to fight with the compiler and all the errors/warnings that go with code that has an occasional error in it.
Case in point: when I was first learning C, I missed a semicolon in one line of code. Although I eventually found other errors, that single missing piece of punctuation threw an absurd 30 errors up onto the screen in the compiler. There really wasn't 30 errors, but talk about a fast way to discourage someone. Those types of situations tell me there are better ways of doing this. Hopefully I'll have time to pursue that soon.
