ok woah. you are creating the vertex buffer to hold 3 vertices, but you copy 30 vertices into it. So change your vertex creation function, and mulitply sizeof(CUSTOMVERTEX_UNTRANSFORMED) by 30 instead of 3. Becuase you want 30 vertices correct?
indeed it is unfortunate that you didnt get access violations. It would''ve at least helped a little in finding the problem.
:::: [ Triple Buffer V2.0 ] ::::
dx8.1 vertex buffers need be called every frame?
Author
By golly gee wiz...you are right!
I will make that update right away....but...this brings another question...
First of all, before I read prgrmmr''s post, I ran my program without filling the VB every frame. I tried this again so that i could test if everything is drawn when i click the title bar.
Well, to my pleasant surprise and pleasant frustration, the whole box is being drawn - which is NOT what it used to do. And nothing has changed!
Now after reading prgrmmr''s post, we have godo reason to suspect that the mismatched vertex count being passed in is the problem (ill find out soon enough). But why would the copying of 30 vertices into an allocated space of 3 allow most of the box to be drawn in the first place?!
This is just weird and bad.
But then again, so is my programming i guess.
I will make that update right away....but...this brings another question...
First of all, before I read prgrmmr''s post, I ran my program without filling the VB every frame. I tried this again so that i could test if everything is drawn when i click the title bar.
Well, to my pleasant surprise and pleasant frustration, the whole box is being drawn - which is NOT what it used to do. And nothing has changed!
Now after reading prgrmmr''s post, we have godo reason to suspect that the mismatched vertex count being passed in is the problem (ill find out soon enough). But why would the copying of 30 vertices into an allocated space of 3 allow most of the box to be drawn in the first place?!
This is just weird and bad.
But then again, so is my programming i guess.
Cheers guys,
When using DirectX for programming/rendering, I recommend using the debug dll''s, because if you have an error, or an access violation or something, it will output a message to your debug window.
Also, you should think about writing a wrapper class for the vertex buffer object and index buffer, along with anything else you can think of! This can help (read: eliminate) these kinds of errors.
You can check out most major engines, like the NeoEngine, or the OGRE engine. Or, comparitevly, you can check out my render API, at www.geocities.com/aes_cyber_god/xion_engine_v2.zip
It''s really a useful tool, and totally stops these kinds of errors before they occur. Good luck, and may the force (read: electricity) be with you
Chris Pergrossi
When using DirectX for programming/rendering, I recommend using the debug dll''s, because if you have an error, or an access violation or something, it will output a message to your debug window.
Also, you should think about writing a wrapper class for the vertex buffer object and index buffer, along with anything else you can think of! This can help (read: eliminate) these kinds of errors.
You can check out most major engines, like the NeoEngine, or the OGRE engine. Or, comparitevly, you can check out my render API, at www.geocities.com/aes_cyber_god/xion_engine_v2.zip
It''s really a useful tool, and totally stops these kinds of errors before they occur. Good luck, and may the force (read: electricity) be with you
Chris Pergrossi
quote:But why would the copying of 30 vertices into an allocated space of 3 allow most of the box to be drawn in the first place?!
Probably becuase the next 27 spaces in memory were not being used, and were free. So they just got copied in and nothing was there to stop them. These kind of memory writes are really pains in the neck. Becuase they work sometimes and other times they dont work. So it gets really confusing. I had an array[150] that was storing stuff once, and it would work fine all the time, then it started crashing all of a sudden. Turns out all the time I was writing about 200+ objects into the array[150]. And it took me months before I noticed it
:::: [ Triple Buffer V2.0 ] ::::
I had once the same problem as IFooBar. It''s really a painful problem.
The reason is ( why does it work sometimes and not other times ) that you can use the unallocated places of the memory free. So if you make a random number, and do for example:
(INT*)*rand()=16;
it maybe works, if no other application uses that area of the memory. And the 16 will there until other application uses that memory block.
So for some time the
(INT*)*thesamerandomnumber()==16
but when an other applicition allocates that memory block, and may fill it with zeros.......
(INT*)*thesamerandomnumber()==0 or (INT*)*thesamerandomnumber()==random number
so, if you have some fortune, you may write values into unallocated memory, and it may works. But if you don''t allocate the block, other apps have rights to allocate it, and the values can be changed.
So if 36 vertices written into the place of three vertices, and renders correctly, you are fortunate. If the memory block after the 3 vertices is already allocated, you''ll have an exception. I some app allocate that memory after you wrote into it, the values will be lost. If no app writes to that block, so can use it.
If you allocated 36vertices*sizeof( VERTEX ) you''ll never have any problem. Because that X bytes of memory is yours, and just yours.
So the reason why the whole cube rendered is you had fortune.
The reason is ( why does it work sometimes and not other times ) that you can use the unallocated places of the memory free. So if you make a random number, and do for example:
(INT*)*rand()=16;
it maybe works, if no other application uses that area of the memory. And the 16 will there until other application uses that memory block.
So for some time the
(INT*)*thesamerandomnumber()==16
but when an other applicition allocates that memory block, and may fill it with zeros.......
(INT*)*thesamerandomnumber()==0 or (INT*)*thesamerandomnumber()==random number
so, if you have some fortune, you may write values into unallocated memory, and it may works. But if you don''t allocate the block, other apps have rights to allocate it, and the values can be changed.
So if 36 vertices written into the place of three vertices, and renders correctly, you are fortunate. If the memory block after the 3 vertices is already allocated, you''ll have an exception. I some app allocate that memory after you wrote into it, the values will be lost. If no app writes to that block, so can use it.
If you allocated 36vertices*sizeof( VERTEX ) you''ll never have any problem. Because that X bytes of memory is yours, and just yours.
So the reason why the whole cube rendered is you had fortune.
Just a general note: Whenever something runs wrong/doesn''t run, try it with the reference rasterizer. If the reference rasterizer gets it right, then it''s a driver/card issue. If it doesn''t get it right then it''s certainly your fault.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
