Quote:Original post by scope you need a surface in D3DPOOL_DEFAULT to render to and another one in D3DPOOL_SYSTEMMEM to copy the render target data to and lock.
*** Source Snippet Removed ***
thanks you!
Quote:Original post by InvalidPointer Is there a reason why you need to be using the GPU for this sort of calculation? Why are you not creating a separate buffer in regular system memory and working off that? Depending on the number of teams you could probably get away with a big array of bytes (i.e. one byte per 'texel') and avoid the massive hassle of lockable render target support, (which varies from card to card, btw) video memory transfers, etc. You're placing a lot of unnecessary constraints on your implementation, methinks :)
I don't get it, what I am doing is not just calculation. I am actually painting the model textures in the game and I also need to be able to find which part of the models are painted.
Quote:Original post by InvalidPointer Is there a reason why you need to be using the GPU for this sort of calculation? Why are you not creating a separate buffer in regular system memory and working off that? Depending on the number of teams you could probably get away with a big array of bytes (i.e. one byte per 'texel') and avoid the massive hassle of lockable render target support, (which varies from card to card, btw) video memory transfers, etc. You're placing a lot of unnecessary constraints on your implementation, methinks :)
I don't get it, what I am doing is not just calculation. I am actually painting the model textures in the game and I also need to be able to find which part of the models are painted.
Sure, I understand that. What I'm suggesting is that you keep and maintain a separate record of what is painted CPU-side (theoretically at a lower resolution, unless you require really high-precision control) and keep it updated in tandem with the GPU representation. While there's obviously a bit of extra work involved, odds are good that you'll get better performance anyway as you avoid the stalling/pipeline bubble headaches associated with doing frequent video memory transfers every frame. While the approach you suggested sounds elegant at first, I suspect it may end up being more trouble than it's worth once you actually start using it in practice. It's not really what graphics hardware was designed for; algorithms that run "entirely on the GPU" are considered heavily advantageous for a reason.
clb: At the end of 2012, the positions of jupiter, saturn, mercury, and deimos are aligned so as to cause a denormalized flush-to-zero bug when computing earth's gravitational force, slinging it to the sun.
Sorry I'm a late to follow up. You can do what you want without reading any texture data back to the CPU side by using an occlusion query. I have a sample of using an occlusion query to count texels which answer a certain condition. It shouldn't be difficult to make this fit your needs by limiting the drawing (and therefore counting) to the area of the texture that the character is over (instead of using a rectangle that covers the entire texture). You can then read the query result to see if the character is over the relevant colour.
