|
[ Screenshots Blog ]
[2010][
2009][
2008][
2007][
2006][
2005][2004]
| Late November, 2005 - Cel Shading #1 |  |  |  |  | | | | In cel shading, lighting with usual NdotL scalars are calculated, but they are not used to multiply across the surface like traditional lighting. Instead the NdotL scalars are converted to the nearest shade of gray, of say, four or so. This is achieved by a mere texture fetch. So yeah, very easy. | |
| Late November, 2005 - Cel Shading #2 | |  | | | | | | Notice the cracks in the ink outline. An artifact in exchange for speed. The sihluette (and standard) method is better (not shown, yet), of which is edge detection and extrusion very similar to stencil shadowing on the CPU/GPU. This faster, yet cracked technique merely extrudes black shaded faces using the normal, with backface culling on. The hydralisk's skin needs to be fixed up a bit. | |
| Late November, 2005 - Metaballs, Marching Cubes | | | | | | | | This is one of those near useless novelty items in a programmer's bag of tricks. It's quite fun to look at, makes a neat screensaver or cool visual winamp plugin. The patent for the marching cubes algorithm has long been expired. | |
| Mid November, 2005 - Ambient Occlusion #1 | | | | | | | Ambient occlusion is (from how I understand it) the process of multiplying incoming ambient light on a mesh by a precalculated scalar. This scalar is based on the amount of incoming ambient light on a point on the mesh, whereas only the mesh itself can block the incoming light. Besides using ray tracing for each vertex, I draw the scene to a floating-point 64x64 texture from the vertex's point of view, down sample to 16x16, to 4x4, to 1x1, grab it, and use that as the scalar per vertex. Since it's per vertex, the normals need to be averaged. There is no cosine term - light from all directions have even distribution (unless blocked).
The entire process takes a while, at least two minutes for all 40k vertexes, yeesh. I dumped all the vertex data to a .clc binary file so that it takes only seconds to initialize. It's almost 22mb uncompressed. [update: code uploaded].
After some tweaks and added rendering techniques, the mesh could look very nice. The benefit to this in realtime, is that it's a mere multiply per vertex or texture lookup per pixel for a better looking mesh with an improved sense of depth. Rendering requires shader model 1.1, but calculation requires 2.0, unless using CPU ray tracing or some kind of hack. | |
| Mid November, 2005 - Ambient Occlusion #2 | | | | | | | | (averaged normal + 1) * 0.5, rendered while avoiding black pixels caused by negative scalar values in the vector. | |
| Mid November, 2005 - SH Lighting | | | |  | | | | Ack! This Spherical Harmonic Lighting is what I've been doing for the past week... and I'm still trying to understand the math to a deeper level. Spherical harmonic lighting allows prebaked global illumination (soft shadows, etc) per vertex with receiving light in all directions. It is very difficult and I'll have to return to it when I have a better math background. | |
| Mid November, 2005 - Spherical Harmonics | | | | | | | | image from Robin Green, Spherical Harmonic Lighting: The Gritty Details. "L" is the band, I only use up to four so there are a total of 16 coefficients. I use 50^2 samples. | |
| Mid November, 2005 - A* ("a star") Path Finding | | | | | | | | This is a console application that uses the A* path finding algorithm, but without any optimizations. There are more comments inside. The nodes do not have to be placed as a grid, but can be placed in random places in a map. Connections between each can be done through ray tracing during map compilation time. This is at least how I understand it... | |
| Mid November, 2005 - SW, 3D Perlin Noise | | | | | | | | This is software (SW) Perlin noise in three dimensions, so it animates in two dimensions where the third variable (z) is time. I did it in software mode because the previous versions with hardware acceleration were bugged or something (the animation was not smooth). Good for clouds and bumped ocean water (not displaced). | |
| Mid November, 2005 - Height Based Fog #1 | | | | | | | | Fog that is view dependent. Something that I have been toying with. It may not be very physically correct, but it is quite convincing. The fog scalar is the sum of the height and distance scalars with a few constants and math thrown in. The values can be stored in a 2D texture. | |
| Mid November, 2005 - Height Based Fog #2 | | | | | | | | A second screenshot. | |
| Early November, 2005 - MFC App | | | | | | | | A basic MFC window. I was wanting to get into tools programming, but it was held off shortly after writing this. The day I do invest a great deal of time into tools will probably be in C#. | |
| Early November, 2005 - Edge Collapsing #1 | | | | | | | | Edge collapsing, inverse of vertex splitting, used to reduce the number of polygons on an arbitrary mesh. I rushed things on the first attempt and tried to merge the edges with Garland's Quadric Error Metrics for best vertex placement and error measurement for edge collapse sorting, but something was off. Nothing ever works on the first attempt. The quadric error metric is for an extreme calculation optimization. | |
| Early November, 2005 - Edge Collapsing #2 | | | | | | | | 50% faces removed | |
| Early November, 2005 - Edge Collapsing #3 | | | | | | | | 20% faces removed | |
| Early November, 2005 - Depth Fail Shadows #1 | | | | | | | The volume is not extended to infinity and clamped to the far plane yet. I did zpass shadows about a year ago. It may just be my ignorance, but it's tricky to calculate the winding order of the quads forming the silhouette along the edges unless using a cross product in the middle of nowhere, on the CPU side. It must also be done whenever the light or object moves enough... but I'm probably just not seeing something correctly. There's still a bug somewhere, i can tell.
I disabled culling during the two silhouette passes and instead used the clip(x) pixel shader instruction called with a dot product times a float constant to toggle the culling order. It's wasteful because simply using correct winding order writes 0 pixels of the quads (red) if it was not an edge quad forming the silhouette. | |
| Early November, 2005 - Depth Fail Shadows #2 | | | | | | | White: front caps (no winding order calculations)
Green: back caps (no winding order calculations)
Red: silhouette quads | |
| Early November, 2005 - Kp Map (Q2 BSP Version# 38) | | | | | | | | Surprisingly different than the other Quake BSP formats. The reference I'm using is incomplete and it did not specify some essential stuff. This is rendering the edges. The faces which index into the edge table, which index into edges, which index into the vertices is bugged for now. No worries. This was intended to be used for a particular project, but it got called off. | |
| Early November, 2005 - Vertex Shader Fragments | | | | | | | | Besides using the FX framework interface "ID3DXEffect" to compile shaders from a file that are executed using a "technique," shader fragments can be used instead. Here, this vertex shader had its vertexes colored with the option of green or red, and the option of animated or static. I find this a great feature and very worth checking out. My version is based on the DX SDK example. This is great because now the vertex shaders become doupled from the pixel shaders. Things can be swapped around more easily. It's a tad more code, but much more powerful indeed. | |
| Early November, 2005 - Framework | | | | | | | | The application is built with a kernel that extends to graphics and an application singleton using a template. Subobjects such as camera and renderer in graphics are allocated with smart pointers, but passed as normal pointers. When graphics and any future managed singleton within the kernel dies, so do the subobjects, but automatically through garbage collection. I admit it takes a bloody long time to do and it's generally not worth it for small test apps, but it seems very beneficial in the long run for larger applications. | |
Doom3 Files I was just wanting to look through some of the formats associated with Doom3 out of curiosity. |
| Late October, 2005 - Doom3 Map (light entities) | | | | | | | | The .map file contains all the entities and more. It is also in text format so can be parsed however. Loading in one of the delta labs maps works fine, but takes longer. I just realized that this map is sideways, doesn't matter for now. Anyways, I'm pretty sure that the string value from the "target" key of each light entity is for the respectable shadow model in the proc file. | |
| Late October, 2005 - Doom3 Proc (Textured) | | | | | | | | Textured now, it's fairly straight forward. The texture coordinates' 'v' values may need to be eventually flipped along with the geometry's 'z' values to compensate for OpenGL->D3D conversion. | |
| Late October, 2005 - Doom3 Proc Format | | | | | | | | The Doom3 proc format contains indexed geometry. It is in text format so you don't need to know the format in binary mode. It is extended to other formats for materials, models (lightwave LWO), etc. | |
Assembly Language I spent a few weeks getting introduced to SSE and HL (high level) assembly language. I did it because I wanted to understand lower level code and the CPU better. |
| Early October, 2005 - SSE Particle Effect | | | | | | | | Here are 8192 particles being integrated with Euler integration. The method can be toggled with the space bar to compiled C or to SSE assembly. Compiled C runs at about 2000 frames per second on my PC, while inline SSE boosts it to 2900 frames per second. There is no way I'm going to write the entire thing in assembly. | |
| Early October, 2005 - Direct3D App in MASM | | | | | | | | I couldn't find any masm inc files for the DirectX library, so I had to convert parts of them myself. I found one for DX8, but it was for TASM. The file will expand when I need other interfaces or particular functions. It is of course, included in the zip file. Very important: read the new steps for DX programs above! | |
| Early October, 2005 - Win32 Program in MASM | | | | | | | | I put a few comments where needed. I'm pretty sure that switch statements are only found in high level assmebly (HLA). I'm still looking at all the pure assembly conditional handling, it's more interesting. | |
| Late September, 2005 - First Program in MASM | | | | | | | | Adds two numbers. I didn't make a hello world program because the world never replies back. | |
Demo4 This ended up turning all technical with little emphasis on any game whatsoever. Fortunately, I now realize a solution for a huge technical error that would always cripple the engine. I know, I know, most of what I do is unpredictable, even to me. I'm going to begin designing things both creatively and technically from now on. |
| Mid September, 2005 - My Room #1 | | | | | | | | An actual photograph. | |
| Mid September, 2005 - My Room #2 | | | | | | | | A rendered version. The white boards are the most convincing, but the proportion of some close up objects kill the illusion. | |
| Mid September, 2005 - Collision Handling | | | | | | | | While playing around with different kinds of collision detection approaches, I think that I have finally figured out the most suitable one. It took a long time, but now I don't have to fudge it in anymore. This will serve as a reference. There may still be bugs, but as with most things, the techniques get upgraded with each implementation. | |
| Mid September, 2005 - Collision Detection | | | | | | | | This is detection only, without respect to time steps. It's a single frame check if a point is within a brush constructed by planes. Full collision detection & handling is not even that complex, it's just I neglected it in the past while using the more intuitive approaches. Well, no more of that nonsense. I used this yellow box and the walls to collide against. | |
| Mid September, 2005 - Map Entities | | | | | | | | A rotating collection of "detail brushes". I currently do not compute the rotated collision data in system memory so they will not collide against the player as expected. These will be used as ceiling fans and other things. The actual level uses an identity world matrix, these use a custom 4x4 world matrix and 3x3 world rotation one, so only the vertex shader parts needed to be written for these. | |
| Mid September, 2005 - AlphaTested Shadowed Surfaces | | | | | | | | Same as in the previous demo. The scene rendering is very flexible for these sorts of things. As a hint, the shader uses the clip(x) function. You can view the documentation to determine how to clip a shadow map through a surface. | |
| Mid September, 2005 - 64bit HDR with Model Reflection | | | | | | | I'm very pleased with the results of the HDR, it feels stable and there aren't any flickering artifacts when moving around the room (the previous version suffered from some). I tried 128bit mode and there was no difference. Easier DONE than said, all it involves is changing the D3D format to be honest...
I want glows primarily from shiny spots on armor so there is currently a (4*CubeMap*Base.Alpha) term on the models in specific places depending upon the alpha channel.
It is quite tough to distinguish the reflection, click here for a close up shot. Lol, hopefully no one will get that close to see the microsoft lobby.
If you would like to do High Dynamic Range rendering in DirectX with star/bloom filters, then I highly recommend the example in the DirectX SDK. The one with two point lights and a painting on the wall. It is a good implementation and I used it as a primary source to to develop my own version. It was really tough the first time, but that's why it's good to do things in a test app before coding it into a project. There are just so many cool techniques and papers out there and so little time to do them all. | |
| Early September, 2005 - HDR #1 | | | | | | | | I want to emphasize what HDR does for those that aren't aware. But first, ignore the blur, that is the bloom filter and is commonly mistaken (I once did). The HDR controls the lum adaption to light in the current scene. If light in a scene is very bright, then staring at it long enough will cause it to dim. Likewise, staring at a dark corner will eventually brighten (if there is at least some light). | |
| Early September, 2005 - HDR #2 | | | | | | | After looking at a dark corner shortly before staring at these brightly lit walls. The black thing is the alien's tail, just ignore it.
As an example, the actual sun is really bright, a sun on a computer monitor is physically not so bright, but HDR adjusts the brightness of the monitor to trick the eye into believing that the person is getting used to the "bright" sun on the monitor. | |
| Early September, 2005 - HDR #3 | | | | | | | | One of the earlier screenshots, back when the lighting on the models were not correct and before realizing copyrights on this character. It purposely had a lot of bloom to merely emphasize it. | |
| Early September, 2005 - Softened Shadows | | | | | | | | It is very easy to blur a shadow map if it is a single texture with percentage-closest-filtering or any extensive method... But this is a cube map so six vectors are used from the actual ToPosFromLight vector, offsetted per element (xyz) in both the positive and negative direction. Therefore, six tests are used and it is probably not worth extra conditionals in the pixel shader. It's been deleted. | |
| Early September, 2005 - Omni Shadow Maps | | | | | | | | It uses six depth maps forming a cube, and therefore six frustums. If nothing changes, then the depth doesn't need to be updated. After the initial lights, this is an additional blended pass so it can be easily toggled on/off. The edges are not softened out yet. There is no specular light in this scene because I haven't made the albedo channel on the textures yet. | |
| Early September, 2005 - Dynamic Lights | | | | | | | | I realized that omni lights can be culled by surrounding them with a box and performing a frustum test against each. These surfaces are not bumped.
The font in the top left corner is outlined... and it allows it to always be seen despite color similarity with the actual background. | |
| Early September, 2005 - Models, game dll, etc | | | | | | | | Uses two dynamic vertex streams and one static one to reduce the amount of needless data. The dynamic streams are for the current and previous frames and the final values are the interpolated values between these two. The static stream contains only the texture coordinates for now. They are the same for every single frame which is why it's a static stream. | |
| Early September, 2005 - Framework | | | | | | | | | |
| Late August, 2005 - Many Things | | | | | | | Shaders, md3 models, game dll, etc.
I found that the easiest way to get all of the above up and running for debugging is to write every single one and then proceed to add the finer details later. Top-down programming. Here, a particular debugging map entity has the proper render flags and pointer to this particular model. The matrices and tags for the md3 still haven't been coded yet, it's not a big deal. The level is not normal mapped yet, though it IS using the three lightmaps and a constant normal of <0,0,1> | |
| Late August, 2005 - Octree Construction | | | | | | | | White lines are world geometry. I know with modern hardware it'll be faster to just render the entire thing, but not so with a larger level, especially with other operations such as collision detection and ray tracing. I'll probably delete the children that don't have any faces within them. | |
| Late August, 2005 - LEV3 Geometry | | | | | | | | Everything is going to be in wireframe for a while... at least until the octree works. The DX9 rendering and shaders will come second, then models, then collision, then game, then in the very very end, the DX8 renderer. Yes, it really is that simple, it just takes time and patience. I think I've found my first person shooter programming paradigm. | |
| Late August, 2005 - Foundation code | | | | | | | | I rewrote the interfaces for the DLLs a few times until I eventually got the hang of having such independent code. The keyboard / mouse input handling is in a DLL too. There will soon be a game DLL too... they're all written in such a way that the central executable only has standard headers such as stdio.h and windows.h. | |
LEV3 Level Format There are added surface properties from external material files. For now, there are ones for: bump, refract, and water surface types. All I would ever need. Adding another list is just 5 lines of code and it won't corrupt old level versions.
The main reason as to why I coded the new level format was to add support for map entities and three calculated lightmaps for normal mapping. I ended up not recoding radiosity in the final version of the level compiler. I was pretty sure that using shaders and render targets would allow me to do this, and it did. Now let's wait a few years for it to be feasible in real time.
These screenshots of the level format are rendered in a test application. |
| Mid August, 2005 - Fixed Lumel Coords #1 | | | | | | | | Using the lightmap packing below produces the side of as already said - sublightmaps bleeding into their neighbors. It's not a bug. It's expected behavior from min/mag/mip texture filtering. The texture coordinates along 'u' and 'v' are simply themselves, but minus epsilon if greater than 0.9 and plus epsilon if less than 0.1 before they become sub lightmaps on the table. Hmmm, not too hard at all. I posted this for anyone planning on using lightmaps. This is not normal mapped. | |
| Mid August, 2005 - Fixed Lumel Coords #2 | | | | | | | | Before pinching. The black lines are from other sub lightmaps, the red lines are from the cleared color of where no data is. You can view the texture here in case you need a visual representation. | |
| Mid August, 2005 - Fixed Lumel Coords #3 | | | | | | | | The actual packed lightmap texture for a visual representation. | |
| Mid August, 2005 - Map Entity Parsing #1 | | | | | | | | The specular highlights below were defined by an arbitrary structure of data, part of the file. I hated this, so I extended the .MAP file parser which grabbed light values, to support arbitrary entity parsing names while saving the attributes (key and value strings). It uses the BSP entity string, not the bloated .MAP file. | |
| Mid August, 2005 - Map Entity Parsing #2 | | | | | | | | The red line is the min to max of the bounding box. New entity types, such as doors and platforms can be added in seconds by giving the parser an entity name and an array of attributes (some can be required) to search for. It converts each value string to either a vector, float, or integer. These map entities are independent from the world geometry so they are not lightmapped. | |
| Mid August, 2005 - Lightmap Packing | | | | | | | | It uses a binary tree and recursion to merge many lightmap textures into just a few. There is no padding. I really hope that there aren't going to be too many artifacts from lightmaps that bleed into their neighbors as a side effect from mip mapping and texture filtering. | |
| Mid August, 2005 - Additive Specular Highlights | | | | | | | | Besides drawing a set of polygons with 'n' specular lights, I just drew the faces and then used additive quads that are coplanar to the face using a separate shader. The app solves for the center of the highlight on the surface. It looks horrible in action and I don't think it's worth supporting. Fortunately, it replaces the common method of using one or more specular cube maps. | |
| Mid August, 2005 - Soft Shadows #1 | | | | | | | | The blurring for each texel is the sum of each corner over 16, each nextdoor neighbor over 8, and the center over 4. It works well and light only spills over to its neighbors so doing multiple passes produces some nice edges. Trying to blur everything in a single pass with a larger area of blurring looks awful because of the low resolution lightmaps. The min resolution is 8 texels, the max is 32. | |
| Mid August, 2005 - Soft Shadows #2 | | | | | | | | After 4 passes. The entire map takes less than a second to compile. The low resolution looks better than I thought it would. | |
| Mid August, 2005 - Soft Shadows #3 | | | | | | | And at the exact same rendering cost, unlimited lights can be applied!
The application controls the ambience. It'll makes it easier to adjust this way. The cool thing is that the light sources become decoupled from the shadow edge softening so it becomes an independent step - more lights do not slow it down at all! | |
| Mid August, 2005 - Shadowed Lightmaps #1 | | | | | | | | This was a one line fix. I swapped the right and left faces of the renderable cube map that stores the depth of what the current light can see. The bump feature is currently disabled for clarity. This cannot be the actual problem because I triple checked the matrices for these faces, as well as the DX documentation again. I moved the light source around and it works as it's supposed to, I'll probably find the actual fix later. | |
| Mid August, 2005 - Shadowed Lightmaps #2 | | | | | | | | I a particular attenuation model to gather light values on faces, but only if they are within the light's finite radius. Long story short, using attenuation that only converges to zero would be problematic for several reasons. Instead, using a model that gets to exactly zero at the end of a radius allows very quick rejection tests of which faces the light can see and therefore limits processing of additive light to just these faces. | |
| Mid August, 2005 - Orthonormal Lightmaps #1 | | | | | | | | I decided that the extra cost of memory is going to be worth it. This is too efficient to be ignored. I recoded the initial pass (again) but I defined the lights as cubic shadow maps that add (and only add) light to nearby faces. This is a hell of a lot faster than CPU ray tracing that I did before. I'm repairing the in-shadow test so you can't see the shadows just yet. The specular term will be coded next, it cannot be saved in lightmaps... it needs a cube map using the reflection vector. | |
| Mid August, 2005 - Orthonormal Lightmaps #2 | | | | | | | dot product (texture normal, tangent space vector 1)
These tangent space vectors are constants used by both the map compiler and the game. The map compiler transforms the vector to the light source and dots it with the tangent space vector constant. The game only needs to dot the tangent space vector constants with the normal map and multiply each by its respective lightmap(!) | |
| Mid August, 2005 - Orthonormal Lightmaps #3 | | | | | | | | dot product (texture normal, tangent space vector 2) | |
| Mid August, 2005 - Orthonormal Lightmaps #4 | | | | | | | dot product (texture normal, tangent space vector 3)
The first screenshot is all of them added together. You may notice the edges around the cylinder walls which is due to the actual face normals being different. I'm not going to bother with averaging vertex normals within a proximity off... it's not that big a deal unless I feel like doing so later. Radiosity will come soon. | |
| Mid August, 2005 - Everything Rewritten | | | | | | | | Again. This time is uses Win32, how I should have done it in the first place. | |
| Mid August, 2005 - Precomputed Light->Surface Visibility | | | | | | | Doesn't look like much, but it was an attempt to light a scene sorted by light source. Each light renders a six sided box in the map compiling process, checking for visibility for every face (if a quick rejection test failed). The scene is drawn to the zbuffer and each light's list of faces are added on top, soon to be multiplied by the textures for a lit scene. The z-rejection is really fast.
Don't do this. It's not worth the cost of reading from memory because you have to use full screen blending. It was slower than I thought. Fortunately, the lights don't shine through walls and rooms that it can't see. | |
| Early August, 2005 - Radiosity #1 | | | | | | | Uses the GPU almost entirely. The light source is white. The excident light is pitch blue in order to demonstrate what radiosity does. I ended up rewriting all the lightmap code (again). It's really fast considering what it's doing.
The initial pass has no shadows from object occlusion in case you were wondering. | |
| Early August, 2005 - Radiosity #2 | | | | | | | After one radiosity pass...
It draws the scene at each lightmap texel with a Lambertian term, finds the average through down sampling, collects each, and then adds the samples to the original lightmap. This repeats for a few times because each lightmap texel relies on every other. It took a LOT of code. It's randomized to prevent an imbalance. | |
| Early August, 2005 - Radiosity #3 | | | | | | | After four radiosity passes
It's not too different from one pass, just a bit smoother... these are the expected results. | |
| Early August, 2005 - Radiosity #4 | | | | | | | Black and white version
Update: Radiosity can create true soft shadows that are not fudged in as what many realtime shadow rendering techniques do. Values near the base of a statue opposite of a light source see mostly darkness and those further up the shadow mostly see a scene with scattered light, therefore affecting what the value is. | |
| Early August, 2005 - Lambertian Pass (32bits) | | | | | | | The initial hard pass before the light scatters across an environment. Uses ray tracing for the first pass, just something to get started with. I'm convinced that it will be the slowest part of the process. The lightmaps are not pinched inwards to avoid artifacts yet, nor are they batched into tables.
It was rewritten several times and I'm still not happy with it. I'll probably just refactor it later. | |
| Early August, 2005 - BSP Data | | | | | | | | This is a test application. I use it to merely view the current state of the map file. For now, it's all the BSP and PVS data to ensure everything was packed correctly. All the points and planes are converted to the proper coordinate system. | |
| Early August, 2005 - LEV3 File Tool Framework | | | | | | | I'm probably going to be using this tool with further additions in the next half year or so. It must be written in a Win32 DX app in order to take advantage of the GPU performing bucket loads of calculations.
I used arbitrary colors because I thought it would look cooler that way. | |
| Early August, 2005 - Bumped Lightmaps | | | | | | | | Normal mapping with three precalculated light maps based on an orthonormal basis (yes, it is possible). It takes "only" five texture fetches and "very few" ALU shader ops to light an entire world that is batched by lightmap and texture. I could change the number of lights to more than a million and this technique will never slow down. The entire surface should not be precalculated because that would a DrawPrimitive call per surface. | |
| Late July, 2005 - Separating Axes w/ Nonpenetration | | | | | | | | Ignore the screenshot. This algorithm is used to detect collisions between convex polyhedrons with linear velocities. I use an AABB for the entities (including the player) when dealing with collisions against the level. If something shoots at ten million units per second from point c0 to c1, then this solves for a time 't' in the interval [0,1] that gives the exact moment of collision. I used to use a push back method, but it was too unreliable. | |
| Late July, 2005 - View Ports | | | | | | | | Commonly used in level and model editing programs to display different views. I planned on using this for a future game, but the plans had changed soon after. | |
| Late July, 2005 - Part of GTA3 Model Format | | | | | | | | You can kind of notice the car outline of this GTA3 (Grand Theft Auto 3) model format. There is only one page of [unofficial] documentation (won't post the link) and it even had an error with certain variable sizes which I discovered the hard way. The structures following the geometry is unknown leaving me forced to abandon this file format for any personal use. I'll just have to find car models in either 3DS or another format I know. | |
| Late July, 2005 - Decals Splitting (non coplanar) | | | | | | | | Same as below, except I realized that it's possible to extend the algorithm and shove the decal towards non coplanar triangles (here, a corner of a room). I can use this to throw some paint or blood on a static mesh and it will split accordingly. I didn't bother to calculate the triangles. I also didn't bother to calculate the texture coordinates, but that would just involve two quick lerps. | |
| Late July, 2005 - Decals Splitting (coplanar) | | | | | | | My algorithm splits an n-sided polygon with respect to a set of coplaner triangles on which it is placed onto. This gets rid of bullet marks, blood splats, and other decals, being rendered in midair off the edge of a wall. Another method involves the use of the stencil buffer, but I consider it both obsolete and slow.
Each decal begins as a four-sided quad where new points are created along the triangles' edges. In the end, the points are turned into a single triangle fan. The fan construction involves planar projection. The whole process is very fast. | |
| Late July, 2005 - High Dynamic Range (HDR) #1 | | | | | | | This is unlike that hacked version a few months ago that was based off of very misleading articles. The top screenshot was taken while staring at the light for a long period of time, the bottom was taken with the camera staring at a dark corner prior.
It's probably the most hardcore graphics technique I've ever implemented so far, but I think it was well worth it.
The best thing is that it simply distorts the original scene. I'm using a single lambertian light model. No ambience, no specular, just diffuse lighting. I can add perhaps 8 more and it'll drop the FPS by such a negligible amount (!)
All the lum calculations are done on the GPU. | |
| Late July, 2005 - High Dynamic Range (HDR) #2 | | | | | | | | A second screenshot, taken shortly after staring at a dark corner. The light intensity is still being adjusted on the screen. | |
| Late July, 2005 - High Dynamic Range (HDR) #3 | | | | | | | | A third screenshot, with a blue light. | |
| Late July, 2005 - High Dynamic Range (HDR) #4 | | | | | | | | A fourth screenshot, with a blue light. | |
| Late July, 2005 - High Dynamic Range (HDR) #5 | | | | | | | | A fifth screenshot, with a blue light. | |
| Mid July, 2005 - Glass Shader | | | | | | | | Very convincing. The only stream input you need for this shader is the vertex position, and normal... that's it! The rest are constants to tweak, such as the refractive index for each color channel. Doing this allows a subtle rainbow effect. | |
| Mid July, 2005 - Refraction with Density | | | | | | | | I draw the back faces and front faces while balancing the two with respect to distances and density. This is way, way, too difficult to get just right! I'm never going to use it. If you look closely, you can see the ring on the opposite side, this is the desirable result. | |
| Mid July, 2005 - Refraction with Density | | | | | | | | The water is a single quad and the entire scene only needs to be drawn once(!). The water is animated with procedural noise and the height derivatives are calculated (for the normal) each frame. It is easy to get a 3D refraction vector, but it must be transformed to 2D (using the camera vectors) in order to use the underwater texture reference for a refraction-color approximation. | |
| Mid July, 2005 - Refraction with Density | | | | | | | Similar to water, except the eye vector is in tangent space. There is also a 2 * tint_sampler to make things brighter. This texture isn't very good.
In the future, I will probably copy the the back buffer to a subrect for multiple layers of refraction... this is similar to how Half-Life 2 does it (except with better textures). | |
| Mid July, 2005 - Detail Textures #1 | | | | | | | Increases the visibility of a secondary texture as the distance from the view position to the world space position at each pixel decreases.
(yeah, like that's hard)
My detail texture is just noise. Ones with specks on it would probably look really nice =) . From what I've seen, usual detail textures are gray and get thrown into the range of [-s, +s] where 's' is some small constant. When added to the final color, it will slightly darken or brighten areas of the mesh. Mine is just added because it didn't work well with this particular texture. I think that I also tiled it too many times. | |
| Mid July, 2005 - Detail Textures #2 | | | | | | | | A second screenshot. | |
| Mid July, 2005 - Detail Textures #3 | | | | | | | | A third screenshot. | |
| Mid July, 2005 - Hardware Perlin Noise | | | | | | | | This Perlin noise shader is extremely fast and the computation is processed much faster than a software version. | |
| Mid July, 2005 - Occlusion Queries #1 | | | | | | | | This allows the hardware to return the number of pixels drawn between a begin and end state. This is used for occlusion culling whereas if you have say, a 100,000 triangle mesh encapsulated by a 12 triangle (6 sided) box, you can simply draw the box and if the pixels returned are at least 0, then you can draw the mesh because it is most likely visible (the outer shape can be slightly bigger). Software frustum culling before even drawing the box can reduce the number of expensive draw-primitive calls. | |
| Mid July, 2005 - Occlusion Queries #2 | | | | | | | | A second screenshot. Notice that there are no pixels of the model being drawn. | |
| Mid July, 2005 - Colored ShadowMap #4 | | | | | | | | The final image of the colored shadow map shader. | |
| Mid July, 2005 - Colored ShadowMap #3 | | | | | | | | The solid geometry with 24bit textures get drawn here. As far as I know, blending operations are not possible on render targets, but only with the back buffer. I believe there is a render state to allow this. I didn't bother to filter any of the edges out so the enlarged screenshot looks really, really, bad. | |
| Mid July, 2005 - Colored ShadowMap #2 | | | | | | | | You can notice that the stained glass door is included. This is part of how the algorithm works. | |
| Mid July, 2005 - Colored ShadowMap #1 | | | | | | | The color must be written in order to have colored shadow maps. You could also use a separate cube map whereas one is used primarily for depth and the other just for color, but the extra render target changes is far too high.
For some reason, I found that a 64bit (16bits/channel) texture for each face is not any faster than using 128bit (32bits/channel). 16bits per channel is enough though, 8bits make it look a bit crap. | |
Mage Duel A small project created after taking a crash course in OpenGL, Winsock, and basic networking. The interpolation code was thrown out as it became mathematically unstable.
In this game, you can either host or connect to a current game. Since this is P2P (peer to peer), there is a limit of one other simultaneous connection. Then, you run around a map collecting magic to cast spells against the other player. Only the arrow keys and space bar are used. |
| Early July, 2005 - Mage Duel Screenshot #2 | | | | | | | | Another screenshot. | |
| Early July, 2005 - Mage Duel Screenshot #1 | | | | | | | | It's done. I'm glad, because I kept wanting to add more graphics and content. | |
| Early July, 2005 - 2D Quads, Particles, Spells | | | | | | | | Alpha blended stuff, I don't care, it doesn't matter. I'm more concerned with the networking glitches right now. | |
| Early July, 2005 - Light Manager | | | | | | | | These lights use the ones built into OpenGL (fixed function pipeline). The brightness is based on the attenuated distance away from each triangle's vertex, interpolated across for each pixel. These may look like per-pixel lights, but they're not. They're a bit glitchy too (just imagine the dynamic lights in the original Everquest engine). | |
| Early July, 2005 - Cubic Spline w/ Quadratic Movement | | | | | | | | Obviously I could not take a screenshot of this super-smooth player movement so I drew a picture. The cubic spline interpolates positions between packets very accurately. I therefore threw away the "net-variable interpolation" as shown below because this is much more reliable. I created fake lag and allowed only one packet per second and it still ran fairly smoothly! Sooo... now I know why some games have the somewhat bug whereas players quickly fly through walls when respawning. | |
| Early July, 2005 - Models & Net-Variable Interpolation | | | | | | | | 10 player state packets are sent per second (will probably increase with respect to ping time) and the variables are interpolated based on the current state compared with the received state. There are tolerence amounts for if the delta is too high, whereas it will just set it to the received state. For example, the received state position is very far away from the current because the player has respawned - it would be freaky to have the player fly through walls towards this new position... | |
| Early July, 2005 - Level & Textures | | | | | | | This reminds me of old RPGs... in a good way.
I just realized that a win32 chat system and actual game in the same window do not mix very well - both fight over the key input. I can't find any windows message to check if the "edit" control is selected or not. | |
| Late June, 2005 - Client / Host & Chat System | | | | | | | | This is actually one application so writing both the host and client in one workspace felt a bit weird. It also takes longer to get setup over and over for debugging. | |
| Late June, 2005 - Level - CSG Addition (brush level) | | | | | | | | It's been a while since this was last done. It basically forms planes from a huge 2D integer array into brushes, splits the brushes into multiple ones (CSG add), where it can then perform CSG at the polygon level to get rid of overlapping and unseen polygons (not shown yet). Last time I did this directly at the polygon level, what a nightmare that was! This is pretty much an overkill, but I still think it's cool. | |
| Late June, 2005 - Asynchronous Sockets (P2P, TCP) | | | | | | | | Allows data to be received only when necessary to prevent stalling. The DX client screenshot showed flooded data received from the red triangle when the programs were shutting down. This console app pushes the triangle back... or pushes the camera forward depending on how you think about it.
I was doing a bit of GLSL too, but realized that it goes against the current topics to be studied =/ | |
| Late June, 2005 - Winsock (P2P, TCP) | | | | | | | Kind of straight foward, but there are many subtopics to be covered. I managed to connect to hotmail.com too, but couldn't really do much because my app was basically all ears. I have a feeling that every future game developed will have multiplayer support.
I noticed that with a listening socket set to a particular port allows firefox to stall, trying to access it. | |
| Late June, 2005 - Server w/ D3D Client (P2P, TCP) | | | | | | | | Really cool, but the Win32 server stalls when trying to receive a packet, until it does. I do believe that the server needs multiple threads in order to continue updating the form. Or WinSock 2.0, dunno, still looking into both. The code is really bad though, I'm rewriting it. I realize that this is listed under OpenGL, so just pretend it's not. | |
| Late June, 2005 - Packets (P2P, TCP) | | | | | | | | Well, this isn't really a "server" since it doesn't collect the packets received and send them back out to each client... it's really just a direct IP connection. | |
Demo3 I had a lot of fun making this and it turned out three times better than I thought it would. Some things were removed while polishing the game and I learned a lot about game architecture by realizing what not to do in the future. Hopefully the next demo will be just as good.
To make things a bit more clear, it's impossible to "beat" the game. Instead, each swarm gets more and more difficult as you must survive for as long as possible while purchasing ammunition and sipping down pepsi for health (or diet pepsi if you prefer). When you die, you can either try to beat your own score, challenge a friend, or shut it down and play a better game. |
| Mid June, 2005 - Demo3 Screenshot #1 | | | | | | | | Three recruits attempt to hold back the incoming swarm. What a mess. | |
| Mid June, 2005 - Demo3 Screenshot #2 | | | | | | | | The shadows you see are simply decals on the floor. It works well enough for me. The recruits can also cast shadows from the red siren's light. | |
| Mid June, 2005 - Demo3 Screenshot #3 | | | | | | | | A blast with the ray gun can kill many spiders at once. | |
| Mid June, 2005 - Fixed-Up Ray Gun #1 | | | | | | | | Added some additions to the effect. It's normally a bit brighter than the screenshot, but it had faded a bit at the moment that it was taken. The inner strip (see below) remained untouched. | |
| Mid June, 2005 - Fixed-Up Ray Gun #2 | | | | | | | | This muzzle flash is animated using three textures for each frame. | |
| Mid June, 2005 - Health Bars | | | | | | | | I just realized that Kingpin used a different health bar for each 10% of hit points. What a waste, you only need 1 texture, but two quads. It's also possible to have it tween between red and green, slightly forming yellow in between. Is this why a traffic light has yellow in between red and green? | |
| Mid June, 2005 - Shipment, Text, Dimmer | | | | | | | | The game is almost done. It just needs extra sound effects here and there and it'll be released in a matter of days. Also a few fixes and tweaks. Note: the font currently looks a bit better and is no longer green. | |
| Mid June, 2005 - Ray Gun #1 | | | | | | | | Basically there are two long series of quads (imagine 2 DNA strips), 1 green, 1 blue, whereas 1 has a z-angle difference of half pi. Therefore, looking at it from different locations causes it to change color. Sweet. The z-angles increment each frame.
It normally won't last long enough to take a screenshot of it from the side, in the final game. | |
| Mid June, 2005 - Ray Gun #2 | | | | | | | | Today, I coded most of the ray gun. I wanted to make it as surreal as possible to help cancel out all the orange and redness in the static scenery. Looking at it dead on causes sharp flower petal-like artifacts.. I cannot remove these without using the stencil buffer or some other hackish method - so I won't, it's unnecessary because they quickly disappear if the player is running around. | |
| Mid June, 2005 - Flaming Grenade Launcher | | | | | | | | Today I coded the entire grenade launcher. The screenshot was taken with the player strafing to the right, in order to see the projectile better. The flame is simply a series of quads using a 4x4 lookup texture. It uses a dynamic light to help make it more believable. There is a smoke trail as well. This is an old screenshot, the flame trail texture cells are now randomized a bit, to avoid such lame similarity. | |
| Mid June, 2005 - Machine Gun, Decals, Smoke | | | | | | | | The machine gun is done. It's really powerful, but shakes the screen as a form of recoil. The bullet decals and smoke took barely any code... it's basically filling out a data structure of variables and letting the manager take care of it. This manager handles every single 3D blended triangle on the screen. | |
| - completion of AI
- fake dynamic lights
- blood
- 3D sound and music code (fmod library)
- reloading (might remove it because it's annoying)
| |
| Mid June, 2005 - Movement Orders #3 | | | | | | | | Wave crosshair over a recruit to give him movement orders. | |
| Mid June, 2005 - Movement Orders #2 | | | | | | | | Hold right mouse button. | |
| Mid June, 2005 - Movement Orders #1 | | | | | | | Position crosshair across the map and release to give the order. Very simple. They automatically shoot any incoming enemies. Pointing at the ceiling will cause the waypoint to flatten onto the ground, so don't even try.
I will probably add a green line from the source to the destination if there is time to add little gimmicks in the end. | |
| Early June, 2005 - Weapon Code | | | | | | | | I'm not too happy with this shotgun model. I also removed the bloom because it was too expensive and simply not worth it. You can also notice how much smoother the spider is in this image. The specular reflection on the armor was replaced with a cube map lookup... the guns also use a cube map lookup. | |
| Early June, 2005 - 2D Graphics Framework | | | | | | | | Handles all sorts of things like multiple changing crosshairs and sprites with a texture table (digits). I had to hand draw those digits. | |
| Early June, 2005 - Collision & Ray Tracing | | | | | | | | I spent the day adding these two features in. The screenshot is a bit misleading, basically it's the debugging min to max lines of boxes that surround multiple world triangles to collision detect against ents and spiders (green is min, red is max). Collision detection of ents with each other / the player uses cylinders because it's much smoother that way. | |
| Early June, 2005 - Averaged Normals | | | | | | | | Basically it averages the per triangle normals and distributes it per vertex. The actual code is quite nasty though because it requires a linked list of linked lists (or vector of vectors). RGB = XYZ. There are other ways of doing it. | |
| Early June, 2005 - Demo3 Screenshot #4 | | | | | | | The telephone - where you call in for new recruits and buy more ammunition / weapons.
The boxes and tools closet - where new supplies spawn.
The door on the right - where the new recruits spawn.
The red glow - the siren of when the next swarm of spiders is about to come in.
| |
| Early June, 2005 - Demo3 Screenshot #3 | | | | | | | | The spiders spawn and come out from underneath these walls. It's obvious what game I got this idea from. You can see the bloom (softness) in this screenshot much better than in any other. | |
| Early June, 2005 - Demo3 Screenshot #2 | | | | | | | | This hallway cannot actually be accessed, it is only for looks from the outside. | |
| Early June, 2005 - Demo3 Screenshot #1 | | | | | | | | Purchase sodas from these vending machines to heal both yourself and your men. It doesn't make too much sense, but neither does stepping on med kits all day... lol. | |
| Late May, 2005 - Alpha Testing | | | | | | | The metal wall consists of two triangles, but its texture contains an alpha channel for which I can easily clip away depth and color by discarding it in a pixel shader. That is, it won't get written at all. I use the function clip(-1) if sampler.a == 0. I didn't know that you could even do that in a pixel shader until now, I found it by accident. Nice!
I'm going to be using a metal fence to make it a noticeable effect. | |
| Late May, 2005 - Entity Framework | | | | | | | | Including the rendering, but I need to make it look better. | |
| Late May, 2005 - Scene Addition, Textured | | | | | | | | It's now a spotlight with exponential falloff to give it a better look. Looking back now, I should have used a texture for the falloff. | |
| Late May, 2005 - Scene Addition | | | | | | | Adding the first and the third together. This new scene will now be bloomed based on where the positive "alpha" values are. Sweet.
The second render target is a weird color because Direct3D apparently cannot draw a texture with R32F in black and white. | |
| Late May, 2005 - Shadow Mapping | | | | | | | | Works well, will add the color onto the current scene to produce the final image. Enlarged image shows the depth map at the light's position. | |
| Late May, 2005 - Shadow Depth Mapping | | | | | | | | These are the two render targets. I drew the whole diagram and I'll need a total of 6 render targets! | |
| Late May, 2005 - Light System Upgrade | | | | | | | | Looking a bit better. I take full advantage of the alpha channel in the normal map and the actual color texture (knowing where to bloom and knowing the height, etc). | |
| Late May, 2005 - Light System | | | | | | | | Handles dimming, coloring, ranges, and applies the constants for each shader. | |
| Late May, 2005 - Textures & FX Files | | | | | | | | Looks a bit crap for now. Kind of looks like Duke Nukem 3D. | |
| | That's the recruit. I would have taken a screenshot of him in a model viewer with the original MD2, but I kept getting errors. Weird. The format for the MD2 is converted to a personal format called CMF (converted model format). | |
| | The Quake3 MD3 model format, once again. It's a nice little format, very easy to load. I simply do not need skeletal animation yet. | |
| Late May, 2005 - Demo3 - Framework & Level | | | | | | | | And so it begins... | |
Rigid Body Dynamics I coded a little physics application that allows boxes to topple over one another. There is no resting forces support and the collision detection/handling was the most challenging part. It was unfortunately too buggy to be used in any future project. |
| Early May, 2005 - OBB Collision & Impulse Solver | | | | | | | | The huge list displays each min/max dot product for rigid bodies A and B... in the absolute worst case scenario when tested with all 15 separating axes. I don't care about optimizations for now. | |
| Early May, 2005 - Rotational Forces & Collision | | | | | | | | This needs resting forces because it jitters. | |
| Early May, 2005 - ODE Solver | | | | | | | | You'll notice that the lines are a bit stretched. This is a little hack in D3D whereas the application window is larger than the app's backbuffer. | |
Demo2 An attempt at implementing HDR and bloom into a game, but the technical details were only stressed. I eventually pulled the plug on this when I realized how incorrect the shader code was written. |
| Early May, 2005 - Parallax Mapping | | | | | | | | Parallax mapping is an extra calculation on the texture coordinates w/ a height map to slide them based on where the viewer is.
I couldn't tweak the scale and bias to look any better than this. | |
| Late April, 2005 - Demo2 Screenshot #2 | | | | | | | | The gamma ramp is very high in order to give it a saturated look, similar to the older monitors that supported a FPM (fine picture mode) button. Specifically, the 'exposure' is 2.8, the 'kd' is 2.9, and the gamma ramp powers are 3.5 to each color channel. | |
| Late April, 2005 - Demo2 Screenshot #1 | | | | | | | | No comment. | |
| Late April, 2005 - Bloom - Original Scene | | | | | | | | The scene is rendered to this render target and is further manipulated. | |
| Late April, 2005 - Bloom - Final Image | | | | | | | | Final Image (toned)
It's a bit blurry though, makes me blind just looking at it. | |
| Mid April, 2005 - AI Path-Finding Nodes | | | | | | | | I got the idea from Everquest. | |
| Mid April, 2005 - MD3 Models (again) | | | | | | | | Say cheeeese :) | |
| Mid April, 2005 - Usual Normal Mapping | | | | | | | | Nothing special, no specular lighting yet. | |
| Mid April, 2005 - Demo2 Framework | | | | | | | | No comment. | |
Shaders With Render Targets Mostly shaders combined with render targets. Render targets (renderable textures) open the door to so many cool techniques and some techniques simply cannot be achieved without them. |
| Early April, 2005 - HDR and Bloom #3 | | | | | | | | A third screenshot. | |
| Early April, 2005 - HDR and Bloom #2 | | | | | | | | A second screenshot. | |
| Early April, 2005 - HDR and Bloom #1 | | | | | | | | HDR mixes very well with the bloom filter. Both merely manipulate the final image. This is going to be very popular in the game industry, but perhaps infamous after a few years. | |
| Early April, 2005 - Shadow Mapping | | | | | | | | Very easy to program. Personally I dislike how this is restricted to spotlights, unless using cube maps for diffuse lighting (as suggested by the sdk). | |
| Early April, 2005 - Shadow Mapping (depth map) | | | | | | | | The light's depth map. | |
| Early April, 2005 - LEV2 Format | | | | | | | | Features more data than the previous converted level format. | |
| | Does not look exactly like glass. The issue with alpha blending front-to-back triangles with anything but "ordinary additive blending" is noticeable in the screenshot, but not so much in real time. In fact, I didn't even notice this until a few days later. Therefore, I don't think sorting the triangles depending on view angles is worth supporting... at all. | |
| Late March, 2005 - Gaussian Blur Filter | | | | | | | Due to the use of 8 weights, despite the fact that they're "normalized", the brightness seemed to have increased, even on the constant blue background. The larger screenshot has a comparison of before and after.
The boxy look was fixed afterwards. | |
| Late March, 2005 - Height Based Fog | | | | | | | | The color was a bit exaggerated, just to make it more visible. This does not work if the view is within the fog, but in such a case, the solution would be to simply dim the entire screen. | |
| Late March, 2005 - Deferred Shading #1 | | | | | | | | Deferred shading is a method to use lighting in screen space as simple 2 dimensional quads. All triangles are rendered only once(!), and the technique allows going from around the usual 8 lights to the possibility of thousands. It however, is limited and texture bandwidth for additional variables other than the normal will kill the performance on higher resolutions. You also cannot use alpha blending, unless hacked in somehow. | |
| Late March, 2005 - Deferred Shading #2 | | | | | | | | A second screenshot. | |
| Late March, 2005 - Tube Surface | | | | | | | | A tube surface whose central axis is a helix. I made it because I remembered the weird background in particular levels of the game Alice, and also the main menu screen in the game Sacrifice. The points are positioned with respect to time of course. | |
| Late March, 2005 - Volumetric Fog | | | | | | | | Uses depth mapping. There is a linear falloff so a sharp border line on the walls is clearly visible. The jagged lines are not the jpeg image quality, but actually the smaller resolution of the texture render targets compared to the backbuffer. | |
| Late March, 2005 - Translucency Attempt | | | | | | | | There are no back-facing triangles on the base, located on the neck. It didn't look as good as I hoped it would. | |
| Late March, 2005 - Render To Texture | | | | | | | | The outer triangle is textured with a rendered texture - of which had its background cleared to blue and a colorful triangle rendered within. | |
| Late March, 2005 - Depth Mapping | | | | | | | | This renders to two different textures (render targets). Each one uses a 32bit texture consisting of just red (D3DFMT_R32F). One contains the back-facing distances and the other contains the front-facing distances. The app then changes the render target for a third time, to the backbuffer, and uses the 'w' component of the projected points to calculate the correct texture coordinates of each texture. | |
| Late March, 2005 - Multiple Lights Shader | | | | | | | | Multiple lights shader using multiple passes or a loop. I wish I had looked-up on how to do this sooner, instead of hacking the additional light source into the previous game below. | |
| Late March, 2005 - Disco Light | | | | | | | | Easy, but adding methods to prevent the light from not shining through geometry is the difficult part. | |
Demo1 The first of the demo series. I chose to begin working on many game demos (first-person-shooters) where each uses all the latest techniques I've learned.
This one makes use of bump mapping and vertex shaders to animate the MD3 models very quickly. The shadows were simply quads on the floor - sometimes the most simple method is also the most convincing if used correctly. |
| Mid March, 2005 - Finished Screenshot #2 | | | | | | | Scary. You can see a dead spider near the back. The pistol looks weird because it's out of bullets and the reload sequence had just begun. I also added some blood decals and adjusted the colors so that the screen is no longer saturated with yellow.
I've always been a stronger believer in tweaking variables around, it can influence a scene so much. | |
| Mid March, 2005 - Finished Screenshot #1 | | | | | | | | Alpha blended quads never get old. | |
| Mid March, 2005 - Rope Physics | | | | | | | | The light is just an alpha blended quad. The rope is a series of spring nodes attached to one another. The only forces given are from neighboring nodes, gravity, and a slight breeze, blowing from the portal. | |
|  | (no larger screenshot) | Basic 2D blitting for the GUI (Graphics User Interface). | |
| Mid March, 2005 - Font Table | | | | | | | | All the other 2D text uses DirectX's ID3DXFONT... of which is very precise, but very slow. This actual font table is low resolution, but it should work fine for my purposes. | |
| Mid March, 2005 - Fake Shadows | | | | | | | There are also very fake shadows on the bottom of each. This was just ten extra lines of decal code. It may not look very realistic, but it's better than no shadows at all.
This screenshot was taken before the issue of them going through the floor was resolved. | |
| Mid March, 2005 - MD3 Models | | | | | | | | These are the little critters that will be spawning almost nonstop through some magical-looking portal. | |
| | Code that allows decals of whichever texture/size to be applied to an arbitrary planar surface. | |
| Early March, 2005 - Weapon Shader | | | | | | | | Since D3D uses per-vertex lighting, I figured it would look awful than to just shade it properly. | |
| Early March, 2005 - Weapon Code | | | | | | | | The model is not properly shaded yet, but nevertheless it works. | |
| Early March, 2005 - Improved Logging System | | | | | | | I wrote this because...
"a loaded successful
b initialize successful
c successful"
can become difficult to read. This logger follows similar output compared to the previous released projects, but the code is much easier to use. | |
| Early March, 2005 - Level Shader - Yellow Light | | | | | | | | A bit too yellow, will need to be adjusted a bit. | |
| Early March, 2005 - Level Shader - Blue Light | | | | | | | | This is a new demo that I am working on. | |
| Late Feburary, 2005 - Kingpin MDX Models | | | | | | | | The only purpose for this format is to load and use the weapon models. Kingpin was a game developed by Xatrix Entertainment (now called Gray Matter) and it used the Quake2 engine. Therefore, this format is similar to the Quake2 MD2 format. | |
| Mid Feburary, 2005 - Stencil Reflection | | | | | | | | It looks awful, plus the texture coords got shifted during the matrix reflection - this is because I forgot to reverse the culling order when drawing the reflected geometry. | |
| Mid Feburary, 2005 - Fixed Specular Term | | | | | | | | Relatively fixed, screenshot taken before adjusting the angles for the side the highlight is on. | |
| Early Feburary, 2005 - Improved Attenuation | | | | | | | Something really annoyed me about the past "test environment" screenshot... The floor would darken in an unrealistic manner using Lambertian (n dot L) light times a false atten multiply. Here it is fixed. The distance "x", is squared on default and the linear term was dropped to avoid a nasty square root.
For those of you who noticed, this was origianlly titled as Fourier Transform from the previous website. | |
| Early Feburary, 2005 - FFT Water | | | | | | | | Fast Fourier Transform water, using a third party library for the actual algorithm. I admit that my desire (and need) to render it any better depleted soon after the wireframe part. | |
| Early Feburary, 2005 - Discrete Fourier Transform | | | | | | | | This is not the "fast" method. That is, it does not use the fast fourier transform. | |
| Early Feburary, 2005 - 3D Perlin Noise | | | | | | | | This is actually 2D Perlin noise, but the third dimension is time for animation. It is definitely not easy to tweak. | |
| Early Feburary, 2005 - Diffusion | | | | | | | | Without constraints, it apparantly condenses into a wavy surface in a single second. It then continues to flatten, which on the other hand, is very time consuming. The only reason I did this was out of curiosity. | |
Test Room This little application tested out bump mapping and some general algorithms including stair climbing. It wasn't meant to be released and it was coded for personal reasons. |
| Late January, 2005 - End of the Test Room | | | | | | | | I programmed this little application to test out improved game architecture. I wanted to experiment with how collision, shaders, and other game elements are combined into one project. | |
| Late January, 2005 - Basic Level Shader | | | | | | | | This supports one light source and will need gloss maps, specular lighting, ambience, and attenuation to complete it. Those are very straight forward additions, so will be fairly easy to write. I'm just happy that there wasn't one single bug. | |
| Mid January, 2005 - Better Collision Handling | | | | | | | | Features stair climbing as well. This uses the easiest method of AABB to AABB tests because it's as sufficient as OOBBs or cylinder to plane tests. There is no need to add support for "ghosting through walls" because the timer resolves such large delta spikes. | |
| Mid January, 2005 - MD3 Models (again) | | | | | | | | The models are precached so all that needs to be done is a memcpy to the vertex buffer. The tween (lerp) constant [0,1] will be handled by a vertex shader for the animation. | |
| Mid January, 2005 - LEV Format | | | | | | | | I had actually made this converted map format before, but this'll be the first time I use it. I like the idea of using my own formats, even if they are mere conversions. This way, I can store any kind of information I want, rather than being tied down to what is given. | |
|
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)