I've been working on my engine some more :)
It now supports the following features:

-referenced textures (N materials share a texture)
-referenced meshes (N meshes share a reference mesh)
-instanced dynamic objects (objects have unique physics)
-bounding box and bounding sphere culling options (option for a third layer, simplified shell geometry around complex object)
-object-relative "mouse pick ray" intersection testing

Intersection tests with "mouse pick ray" are only performed on objects which have passed initial culling test(s).

At the moment I can drop objects with the left mouse, and select objects with the right mouse. Multiple object selection is possible (grouped selections).

There's currently a small issue with deleting selected objects to be sorted out, and then I'll be continuing toward a simple rigid object physics simulation engine :)

All source is object-oriented and is based in Ultrano's ATC oop support.
Show your interest, and I'll show my source :)
Posted on 2004-02-22 00:28:17 by Homer
Afternoon, EvilHomer2k.

I'm showing my interest.
Now show your source :).

Posted on 2004-02-22 03:10:11 by Scronty
Hi Evilhomer2k
I am showing my interest
show your code
its probably better than my 2d .bmp to 3d method
redrawing map, whenever I crush windows+ render to floor texture with splinter, texture info also stored in .bmp
objects#/textures# coded in .bmp

Posted on 2004-02-22 06:50:18 by daydreamer
I was planning to clean up the codebase before I made it public, but nonetheless, here is the link to the complete project source, less libci.lib and uuid.lib, some 5 and a bit megs..
I'll still clean up the code and repost it later, as I'm not satisfied with this code yet.I'm wander off now and make a link , u can find it at http://homer.ultrano.com

We are playing with a single object in this example, but adding new ones is not difficult. The object has 2 Materials, this source assumes that if a meshed object has >1 materials, that the last material is to be alphablended. I took the liberty of providing a textured box with a textured translucent surface. The art is crap, it isn't the point. Use left mouse to drop an object where you stand, now use the cursors to move so you can see it (lol) , use space to drop craploads of objects while moving fast to make walls, and use right mouse to "select" objects, should work in any screen resolution, window size, and full screen, this demo it will rotate the object(s) selected, I'll work on some tools as I go, right now I'm trying to decide which rotation model to go with for objects as far as implementing rigid body dynamics is concerned:P
(Oh I forgot, middle mouse button to "regrip" the world window, little buggy)
If anyone wants to get involved with this source as far as some kind of public project is concerned, I'm open to that, on the proviso that the source remains completely free of any and all legal obligation and remains available to all.
You may carry with you any posted code from this project and use it as you see fit, but you may not express ownership of any code which you contribute.
Your source must be made available to other programmers to use as they see fit, with no legal repercussions from or on the behalf of any contributor or contributors.
Anyone may profit from this source in any way, but must not deny anyone else the opportunity to do so.
Posted on 2004-02-22 06:55:45 by Homer
EvilHomer2k, your interest is obviously bigger than my interest. So, showing mine would only make me feel inferior by comparision. Can I just stand here with a blank look on my face until I understand what you are talking about? :grin:
Posted on 2004-02-22 11:53:11 by bitRAKE
pmsl :grin:
Sure but once you figure out what I'm on about, can you please explain it to me?
lol, currently reading for the maybe 50th time in my life the section on dynamics, mechanics and properties of matter in my 1971 print of Nelkon & Parker's Advanced Level Physics, one of my more weighty and more favored tomes. I expect to have implemented some kind of scenegraph-based dynamic simulation of rigid bodies pretty soon, just trying to decide which math method to follow.
Posted on 2004-02-22 22:21:31 by Homer
What do you think of the method employed by Hitman?
Posted on 2004-02-22 22:38:25 by bitRAKE
They used a Verlette integrator function, whereas I would think about implementing staged integration aka Runge - Kutta integration.
They used the notions of molecular physics equations applied as weightings of clusters of vertices, I would think the same way.
They used a "convergence" (plug and pray) method of solving simultaneous multiple constraints, I would suggest this is inconsistant and again would think in Runge - Kutta terms (look at it as a simultaneous differential equation, similar to how their IK solver works).
They built their models such that the model's origin coincides with its center of mass, such that object rotations are simplified in terms of all "molecules" having the same angular velocity at all times. I would suggest that this leads to a rather cheap simulation due to incorrect behaviour of rotating dynamic objects (think of an axe spinning through the air, its center of rotation is its center of mass, nowhere near its "geographical center" aka BB center, due to the Axe Head having much higher density than the handle).
Their particle effects were probably a little underused in the game itself.
The water and cloth simulations were superb.
The modelling was excellent.
Whoever made the textures should be shot.

Opinions, heh, they're like assholes, everyone has one and feels compelled to voice it in a public forum...

