awww, i could use a gun right now
Wast of time dude, I did this years ago and it only resulted in collision detection that was so slow it was unusable. Just find a physics API and stop pounding your head on the table.
Quote:Original post by CodaKiller
I did this years ago and it only resulted in collision detection that was so slow it was unusable.
Well, that does not mean that implementing a custom collision detection system is generally bound to be slow and unusable, now does it?
After all Bru said he is doing this for learning and (at least I assume) for the sake of the fun of just doing it. Also, when done right you won't suffer any performance impact, e.g. when using hiearchies such as octrees or optimize in the right places such as inverse transformation of the camera position as opposed to transforming all vertices.
If it was 'years ago' then even your code will be 50-100 times faster today. For a finished game I would recommend using the library but it is well worthwhile learning how things work in my opinion.
Quote:Original post by Bob Janova
Wait, what?
Because if we quote your first post, then your mentioning of [ source ] will break all the layout [smile].
Quote:
And yeah, the code is not well written, but at least with a XXX tag it doesn't give me a horizontal scrollbar :p
Ah no, the astlye suggestion was targetted at the OP :D
edit: D'Oh, it happened again :/
Aha, I see. Yeah the trick to get [source] to appear correctly in a post won't get copied through to a quote. Cunning :)
Author
oh wow, it still doesnt work.
i mean i am pretty sure my direction is correct and so is my player's position data(i even manipulated the vertices with rock's world matrix,and vice versa i also later tryed entering 0,0,0 as the position) am i realy still doing something wrong?
i mean i am pretty sure my direction is correct and so is my player's position data(i even manipulated the vertices with rock's world matrix,and vice versa i also later tryed entering 0,0,0 as the position) am i realy still doing something wrong?
If you haven't already, my advice to you would be to distill the problem down to its most basic elements. Create a mesh with only 3 vertices and try to reproduce the problem there. If you can, you know something is specifically wrong with your line segment / triangle test. Otherwise you know to look elsewhere, such as at your vertex gathering (i.e. Are you generating actual triangles to check against).
The best way to go about programming is to compartmentalize everything, whether it be a function or class. Once you do that, you can test each chunk by itself and feel confident that once each chunk works you no longer need to worry about them.
The key is to divide and conquer - that can never be said enough!
The best way to go about programming is to compartmentalize everything, whether it be a function or class. Once you do that, you can test each chunk by itself and feel confident that once each chunk works you no longer need to worry about them.
The key is to divide and conquer - that can never be said enough!
Author
Quote:Original post by earl
If you haven't already, my advice to you would be to distill the problem down to its most basic elements. Create a mesh with only 3 vertices and try to reproduce the problem there. If you can, you know something is specifically wrong with your line segment / triangle test. Otherwise you know to look elsewhere, such as at your vertex gathering (i.e. Are you generating actual triangles to check against).
The best way to go about programming is to compartmentalize everything, whether it be a function or class. Once you do that, you can test each chunk by itself and feel confident that once each chunk works you no longer need to worry about them.
The key is to divide and conquer - that can never be said enough!
i'll do that soon, but first i found something intresting that is causing the problem.
i printed VerticesNum into a textfile, and then compared with the original mesh. what i found out is that the x and z coordinates of every vertex are almost the same(probably not the same because in the mesh file it is printed as a double and probably in the buffer it is a float). yet the y coordinate in the VerticesNum buffer is completly diffrent than the one in the original mesh.
i've put the code that gets the vertex buffer on the first post. anybody knows what's wrong with it?
Couple of things to check:
- Does GetNumBytesPerVertex( ) == sizeof(D3DXVECTOR3)?
- Are you comparing VerticesNum before or after you transform to world space?
- If you're comparing both in world space, are you transforming VerticesNum to world space correctly?
- Does GetNumBytesPerVertex( ) == sizeof(D3DXVECTOR3)?
- Are you comparing VerticesNum before or after you transform to world space?
- If you're comparing both in world space, are you transforming VerticesNum to world space correctly?
Author
Quote:Original post by earl
Couple of things to check:
- Does GetNumBytesPerVertex( ) == sizeof(D3DXVECTOR3)?
- Are you comparing VerticesNum before or after you transform to world space?
- If you're comparing both in world space, are you transforming VerticesNum to world space correctly?
- Does GetNumBytesPerVertex( ) == sizeof(D3DXVECTOR3)? it seems like not.
- Are you comparing VerticesNum before or after you transform to world space?-before
- If you're comparing both in world space, are you transforming VerticesNum to world space correctly? - i think so, i use D3DXVec3TransformCoord to multiply each cell in the verticesnum array with rock's matrix(scale*rotation*translate);
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
