|
[ Screenshots Blog ]
[2010][
2009][
2008][
2007][
2006][
2005][2004]
Shareware and 2D For the entire month of December I experimented with 2D and NPR (non photorealistic rendering) graphics. It was in the hopes of creating a cross-platform 2D game, but I decided against it.
Screenshots to one day be posted here... |
| Late November, 2006 - Bumped Diffuse Passes |  |  |  |  | | | | Additive diffuse lighting passes, where the SM2.0 shader is capable of using many at once. Right now the max number of lights per pass stands at four, but it will soon be increased to max out the instruction limit. There is fixed attenuation that goes to zero (rather than approaching it) so that the light sources can be quickly culled against the view frustum. | |
| Late November, 2006 - Rigid Body Entities | | | | | | | The physics simulation has been connected with the entities. The boxes are not hard coded in, they are actual static meshes I created and placed as map entities in the editor with some attributes.
These map objects can have other specified attributes such as Lua function names to interact with others using certain event callbacks such as collide, pickup, etc. Basically if I was to leave the level work to others then they would simply create map entities and write the little scripts to go along with it, entirely apart from the core engine. | |
| Late November, 2006 - Static Meshes | | | | | | | | I've set up the entity system, a member of each world where each world contains the zone (level). The actual zone geometry is known to the physics dll (using ODE) and I'm working on getting the physics simulation to run. I'm having to destroy old paradigms that no longer work when it comes to the entities and the introduction of scripts and physics. | |
| Mid November, 2006 - Ambience and ZPass | | | | | | | | The scene is drawn to the zbuffer, if the option is marked. Then then scene is additively drawn using the successive techniques with a z-equals test. Shown here is the ambience pass. This is nothing new. | |
| Mid November, 2006 - Zone Format (batch rendering) | | | | | | | This is a wireframe view of the level format (*.Zon). It does not look like much, but a great amount of effort was invested into the pregenerated batches, where all the geometry (including indexes) are in the default pool of the GPU. I sort things by surface material (shader) and then by texture because each texture only belongs to a single surface.
At first I was writing down all the plans for some spatial partioning tree, even one that breaks down geometry for as few pixels as needed when it comes to the lighting passes. But this would involve dynamic index buffers and extra CPU work which I wanted to avoid. Things are better in static batches that sit on the GPU waiting to be drawn. I plan on precompiling several lighting techniques, each with a different number of lights to draw as as many as possible in one go. If I had gone with the partioning way, then ideally there would be one light per pass, but some huge walls could be covered with several lights meaning extreme fillrate. Plus there is not much world geometry as each level is broken down into zones, so excessive draw primitive calls are neglible.
As a side note the sm1.1 renderer can only do one light per pass, in which case partioning would be better, but it's not worth the effort to reduce the frame rendering by a few measly milliseconds. | |
| Mid November, 2006 - Input and Cursor | | | | | | | The simple straight forward DirectInput system has been written, but this time around all the key and mouse events are handled in one place. This is cleaner than having a bunch of conditionals scattered in the code, each of which check the device state and act accordingly.
It's in my best interest to limit the number of "Update" functions that tediously check and or set the same data over and over. Instead many callback functions are used - it's far from a huge speed gain, but the code is more intuitive and reliable this way.
These screen objects are rendered using SM1.1. | |
| Mid November, 2006 - Frame and Forms | | | | | | | Unlike previous projects, I'm laying down a LOT of framework code because the engine does need to have a somewhat large range of backend support. I've always used the same programming paradigm in all my projects, but not this one. It took some time to sit down and design the fundamentals, but things are working very well behind the scenes.
I'm beginning with the user interface. The fonts were originally from textures, but even with the characters mapping directly onto the texture with point filtering and no scaling, they would look like such crap! Needless to say I happily replaced it with D3DX fonts - hopefully they've been optimized compared to last year. | |
Gem Towers A game programmed in C# and Managed DirectX (MDX). |
| Late October, 2006 - Main Menu | | | | | | | Very plain and lite main menu system, no different than the ones feature in my other projects. I'm not too big on user interface code.
The game is not "done" but it is ready for an initial release. I'd rather have the game out there so I can make changes and add new features based on feedback. | |
| Late October, 2006 - Animation | | | | | | | | I would say that all the models and animation are pretty much done. There is a small frame state class that controls each animation based on sequences. This centaur is a place holder model. | |
| Mid October, 2006 - Trading System | | | | | | | | Between battles the player is capable of buying gems, gem quality upgrades, and tower height upgrades. The quality of the gem controls the recast delay and the height changes the radius of effect/damage. | |
| Mid October, 2006 - Gem Selection UI | | | | | | | I've thrown away three other ways of selecting a gem.
One was using the F1-6 keys and having a beam of colored light emit from the gem at the castle, but it was not intuitive and downright annoying.
The second way was to have icons on the side or bottom of the screen as in many MMORPGs, but it intefered with the smooth camera-scrolling feature handled by the cursor's location.
The third way was having the player click to select the gem tower at the castle using ray tracing, but it was too tedious to move the cursor back and forth when casting and reselecting.
But now I've settled with letting the player hold the right mouse button to select a gem in 2D that corresponds to the layout of the castle's towers. I've also added some flare effects for a polished appearance and the old target decals were replaced with cleaner and more simple textures. | |
| Early October, 2006 - Castle and Gems | | | | | | | | I've written most of the code for the castle and gems. Besides glow effects, this is pretty much how it will look in the final game. What is not seen is varying heights of the towers and gem quality - each is set to the highest quality and lowest level. | |
| Early October, 2006 - Targets | | | | | | | | Spell targets that fade when clicked. these are just ground decal effects (see previous entries). | |
| Early October, 2006 - Game Logic w/ Placeholders | | | | | | | | Two boats arrive for each invasion, one on each side of the island. They constantly spawn troops which march towards the castle. These troops must be stopped with magical attacks or defended using other arcane abilities. Of course there is more to it than that. These models are mere placeholders until Chris finishes the content side of things. | |
| Early October, 2006 - Fire and Ice Revisions | | | | | | | | The fire and ice were fixed up, they look more fun and friendly to look at. Blended effects such as these two will constantly undergo tweaking. In fact, they currently emit a fading flash of light upon each bolt's impact so this screenshot is not entirely up to date. | |
| Late September, 2006 - Table Fonts | | | |  | | | I use a tool called MudFont that generates an XML file and table texture of particular characters in a Windows font. The texture's RGB channels are all set to full intensity, but the alpha channel contains the filled characters. I used the antialiasing option in the tool and generate the triangles for the text lines when needed.
The rendering does not use alpha blending. The shader clips away any pixels where the texture's alpha channel value is below a small decimal threshold. | |
| Late September, 2006 - Firestorm | | | | | | | | Basically a billboarded sun and a flame tail achieved with an alpha texture and scrolling noise. It may be replaced with something more pleasing to look at. | |
| Late September, 2006 - Ice Bolt | | | | | | | | The effect was rewritten many times and several parts were thrown out or heavily modified. I just cannot get it to look any better, as of now. The colors are a bit dull and too similar. No further comments, it will look better when I come back to this. | |
| Late September, 2006 - BlendEffect: Lightning Bolts | | | | | | | | The bolt of this blended effect is achieved by a main lightning texture and static electricity texture. The second one vigorously shifts vertically to give a deadly electrical apperance. The two decals on the bottom grow outwards, but only slightly to depict the shockwave radius damage. | |
| Mid September, 2006 - Smooth Triangulated Decals | | | | | | | These decals are part of the blended effect base and they calculate triangles on top of the terrain. Rather than setting the vertex positions on the XZ plane to match the grid of the terrain and do hackey texture shifts, I chose NOT to align them, so instead I used the max height of the four surrounding grid points on the terrain.
Decals can be used for crater marks and currently selected building/unit highlights as in most RTS's. It can also be used for fake point lights, but the color operation is additive without any regard to the destination pixel so the ground can appear washed out. The existing dynamic light system is already optimized enough. | |
| Mid September, 2006 - Lighting Solution | | | | | | | | Chris adjusted the island and remade some of the textures. It looks much better now. The XML files now store all the lighting information to generate the lightmap and render models with. The ocean also attenuates to blend better with the sky. | |
| Mid September, 2006 - Blended Effects | | | | | | | | An abstract base effect that draws with any blending mode desired. Multiple shader techniques can be used and the system is aimed for flexibility over speed (no batching support which I used to do extensively). | |
| Mid September, 2006 - XML Support | | | | | | | | The worlds and terrain variables are no longer hardcoded in. The settings are loaded in by a separate class using simple System.XML.Serialization routines. This will allow changes to be made easily, and these changes can take effect even while the game is running. A liteweight program called XML Notepad 2006 is used. | |
| Mid September, 2006 - Dynamic Lighting Passes | | | | | | | | I've allowed for lighting through multiple passes. The lights are surrounded by boxes and generate triangle lists of nearby terrain geometry. They are drawn with additive blending and an extra intensity modifer can be specified, but here it's set to 1.0f. I'd say that it's quite efficient. | |
| Mid September, 2006 - UI and Cursor | | | | | | | | I'm really happy with the user interface (UI) system. It's simple, straight forward, and robust enough to handle any 2D effect I want. This cursor turns into an arrow while scrolling and uses the clamp sampler state to prevent artifacts near the borders of quad. | |
| Mid September, 2006 - Ray Picking | | | | | | | | I use basic matrix and vector math to compute a direction vector from the camera by converting from screen space to view and finally to world space. The intersection on the terrain is calculated with Tomas Möller's ray to triangle algorithm, but can become a bottleneck. I could optimize the algorithm by only testing within a proximity, but extreme height values would produce errors. I figure it's fast enough given that the intersection need only be calculated upon each mouse click rather than each frame. | |
| Mid September, 2006 - Game Objects | | | | | | | Every map object is abstracted from a base class - capable of doing common update routines using bitwise flags. This specific map object is named Bob and "he" is represented by a single green mesh model and "he" runs around while having the base routines calculate the proper bilinearly interpolated height value across the terrain.
Hopefully the fun stuff can begin soon. | |
| Early September, 2006 - Lightmap | | | | | | | | A precompuated lightmap texture using the sun's vector dotted with the normal. There is also occlusion tests using half of Bresenham's algorithm (along only one axis rather than two), for simplicity. | |
| Early September, 2006 - Mesh Based Models | | | | | | | | Here is the model interface that is constructed out of multiple meshes. The reason being so that the scaling of the matrix of a particular mesh can grow slowly over a second or two while the tower is being upgraded. The only format supported is Q3MD3 which I still use, it has everything I need. | |
| Early September, 2006 - Post Processing (saturation) | | | | | | | The backbuffer is copied to a full screen texture and then a full screen quad is drawn using the texture as a reference. Currently the pixels are merely taken to the power of some value, which in my opinion makes the pixels appear saturated with more color. Comparing the scene to the original makes it look as if a slightly transparent white sheet has been removed over the image.
Besides this, the post processing will soon be occupied by bloom and star filters. It will be optional. | |
| Early September, 2006 - Terrain Texture Splatting | | | | | | | | I use multiple samplers and one that encodes the intensities of the color maps in each color channel indepedently. The final image was saturated with the toning balance that I hope to achieve as a post process later on. | |
| Early September, 2006 - Land to Water Transition | | | | | | | | I really hated how the terrain would instantly cut off along the ocean line. The idea of doing some kind of two pass refraction came to mind, but that would have been more work than it's worth. I use the HLSL clip (clp in assembly) to render the terrain above and below the ocean's height. For below the surface, I use a fade scalar 'x' computed by min(pow(v.worldPosition.y / OceanHeight, 2), 0.6f). Very simple. Without a fade transition, a top down view makes the terrain appear to be floating above the ocean. | |
| Early September, 2006 - Ocean Shader | | | | | | | | This is a basic ocean shader currently with fake sky reflection and without refraction. Polish and detail will be added near the end. | |
| Early September, 2006 - Framework and Heightmaps | | | | | | | | I've only loosely designed the basic structure of the game, but most of it follows my personal paradigm. | |
Managed DirectX (MDX) C# and things like that. |
| Early September, 2006 - MDX Hello World | | | | | | | I wrote this personalized level loader in Managed DirectX. It is incredibly fast to write an application in C# as it requires very little code for the same output.
The only problem was reading the binary format into variable structured data. This required some utility class that performs a raw deserialize from a byte array into a "Type" through calls to the Marshal class (located in System.Runtime.InteropServices). | |
VS.NET Macros Macros in VS.NET are programmed in Visual Basic and are used to save a programmer time from tedious things. I for one am sick of typing code that converts function prototypes to definitions. |
| Late August, 2006 - Prototype to Definition Macro | | | | | | | | I wrote this VS.NET macro that takes highlighted function prototypes and changes them to empty definitions. This saves times from typing the usual curly brackets and such, plus function header comments can be added in as well. Wholetomato's Visual Assist does help with the function comments, but it does get tedious. I'm going to write a basic one for member functions and then upload them. | |
| Late August, 2006 - Function Macros | |  | | | | | | These macros turn a bunch of highlighted function prototypes or a class declaration into empty function definitions. You can customize how the comments are written - I just used a general approach that I personally do not prefer. | |
Room of Boxes For a while I was writing up the usual methods of Rigid Body Dynamics that I used in the previous years, but I found articles by Erin Catto and I decided to simulate his impulse-based methods in 2D. |
| Late August, 2006 - Finishing Touches | | | | | | | | It's pretty much done. The simulation runs at 50hz to guarantee stability across all systems. You can find it in the download section. | |
| Late August, 2006 - Antipenetration Method | | | | | | | | The reason I came up with this algorithm is beacuse my "Arbiter" code is different compared to Catto's. Long story short, the rigid bodies would bleed through each other like quicksand due to outside forces (gravity). You cannot simply push the bodies away from each other as that would cause a ping pong problem when it comes to stacking. I solved this by checking contact points of the bodies - if there are none then the force is linear, but if there are some then the force gets scaled and applied solely as torque along each contact point. It can jitter and penetrate slightly, but this is ok. | |
| Late August, 2006 - Tangent Impulses | | | | | | | | Tangent impulses are the changes in velocity along a nintey degree angle of the axis of least penetration. They are based on the friction values of both bodies. There is currently no bias penetration impulse so the bodies are constantly falling through one another due to gravity - the normal impulse alone is not large enough. | |
| Late August, 2006 - Normal Impulses | | | | | | | | An impulse (instant change in velocity, or extreme acceleration) along the axis of least penetration. Since the integration to the bodies apply after the integration calculations, there is less chance of rotation bobbing (jittering) when an object falls directly onto something with zero. | |
| Late August, 2006 - Contacts along the LP Edge | | | | | | | | The yellow line is the edge of LP (least penetration) with the usual separating axis theorem. There are always zero, one, or two contact points of where the impulses should be located. The points of greatest penetration along the edge (yellow) are projected onto it and clamped within the two edges to the sides of the edge of least penetration. | |
| Late August, 2006 - Framework | | | | | | | | It's lite and fast, that's all I can say. | |
Unnamed Project A project setup in such a way that I can easily create new shader techniques and experiment with them quickly. It won't be released. |
| Early August, 2006 - Polychromatic Light Shaft | | | | | | | I've added support for multiple color channels. The streaks of light is based on the cookie-texture which has blotches of red, green, and blue. In real life stage lighting, cookies are pieces of slightly transparent materials placed over a light source to give some sense of shape and color.
I think these light shafts look awesome, but they are extremely fill rate intensive. I'm using a hundred additive quads clipped to the light's frustum in the pixel shader with clip(x), rather than clipped in the CPU with planar arithmetic. I'm considering using a variable number of quads based on the AABB's length along the z axis. Once again, the light's AABB is oriented with respect to the camera, not the world. | |
| Early August, 2006 - Monochromatic Light Shaft | | | | | | | A layer-based approach to rendering a volumetric light shaft. The technique is based entirely off of ATI's method, which they based off of Dobashi and Nishita Volziz's research. It works by using a shadow map and cookie-texture to draw the scene with additive static billboarded quads facing the camera. These quads are automatically positioned with respect to an AABB in world space, using the min position and lengths. The AABB is not axis aligned to the world, but axis aligned to face the camera.
There are two layers of scrolling noise to give a sense of dust and debri in the atmosphere, but it's very subtle and must be observed in realtime to distinguish the effect. | |
| Early August, 2006 - Iterative Motion Blur | | | | | | | | A simple motion blur technique. I've never done motion blur before, but I am beginning to understand the more advanced algorithms to simulate the particular phenomenon. | |
| | I'm switching to LUA from Ruby for no specific reason. I'm not well-experienced with either just yet. I really like scripting though, it's definitely underrated. | |
| Late July, 2006 - FX Processes | | | | | | | | This dialog allows FX shaders to be loaded into a library and then freely appended to the active processes list. The sampler input / output is assigned uniquely for each member in the active processes list. | |
| Late July, 2006 - Render Targets | | | | | | | | Nifty dialog boxes to create render targets. The main one is not listed yet. I'm using Win32 and it's extremely easy, easier than MFC in my opinion. | |
| Late July, 2006 - Initial Pass | | | | | | | Part of the initial pass, showing the normals of an inwards facing sphere which will have a cube map painted onto it. The initial pass is written to a floating point render target which the end user can then manipulate with additional render targets and customly written shader passes - tone map, brightpass, supersampling pass, star filters, bloom filters, etc.. all within several dialog boxes.
I figure that certain shaders will require certain variables such as 5x5 Gaussian weights and texture coordinate offsets, therefore Ruby scripts may solve this problem. | |
| Late July, 2006 - Framework | | | | | | | | The general infrastructure with scene object dialog box. Every dialog box shown is heavily subject to change within the next few months. | |
| Mid July, 2006 - Basic Multi-threading | | | | | | | I've been looking into multi-threading, but not deeply. It seems simple in nature, but it can quickly turn complex from what I've read. For my applications, the payoff is just not worth it in the slightly distant future. My time invested into optimizations would be better spent through improved scene partitioning or SSE math methods. But still, I figure that I will use multi-threading for the user input to prevent the mouse from lagging at a high fill rate.
The screenshot was taken with the threads simply spamming printf calls in a while(1) loop. | |
| Early July, 2006 - SH Positive and Negative View | | | | | | | The positive (blue) and negative (red) views of plotted points about theta in [0,2PI] and phi in [0,PI] with radius given by the spherical harmonic function. The order is 2 and the degree is 4. The order can actually go from [-degree, degree] as integer values, where coefficients can be calculated for spherical harmonic lighting.
You can imagine theta as the spin about the Y-axis and phi as the pitch from the top to the bottom. Many references use different greek letters for phi. | |
| Early July, 2006 - Morph Shader | | | | | | | The beauty of constructing a mesh with the spherical harmonic function is that points about a sphere are placed with spherical coordinates, and then the value is calculated using the spherical harmonic function. I treat this value as the radius, but it is usually represented with a color map for illustration purposes..
This data structure makes morphing between spherical harmonics incredibly easy, using a single tween scalar in [0,1].
To smoothly morph back and forth between two, I use the function tween(t) = (sin(t*0.001*lambda)+1)/2, where t is the time in milliseconds and lambda is an arbitrary constant to control the morph transition speed. This is basic arithmetic, the range of sin(x) is [-1,1] so adding one makes it [0,2] and tween should be in [0,1] so the entire term is halved. | |
| Early July, 2006 - Spherical Harmonic Normals | | | | | | | I wrote an optimized method to calculate the averaged normal vectors per vertex, where each vertex is shared by four triangles. It could be optimized greatly one more time, but these spherical harmonics are generated very quickly as it is. The resolution is 32x32, but more complex ones require a much higher resolution to reliably represent the surface.
The white grid is the same object, but with the positions displaced by the normal multiplied by a small scalar. It appears that only half is rendered, but actually only half is visible due to half the polygons facing inwards (the cullmode is set to none). This has to due with the spherical harmonic function returning negative values, where the values are treated as the radius value - the surface is inside out, but these are the expected results for this particular input. | |
| Early July, 2006 - Inheritance, Loops, etc | | | | | | | | Looping and creating classes in Ruby is very easy, it's all very intuitive. Having a background in a previous programming language helps a great deal though. Ruby is very generous with usage of parentheses, but some warnings regarding white spaces hint that they're moving towards a standard. | |
| Early July, 2006 - Embedded Ruby & Script | | | | | | | | Ruby is an extremely easy scripting language to embed into C/C++. Ruby for Win32 can be downloaded from here. I chose the 1.8.2-15 Stable Release. | |
| Early July, 2006 - Spherical Harmonic Point Plotting | | | | | | | I attempted spherical harmonic lighting last year, but came out mostly empty handed. But now I'd like to learn the math much deeper and not just the essentials for the light-related graphics technique. The degree used to generate this plotted mesh is six.
Many demos and pictures use spheres and color values to represent positive and negative values, but I use the computed term as the radius instead. | |
| Early July, 2006 - GeoMipMap Sublevels #1 | | | | | | | Sublevel 0.
I've been reading about geomipmapping, geomorphing, chunked LOD again, and several other LOD terrain algorithms. I recognize that with modern hardware it's faster to just bruteforce everything if the terrain is small. | |
| Early July, 2006 - GeoMipMap Sublevels #2 | | | | | | | | Sublevel 2. | |
| Early July, 2006 - GeoMipMap Sublevels #3 | | | | | | | | Sublevel 4. | |
| Late June, 2006 - WinRAR 3.60b5 Evaluation Skip | | | | | | | There are a few checks to a particular variable within the program that checks for evaluation and number of days left. It's possible to change a few addresses and redirect assembly language jmp's to skip nag screens and such.
I remember this program used to allow registration through a dialog box, but it allowed users of such debugging tools such as SoftICE to "break" WinRAR as it does a string comparision check. The result was the ability to view the registers to create virtually unlimited serial keys. | |
| Late June, 2006 - Branch Skipping | | | | | | | | This requires no programming experience. The process skips a DWORD equals conditional using a hex editor, disassembler, and a few other tools. | |
| Late June, 2006 - Raw Sockets | | | | | | | | Raw Sockets using Winsock to observe incoming packets, their header, and data. They are not intercepted. | |
| Late June, 2006 - Windows Message Spoofing | | | | | | | | A program that grabs a windows handle based on its name and proceeds to send a windows message (WM_SETTEXT) to change its name. Specifically, hardcoded to change Internet Explorer's title after navigating to Yahoo.com. It also gets the process handle for other purposes. | |
| Late June, 2006 - MFC Direct3D, Dialogs | | | | | | | | Rendered image onto an MFC Cmfc9View, public CView, public CWnd object. I do use the wizard, but it takes manual editing to override member functions. The dialog controls (radio buttons, check boxes, etc) are not functional. | |
GrimSim Part FPS, part Sim game set in a gang environment. It turned out to be a complete flop in terms of game play. Plus the graphics were butchered to support an identical rendering method for a fixed function pipeline renderer.
Well, at least I feel as though the immense programming effort has improved the paradigm of my game projects. Plus I finished the darn thing, rather than pulling the plug on something just because it's a challenge. I'm not going to sit around moping and regretting the initial plan, I'll just optimistically attempt something better next time - perhaps a game with either modern or unique NP (nonphotorealistic) graphics. |
| Mid June, 2006 - Everything Else!!! | | | | | | | | I just finished everything. Yup, don't have much else to say. It's very easy to gaze at these progress screenshots, but it was more work than it looks. The game can be found in the portfolio section | |
| Early June, 2006 - Shotgun | | | | | | | | Shotgun weapon that can either be purchased for a very expensive price or found in a particular place which I won't reveal here. | |
| Early June, 2006 - Drug Addict Merchants | | | | | | | Drug addicts are only interested in buying drugs which can be found from dead drug dealers. The sale value fluctuates depending upon their addiction.
I added a zone boolean to restrict weapons in the home city - this rids the need for a "Use" or "Activate" key. Now the player activates trades by intuitively using the left mouse button. | |
| Early June, 2006 - Bloom #1 | | | | | | | | No bloom. It still looks very crisp and lively. | |
| Early June, 2006 - Bloom #2 | | | | | | | | The first method. The bloom and brightpass scalar is based on the maximum color channel value and then used to heighten all the other channels by the same value. I think it looks better than the others, but it is noticeable that very red/blue/green areas turn into white. | |
| Early June, 2006 - Bloom #3 | | | | | | | | The second method. The bloom and brightpass scalar is based on the average of the color channels. The red/blue/green areas therefore do not get washed out, but believe me that it does involve a bit more tweaking. I'll probably leave both methods in and have it changeable with a setting. | |
| Early June, 2006 - Slot Machine Minigame | | | | | | | A very basic slot machine minigame that can be used to gamble away money with. There are four different fruits and one BAR so the probability is very low, but still worthwhile if you're feeling lucky. There will be a small prize for two in a row.
Initially I wanted to do BlackJack but I'm running short of time. It could always be thrown in after the initial release. | |
| Early June, 2006 - DDR Minigame | | | | | | | The club features a DDR (Dance Dance Revolution) minigame. It is called as such in the source code, but the name is never mentioned in the final game for copyright reasons.
The music will not be synced to the arrows as that would cost a great deal of development time. Anyways, getting a high score will give money and prizes - items that increase the player's stat points. Maybe some shoes to run around faster (there are so many possibilities). | |
| Early June, 2006 - University Triggers | | | | | | | I'm turning this building into a University or some kind of recreation center that offers muscle and knowledge points in exchange for cash. Knowledge points are used for job promotions at the bank for a higher salary. Muscle points are used for job promotions at the crate area near the train station. The bank is better in the long run, but work at the train station can give quick bucks within a short period of time.
Items can offer a boost in these points. | |
| Late May, 2006 - Waypoint Features | | | | | | | Look around the city for waypoints such as this. The phone is owned by The Dragons gang and it triggers another waypoint at the subway station to China Town where swarms of drug dealers must be exterminated. They drop drugs which can be distributed to others.
It's now easy to see how this game can be easily extended - something a FPS with a linear story cannot do so easily. | |
| Huge update. I've coded most of the AI which should allow faction standings (teams) and path finding throughout a level without the need for nodes and such. It is a simple idea, but should be effective and real enough for this kind of game.
I also added support for ray tracing to body parts so that damage depends upon the location of the impact.
I figure once this particular part of the code is done, then adding more content such as maps and other novelty features should be a piece of cake. | |
| Late May, 2006 - Inventory | | | | | | | | An inventory system which allows items to give bonuses to the player. This means that Sims-like stats are not going to be featured as I don't have the time to do both. Weapons and ammunition are indendent of the inventory because there are no slots for such things as hands, torso, head, etc. It doesn't make sense for multiple pairs of shoes to give bonus run speeds, but it is a game after all. | |
| Mid May, 2006 - Weapon Code | | | | | | | | The zbuffer is cleared and then weapons are drawn on top, only in FFP mode. In FFP mode, the ambient cube cannot be rendered as lighting solution for a model, so an averaged color sample of the ambient six sides are used as each vertex's diffuse value instead. It's not visible in this screenshot, yet, but it is one of the last engine features besides user interface code. | |
| Mid May, 2006 - Fake Dynamic Lighting | | | | | | | | Fake lighting through additive quads. Originally I wanted to use proper blending with multiple passes on the screen, but that would've made dynamic lights coded for the FFP renderer very tricky. Instead, I use a sphere to brush (set of planes) test and then clip a quad along the edges. Then I use the attenuation as part of the alpha calculation. The problem is that this "light" is merely added, rather than modulated with the base texture and lightmap so it creates a washed-out look, but it's probably not going to be noticeable for gunshots and other flashes. The same method can be found in GTA: San Andreas, underneath most traffic lights. | |
| Mid May, 2006 - Nonpentration Collision | | | | | | | | The collision system is upgraded to support nonpenetration, within time t[0,1]. That is, something moving so quickly will always collide rather than ghost through it. This usually occurs during low frame rates and/or high velocities. It is possible to just limit the velocities and adhere to a frame rate requirement, but it is nice knowing that something like the player will never fall through the ground. | |
| Early May, 2006 - 3D Billboarded Text | | | | | | | | These characters are just particle effects, constructed using a font table. There are however, bad aliasing issues as billboarded quads are distanced away from the camera. I'm not concerned with it and won't go so far as to add another branch to the particle rendering for specific types of min/mag/mip filtering. | |
| Early May, 2006 - Scrolling Text | | | | | | | The red text you see smoothly scrolls across the building. This was accomplished by updating the zone to support such textures within a particular directory. The quad is not drawn along with the rest of the zone, but interestingly as a particle effect instead. It is a neat little effect. Other alpha blended surfaces can also be drawn easily by merely having the zone hand out static geometry and texture references.
I could extend the previously written font table code to write new messages in the world, but I think precreated ones are good enough. | |
| Early May, 2006 - Better Coronas | | | | | | | To me, the most annoying side effect when it comes to billboarded alpha blended effects (such as coronas) is the terrible aliasing that occurs when triangles are partially hidden by solid triangles closer up. A better approach is to disable the zbuffer and ray trace from the camera's eye to the corona's origin and do a corona position to frustum test. That way they are drawn over everything if the origin is visible to the camera. However they do not immediately cut on and off, but rather endure a very quick fade transition.
This is rather simple, but it is all the little things that make a difference. | |
| Early May, 2006 - Collision Hulls | | | | | | | | Perframe collision with no use of deltas (no interpenetration support for long position changes yet). The boxes surrounding entities (red) are pushed outwards from the ones that make up the zone (white). Cylinder to cylinder tests will be used for entity to entity collision. | |
| Early May, 2006 - Fog, Stencil-Tested Sky, Z-Equals Test | | | | | | | The map was also slightly updated - much better than previously. I'm adding potential optimizations for the purposes of benching marking later on (primarily out of curiosity).
Stencil-tested sky is where sky values are only written where stencil values are equal to zero (where the world was not rendered). This may slightly reduce fill rate when compared to drawing the sky and then everything over it. I am aware of the other method dealing with an enormous skybox rather than one surrounding the view point.
The Z-Equals test is when the world is rendered to the z-buffer during an initial pass, and then redrawn using a z-equals test.
As for fog, it's quite basic but can be tedious for multiple renderers. | |
| Late April, 2006 - Font Tables and XML Support | | | | | | | I used a third party program called mudFont to generate font tables and XML files for character information. I had always used low resolution font tables where the characters are evenly spaced, but now I parse XML files for specific ASCII character positions and lengths. This allows the font tables to be loaded successfully regardless of changes made. Right now the game code for these fonts are such that ANY font can be loaded in without any extra code.
mudFont does save the textures as 32bit targa files where the alpha channel contains the characters and the colors (RGB) are 255 for each texel. I wrote a little function to convert them if the game is running in developer mode. This way, the blending is easier because the RGB channels contain the character information too. To be honest I couldn't figure out the texture stage states for such an odd scheme.
The map you see is the home town. Just imagine "town" in Diablo I and II, except in a more urban setting. It's just something I whipped up so it looks a bit dull right now. | |
| Late April, 2006 - Dynamic Ambient Cubes | | | | | | | This was programmed with the entry of the second renderer (shader model 1.1). Models are now lit by a separate dynamically generated ambient cube. This is a 1x1x1 texel sided cube with the calculations performed on the CPU. Ray tracing from a position towards each of the "lights" are done per frame, where the sides are lit with a basic light equation consisting of the Lambertian dot product and linear attenuation. The cube (6 sides x 3 color channels RGB = 18 floats) is given to the model shader where the final light value per vertex (yes lighting in the vertex shader) is calculated.
At first I planned on precalculating many ambient cubes within the world and rely on hackey interpolation, but I knew that it would've been too glitchy without even trying. | |
| Late April, 2006 - RayTracing & Brush Data | | | | | | | I've converted the brush data, which is annoying to do because it uses planes which aren't under the same coordinate system as the faces. It's just a matter of figuring it out. Brushes are merely a collection of planes which construct convex shapes.
I will use brushes to allow passes of dynamic lights where only the intersecting brushes against an omni light's surrounding AABB (axis aligned bounding box) are rendered with the light. This allows for unlimited dynamic lights as well as the ability to cull them. I considered using clipped decals for the dynamic lights as in previous games, but this idea is far superior without the need for odd attenuation calculations. | |
| Late April, 2006 - Blended Effects | | | | | | | I just wrote all the code for peffs (short for particle effects). There are some dramatic changes in terms of how this was programmed when compared to previous implementations. It's far more optimized because of the shared algorithms and use of absolutely no dynamic memory.
I've also written code to prevent tedious Direct3D calls to such things as stream source, textures, render states, texture stage states, sampler states, etc. | |
| Mid April, 2006 - Lightmaps | | | | | | | | Lightmaps are textures that when multiplied with a base texture, the final surface appears to be lit. I'm not going to write another lightmap generator so I'm using some classic tools instead. | |
| Mid April, 2006 - MDX Skinning | | | | | | | | The format places the texture coordinates into OpenGL command lists. I ended up having to write a lot of nasty code just to extract them, plus the algorithm is slow so I'll have to make an obvious optimization which I should have done in the first place. | |
| Mid April, 2006 - Entity and DebugText | | | | | | | | Still doesn't look like much, but the entity framework has been setup as well as the actual game structure. I'm doing something differently this time - even special effects are inherited from the structure, rather than being independent with their own manager. The debug text (perframe in the top left corner) and debug file logging are two things that have always helped me develop my demos and games so I recommend it. | |
| Mid April, 2006 - Zone Lightmaps & Batching | | | | | | | | The zone is rendered in a precomputed batch manner where the static vertex buffer is filled once. If the worlds get too big, then I can easily switch to octrees and dynamic index buffers. The batched are sorted by lightmap and then texture, as I believe that it's usually most optimized this way. | |
| Mid April, 2006 - Zone Level Format | | | | | | | | Zone is a new level format I made where data from multiple files (three or more) come together to merge into one. I've also added textures, but many default render states and texture stage states haven't been set yet. Also, I realized that the backbuffer's dimensions for width and height were swapped by accident. | |
| Mid April, 2006 - MDX Format | | | | | | | | Doesn't look like much, but it is the Kingpin MDX model format. It was documented thanks to a guy named Tical. | |
| Mid April, 2006 - Framework | | | | | | | | As usual, it always begins with a Win32 window and DirectX initialization. | |
| Early April, 2006 - GameMonkey Script | | | | | | | | I've tooled around with Lua and Python, and almost Ruby and Perl. I'm sticking with GameMonkey for now, a very simple language. It was designed similar to Lua and it is much easier to embed in my opinion, than the other languages. | |
Physics Toying around with physics through equations written manually and through third party libraries. |
| Mid Feburary, 2006 - Newton lib, Ragdoll Animation | | | | | | | | A ragdoll is a set of rigid bodies connected to each other by different joint types. Usually a ragdoll is not so fat as shown in this screenshot. They also tend to have more limbs and joints at the elbows and kneecaps, but this was a mere test. There is a ragdoll data structure in Newton, but I couldn't find any good info on how to use it. | |
| Mid Feburary, 2006 - Newton lib, Ball Joints | | | | | | | | The red ball (which is a joint) is stationary. It is connected to the green joint whereas both spin freely and self collision (bounce) is handled automatically. Ball joints are used to construct a rag doll. | |
| Early Feburary, 2006 - MD5 Model Format | | | | | | | | The rocket launcher from Doom3 (only identity transforms applied). I wonder if I can use ragdoll physics to apply to one of the monster's skeletons... | |
| Early Feburary, 2006 - Room of Boxes | | | | | | | | The Newton library is definitely really, really easy to use. Can't think of much else to say, but I hope to eventually write [another] physics engine that mimicks the function names and data types (world, collision, box, callbacks, etc). | |
| Early Feburary, 2006 - Newton Cube | | | | | | | | This cube spins, but its torque is negative due to air friction. I chose to work with the Newton library, chosen by a somewhat coin toss. It's really good and I'm learning how others have developed the exterior of their physics engines (I looked at Open Dynamics Engine too). | |
| Early Feburary, 2006 - FFT Ocean Waves | | | | | | | | This was done last year too. It uses the Phillips spectrum to initialize values at time 0 (for ocean waves), then height values are calculated by using more equations and taking the real part of the complex number through the inverse FFT (fast fourier transform). This uses the rfftw library like last time. When animating, this looks very much so like a bed sheet with air pockets sliding across. | |
| Late January, 2006 - Cloth (without collisions) | | | | | | | | I was just wanting to see how stable this would be when changing the forces applied and the spring constant. Yes, spring constant. Attach multiple springs in 1D and you get a rope, make a grid out of them in 2D and you get a cloth, construct a 3D grid out of them and you get a... jelly thing. Like most things, this would look better with usual per pixel lighting and textures. | |
| Late January, 2006 - Rigid Body Dynamics (again) | | | | | | | | There is no friction, damping, or collision between two mobile bodies (just mobile-stationary collisions for now). For simplicity, the angular velocity is NOT integrated if there is a collision during that frame. This simplifies the time of collision solving tremendously. | |
| Mid January, 2006 - Multiple Velocities, Contact Points | | | | | | | | Further extended version from below. One velocity is subtracted from the other to solve for time 't' where one polygon is considerd moving, and the other is considered stationary. Contact points are calculated using the distance and equation of a plane, except simply in 2D instead of 3D. If a point is behind all the axes, then it is a contact point. | |
| Mid January, 2006 - MTD Solver | | | | | | | | MTD (min translated distance) solver. Further extended version from below. It actually saves the 1D projected intervals of both polygons against each separating axis. If every single one overlaps, then the polygon is displaced outside the other polygon, by going along whichever axis that allows it to move the least amount of absolute distance (determined by the interval). | |
| Mid January, 2006 - Time of Intersection | | | | | | | | Also uses the method of separating axes, but with the entry of constant velocities. The algorithm uses the furthest time 't0' that polygon 'A' enters 'B', and the smallest time 't1' that polygon 'A' exits 'B'. This is done for each separating axis (polygon side). If t1 is ever less than t0, then the algorithm quits as it has determined that the polygons do not ever overlap each other. Add a time <= 1.0f conditional, I forgot to do this. | |
| Mid January, 2006 - Method of Separating Axis | | | | | | | | I've implemented this method many times, so here is an interactive application that shows the method in 2D. It is different in 3D as it requires the use of cross products. As an optimization, you can test if bounding rectangles/squares intersect each other, before going through every single separating axis (the normal of each polygon side). The worst case scenario is when they are in fact overlapping. | |
| Mid January, 2006 - 2D Inverse Kinematics (stable) | | | | | | | | This uses the Jacobian inverse method instead, which is smoother, but takes a lot of matrix computation. The hardest part is the matrix indexing into the Jacobians when multiplying them to form a square 3x3 one. The code is a real mess as it got complex really quickly. It'll have to be redone, a few times. Links are to the power point I used, and free Linear Algebra videos. | |
| Mid January, 2006 - 2D Inverse Kinematics (unstable) | | | | | | | | Uses the cyclic-order descent algorithm. Each of these joints can rotate. The one closest to the middle translates all and the one at the end translates none. They rotate in order to find a path to the target (red circle). Usually limbs are used, but I merely made the joints' radii big enough to make it appear as a chain. | |
| Early January, 2006 - MS3D Format | | | | | | | | This loads only part of the milk shape 3D format, enough to render the entire thing. MS3D supports bones and joints that can be used for ragdoll physics and proper animation. | |
| Early January, 2006 - Leak Detection | | | | | | | | Performed by placing at least one point based entity (the triangle) in a leaf and then traversing upwards through the portals while flagging the nodes as occupied. If the created "outside node" becomes occupied, then the map is leaking and a path can be created (the red line) using points in the middle of the portals' faces. The code, rewritten for about the fourth time, ended up getting bugged somehow. | |
| Early January, 2006 - Auto-Generated Portals | | | | | | | | The green overlay are the portals. There is a wall missing on the side. | |
| Early January, 2006 - Exterior Polygon Removal #2 | | | | | | | | This screenshot shows what happens after the algorithm does its magic. This cuts down on a whopping seventy polygons(!!!) that the player inside this single box room will never see. For lack of better explanation, six initial portals surround the entire world and leafs are flagged as outside by traversing and staying on the side of the current portal's node, if that makes any sense. | |
| Early January, 2006 - Exterior Polygon Removal #1 | | | | | | | | I am not going to lie. This algorithm is very, very difficult. For one, portals are generated during the solid BSP construction process and reference into a front and back node, while the nodes reference into one of the portals. Split where necessary. | |
| Early January, 2006 - Solid-Based BSP Tree | | | | | | | | Slightly different in how the tree is calculated, compared to a leaf based one. Here, the app is rendering using line-strips that show the edges of the subdivided polygons, not the triangles. This was done to merely reduce the complexity when looking at the results. Solid based BSP trees use unique planes only once, and the leafs are always outwards facing from the center. | |
| Early January, 2006 - Leaf-based BSP tree | | | | | | | | The data was originally from a GTK radiant map file. The order of the geometry goes: planes to brushes to points to polygons to subdivided-polygons to triangle-fans. Everything is convex for now, but concave brushes can be handled by merely splitting them into two. Notice the subdivisions. The initial plane of each root is whichever gives the absolute best even ratio for polygons on the front and back. | |
|
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)