Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

euank

Any way to spy on DDRAW calls?

This topic is 5721 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

A program I''m writing a replacement dll is crashing out with a Direct Draw error smply saying "unsupported function". The program is pretty old, and was written in the win95 era. Uses Direct Draw 3 I think. I''m trying to find out what the unsupported function is. How can I do that? Are there any programs that can log the COM calls? I have seen similar things for D3D using a wrapper library. None for DirectDraw however. I don''t care what version of DirectX it works for, as I will simply install it on another partion (I had 8, now 9). Here''s an example: http://codeguru.earthweb.com/dll/apihijack.shtml It just gets the interface call. I think I need the interface function, and data. COM DLL''s just show up as a few exports/imports and use some sort of virtual table thing. (Sigh, I hate COM). Dlldetective is another D3D only, but has disapeared. I can make some files avaiable if your a good debugger, but you will require a copy a tombraider 1 for PC. Here''s what the exe spits out from the kernel logger: InitialiseHardware: SetHardwareVideoMode: Switching to 640x480 Allocating front/back buffers Picking up back buffer Allocating Z-buffer Creating texture surfaces DirectDraw error code 80004001 (16385) Fatal DirectDraw error! Now I have no idea where it''s trying to create the texture surfaces. The way the program works is that DDraw does all 2d stuff, and buffer flips. The 3d library dll simply takes vertices and textures, then renders a surface, then returns the surface to 2d (I think). The potential problem I think may be that the 3D library sends 3 variables to the exe that are slightly worrying: u32FrameBuffBase; // Host pointer to frame buffer base u32OffScreenHeap; // Host pointer to offscreen heap u32OffScreenSize; // Size of offscreen heap I don''t know if this is actually the physical address of the video card memory, or a simple DDraw surface allocated in either system or local video memory? At the moment I malloc''d a section of memory to see if the exe tried to do anything with it. Oh BTW I have no idea about 2d\3d graphics. This has been a pet project for rainy days when I can''t be bothered working on my day job programming skills (limited to wince comms and GDI stuff, with the odd VB programming here and there).

Share this post


Link to post
Share on other sites
Advertisement
I''m not sure I understand why you''re doing this, so perhaps saying why would help us out.

Tomb Raider is a fully 3D game, and will use DirectDraw and Direct3D interfaces (DX3 or DX5, forget which) to render.

If you just want to see what it''s calling, find an old eval copy of the Intel IPEAK GPT program. Should be one somewhere out on the web.


If you were at DX Dev Day @ GDC, you saw a preview of the new Direct3D Graphics Performance Analyzer (GPA). It does many many things, one of which is allow you to analyze application interaction with Direct3D9 and the platform.

Development Lead
Windows Graphics & Gaming Technology

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Tomb Raider 1 had a software rendering mode, which presumably used DirectDraw to get its frame buffer access.

The software rendering mode was preferrable to hardware in many cases, because the backface culling was really quite broken in its interface to the Voodoo1, which was the only halfway decent 3D accelerator anyone could afford back then.

Ah, those were the days!

Share this post


Link to post
Share on other sites
Thanks for the replys people!

Basically I think that the tombraider exe is trying to create some sort of now-obsolete texture surface. IE something daft like 15-bit el-weirdo texture format, or maybe a palettized texuture that the Ati cards no longer support.

I would hook that call, and either re-direct it, and convert the data, just ignore it, or use another method (basically make it go away).

The API I'm tring to recreate is ATI3DCIF. No-one has heard of it, and it only made it into a couple of games. Basically it is a 3d layer on top of Direct Draw. Simply a rendering interface... just textures and polygons.

The ATI3DCIF version of Tombraider is the only win32 version of the game.

I've never heard of Intel IPEAK GPT, but will look it up. Isn't GPA just for D3D? Will it work for older DDRAW interfaces?

It's easy to hook and monitor the DLL function calls, but becuase com uses vtables it gets really messy to work with the member functions. I haven't even found anywhere that has good info on decoding the vtables in the ddraw library. The idea is to write a new ddraw.dll that has all the same exports and the app calls this library that simply forwards the calls (after logging, or even modifing). It's a bit like how Fraps works, along with some other cool apps.

