Afternoon, EvilHomer2k.

Cannot reassemble.

The linker says it can't find D3DXCreateFontA, even though none of the files seem to use it.

Cheers,
Scronty
Posted on 2004-06-06 07:50:52 by Scronty
Afternoon, EvilHomer2k.

It's ok.
Seems you've declared D3DXCreateFontA as:
D3DXCreateFontA proto :DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD


You only need those declarations as:



D3DXCreateFont proto :DWORD,:DWORD,:DWORD
D3DXCreateFontIndirect proto :DWORD,:DWORD,:DWORD


Cheers,
Scronty
Posted on 2004-06-06 07:57:47 by Scronty
Afternoon, EvilHomer2k.

Attached is the proggy updated with corrected d3dx9core.inc file plus with zbuffer enabled.

Note that the zbuffer requires switching off to render the 2d panel (shown in code).

Cheers,
Scronty
Posted on 2004-06-06 08:29:23 by Scronty
lol, whoa thanks :)
Build ok after that?

I had no Render issues.. wonder if I updated all files in that zip? You may have noted there were a few other changes and additions made to the Headers etc...
Posted on 2004-06-06 08:29:24 by Homer
Afternoon, EvilHomer2k.

heh. Must've bet ya to posting by <1 sec ;p .

Cheers,
Scronty
Posted on 2004-06-06 08:30:27 by Scronty
yup :) I'll grab your updated dxcore and see if I still build ok this end ..
Posted on 2004-06-06 08:34:19 by Homer
Added the zbuffer code (and changes to D3DInit) and noticed that the mesh polygons and the 2dpanel polygons are built in opposite directions .. I'll have to change the 2dpanel vertex-filling code. I guess I'm ready to begin wrapping the Mesh code in another OOP class now, removing it from the main source file and enshrining it in its own as I did for the 2dpanel... meshes just happen to be a perfect candidate, and I'm hoping this set of examples highlights the potential benefits of OOP that can be had despite the extra access cost, if it applied to appropriate situations, especially where we intend to create multiple instances of something that we could define as a struct, and possibly has one or more closely-associated functions...
Posted on 2004-06-06 08:45:57 by Homer
Afternoon, EvilHomer2k.

built in opposite directions


Pardon?

The map of earth displays correctly (it's not backwards). The tiger rotates in a clockwise direction, as expected.

Cheers,
Scronty
Posted on 2004-06-06 09:14:08 by Scronty
You misunderstand me - changing the CULLMODE to CW or CCW, one way we get the 2DPanel, but see "thru" the tiger to its backfaces, the other way we get no 2DPanel (I assume its been culled) and the tiger looks good.. I have left culling disabled for now.
Posted on 2004-06-06 11:10:02 by Homer
Afternoon, EvilHomer2k.

That's what I'd done in the update I posted.
pcall lpd3dDevice.SetRenderState, D3DRS_CULLMODE, D3DCULL_NONE


Of course.... it'd be better to change the 2dpanel code so that it's created as CCW vertices.

Change the SetRenderState line to:
pcall lpd3dDevice.SetRenderState, D3DRS_CULLMODE, D3DCULL_CCW

and modify the 2DPanel.inc file so that the vertice-generating code is:


fild [ecx].My2DPanel.rc.left
fstp [ebx].My2DPanelVertex.x
fild [ecx].My2DPanel.rc.bottom
fstp [ebx].My2DPanelVertex.y
m2m [ebx].My2DPanelVertex.z,fp1
m2m [ebx].My2DPanelVertex.rhw,fp1
m2m [ebx].My2DPanelVertex.tu,fp0
m2m [ebx].My2DPanelVertex.tv,fp1
add ebx,sizeof My2DPanelVertex

fild [ecx].My2DPanel.rc.left
fstp [ebx].My2DPanelVertex.x
fild [ecx].My2DPanel.rc.top
fstp [ebx].My2DPanelVertex.y
m2m [ebx].My2DPanelVertex.z,fp1
m2m [ebx].My2DPanelVertex.rhw,fp1
m2m [ebx].My2DPanelVertex.tu,fp0
m2m [ebx].My2DPanelVertex.tv,fp0
add ebx,sizeof My2DPanelVertex


fild [ecx].My2DPanel.rc.right
fstp [ebx].My2DPanelVertex.x
fild [ecx].My2DPanel.rc.bottom
fstp [ebx].My2DPanelVertex.y
m2m [ebx].My2DPanelVertex.z,fp1
m2m [ebx].My2DPanelVertex.rhw,fp1
m2m [ebx].My2DPanelVertex.tu,fp1
m2m [ebx].My2DPanelVertex.tv,fp1
add ebx,sizeof My2DPanelVertex

fild [ecx].My2DPanel.rc.right
fstp [ebx].My2DPanelVertex.x
fild [ecx].My2DPanel.rc.top
fstp [ebx].My2DPanelVertex.y
m2m [ebx].My2DPanelVertex.z,fp1
m2m [ebx].My2DPanelVertex.rhw,fp1
m2m [ebx].My2DPanelVertex.tu,fp1
m2m [ebx].My2DPanelVertex.tv,fp0
add ebx,sizeof My2DPanelVertex


Cheers,
Scronty
Posted on 2004-06-06 19:47:19 by Scronty
What he said :)

