I'm having some problems with SronSoft's directx tutorials... I did the first one without any problem but the second one give's me a memory violation error every time I run it... The weirdest thing is that the .exe example given with the tutorial has the exact same error... I run my program with a debugger and found that the error is in the InitVB function... I've atached my code so that you all can see it, it's sligthly (sp?) different from the original one.
I have just run all of the other examples and it seems that none of them is working... Is there something wrong with that site?
I have just run all of the other examples and it seems that none of them is working... Is there something wrong with that site?
Runs perfectly here, no crashes. R9200SE, Win2k SP4
Really weird... Is there some directx upgrade or some DLL I should download? I'm with Win XP SP2.
Runs fine, WinXP SP2 ( SP2 since this morning :woot: )
Works fine. Win XP SP2, GF FX 5200, DX90c
Maybe your card has the same problem as mine: running at 8x AGP, Fast-Writes:On, it crashes on many games during startup. Thus I run it at 4x,Off ^^"
Hum... So is this some problem with my video card? In that case is there some way to fix it?
I've attached the error this time, it's in portuguese though, but I beleive you guys already memorized the error message :P
I've attached the error this time, it's in portuguese though, but I beleive you guys already memorized the error message :P
The problem is at
But not during or after the call -
g_pd3dDevice here is NULL - that's why
Seems like at IDirect3D8_CreateDevice you didn't get a g_pd3dDevice, yet no error was returned. Maybe the number of parameters is incorrect? (in DX8.1 there were some differences from DX8, some methods having 2 more arguments)
Check if the stack is ok around the CreateDevice. Check if the g_pd3dDevice is 0 .
mcall ,IDirect3DDevice8_CreateVertexBuffer, sizeof g_Vertices,\
0, D3DFVF_CUSTOMVERTEX, D3DPOOL_DEFAULT, ADDR g_pVB
But not during or after the call -
g_pd3dDevice here is NULL - that's why
Seems like at IDirect3D8_CreateDevice you didn't get a g_pd3dDevice, yet no error was returned. Maybe the number of parameters is incorrect? (in DX8.1 there were some differences from DX8, some methods having 2 more arguments)
Check if the stack is ok around the CreateDevice. Check if the g_pd3dDevice is 0 .
Hmm I remember that in my uni, at the win2k PCs there, DirectX was severely limited for non-admin users: even simple DirectDraw1.0 demos of mine could not run. I don't know how those limits were put on those PCs - but maybe your case is similar.
I've just checked the version of this tutorial made for dx 8.1 and the IDirect3D8_CreateDevice call has the same number of paramaters of the 8 one. I have run the program with a debugger and indeed after the IDirect3D8_CreateDevice call the g_pd3dDevice (00403300h) remains empty (or atleast it's what I think, I suck using a debugger :P)...
I don't know how you figured out that I'm on a non admin account, in fact I got a little scared :P, but I tried running the program on another WinXP SP2 with administrative privileges and still the error came up.
I don't know how you figured out that I'm on a non admin account, in fact I got a little scared :P, but I tried running the program on another WinXP SP2 with administrative privileges and still the error came up.
hm maybe you should search for ready-to-run DX8.1 hello-world tutorials, (mostly in C++), test if they run - and if yes - compare their code to yours.
Ah, a silly question -but have you installed the DX9c, or you have some previous version?
Ah, a silly question -but have you installed the DX9c, or you have some previous version?
I searched in google but couldn't find any compiled source code... Just lots of cpp and dsp files...
I don't know wich version of DirectX am I running, is there some way I can see it?
I don't know wich version of DirectX am I running, is there some way I can see it?
run the "dxdiag"
It seems like I have DirectX 9.0c, what does this means? Can I still use Dx8 normally? Are there tutorials for Dx9 in asm?
DxDiag:
DxDiag:
I'd be happy to help you out with DX9 in asm.
Most of the tutorials out there rely too much on Microsoft's application framework, but fear not, we can safely disregard this and get our hands dirty with a barebones approach.
As a matter of fact, I am sure other users would benefit from a staged series of tutorials posted here in this forum, if you are still interested let me know :)
Most of the tutorials out there rely too much on Microsoft's application framework, but fear not, we can safely disregard this and get our hands dirty with a barebones approach.
As a matter of fact, I am sure other users would benefit from a staged series of tutorials posted here in this forum, if you are still interested let me know :)
I am definetely interested and looking forward those tutorials :)
I don't know who I am talking to, so I apologise in advance for presuming you have no idea what I am talking about in the following paragraphs. Anyone can learn this stuff, you don't need to be any kind of genius.
The first thing you are going to have to decide is which D3D9 interface headers to use.
I do not use the mcall macro anymore.
I originally translated the SDK headers for the ATC oop model, and since then, Biterider has modified them for the ObjAsm32 oop model, which is actively being developed (I'm messing around with the December 2005 SDK, and help Biterider to keep his headers up to date as much as possible).
Under the OA32 oop model, we use a macro called ICall.
Here's what ICall looks like:
As you can see, its a lot like mcall, but uses a c++ style syntax.
"ICall lpInterface::InterfaceName.MethodName, Params"
I strongly recommend you install OA32 in order to take advantage of the ICall macro and the D3D headers.
As for using OA32's OOP support macros, I am not trying to twist your arm, but I think you are crazy if you don't at least consider it.
It sure makes translating (and understanding) existing C/C++ a lot easier, and has other advantages later on (the main one being that unlike ATC, OA32 can build projects from PRECOMPILED OBJECTS which VASTLY improves your build times in larger projects).
If you decide to install OA32, or have already done so, then you will be able to compile my examples rather than having to port them to use mcall, and will receive my full support.
I am willing to help you solve any "teething problems" associated with your new OA32 installation, as well as explain to you in "idiot terms" exactly what the heck all this oop stuff is about.
What I won't do is help you privately, as I believe that any information I have to offer should be accessible to the general public.
I'm not going to write any formal tutorials, instead I'd prefer to use this forum to record an informal discourse, starting at the very start, and seeing where it takes us.
So... step 1, install OA32.. read the README contained in the install package, try to build one of the provided example sources (without understanding it), and respond here.. either tell me that you had problems and we'll address them, or tell me it built ok and we'll get started !!
The first thing you are going to have to decide is which D3D9 interface headers to use.
I do not use the mcall macro anymore.
I originally translated the SDK headers for the ATC oop model, and since then, Biterider has modified them for the ObjAsm32 oop model, which is actively being developed (I'm messing around with the December 2005 SDK, and help Biterider to keep his headers up to date as much as possible).
Under the OA32 oop model, we use a macro called ICall.
Here's what ICall looks like:
ICall pMesh::ID3DXMesh.GetFVF
As you can see, its a lot like mcall, but uses a c++ style syntax.
"ICall lpInterface::InterfaceName.MethodName, Params"
I strongly recommend you install OA32 in order to take advantage of the ICall macro and the D3D headers.
As for using OA32's OOP support macros, I am not trying to twist your arm, but I think you are crazy if you don't at least consider it.
It sure makes translating (and understanding) existing C/C++ a lot easier, and has other advantages later on (the main one being that unlike ATC, OA32 can build projects from PRECOMPILED OBJECTS which VASTLY improves your build times in larger projects).
If you decide to install OA32, or have already done so, then you will be able to compile my examples rather than having to port them to use mcall, and will receive my full support.
I am willing to help you solve any "teething problems" associated with your new OA32 installation, as well as explain to you in "idiot terms" exactly what the heck all this oop stuff is about.
What I won't do is help you privately, as I believe that any information I have to offer should be accessible to the general public.
I'm not going to write any formal tutorials, instead I'd prefer to use this forum to record an informal discourse, starting at the very start, and seeing where it takes us.
So... step 1, install OA32.. read the README contained in the install package, try to build one of the provided example sources (without understanding it), and respond here.. either tell me that you had problems and we'll address them, or tell me it built ok and we'll get started !!
although I dont use the OOP to fullest extent, it has helpful macros, so its easier to read dx sdk help files without think about convert to asm