The search continues...

[edited by - euank on April 20, 2003 5:32:34 PM]

Share this post


Link to post
Share on other sites
I''d use microsofts detours to do the job ( http://research.microsoft.com/sn/detours/ ) Its very easy to hook apis this way. Simply apply one of the samples on the DD function you want to hook and it works

Share this post


Link to post
Share on other sites
Ah, so what you''re really trying to do is to write an ATI 3D CIF wrapper. That was an ATI proprietary API back in the day, and a quick google search says

"... the right person probably could probably create a 3D CIF wrapper/translator pretty easily, by translating the 3D calls into OpenGL or D3D. This has yet to happen and at this point it is very unlikely to ever happen."


The new GPA is DX9 and later only, but it doesn''t look like DirectDraw/Direct3D is even the primary issue if Tomb Raider is trying to call CIF functions

Development Lead
Windows Graphics & Gaming Technology

Share this post


Link to post
Share on other sites
It's not handling CIF functions (Yet). Direct Draw handles all memory and texture management. The application returns a ddraw error trying to create texture surfaces before CIF has started to be used.

Much later, the app will pass these surfaces to the CIF wrapper which will register them, and create mipmaps, etc. It then simply renders the polylists, and textures to the desktop surface.

I have my wrapper framework ready. CIF never returns info, except to say the function returned ok. So I should be able to run tombraider and get a log like the following (Taken from a Ati SDK app):


Called DllMain
Attached to process
Called ATI3DCIF_Init
Called ATI3DCIF_ContextCreate
Called ATI3DCIF_ContextSetState
eRStateID: C3D_ERS_VERTEX_TYPE
Vertex type =4
Called ATI3DCIF_ContextSetState
eRStateID: C3D_ERS_TMAP_EN
Enabled Texture Mapping =1
Called ATI3DCIF_ContextSetState
eRStateID: C3D_ERS_SPECULAR_EN
Enabled Specular Lighting =1
Called ATI3DCIF_TextureReg
size of structure = 88
is texture a mip map = 0
array of pointer to map level = 0x00000007
log 2 X size of largest map = 7
log 2 Y size of largest map = 7
texel format = 4
specify texel transp. clr = 0
pointer to texture palette = 0x00000000
Rage3: smear/repeat s=1 if s>1 = 0
Rage3: smear/repeat t=1 if t>1 = 0
Rage3: alpha as blend factor = 0
Rage3: tex max for local ref = 0
ptr to tex handle =0x00429150
Called ATI3DCIF_ContextSetState
eRStateID: C3D_ERS_SURF_DRAW_PTR
Desktop surface @0x0012FDC0
Called ATI3DCIF_ContextSetState
eRStateID: C3D_ERS_SURF_DRAW_PITCH
Desktop Pitch =640
Called ATI3DCIF_ContextSetState
eRStateID: C3D_ERS_TMAP_SELECT
Texture Handle @0x00429150
Called ATI3DCIF_RenderBegin
Render Context =0x00000001
Called ATI3DCIF_RenderPrimList
Number of Vertices =3
Called ATI3DCIF_RenderEnd
Called DllMain
Detached from process


I need to know what "unsupported function" is preventing tombraider from initialising. Maybe it was something long obsolete. I'm going to try and get an old copy of win95/98 and try it with an old Nvidia TNT to see if it comes up with a different error. It may also be related to NT memory protection, but doubt it as the dll and exe run in the same memory space, and ddraw is used as the access medium to the video memory.

I'm betting that the texture surfaces are an unsupported pixel format (I'm starting to think 8-bit palettized is most likely). If so the texture creation will have to be intervened by hooking the call in ddraw, altering it then recalling ddraw. Is it possible to force ddraw caps on? Maybe that would be an alternative method of finding the problem? In fact how do you force apps to use the "reference rasterizer"? :D

[edited by - euank on April 21, 2003 7:15:23 AM]

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!