9/21/99 15:40:00 Well, to make a long story short, here's what I've been up to. I moved my cable modem from one machine to another. It wouldn't work anymore. After 3+ weeks of messing with it, I aquired help from a member of the KPLUG (Kernel Panic Linux User Group, San Diego, CA) and we finally got things going. It appears that the DHCP client in RedHat 6.0 is slightly more than faulty. I'm also having trouble with NFS, which I need to code Beowulf support into the game engine. It appears that RedHat 6.0 has a slight problem here as well. I'm back online now though, so I can get back to working on the engine. I'm also contemplating an update to ROS and NS2. I'd like to play them, and I know others would like to as well. I do have my two servers running now, 24.5.14.144 :27969 for ROS and :27966 for NS2. NS2 could be buggy though, it's an older code release. Thank the Linux gurus for CROND, in case the servers crash. :) 8/4/99 18:17:00 Wow, over a month sense my last plan update. Shamefull. Well, I've been terribly busy with my Real Job. Every time I turn around I have to solve another problem. Such is life I guess. :) Well, I haven't purchased the Alpha yet. The Permedia 3 is not yet available in PCI and there are no Alpha drivers that I know of. I have been putting off the purchase, but I am becoming anxious about it. I may just buy the darn thing and replace the video card later. I have made progress on the renderer though. I now have the ability to render complete objects consisting of up to 256 convex polygons. I have also added a configuration file to make testing easier. The configuration file allows me to change blending modes and turn features such as fog on and off. The next task at hand is to finish debugging a slight problem I'm having regarding the use of texture coordinate arrays. After completing an initial version of the renderer, I realized I was missing an important feature: compiled arrays. I forgot to add support for the use of vertex, color and texture coordinate arrays. Adding this feature decreases the overhead involved in rendering a 256 polygon object from many hundreds of OpenGL calls to only about 10 -15 per polygon. This constitutes a great increase in performance. I recently acquired some more PCs and am in the process of setting up a Beowulf cluster. This will go well with development plans because the engine that DP is working on will support distributed processing in a cluster. Once set up, I will be ready to start coding PVM modules and testing in a distributed environment. Now if I can just get RedHat 6.0 to work as well as RedHat 5.2 did... 6/2/99 16:30:00 Well, something else came up. Actually, a couple things. Memorial day weekend was one of them and I went on a camping trip, the camping trip from hell. I should have stayed home and wrote some code. The other thing (before the trip) was that I found the CS OpenGL renderer lacking and the code not easily understood. I decided it would be faster if I just wrote a new renderer from scratch and submitted it to the CS team for integration. I've begun doing this and I have the following code complete: - Polygon renderer - Volumetric fog - Texture manager using OpenGL hardware - Material property support for polygon lighting - New OpenGL TIFF file loader (loads TIFF files and converts them to RGBA textures) - RGBA texture support for transparent textures The code is much faster and shorter than the existing CS code, but this is because the original CS code was written for a software renderer and this code uses hardware rendering. I will be using some of this code as tutorial material for the DP web site in the near future. I plan to purchase an Alpha workstation this month and a Permedia 3 video card. This will accelerate development and allow me to develop code for the OpenGL 1.2 standard. I like q3test and I will buy Q3A when released, 'nough said. 5/20/99 12:10:00 After doing a little research last night, I've realized that it is possible to fairly easily put lens flare support in the OpenGL renderer for CS. I believe I can also add Real Time Shadows (RTS) using Mark Kilgard's RTS library. The lens flare algorithm was derived at MS for use with D3D, so the algorithm should be portable to the D3D renderer as well, but I leave that to the D3D coder on the CS project. The RTS library on the other hand uses the stencil buffer and will not work with some cards nor will it work (from what I understand) with D3D, but it is fast, and that's the key in 3D. I believe I can add both of these this weekend, unless something else comes up, as is often the case in Murphy's world. :) 5/19/99 19:50:00 Tomorrow I go to see Star Wars after work. It's funny how everyone in town seems to be going to the theater with the best seats instead of the one with the larger screen and better sound. Fine with me, I will have no problem getting tickets and I'll enjoy the film more :) I have repaired my makefile and the fog works. It's fast too - no performance hit that I can notice. I am now dealing with the rather bad blending support on my Permedia 2 card. I have been able to increase the speed of CS by approx. 25% by using an optimized dot product and an optimized cross product routine. In the process, we (my brother, Codermotor, and I) noticed something disturbing about some compilers, like egcs. Not only are they not the most efficient compiler - by this I mean that the asm code created from a C++ version of the dot product is not optimal for example, but they also do some bad things with overloaded operators. We found that all overloaded operators (well, modt of them) are compiled as subroutines, meaning extra stack operations. In most cases the extra stack ops take more instructions and cycles than the floating point operations for the operation itself. So, the moral to this story is: even though overloading operators may make the code easier to write, that doesn't mean it will run as fast. I suggest not using them at all and use a macro definition for your special math functions instead. Macros are always inlined and not compiled as subroutines. Back to the optimized dot and cross product in CS. These routines were overloaded operators and are used in several hundred places throughout CS. By replacing them with optimized code, engine data loading (startup calculations) and engine speed have increased by about 25% overall. The next step is replacing all occurances of these overloaded operators with macro definitions to decrease the function (stack) overhead. I expect to see another 25% increas in speed once this is done. I leave this to Codermotor as I have other things to do... The next thing on my plate is the OpenGL renderer. Not only am I implementing fog into it (I need to add some extra info to sector/thing definitions in the world files), but I believe I can greatly speed it up. I am expecting to purchase an Alpha workstation soon with a much better OpenGL card, so once I do I will be in a good position for OpenGL (and other) work. Meanwhile I suffer with my Permedia 2. 5/15/99 2:02:00 Well, I ran into a couple of problems relating to development tools. I was able to get all the fog code written, but I'm having trouble compiling due to a slightly hosed makefile. I am working on it. I have a new tool that I have used on NSDG. With it I am able to create metrics reports, object xref reports, call trees, and the like. You can see the entire NSDG project via the NSDG link on the "Games Development" page. 5/7/99 17:00:00 I think I have a good algorithm for fast volumetric fog in OpenGL. It is based upon my work in NSDG and ROS for Quake II. The CS engine renders polygons by sector where all polygons in a given sector are rendered before moving to a new sector. There is one exception when a polygon is a portal. In this case, the sector that the portal points to is rendered, and when complete, rendering returns to the first sector. This is a Good Thing. By giving a sector fog density, color, and formula (GL_LINEAR, GL_EXP, GL_EXP2) attributes, every polygon in a sector can be rendered with fog, without effecting other sectors. In the case of a portal, if the portal is in front of the camera - behind the fog sector with respect to the camera - then the sector pointed to by the portal will not be fogged, but will be obscured by the fog sector, as it should be. In the case of ground fog, or a shaft of light shining through a window in a dark and dusty room, there is a second method that can be used. This method involves using things for the fog. Things (like entities in Quake II) can be made transparent and if given the same fog attributes as sectors, they can be made into fog volumes. Things are rendered after all other objects in a sector, causing overdraw. This is another Good Thing as they will be blended with anything behind them, making realistic fog effects. If the camera is located inside a fog sector or thing, and looking toward the edge of the fog into a clear (non-fogged) area, then a little math must be done. As in real life, when approaching the edge of a fog bank, the fog density should thin. This can be easily accomplished by calculating the distance between the camera and the fog edge and adjusting the density accordingly. This is the only operation (outside of setting the initial color, density, and formula) that is not hardware supported, but it is a simple one. When using this technique in Quake II (without the full volumetric effects), there was no detectable performance hit using my Permedia 2 graphics card. This is s definite Good Thing. I expect to have the algorithm fully implemented by the end of the weekend. 4/22/99 15:50:00 I finally got a working project file for CS last night. We are now able to fully use Code Forge and RCS for the next version of NSDG development. It's time to move on to bigger and better things other than project and make files. For the next couple of weeks I will be looking over the Crystal Space code and getting familiar with it. During this process, I will be adding NSDG game content and picking out sections of code that are in need of optimization. I expect it should only take me about a week to become familiar with CS and how to add NSDG content to it. Other things I need to do: - Write a small test application for hardware accelerated volumetric fog. - Look over the OpenGL code in CS to see what functionality it incorporates and what should change. - Write a player/monster/weapon class data loader to support the upcoming PCE and WCE. - Get the network running properly and setup the ROS and NS2 servers again. - Buy a new HDD and get another computer for our cluster. - Get the brakes fixed on my Mustang, buy that ram air kit, and get laid more. (sorry, I digress! :)