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).

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!

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]

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

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 processCalled ATI3DCIF_InitCalled ATI3DCIF_ContextCreateCalled ATI3DCIF_ContextSetState	eRStateID: C3D_ERS_VERTEX_TYPE	Vertex type =4Called ATI3DCIF_ContextSetState	eRStateID: C3D_ERS_TMAP_EN	Enabled Texture Mapping =1Called ATI3DCIF_ContextSetState	eRStateID: C3D_ERS_SPECULAR_EN	Enabled Specular Lighting =1Called 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 =0x00429150Called ATI3DCIF_ContextSetState	eRStateID: C3D_ERS_SURF_DRAW_PTR	Desktop surface @0x0012FDC0Called ATI3DCIF_ContextSetState	eRStateID: C3D_ERS_SURF_DRAW_PITCH	Desktop Pitch =640Called ATI3DCIF_ContextSetState	eRStateID: C3D_ERS_TMAP_SELECT	Texture Handle @0x00429150Called ATI3DCIF_RenderBegin	Render Context =0x00000001Called ATI3DCIF_RenderPrimList	Number of Vertices =3Called ATI3DCIF_RenderEndCalled 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]