Quote:Original post by circlesoft
Ok, I ran it on a quad-core Intel 3.2ghz machine
Stop saying that. You make me feel all envious. :)
Debug D3DX uses 22 threads on a dual core CPU?
Stop saying that. You make me feel all envious. :)
Author
Well, this is odd. D3DXCreateTextureFromFileInMemoryEx() creates 22 threads, but D3DXCreateTextureFromFileEx() creates a mere 16 (Loading the same image as that sample app)
I'm still trying to find out what boosts it from 4 threads to 16 or 22 though.
I'm still trying to find out what boosts it from 4 threads to 16 or 22 though.
Quote:Original post by ET3DQuote:Original post by circlesoft
Ok, I ran it on a quad-core Intel 3.2ghz machine
Stop saying that. You make me feel all envious. :)
Ok sorry. So I uhh...ran it on my old Apple II (porting it = [sick]), and it only made 1 thread and finished in a brisk 35.000 seconds. You should see this baby play FarCry:
Are you some kind of masochist? As long as release mode works as expected, I'd rather not know the details of what the debugging code was doing, as long as the debugging code worked.
Quote:Original post by circlesoftDoes that beast have hardware D3D10 support? If so, chalk me up for one.
Jack
Quote:Original post by jollyjeffers
Does that beast have hardware D3D10 support? If so, chalk me up for one.
Of course! What kind of scam do you think I'm running here? It even comes with a free copy of Duke Nukem: Forever!
Author
Quote:Original post by MastabaYes [smile]
Are you some kind of masochist? As long as release mode works as expected, I'd rather not know the details of what the debugging code was doing, as long as the debugging code worked.
It's mainly because it's poluting my debug output - I can't see a damn thing. The last time I ran this app I counted over 150 lines of "The thread 'Win32 Thread' (0xe04) has exited with code 0 (0x0).". At least it's exiting with code 0 I suppose :P
EDIT: I just noticed I turned a bit of my code off. Wit hmy code running normally, it loads 5 screens in 256x256 chunks, over a 1024x768 resolution. That's 1320 lines in my debug output filled with crap >_<
I'm giving up for now. I've tried to replicate the same conditions in my test app and my main app, but there's not much more I can do without ripping the whole guts out. The only thing left to try is to just set up a device with predefined formats, and then try to create a texture and see what happens...
EDIT: Nope, that didn't work either. I still can't get both apps to have the same number of threads :/
Quote:Original post by circlesoftQuote:Original post by jollyjeffers
Does that beast have hardware D3D10 support? If so, chalk me up for one.
Of course! What kind of scam do you think I'm running here? It even comes with a free copy of Duke Nukem: Forever!
Duke Nukem: Forever! There goes any shreds of plausibility that this had!
You could always write a debug logging system. My current system logs a ton of the stuff that Direct3D does and without all of the nonsense (it logs renderstate changes and values, texturestagestate changes and values, sampler state changes and values, texture creation and creation parameters, device creation, and optionally hardware enumeration. I'm still working on vertex/indexbuffers, shaders, and a few other things.) If you design the system around the Direct3D classes you can do a simple debug switch conditional to get rid of the extra logging:
Here's an example of my log:
Is obviously a LOT slower (since I'm using about 20 overloaded functions to get the string version of types) but its helps a lot when tracking down bugs.
Edit: Also, I want one of those Apples too!
Edit 2: Yeah, I just realized that my response isn't very helpful, since the debug isn't the problem its the thread situation, sorry!
[Edited by - Programmer16 on May 8, 2006 6:31:16 PM]
#ifdef _DEBUGclass VertexBuffer{public:HRESULT FreePrivateData(REFGUID refguid);HRESULT GetDesc(D3DVERTEXBUFFER_DESC *pDesc);HRESULT GetDevice(IDirect3DDevice9 **ppDevice);// etc};#elsetypedef IDirect3DVertexBuffer9 VertexBuffer;#endifHere's an example of my log:
Is obviously a LOT slower (since I'm using about 20 overloaded functions to get the string version of types) but its helps a lot when tracking down bugs.
Edit: Also, I want one of those Apples too!
Edit 2: Yeah, I just realized that my response isn't very helpful, since the debug isn't the problem its the thread situation, sorry!
[Edited by - Programmer16 on May 8, 2006 6:31:16 PM]
Programmer16, thats a pretty neat set of log-file output. I've read a few threads about using the private-data stuff to get extra debugging information but never bothered to implement it myself.
I get the same crap with my copy of VS'05 pro, including loads of "symbol not found" messages at start up... but way back when Vista worked and I was using VSTS instead *none* of those messages ever showed up. It was just pure D3D/D3DX debug output.
VSTS cant be that different from VS'05 pro in this sense. Maybe just a different default setting somewhere...?
Cheers,
Jack
Quote:It's mainly because it's poluting my debug output - I can't see a damn thing. The last time I ran this app I counted over 150 lines of "The thread 'Win32 Thread' (0xe04) has exited with code 0 (0x0).".I think you can turn it off.
I get the same crap with my copy of VS'05 pro, including loads of "symbol not found" messages at start up... but way back when Vista worked and I was using VSTS instead *none* of those messages ever showed up. It was just pure D3D/D3DX debug output.
VSTS cant be that different from VS'05 pro in this sense. Maybe just a different default setting somewhere...?
Cheers,
Jack
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
