Fredericvo

Hello,

 

I just read the following article which I believe has been mentioned here before as well.

 

http://realtimecollisiondetection.net/blog/?p=86

 

As I have a fair understanding of the DirectX 11 API for most of my needs and a somewhat fair understanding of OOP I want to start

designing a render loop (short of calling it game loop since there's no AI or physx yet) around a more scale-able architecture that could ultimately grow into a game... That means separating responsibilities in different classes and decoupling what can be, and ideally have a render class rather than have objects draw themselves.

 

Mind you I'm still at rastertek tutorial level of understanding LOL and it's mostly how to connect all the dots that's difficult more so than each separate topic such as shadows, skyboxes, reflections, render to texture or what-have-you.

 

It's how games elegantly add creatures, remove them, iterate through them, draw them in the most optimal order etc that seems to be the crux of videogame development imho. I believe this article pretty much hits the nail on the head and draw call sorting might make everything fall into place...

 

Now initially that sounded weird... sorting "function calls" ?!? lolwut? but of course it's the data that has to be rendered that's sorted by renderstate. Fine. Now in the article they mention "using standard sorting algorithms" and "key/value" pairs. That to me screams std::map but is this what is usually used by professionals? I tried a bit of dummy example code with std::map to see how fast it is and it appeared that even iterating through a couple of entries on my i5 laptop with 256 kb of cache takes a couple of milliseconds, an eternity when you've got only 16 ms per frame and you are supposed to iterate 2000 draw calls. I admit I haven't tried to actually sort 2000 entries as I had to come up with 2000 things to fill it with but could it be that it won't take much longer as some of this time was overhead? Or is std::map just not the right solution? What I liked about it is that it's actually automatically sorted but maybe some unordered map followed by a sort is better? (then again my measurement was done for iterating only, after I had inserted values so the timing would even be worse otherwise)

Maybe my measuring tool wasn't appropriate? I used "time.h" clock() like so:

 

t=clock()

//iterate std::map with barely 6 key/value pairs in it

t=clock()-t;

cout << t <<endl;

 

I know there are higher resolution timers out there but since we're talking milliseconds here I guess I'd measure the same. Now if it's simply an inaccurate tool I'll reconsider...

 

I wanted to show some simple directx 11 program I made to a few online friends and then it appeared that

they got a missing msvcrt11.dll error.

 

I've tried to use a few solutions found online such as:

 

http://www.rhyous.com/2011/11/01/avoiding-the-msvcr110-dll-or-msvcr110d-dll-is-missing-error/

 

and

 

http://www.cplusplus.com/forum/beginner/91177/

 

but nothing works. especially the following solution:

 

For the C-runtime go to the project settings, choose C/C++ then 'Code Generation'. Change the 'runtime library' setting to 'multithreaded /MT' instead of 'multithreaded dll'

 

the exe would simply crash.

 

I wouldn't want my programs to require users to install the runtime library and such. What do I do next?

 

PS: I'm using Visual Studio Express 2012 on a 64-bit windows 7 although my friend needed a 32-bit build so I did that. Apparently a 64-bit release with the /MT setting does work but not for 32-bit. I still need it to work since he's got a 32-bit PC.

 

 

Hello,

 

I've finally decided to do the big step towards D3D11 from D3D9 and whoah it's a lot more overwhelming indeed.

I was a bit shocked to hear that D3DX was deprecated so decided to directly learn it the right (and hard) way without it.

Unfortunately every tutorial available, including the excellent Rastertek ones, seems to still use D3DX rather than DirectXmath.

I wanted to give it a try updating their tutorial to one that wouldn't require D3DX, even for compiling shaders and loading textures.

After battling with compilation errors the whole weekend I managed to finally compile without errors or warnings but.... Big disappointment.... It doesn't work when I run it. I can see the coloured background being cleared (set it to red on purpose as I wasn't sure the original black was the clear colour or just a fullscreen of plain nothingness lol. The triangle however isn't being rendered.

Very often beginners have problems with backface culling settings, or plain wrong transformations etc but this is from an existing tutorial that is known to work...

 

Here is what I did.

I replaced every D3DX type (e.g. D3DMATRIX, D3DVECTOR4, etc) with a new DirectXmath type (XMMATRIX,...)

I replaced the utility functions (D3DXMatrixRotateY,...) with equivalent XM functions too and adapted the parameters or other peculiarities that changed.

I removed runtime shader compilation (D3DXCompileFromFile) and instead embedded compiled shader files (*.cso) into the exe by using the resource compiler. Visual Studio 2012 itself uses FXC.EXE to compile the shaders along with the project. Very elegant solution.

During runtime I use FindResource/LoadResource/LockResource to get a pointer that CreateVertex/PixelShader can use.

I tried debugging extensively and all the pointers are being allocated and buffers created successfully so I assume it works.

 

One issue I had earlier was alignment errors on XM types and apparently compiling as x64 (which ultimately is also what everyone will have to do anyway in a near future) solved it. However, could it be that some variable size somewhere would need to be updated to a size_t or whatever to solve my problem? Or is it something else? I really can't find it which is why I decided to post my source here (well it's Rastertek's source with my updates)

If I can get this to work I might create an online tutorial as well and will credit whoever helped me here. Thanks.

 

EDIT: Before" RARing" the project to upoad it here I introduced a careless mistake due to which you probably got resource compiler errors... colorv.cso not found etc

I assumed I couldn't know if you'll compile under debug or release so attempted conditional compiling but it appears that #ifdef Debug or _Debug doesn't work at all at least on my system. To add insult to injury I misspelled a directory name (Debuge). 

If you compile under debug update the resource file to

 

 

OK so I'm trying to move away from the FFP and step into the world of shaders and the first thing I get is an error LOL.
I'm trying to get www.two-kings.de 's tutorial #18 to work but the pixel shader doesn't seem to compile. The executable they delivered worked on my computer but if I compile myself and run the program then the pixel shader fails)

I'm trying to isolate the problem so I made the following little C program

#include <d3dx9.h>
#include <stdio.h>
#include <D3DX9Shader.h>

#pragma comment (lib, "d3dx9.lib")

LPDIRECT3DPIXELSHADER9 pixelShader = NULL;			
LPD3DXBUFFER code = NULL;

int main() {

HRESULT result;
result = D3DXCompileShaderFromFile( "pixel.psh",   //filepath
										NULL,		  //macro's			
										NULL,		  //includes		  
										"ps_main",	 //main function	  
										"ps_1_1",	  //shader profile	
										0,			 //flags			  
										&code,		 //compiled operations
										NULL,		  //errors
										NULL);		 //constants
	if(FAILED(result))
		printf("failed: %p %d %d\n",result,result,D3DERR_INVALIDCALL);
	printf("failed: %p %d %d\n",result,result,D3DXERR_INVALIDDATA);
	printf("failed: %p %d %d\n",result,result,E_OUTOFMEMORY);
	Return 0;

}

Here is the supposed pixel shader

// Pixel shader input structure
struct PS_INPUT
{
	float4 Position   : POSITION;
	float2 Texture	: TEXCOORD0;
};


// Pixel shader output structure
struct PS_OUTPUT
{
	float4 Color   : COLOR0;
};


// Global variables
sampler2D Tex0;


// Name: Simple Pixel Shader
// Type: Pixel shader
// Desc: Fetch texture and blend with constant color
//
PS_OUTPUT ps_main( in PS_INPUT In )
{
	PS_OUTPUT Out;							   //create an output pixel

	Out.Color = tex2D(Tex0, In.Texture);		 //do a texture lookup
	Out.Color *= float4(0.9f, 0.8f, 0.4, 1);	 //do a simple effect

	return Out;								  //return output pixel
}

And sure enough it fails but with none of the standard error values sch as D3DXERR_INVALIDDATA or something like that.

The vertex shader compiles fine.

Hello,

I've been messing around with different ways to export models from 3D modeling software and have achieved mixed success with it.
One program I made based on Damiano Vitulli's program can read 3ds files, and I added multiple subset support but not yet normals since the format doesn't support it and I will have to calculate them procedurally. It still lacks materials too. So in the meantime I tried to use x-files which have normals & materials included and is (at least on the surface) easier to extract data from.

So in theory you are supposed to "Mesh->OptimizeInPlace()" in order to build an attribute table which gives you access to the partitioning of the mesh in different subsets. DrawSubset is supposed to use this information and issue its own DrawIndexedPrimitive calls.

Well if I draw the whole object as one I can see that I got the correct vertex & index buffers but when I try to use info from the attribute table itself i.e.

subset 0: FS:0 FC:12 VS:0 VC:24
subset 1: FS:12 FC:12 VS:24 VC:24
subset 2: FS:24 FC:12 VS:48 VC:24
subset 3: FS:36 FC:12 VS:72 VC:24
legend: FS = Face Start, FC = Face Count, VC = Vertex Count VS = Vertex Start as per D3DXATTRIBUTERANGE structure


d3ddev->DrawIndexedPrimitive(D3DPT_TRIANGLELIST, 0, 72, 24, 36, 12); //Subset 3

It doesn't work properly.

If I'm more lenient about the vertex start & count by issing the following command:

d3ddev->DrawIndexedPrimitive(D3DPT_TRIANGLELIST, 0, 0, totalnumberofverts, 60, 12);

It works a bit better but some subsets appear correctly and others seem mangled.

The idea of course is to achieve the following:

int k=0;
for (k=0;k<numsubsets;k++)
{
d3ddev->DrawIndexedPrimitive(D3DPT_TRIANGLELIST, 0, Attrib[k].VertexStart, Attrib[k].VertexCount, Attrib[k].FaceStart, Attrib[k].FaceCount);
}

What am I doing wrong?


Note that I've already tried different combinations of
D3DXMESHOPT_ATTRSORT | D3DXMESHOPT_COMPACT | D3DXMESHOPT_VERTEXCACHE
for the OptimizeInPlace() call.