Advertisement

Reading BSP map data into DX11 Buffers

Started by February 21, 2020 04:56 PM
50 comments, last by Tom_W 4 years, 10 months ago

https://cdn.discordapp.com/attachments/550944244551122954/682044176845897754/unknown.png

https://cdn.discordapp.com/attachments/550944244551122954/682044253563912239/unknown.png

And I figured it all out on my own, Thank you Joe for all your help! It's far from perfect, it has trouble rendering more complex prims, but I've finally made some progress.

Now, to the index buffer. in DX9 it was simple, you could just do pDevice→SetIndices(&indexbuffer);
What is the equivalent in DX11?

Advertisement

Alright, I am now drawing prims perfectly, without so much as a single tri missing or in the wrong place:
https://cdn.discordapp.com/attachments/550944244551122954/682085825198161943/unknown.png

What I had to do was as follows:
I had to set the index buffer to DXGI_FORMAT_R16_UINT, as my indices were of the type WORD. I'm surprised nobody picked that up.

After setting the index buffer, I used the following draw call:
pDevCon->DrawIndexed(m_pFaces[nFace].NumMeshVerts, m_pFaces[nFace].nFirstMeshVerts, m_pFaces[nFace].FirstVert);

The Z and Y vertices were mixed up, and had to be switched.

Just for the DrawFace function member of the BSP class, since DX10 and after split into a device and device context, I had to adjust all the argument types to both ID3D11Device* pDevice, and ID3D11DeviceContext* pDevCon, for every function. I can now simply call bsp.PVS_Render(d3d11device, d3dcontext, (D3DXVECTOR3)pos); and it drew everything perfectly.

I'm sure I'm bound to run into a brick wall very soon, so I'll be crying the blues asking for help/mercy very soon.

Thank you all for your help!

Yay, congrats : )

Tom_W said:
And I figured it all out on my own

Tom_W said:
I had to set the index buffer to DXGI_FORMAT_R16_UINT, as my indices were of the type WORD. I'm surprised nobody picked that up.

As said, people won't read through all your code to fix your bugs. We have our own issues to figure out.

Yes, I've learned that over and over again. I ported the header 100% – it loads its own shaders, index/vertex buffers, textures(double pointers of ID3D11ShaderResourceView type with sampler states for each texture, and Transposes the matrix for the shader) from the BSP map, and even collision detection.

I will upload the modified header to my server so everyone can make use of it. Seems only fair.

Joe, after watching this video, did you really think I was going to be able to pull this off by myself? Or did you think I was going to pussy out and go back to D3D9? Be honest please. BRUTUALLY HONEST. I kept offering half a grand dozens of times convinced I couldn't pull this off ?

On to porting the game engine and continuing working on it!

Tom_W said:
Joe, after watching this video, did you really think I was going to be able to pull this off by myself? Or did you think I was going to pussy out and go back to D3D9? Be honest please

I assumed you would fix it. Because just using a API is the bare minimum, you know? It's just setting things up, picking the best option of a few… but it does not solve a real problem.

What worries me more are the questions:

Are you aware of the limitations of an ancient Quake renderer? (Can't handle detailed levels; pretty static; can't handle large outdoors. So you are restricted to retro style. Is this intended?)

Does your engine have support for collision detection? If not, are you able to add this yourself? (This would be a problem requiring some skill to solve, and full understanding of engine and its data.)

Notice: With powerful GPUs of today, you could just model the whole level in Blender and render it as is with some frustum culling, with less code.
For smaller low poly levels, the BSP / PVS may actually actually hurt performance more than it helps, because it generates a lot of draw calls and state changes.

Just asking. If your goal would be a more modern looking game, probably you would come to the point where you scratch your current engine and start from zero sooner or later.
So better asking early, i thought.

Advertisement

JoeJ said:

Tom_W said:
Joe, after watching this video, did you really think I was going to be able to pull this off by myself? Or did you think I was going to pussy out and go back to D3D9? Be honest please

I assumed you would fix it. Because just using a API is the bare minimum, you know? It's just setting things up, picking the best option of a few… but it does not solve a real problem.

What worries me more are the questions:

Are you aware of the limitations of an ancient Quake renderer? (Can't handle detailed levels; pretty static; can't handle large outdoors. So you are restricted to retro style. Is this intended?)

Does your engine have support for collision detection? If not, are you able to add this yourself? (This would be a problem requiring some skill to solve, and full understanding of engine and its data.)

Notice: With powerful GPUs of today, you could just model the whole level in Blender and render it as is with some frustum culling, with less code.
For smaller low poly levels, the BSP / PVS may actually actually hurt performance more than it helps, because it generates a lot of draw calls and state changes.

Just asking. If your goal would be a more modern looking game, probably you would come to the point where you scratch your current engine and start from zero sooner or later.
So better asking early, i thought.

Yes, as I mentioned in my previous post, the collision detection system has been implemented. It's flawless(minus a bit of gravity issues--I'll fix that later on as I learn DX11, all these tutorials are using XMMATRIX types and XMFLOAT and I hate that, I'd rather use D3DXMATRIX/D3DXVECTOR3/etc. And yes, it's intended – I'm not trying to to imitate Quake III maps, with the latest map editors you can literally drop in an OBJ mesh and I intend on rendering it. I don't have to go through a painstaking process for OBJ meshes in D3D9 anymore, right in the DX2010 SDK Samples for DirectX 10 they have an OBJ rendering class. It's the way that I can create maps that is important, and GTKRadiant is the best editor to create maps with vertices/indices, even for modern games(IMHO).

Ha, ok.

Tom_W said:
with the latest map editors you can literally drop in an OBJ mesh and I intend on rendering it. I don't have to go through a painstaking process for OBJ meshes in D3D9 anymore

Meaning you can import any model into Radiant, and it converts it to BSP?

Or is it that you model coarse level (walls) in Radiant, but you can also import models as ‘detail’ prefabs (like a statue, or a chair, a lamp…) and place them for decoration?

JoeJ said:

Ha, ok.

Tom_W said:
with the latest map editors you can literally drop in an OBJ mesh and I intend on rendering it. I don't have to go through a painstaking process for OBJ meshes in D3D9 anymore

Meaning you can import any model into Radiant, and it converts it to BSP?

Or is it that you model coarse level (walls) in Radiant, but you can also import models as ‘detail’ prefabs (like a statue, or a chair, a lamp…) and place them for decoration?

The latter. For collision detection with these meshes I can just set a bounding box. I can flat out make an entire map as an OBJ format, which I might do, but as far as I'm concerned atm, the best way of making complex prims that are interactive is using GTKRadiant.

The framerate is very choppy as a result of 100+ chrome tabs open, game/debuggers/instances of visual studio all on a laptop.

I LOVE HOW LIGHTING WORKS WITH DIRECT3D11. In D3D9 to achieve this I had go through so much crap!

This topic is closed to new replies.

Advertisement