Later today I'm going to begin implementing the 'Opposing Face Geometry' algorithm for collision detection, which is geared towards tests between dynamic convex objects.
OFG is outlined @

This will almost certainly form a class just below CCullableThing, called something like CRigidBody, for it will comprise around 50% of the code involved in implementing simulation of rigid body dynamics.

For the those too lazy to read the article, this is nothing more than a set of optimisations applied to the "brute force" method of geometric intersection testing - instead of simply testing for collisions between all faces of objects A and B, we apply an initial boundingsphere check, and then we attempt to find the faces of A which are closest to the center of B, and vice versa... if the boundingspheres intersect, theres a POSSIBLE intersection of geometry, and the faces of each object closest to the other object are obviously the ones we should concentrate on :)
Posted on 2004-02-26 19:58:13 by Homer
Heya all :) More work was done on this fledgling :)
Objects which are part of a group selection are now rendered in wireframe.
A new class called CTerrainPatch was implemented.
A TerrainPatch is a textured flat surface which is a lot like a chessboard, and which can be HeightMapped.
We create an array of 16x16 of these.
Since rendering all of these dropped my framerate from a nominal 160 (yeah, need to work on that too) down to 47 fps, some light culling code was implemented, based on the distance from the center of each Patch of terrain to the camera position. This resulted in a framerate of around 120 fps. Optimizing the terrain cull code a little and adding an early-out check for objects whose Z coordinate relative to the camera is negative (is behind the camera) brought the fps back up to around 136. Not too shabby :)
Rather than get the object dynamics code up and running, I have decided to implement some surfaces to hit against first :)
I'm tempted to add client/server code already so that I can implement an online editor such that N developers can work on a level together :) I am forcing myself to be patient lol.
Posted on 2004-03-03 03:14:23 by Homer
Ok kids, public beta posting is @ - the source is not posted but the exe and resources are - I hear theres an issue in the zip I uploaded, ignore the paths in it, make a folder called Maps where ur exe lives and put the HeightMap jpg in it :)
Posted on 2004-03-05 11:28:37 by Homer
Here's a screenshot which shows the Terrain HeightMap engine in action.
As you can see, the texture applied to the terrain is algorithmically generated by blending several textures based on the height of the terrain. It works, and it looks great as far as I am concerned - a more careful choice of blend textures would yield a more pleasing effect. This is still by no means complete or perfect.
At the moment it takes about 20 seconds to zoom from one end of the world to the other, which means I really should make the world larger - but I'm already generating 256 textures just for the terrain, and there's going to be resource issues if I push much harder :)
Posted on 2004-03-05 22:00:10 by Homer
The TerrainEngine has been improved, and the "line artifact" at the edges of neighbouring terrain patches has been eliminated.
Also, the code for creating terrainpatches has been implemented in its own thread. This causes some minor memory issues when creating the vb's which doesnt otherwise occur, I'll look into it.
Posted on 2004-03-08 01:30:24 by Homer
The problem with creation of VB's has been eliminated, but it wasn't pretty.The way I repaired it was pretty pathetic, but nonetheless it did the job.Let me outline what the problem was and how I fixed it, since I'm sure others will encounter this problem. I had moved my code to create N instances of CTerrainPatch into its own thread, so that the application would not "freeze" due to the heavy-duty work of calculating the terrainpatch textures, and so I could start rendering as soon as the application started up, even though loading was still completing.
The Object Constructor method of the CTerrainPatch Class contains a call to create a vertexbuffer for that terrainpatch. It was sometimes failing, with the error E_OUTOFMEMORY. I knew I had plenty of memory, so I simply added code to jump backwards and try infinitely until we succeeded - the "just keep a'knockin" approach. The error was resolved completely :)

NOTE: Something else I changed in the CTexture class, in particular the CTexture_BeginDrawing function, remove the call to RtlZeroMemory.
Posted on 2004-03-08 22:34:47 by Homer
I think most of my problems have been resolved, I'd really appreciate some beta testing here - please, what nasty messageboxen, if any, do you see? :)
Try the latest at
If your zip appears to be empy, try using the Save As option. (you know, right click menu)
Posted on 2004-03-09 07:27:50 by Homer
Hi Homer,

I got the error

Failed to load texture C:/masm32/NewD3D/Textures/RockTest.jpg

Personally I do not think it is good to hardcode the paths to the images..

