Windows has triggered a breakpoint,error at SetFVF()

Started by
13 comments, last by 21st Century Moose 11 years, 12 months ago
Hi,

how about the size of the index buffer? The size is defined as 2 * 8192 * 3 which gives 49152 bytes. However, you write 65*65*6*2 = 50700 amount of bytes.

Best regards!
Advertisement
It turned out the error is something even deeper,I commented out the entire Terrain class and everywhere it's referenced and now it won't even render the FPS counter text,which worked perfectly a while ago.It even shows the window background color as if the D3D device isn't initialized,even tho it initializes without an error.I guess I'll have to start from scratch,since it's 3000 lines of spaghetti code now and I don't know how to find the problem.
When this happens it is really time to start checking every HRESULT coming from API and DX calls and when one returns different from D3D_OK or S_OK, assert and check the values you are passing to your API calls. Most API calls when they fail will give you a reason why they fail.
Also spagetti code is recoverable just requires more work, easiest is to start splitting of classes to their own files and take it from there.

Worked on titles: CMR:DiRT2, DiRT 3, DiRT: Showdown, GRID 2, theHunter, theHunter: Primal, Mad Max, Watch Dogs: Legion


When this happens it is really time to start checking every HRESULT coming from API and DX calls and when one returns different from D3D_OK or S_OK, assert and check the values you are passing to your API calls. Most API calls when they fail will give you a reason why they fail.
Also spagetti code is recoverable just requires more work, easiest is to start splitting of classes to their own files and take it from there.

When this happens it is really time to start checking every HRESULT coming from API and DX calls and when one returns different from D3D_OK or S_OK, assert and check the values you are passing to your API calls. Most API calls when they fail will give you a reason why they fail.
Also spagetti code is recoverable just requires more work, easiest is to start splitting of classes to their own files and take it from there.


Yeah I re-ordered everything and I think I fixed the problem,cause now D3D starts and it shows the text and reads directinput properly.I jus thave one final question that might sound a little noobish - how do you make a vertex declaration for the programmable function pipeline?The method I'm using now(CUSTOMVERTEX struct,DWORD FVF_CUSTOMVERTEX(blabla|blabla|etc),set FVF) I understand is the old method that doesn't support special effects.

how do you make a vertex declaration for the programmable function pipeline?The method I'm using now(CUSTOMVERTEX struct,DWORD FVF_CUSTOMVERTEX(blabla|blabla|etc),set FVF) I understand is the old method that doesn't support special effects.


Look at the D3DXDeclaratorFromFVF function as a place to start - you can use it to get an array of D3DVERTEXELEMENT9 structs that can then be passed into a CreateVertexDeclaration call, so much of what you currently know is reusable. That should get you up and running quite fast with declarations, and make it easier to move on to custom declarations when the time comes.

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.

This topic is closed to new replies.

Advertisement