1. The new engine work is going well. I am really concentrating on getting a clean interface developed for each required rendering system component, and it is helping me to understand my own system better than before (much of the system is similar to HG1).
2. While defining the interfaces from #1, it has actually helped me to write a small article on how the system works. More or less, when I have to explain how something works to someone it really makes me think about a topic deeply and consider all aspects of it. I need to work on it for a while still, but once it is complete, I'll probably release the article to see what you guys think about it.
3. I have been working on an MFC model viewer app using OGL for rendering. To be honest, I was pretty excited to use OGL and get some experience with it. My normal work doesn't even involve programming, so getting to work on something like that at work should be a bonus. However, I am quickly losing patience with the OGL syntax and programming structure. I don't know if its just because I am used to DX or what, but it seems like there are wayyyy too many function calls just to do some simple rendering. Even so, the results are worth putting all of the effort into and I am happy with how the viewer is working out.
The result of #3 is taking steam away from me wanting to implement OGL as one of my renderer types. In fact, I will probably limit the renderer implementations to DX9 and software for now. Eventually I will do the OGL version as well as a DX10 version, but I just don't have time for all of them at the moment...
Operating Systems CourseI started my course for the semester - Operating Systems. So far it has been really interesting and really solidified much of the knowledge that I have about how OSs work. Since it has only been two weeks of class, that says something about how much (or how little really...) I know about operating systems! But that is why you take courses, right??? To learn something [grin]
Anyhow, all of the abstract talk of what an operating system is and how it handles processes had me daydreaming in class about how this applies to rendering - and it is surprising how much it really does scale onto this problem set. Many of the latest GPU architectures rely on some form of thread control in the shader stages to keep things busy. The thread manager is really just an OS managing a bunch of processes.
On a larger scale, the game engine itself is quite similar to an OS as well. Physics, Input, Sound, Rendering, Scripting - they all can be considered processes that are competing for limited resources, which is usually memory and CPU time. It's going to be interesting to see what I can add to the engine based on the process control algorithms that I learn in the course...
My final year degree module on Operating Systems was one of the best I took for the whole degree. I think it's almost as fundamental as understanding lanuage and computability theory. Not so much as understanding how Unix/Windows do things in an applied sense, just the problems and general solutions - the characteristics for different memory and scheduling models is important to know about if you want to build complex software on top of it.
Jack