After moving it to C:/masm32/NewD3D, it works alright but kind of too cpu intensive.
Posted on 2004-03-09 07:38:58 by roticv
Thats interesting, there shouldnt be any hardcoded paths - I'll sort it out :) Thanks :)
Posted on 2004-03-09 08:07:38 by Homer
Try again a little later, I believe you have received the old copy of this, you can confirm this easily: if theres only one object in the Objects folder and its name is NewCube, you have the new one.
If so, NewCube is a text file, check the paths of its two textures are not fully qualified like that - only the very old version of this demo had hardcoded paths :(
The correct file is called, and is 775457 bytes in size.
The application contains filepaths, but they are relative to the location of the exe.
It requires folders called Textures, Maps and Objects, and all paths are included in the zip to make life easy if u want.
Posted on 2004-03-09 08:28:48 by Homer
Hi Homer,

I downloaded and got the following error when I ran it (Files extracted properly).

Failed to create texture


CTexture_BeginDrawing for : Invalid pTexture (it was NULL!)

CTexture_PutPixel : Cannot draw pixel before calling BeginDrawing
Posted on 2004-03-09 08:50:51 by roticv
You have to combine the package with the the old versions package - extract it over the old folder. I just wonder if you had the old code :notsure:
Posted on 2004-03-09 11:37:40 by Ultrano
No, sounds like he has the right version now, judging by the error messages (I've recently added extra error checking to CTexture) - the Failed To Create Texture (without giving a texture name) is interesting... only the terrain textures are ever "created".. this sounds like another resource allocation failure to me, is the error intermittent or happens every time?

The errors which follow are caused by that failure to create a texture.

I can't make that error occur on my system, so this is great feedback , thanks, I'll try to harden the texture creation function..
Posted on 2004-03-09 21:57:34 by Homer
An update was published, @ 775540 bytes...
the Texture Creation function was harded a little, let me know how that works out.
More importantly, code was added to detect which patch of terrain the player is standing over.
At the moment, I implemented it inside CTerrainPatch_Cull.
If we decide that a patch of terrain is close enough to the player to not be culled, we also test if the player stands above it.
The result is reported in text on the screen (=address of CTerrainPatch Instance we standing over)
I realized later that I can implement this much more cheaply by calculating the exact patch we are standing over in Demo_Render rather than seeking it among unculled CTerrainPatch instances during culling.Nonetheless, it's the first step towards object/terrain hit detection. It also leads me to think about making a terrainpatch the "owner" of a list of objects whose origins are within its XZ boundaries. This way, a terrainpatch would only have to test for intersections with "the objects it owns", which in turn means that by culling a terrainpatch we also cull its contents.
Posted on 2004-03-09 22:14:31 by Homer
As I said earlier, the zip contains relative paths already - rather than just extracting all the files to a folder, let Zip create a folder of your choosing and unzip them all for you, it will create the folders/paths needed and save you messing around.
The actual extraction path should be irrelevant - extracting to a folder on desktop should be fine. That just means you can "install" this anywhere you like.
Posted on 2004-03-09 22:18:11 by Homer
Hi Homer,

It works alright now. The only complain I have is that your program takes 36000+ (which I presume to be in milliseconds...) to load the textures.
Posted on 2004-03-10 06:59:31 by roticv
Yes well, be aware of the workload : we create 256 textures (for the 16x16 terrainpatches), each texture is 256x256 pixels, and is generated by reading from two of four textures based on Height, which is yet ANOTHER pixel read (Terrain HeightMap is a 512x512 jpeg, same as the terrain source textures).
Therefore, we are calculating 256x256x256 pixels based on the pixel colours from three OTHER textures, splitting each pixel into its rgb components, blending them, and recombining them... the workload is horrendous - but thanks to current implementation, we are still free to do other things - at the moment, I simply render a variation on the scene, without the terrain, until its "loaded"... theres no reason we couldn't be for example displaying a logo while the terrain "loading" completes :)
Yes, those are milliseconds :) This application currently has no throttle on its framerate, I am keeping an eye on the fps as I add / modify code. At the moment, theres a couple of major optimisations to be made to the object rendering code, namely that at the moment I render all materials per object, for all objects... I should be rendering all objects by material, for all materials of a reference object.
This would also eliminate the need for object instances to keep any materials or textures :)
By the way, as a benchmark, my 2100 Mhz AMD based machine performs the texture generation in 6500 , aka 6.5 seconds... quite bearable - 36 seconds would be painful to me - what framerate do you achieve? I get 80 to 120 fps on my geforce 4, usually floating around the 100 mark.
Posted on 2004-03-10 23:48:09 by Homer
Hey Homer

I downloaded the latest beta zip but it crashes the computer when I run it.

It starts up and displays the texture creation progress in a window, it finishes that after approx 24500+ms, then I'm assuming it tries to switch to full screen mode at which time the computer reboots and windows informs me that 'The system has recovered from a serious error'.

NO dialog boxes are displayed!!!

I'm using XPPro SP1, DX9.0b, GeForce4 Ti4200, Detonator 45.23, 512MB memory, and an Intel P4 2400MHz 800MHz FSB.

It's interesting that your AMD calculates the textures in 6500ms, my P4 should be at least that fast :confused:
Posted on 2004-03-11 05:46:55 by Maelstrom
All very interesting, since I don't use any "high-end" dx api calls that require special hardware functionality at all - for example, the terrain textureblending is 100% software. Do you see two crates during texture processing, sitting on a flat panel with a nuclear symbol texture on the floor?
I run XP sp3 here... no issues at all. I'm curious what could be failing so hard as to not even return with an errorcode :( No fullscreen, this is currently a Windows app, should work fine at any resolution including fullscreen, but fullscreen currently isnt implemented so that aint it :(

Could the problem be the "infinite loop" hotfix I made? IE, have you got a decent amount of system ram? (not video ram)
Posted on 2004-03-11 06:06:40 by Homer
Hey Homer

Ignore the above prob, I didn't realize you also needed the original download as well.
The proggy should have complained about missing resources tho.
Posted on 2004-03-11 15:29:02 by Maelstrom