All up I found it to be a quite compelling game, with very good AI, particularly in terms of pathfinding. It could have benefited from more local fx, even simple stuff like volumetric fog would have given it much greater depth.
The sequel to the game, Hitman 2, seemed to use pretty much the same engine, with little to boast about (what's new).

We stand apon the shoulders of Giants, but we still can't see past the end of our own nose.
Posted on 2004-02-22 23:01:07 by Homer
Hi EvilHomer2k,

I am interested but the source would be over my head. I'm still waiting for your Game Dev Tutorial in CHM format so I can look through it and begin to understand a bit about what's going on here. I was not a science major so I have no physics to speak of except what I pick up on the road of life (and that isn't much) but I am intersted in advanced graphics.
Posted on 2004-02-22 23:03:25 by donkey
I'm not sure I am the right man to write that CHM after all... I have no formal qualification as a programmer, and everything I have learned, I learned the hard way.
I have found GameDev to be unlike almost any other field of programming, I see it more as an artform than a science.
You put yourself together a basic game engine, and then you spend the rest of your life tweaking it, never really satisfied with the result. There's no hard and fast rules, in fact, you can throw the rulebook right out the window. We don't care how much cpu time we consume, provided its all being used to achieve our goals. We DO care about resource management and structure.
We are basically creating a kind of database, and manipulating its content over time. We are furthermore creating associations between some database elements, and applying constraints to them to force their output to a given range. What kind of database is it? You can use whatever you like, be it simple flat arrays, lookup tables, linkedlists and trees, anything you like. Personally I am taken with the idea of closely integrating some of the hierarchy structure into the supporting Classes themselves.
An example of this would be my CMesh class, which provides support for rendering objects from meshes, but keeps internally a linkedlist of "unique" CMesh instances from which it can clone duplicates on demand with the lowest possible resource usage.
Simply describing a game skeleton with its main loop and user input and render code would not be enough to describe gamedev in generic terms, although it might help.
In closing, I feel gamedev is a specialist field of programming, much as dynamics is a specialist field of physics.
Just because you can program does not mean you can write a winner game, you still require aesthetic ability, because you are both programmer and artist, even if the actual graphic art is not your own, you are a sculptor, and the program is clay. Build on it, shape it, form it to your will, fire it in Vulcan's Forge, and it will still look like an ashtray made by a nine year old. The best gamedev projects are written by small close teams rather than by large disparate teams or individuals - unfortunately the workload / timeframe is not justifiable for an individual anymore.

That being said, most commercial game programmers are crap.
They're game programmers, not GOOD programmers.
Some of the shortcuts they take are in the interest of expediency rather than an attempt to shave cycles and put them to better use, and generally are a requirement to meet a minimal framerate due to fatally slow core code. Maybe this is why they didn't play up the particle engine in Hitman.
Posted on 2004-02-22 23:24:09 by Homer
Hi EvilHomer2k,

I guess I should have further qualified my area of interest, I am more interested in the advanced graphics than in the gaming stuff. I have little to no interest in games (don't even own one) and absolutely no interest in writing one. My interest is purely out of wanting to know a bit more about the subject not because I have any particular application in mind for the information.

But that said, thanks for your reply.
Posted on 2004-02-22 23:30:06 by donkey
Heh. That sounds familiar to me. I'm not sure if I want to write games either, but the programming fields it incorporates intruige me, and the association of them as modules of a larger engine further intruiges me.
I'm personally interested in the mechanics of the beast, in some ways I see even a state engine based game as a primitive neural network. They too fascinate me, yet they are nothing more than scenegraphs, even the feedback learning methods can be evaluated in scenegraph terms. Everything relates to something else I'm interested in, and working on each small part is probably more fun than tweaking the final result I guess, but nonetheless I'm having a blast:)
Posted on 2004-02-23 07:21:04 by Homer
I am missing math3dx8 something _dkt.def when compiling
Posted on 2004-02-23 17:07:42 by daydreamer
Glad you asked, since this file had some minor alteration by me due to duplication of names of macros in this include with some dx functions.
The file is from Caleb's DX8 includes, and contains a bunch of handy fpu macros which make good fast replacements for dx functions in some cases.
I've attached it for you below.
You may also find some issues in Scronty's DX8.1 includes when you try to build.
If you get "incorrect #params" errors, look for the PROTO for the offending function and fix it, Scronty's DX8.1 includes contain numerous minor errors which are a legacy of it being built on his DX8.0 includes, and due to m$ adding extra params to some of the functions. If you have any more issues, just yell out :)
Posted on 2004-02-23 22:19:11 by Homer
Don't be put off by the amount of code presented, as a lot of it is yet to be implemented.
Do spend time examining the CLASS structures, and take note of which classes inherit from which other classes (look at the opening line of the class definitions).

Note that you don't need to have function entries for class object contructor and destructor methods (classname_classname and classname_$classname), but those procs NEED to be defined for ALL classes, even if they contain nothing but a RET statement.

I'll keep supporting ATC and promoting OOP in ASM, I'm sure that some of you will see the benefits of this kind of coding, especially for highly structured, complex database dependant code, modular code, etc... as well as the benefits of being able to write cross-language code modules for VB, C and C++ under a single, easy to understand system, with rather low call overhead.

pcall BeerGlass.Refill, fp100
Posted on 2004-02-23 22:31:20 by Homer
after commenting out things:
after commenting out that:
this is lost because I had this earlier on my old PII and recently got a amd xp2400
Posted on 2004-02-24 11:21:16 by daydreamer
Ah yes, I'd left out CTexture because I was unhappy with it - you see, it was my first attempt at writing a Class which manages its own ref-object instancing, and I used my old LinkedList support module which was cowritten with Scronty some time ago.
I apologise for the oversight - that class is actually at the top of my ToDo list.
I'm going to post it here and now in its current form, and I'll immediately begin reworking it to clean it up, I'll repost the whole source when its done, since there'll be repairs made to several other classes, and this time I'll post it in zipped modules which will contain one folder worth of files each. It will be up to you to download what you need from there, this will save having to download the whole lot again.

Feel free to alter the path for this include to something more reasonable for the purposes of just getting it built for demo, I'll be altering the path myself when I've sorted it out.
Posted on 2004-02-24 22:33:21 by Homer
Here's the other stuff you requested, from memory they came from Scronty's DX includes.
Posted on 2004-02-24 22:36:33 by Homer
I'm pretty sure I've nailed down CTexture this time around. I'll test it thoroughly before I repost it all the same.
CTexture no longer depends on LinkedList.inc, instead it now works just like CMesh - it keeps a global linkedlist of unique entries which is searched each time a texture load is attempted.
If the texture is new, we add to the list.. if not, we clone it.
Unlike CMesh, CTexture keeps count of instances of those unique entries.

What this means is that we don't need to call any function external to the class to provide management of the list when we want to load a texture - it's all done inside CTexture. We can simply create a new CTexture and then either call its Load method (to load texture by name) or call its Create method (to create a "blank" texture which we can manipulate with pixel operators).

It's still not safe to inherit CTexture from CMesh, simply because that means the CMesh would only ever have a single texture, and chances are it has more.
Therefore CMesh retains its array of pointers to CTexture instances.
Posted on 2004-02-25 04:55:21 by Homer
As promised, here is the revised CTexture class, as well as a modified CMesh (since CMesh depends on CTexture, although it does not explicitly inherit from it).

Changes were likewise made to the Demo_Init function, which loads some stuff we use in the demo, like default textures and meshes...

Since I'm a lazy prick, I'm going to spam that file here - you can hate me later.

g_pVertexBuffer dd NULL

fppidiv4 FLOAT 0.7853981633974483096f
fp2 FLOAT 2.0f
fp200 FLOAT 200.0f
pScene dd 0
pPlayer dd 0
pPlayer2 dd 0
pTerrains dd 256 dup (0)
TerrainLoaderThreadID dd 0
pCLoadingTexture dd 0

TerrainLoaderThread proc MyParam:DWORD
local ind:DWORD
local pterrain:DWORD
;Build array of 16x16
mov ind,0
.while ind<16*16
mov pterrain, new (TerrainEngine)
.if pterrain
; $Message "Created TerrainEngine Instance %lu",ind
mov ebx,ind
m2m pTerrains[ebx*4],pterrain
Error "Out of Mem"
inc ind
;Swizzle the Mesh vertices on the Y axis and build terrain textures
invoke BuildPatches,CTEXT("Maps\TestHeightMap.jpg"),
;Message "Patches Built"
m2m g_StartedChange, g_dCurTime
TerrainLoaderThread endp

init proc uses eax ebx ecx edx esi edi me,hWnd
local pVertices,ind,pterrain:DWORD
local ErrBuf[256]:BYTE
local pDevice:DWORD
invoke Direct3DCreate8, D3D_SDK_VERSION ; Create the D3D object.
mov ecx,me
mov [ecx].CApp.g_pD3D,eax
mcall [ecx].CApp.g_pD3D, IDirect3D8_GetAdapterDisplayMode, D3DADAPTER_DEFAULT, addr d3ddm

ZeroMemory &d3dpp, sizeof d3dpp
mov d3dpp.SwapEffect , D3DSWAPEFFECT_DISCARD
mov d3dpp.MultiSampleType , D3DMULTISAMPLE_NONE
mov d3dpp.Windowed , TRUE
m2m d3dpp.BackBufferFormat, d3ddm.Format
mov d3dpp.BackBufferCount , 1
m2m d3dpp.hDeviceWindow , hWnd
mov d3dpp.AutoDepthStencilFormat , D3DFMT_D16
mov d3dpp.EnableAutoDepthStencil , TRUE

mov ecx,me
mcall [ecx].CApp.g_pD3D,IDirect3D8_CreateDevice, D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, hWnd, \
D3DCREATE_SOFTWARE_VERTEXPROCESSING, addr d3dpp, addr [ecx].CApp.g_pd3dDevice
.if eax ==D3D_OK
mov ecx,CApp_OnlyInstance
m2m pDevice, [ecx].CApp.g_pd3dDevice
iCall me,CApp,InitDevice
return FALSE

;Fetch the Device Capabilities for later
mov ecx,me
mcall [ecx].CApp.g_pd3dDevice,IDirect3DDevice8_GetDeviceCaps,addr [ecx].CApp.m_d3dCaps

invoke D3DXMatrixLookAtLH, addr matView, addr g_vEye,addr g_vLook ,addr g_vUp
mcall pDevice,IDirect3DDevice8_SetTransform, D3DTS_VIEW, addr matView

invoke D3DXMatrixPerspectiveFovLH, addr matProj, fppidiv4 , fp1, fp1, fp200
mcall pDevice,IDirect3DDevice8_SetTransform, D3DTS_PROJECTION, addr matProj

; //
; // Load a couple of textures for the floor and the "Loading" SplashScreen
; //
mov pCFloorTexture,new (CTexture)
; mov pCLoadingTexture,new (CTexture)
icall pCFloorTexture, CTexture, Load, CTEXT("textures\dx.bmp"), 0, 0
; icall pCLoadingTexture, CTexture, Load, CTEXT("textures\Loading.jpg"), 0, 0

; //
; // Create the floor geometry...
; //
mcall pDevice,IDirect3DDevice8_CreateVertexBuffer, (4*sizeof Vertex), D3DUSAGE_WRITEONLY, FVF_VERTEX, D3DPOOL_DEFAULT, addr g_pVertexBuffer
mcall g_pVertexBuffer,IDirect3DVertexBuffer8_Lock, 0, sizeof g_floorVertices, addr pVertices, 0
invoke RtlMoveMemory, pVertices, addr g_floorVertices, sizeof g_floorVertices
mcall g_pVertexBuffer,IDirect3DVertexBuffer8_Unlock

; //
; // Initialize a Font for 2D Text Output to screen
; //
pFont dd NULL

invoke CreateFont,32, 10, 0, 0, FW_NORMAL, FALSE, FALSE, \
push eax ; Save the font handle
invoke D3DXCreateFont, pDevice, eax, ADDR pFont
.if eax != D3D_OK
pop eax
return E_FAIL
call DeleteObject ; Destroy the font handle (param is already on Stack)

; invoke LoadHierarchicalObjectFromXFile ,CTEXT("Tank.x")

; mov pScene,new (CScene)
; icall pScene, CScene, Load, CTEXT("ScriptDesign\TestScript.txt")

mov pPlayer, new (CSkinMesh)
set pPlayer as CSkinMesh
pcall pPlayer.RestoreDeviceObjects
pcall pPlayer.SetPath,CTEXT("Objects\Tiny.x")
pcall pPlayer.LoadMeshHierarchy

invoke CreateThread,0,0,addr TerrainLoaderThread,0,0,addr TerrainLoaderThreadID
__LoadFloat3 g_vEyeLoad
__StoreFloat3 g_vEye

;Create two default objects in the center of the room for testing purposes

mov pPlayer,new (CCullableThing)
mov ebx,CApp_OnlyInstance
icall pPlayer, CCullableThing, Load, [ebx].CApp.g_pd3dDevice,CTEXT("Objects\NewCube.x") ;("Objects\ShieldCube2.x")
icall pPlayer, CCullableThing, InitBB
mov ebx,pPlayer
fld fp1
fst [ebx].CCullableThing.m_fRotX
fst [ebx].CCullableThing.m_fRotY
fstp [ebx].CCullableThing.position.y
icall pPlayer, CCullableThing, UpdateMatrix
Message "Demo_init"

mov pPlayer2,new (CCullableThing)
mov ebx,CApp_OnlyInstance
icall pPlayer2, CCullableThing, Load, [ebx].CApp.g_pd3dDevice,CTEXT("Objects\NewCube.x") ;("Objects\ShieldCube2.x")
icall pPlayer2, CCullableThing, InitBB
mov ebx,pPlayer2
fld fp2
fst [ebx].CCullableThing.m_fRotX
fst [ebx].CCullableThing.m_fRotY
fstp [ebx].CCullableThing.position.y
icall pPlayer2, CCullableThing, UpdateMatrix

m2m g_StartedChange, g_dCurTime


init endp
Posted on 2004-02-26 09:08:34 by Homer