I found that Biterider's D3D example was a little unstable on my antiquated hardware (probably a device driver issue), and I found the whole thing was more confusing than it needed to be, and set about creating something more readable.
I decided to write my own rather simple DX9 Skeleton demo.
This application is going to form the "testbed" for my upcoming OA32 Animated SkinMesh demo.
I've created a D3DApp class which does everything that is required, it contains all the Window-related code, etc, making your "WinMain" code extremely simple.
The main application window is a Dialog, which allows the user to configure stuff like the screen resolution, pixel format and windowing mode.
D3DApp::InitWindow creates the main dialog window, and returns TRUE or FALSE to indicate success or failure.
D3DApp::Run contains our MessagePump loop (which won't return unless a WM_QUIT is posted, as usual).
Therefore, WinMain might contain something like:
mov pD3DApp,$New(D3DApp,Init)
OCall pD3DApp::D3DApp.InitWindow
.if eax==TRUE
OCall pD3DApp::D3DApp.Run
.endif
I have not taken great pains with this example, it was a 'quickie'.
Like Biterider's demo, nothing is being rendered in this example.
Fullscreen works fine, but Windowed mode is broken in this example.
Once the D3DApp framework is perfected, I intend to create a RadAsm project template from the democode in order to facilitate future projects.
If anyone cares to figure out what is wrong or missing, please let me know :)
Likewise, if you have suggestions or feature requests, let me know !!
Hi Homer
Nice demo app! 8)
I checked it and found some little points that can be written better.
The SysInit macro by default loads the hInstance value with the returning value of GetModuleHandle. Only if you provide a value, this will be taken to initialize hInstance, which is often the case when a DLL is initialized. That means that you can safely remove your initialization of hInstance.
SysInit internally calls ObjectInit when the "OOP level" is different from OOP_NONE. This is your case. The ObjectInit macro calls all defined <ObjectName>.Statup methods. This is handy to initialize all type of resources BEFORE any object instance is created. SysDone calls ObjectsDone which does the final housekeeping calling all defined <ObjectName>.Shutdown
I usually use it to register the needed window classes used in the application, but it is perfectly legal to do like you have done it.
I noticed that the D3DApp .Done method was not called and found you accidentally forgot to invoke the Destroy pD3DApp before SysDone. As a general rule, all objects has to be disposed by the same mechanism that created it. I.e. if you created an object using the New macro, you have to dispose it using the Destroy macro. If the object was created from a resource, the instance was disposed automatically, but it must be guaranteed in code that the Done method was called. I wrote a brief description a few weeks ago, perhaps this can help a little more. http://www.asmcommunity.net/board/index.php?topic=22234.0
To compile the app I had t adapt the paths for the d3d9.lib and d3dx9.lib files.
Regards,
Biterider
Nice demo app! 8)
I checked it and found some little points that can be written better.
The SysInit macro by default loads the hInstance value with the returning value of GetModuleHandle. Only if you provide a value, this will be taken to initialize hInstance, which is often the case when a DLL is initialized. That means that you can safely remove your initialization of hInstance.
SysInit internally calls ObjectInit when the "OOP level" is different from OOP_NONE. This is your case. The ObjectInit macro calls all defined <ObjectName>.Statup methods. This is handy to initialize all type of resources BEFORE any object instance is created. SysDone calls ObjectsDone which does the final housekeeping calling all defined <ObjectName>.Shutdown
I usually use it to register the needed window classes used in the application, but it is perfectly legal to do like you have done it.
I noticed that the D3DApp .Done method was not called and found you accidentally forgot to invoke the Destroy pD3DApp before SysDone. As a general rule, all objects has to be disposed by the same mechanism that created it. I.e. if you created an object using the New macro, you have to dispose it using the Destroy macro. If the object was created from a resource, the instance was disposed automatically, but it must be guaranteed in code that the Done method was called. I wrote a brief description a few weeks ago, perhaps this can help a little more. http://www.asmcommunity.net/board/index.php?topic=22234.0
To compile the app I had t adapt the paths for the d3d9.lib and d3dx9.lib files.
Regards,
Biterider
I had a problem installing the DX9 october SDK update.
The file is a huge self extracting exe which asks for more resources than my system could provide, just in order to extract another huge self extracting exe containing the installer.
I gave up and copied the libs from another machine, thats why those paths were crafted..
Thanks for the feedback, I'll make those changes.
Can you see what is wrong with my initialising of Windowed mode?
I tried to build your example, but It had a compile error.
It couldn't find the file \masm32\ObjAsm32\Code\DirectX\D3DX9Math.inc
When I installed the OA32 package, I only got the file D3DXMath.inc,
so I changed the include to this file.
The header of it is as follows:
; =================================================================================================
; Title: D3DXMath.inc
; Author: G. Friedrich
; Version: 1.0.0
; Purpose: D3DX mathematical support for ObjAsm32.
; Notes: Based on the work of EvilHomer2k.
; Version 1.0.0, September 2004:
; - First release.
; =================================================================================================
When I build the project I get the following error:
\masm32\ObjAsm32\Code\DirectX\D3DXMath.inc(44) : error A2179: structure improperly initialized
\masm32\ObjAsm32\Code\DirectX\D3DXMath.inc(44) : fatal error A1016: Internal Assembler Error
Line 44 in D3DXMath.inc is:
Did you rename the original include, or do you have another file or version?
Another question is:
On installing the OA32 package, the install.txt file says:
The COM related examples need the Microsoft MIDL compiler. You have to install it in the Masm32\Bin directory.
Do we need this compiler in this project?
Friendly regards,
mdevries.
It couldn't find the file \masm32\ObjAsm32\Code\DirectX\D3DX9Math.inc
When I installed the OA32 package, I only got the file D3DXMath.inc,
so I changed the include to this file.
The header of it is as follows:
; =================================================================================================
; Title: D3DXMath.inc
; Author: G. Friedrich
; Version: 1.0.0
; Purpose: D3DX mathematical support for ObjAsm32.
; Notes: Based on the work of EvilHomer2k.
; Version 1.0.0, September 2004:
; - First release.
; =================================================================================================
When I build the project I get the following error:
\masm32\ObjAsm32\Code\DirectX\D3DXMath.inc(44) : error A2179: structure improperly initialized
\masm32\ObjAsm32\Code\DirectX\D3DXMath.inc(44) : fatal error A1016: Internal Assembler Error
Line 44 in D3DXMath.inc is:
D3DVECTOR textequ <D3DXVECTOR3>Did you rename the original include, or do you have another file or version?
Another question is:
On installing the OA32 package, the install.txt file says:
The COM related examples need the Microsoft MIDL compiler. You have to install it in the Masm32\Bin directory.
Do we need this compiler in this project?
Friendly regards,
mdevries.
Hi mdevries
I renamed the D3DX9Math.inc to D3DXMath.inc according to the original SDK.
There is an obvious inconsistency between the D3DXMath.inc and D3DX9Types.inc files. Simply remove the offending line (44) in the D3DXMath.inc file.
The MIDL compiler is only needed to generate compiled type info for Client-Server transactions. In our case we will not use it.
Regards
Biterider
Yep, I just removed that line too.
Since no suggestions were forthcoming, I've decided to go ahead with the next logical component for this project.
I'm writing a class which is designed to enumerate all available video modes on the local hardware, which is a vast improvement on the "suck it and see" gui-based mode selection avenue.
Wow, it's not easy to enumerate modes under DX !!
Already about eight hours of coding, and a decent 800ish lines of source, just to obtain a list of compatible video modes.
It's about 90% complete, expect a repost within days.
Summer is here, and I'm spending some time outdoors (mostly gardening).
I'm happy to see that a few people took the time to check out this project in its infancy, obviously there is interest in my work, and so I'll keep hammering away.
Here's to beer and bikinis :)
I'm writing a class which is designed to enumerate all available video modes on the local hardware, which is a vast improvement on the "suck it and see" gui-based mode selection avenue.
Wow, it's not easy to enumerate modes under DX !!
Already about eight hours of coding, and a decent 800ish lines of source, just to obtain a list of compatible video modes.
It's about 90% complete, expect a repost within days.
Summer is here, and I'm spending some time outdoors (mostly gardening).
I'm happy to see that a few people took the time to check out this project in its infancy, obviously there is interest in my work, and so I'll keep hammering away.
Here's to beer and bikinis :)
Hi Homer
The DialogDXSetup object does something very close to that what you will do. It only shows in a logical order possible configurations for your installed hardware.
Regards,
Biterider
The DialogDXSetup object does something very close to that what you will do. It only shows in a logical order possible configurations for your installed hardware.
Regards,
Biterider
Argh, you just want to force me into using SdiApp, Dialog, and all those other objects which I've been avoiding for so long :P
Very well Biterider, I will use your DX9 framework.
When I select my (only) adapter, and select fullscreen, the backbuffer format combobox (and all comboboxes below it) remain blank, so I cannot get a fullscreen mode using your mode enumeration code - it must be broken, since I can get fullscreen under my light framework by specifying the options myself.
Would you care to look into this, since you are most familiar with your own work?
Also just to mention that the WindowStyle for Layered windows was undefined - I added the following line to DialogAboutEx.rc:
With that said, I'm willing to throw my DX9 skeleton framework in the bin and go back to work on the animated skinmesh code, using your framework as a testbed.
Should you manage to find and fix the issue(s) in your mode enumerator, I will delete this thread.
Have a nice day :)
Very well Biterider, I will use your DX9 framework.
When I select my (only) adapter, and select fullscreen, the backbuffer format combobox (and all comboboxes below it) remain blank, so I cannot get a fullscreen mode using your mode enumeration code - it must be broken, since I can get fullscreen under my light framework by specifying the options myself.
Would you care to look into this, since you are most familiar with your own work?
Also just to mention that the WindowStyle for Layered windows was undefined - I added the following line to DialogAboutEx.rc:
#define WS_EX_LAYERED 0x80000
With that said, I'm willing to throw my DX9 skeleton framework in the bin and go back to work on the animated skinmesh code, using your framework as a testbed.
Should you manage to find and fix the issue(s) in your mode enumerator, I will delete this thread.
Have a nice day :)
hello homer
If your interrested I have some D3D9 enumeration code, it still has some bugs but it enumerates everything.
greetings Siekmanski
If your interrested I have some D3D9 enumeration code, it still has some bugs but it enumerates everything.
greetings Siekmanski
Hi Homer
The core of the DialogDXSetup object are the Setxxx methods (SetAdapters, SetDeviceTypes, etc.) They fill the comboxes according to the settings made before (from top to bottom in the dialog). These methods checks if the hardware can support some feature but it is possible (quite often) that the sum of all settings exceeds i.e. the available card memory. Switch on the debugging in the DirectX project to see what’s wrong.
I also found a looping bug, so I attach the corrected file. Recompile the object or change the LoadObjects to MakeObjects on the line that contains the object branch.
The D3D9Types.inc has more incompatibilities. This forces me to rework it from ground. For the moment, define D3DVECTOR textequ <D3DXVECTOR3> to compile the project.
The WS_EX_LAYERED flag should be defined in the Windows.inc file. I send the information to the responsible, but nothing happens until now. You can find the definition in the Dialog.inc file. I let it there only as a remainder.
I suggest to experiment with the settings beginning with low resolutions. If you still have problems, let me know the settings you know that work on your hardware.
Regards,
Biterider
The core of the DialogDXSetup object are the Setxxx methods (SetAdapters, SetDeviceTypes, etc.) They fill the comboxes according to the settings made before (from top to bottom in the dialog). These methods checks if the hardware can support some feature but it is possible (quite often) that the sum of all settings exceeds i.e. the available card memory. Switch on the debugging in the DirectX project to see what’s wrong.
I also found a looping bug, so I attach the corrected file. Recompile the object or change the LoadObjects to MakeObjects on the line that contains the object branch.
The D3D9Types.inc has more incompatibilities. This forces me to rework it from ground. For the moment, define D3DVECTOR textequ <D3DXVECTOR3> to compile the project.
The WS_EX_LAYERED flag should be defined in the Windows.inc file. I send the information to the responsible, but nothing happens until now. You can find the definition in the Dialog.inc file. I let it there only as a remainder.
I suggest to experiment with the settings beginning with low resolutions. If you still have problems, let me know the settings you know that work on your hardware.
Regards,
Biterider
I've rebuilt the dxsetup class you provided.
I enabled debug and resguard, rebuilt the project, and crashed due to some unsupported fpu opcode in resguard.
I removed resguard but left debug enabled, and tried again.
Results are as follows:
No matter what options I select, I get D3DERR_NOTAVAILABLE [8876086Ah] notification in DebugCenter.
Windowed mode shows an unhandled backbuffer pixelformat as the first item.
Fullscreen mode shows NO pixelformats, regardless of the selected resolution, and as previously stated, all remaining comboboxes remain empty.
I will try updating my video driver tomorrow and let you know if that is the cause of the issue, my DX is up to date, but the video driver itself maybe not so.
I enabled debug and resguard, rebuilt the project, and crashed due to some unsupported fpu opcode in resguard.
I removed resguard but left debug enabled, and tried again.
Results are as follows:
No matter what options I select, I get D3DERR_NOTAVAILABLE [8876086Ah] notification in DebugCenter.
Windowed mode shows an unhandled backbuffer pixelformat as the first item.
Fullscreen mode shows NO pixelformats, regardless of the selected resolution, and as previously stated, all remaining comboboxes remain empty.
I will try updating my video driver tomorrow and let you know if that is the cause of the issue, my DX is up to date, but the video driver itself maybe not so.
nice work
what flag and what setrenderstate or settexturestage do I need to make d3d render it wireframed polys for debug meshgenerating code?
what flag and what setrenderstate or settexturestage do I need to make d3d render it wireframed polys for debug meshgenerating code?