Spent a while last nite wasting time on support classes including CD3DSettings and CD3DSettingsDialog, which are used to create a hardware-specific video options dialog box, based on the reported capabilities of the hardware...

I won't be implementing it for some time, so it's not really relevant. I'm still tempted to wrap the Mesh code in a class next, but I think it might serve the casual observer to build some examples which more clearly show the usage of various transformation matrices before heading in that direction...

Anyone have requests or suggestions as to what kind of examples they'd like to see? Maybe I should expand the 2DPanel to include mousecursor hit detection so that they can be used as buttons / menu selectors?
Posted on 2004-06-07 01:13:52 by Homer
fild .My2DPanel.rc.right
fstp .My2DPanelVertex.x


I don't know if you ever thought about this, or if you just used the FPU because they are floats... but there's no reason why you should use the FPU for just copying floats around. It's faster to use the ALU, something like:

mov eax, [ecx].My2DPanel.rc.right

mov [ebx].My2DPanelVertex.x, eax


A simple, yet effective optimization ;)
Posted on 2004-06-07 02:12:22 by Scali
It's because I'm actually converting the values from integer to floating point - the load instruction is fild (load fpu from integer) , while the store instruction is fstp (store fpu as float) :)
I'll keep your observation in mind, all the same.
Posted on 2004-06-07 08:00:07 by Homer
The 2DPanel Class was expanded slightly - 2DPanels can now be created as either a static or a button, and switched between these states at will (buttons can be disabled).
We introduce a new method called SetCallBack which takes one parameter, a pointer to a function of our choosing. In the attached example, I first create a 2DPanel, then turn it into a button by calling its SetCallBack method, and then setting its bIsButton flag to TRUE.
Our CallBack in this example simply messageboxes then returns.
There is no current support for resizing the window, that should probably come next, but at any rate, it would be trivial at this point to put together a menu system..

In the current example, MouseClick detection works as follows: we have a global boolean flag "UserClicked" which is normally FALSE. MouseClicks generate a WM_LBUTTONDOWN that is sent to the main application window. WndProc catches it, notes the mousecursor coordinates where the click event occured, and sets UserClicked to TRUE. 2DPanels which are Buttons will check if the mouseclick coordinate lays within the bounds of their own rectangle (rc field), and if so, will switch the UserClicked flag back to FALSE (telling other instances to quit handling the click event) and then call their own CallBack function.

Since all this checking is done from within the 2DPanel class's Render method, we'll only ever perform it on 2DPanels that are on the screen at the time (for the example of a menu system versus in-game panels...)

Any suggestions on improving this mechanism?
Posted on 2004-06-08 01:24:03 by Homer
"heh" nice idea making a 3d-menu.

would be nice, chasing buttons in a 3d- environment.
plenty possibilities to make button effects.
Posted on 2004-06-08 02:00:00 by Siekmanski
You can do something like in the "PICK" example from the dx9-sdk and make real 3d buttons.
Posted on 2004-06-08 02:06:02 by Siekmanski
This wouldn't make a 3D menu exactly - the 2DPanel class provides rendering for textured static/button 2D rectangles - you could achieve all kinds of neat effects by messing with the uv values etc. maybe I should switch to using mousepick :)
As I was saying, the 2D limitation is imposed deliberately by the choice of vertex format (rhw), which tells DirectX not to further transform the vertices.
This causes the 2DPanels to be "stamped" on the screen, no matter what we do to the view (eg move the camera around), and allows us to define the rectangles in "screen space", ie X,Y,1
This way we could have our menu as floating buttons that appear on top of the current gamescene etc, and we can use the 2DPanel class to draw anything that we want to always stay on the screen, like maybe the player's above-view map of the area around them, their healthbar, that kind of thing.. the stuff that gets drawn last over the top of the scene.
Posted on 2004-06-08 02:13:31 by Homer
You beat me to the PICK comment lol I was typing too slow :tongue:
Posted on 2004-06-08 02:14:44 by Homer
This example proves that the 2DPanel oop class is working correctly - I create three buttons using it, and associate each with a different callback.
The buttons can be made any size, the texture is automatically stretched due to the nature of uv mapping.
Posted on 2004-06-08 02:57:52 by Homer
Working OK

Only when I click 2 times on a button the message-box gets behind the main screen and app. crashes.
(I know message box is only there for testing but, wanted to let you know)
Posted on 2004-06-08 03:12:00 by Siekmanski