Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

634 Good

About neneboricua19

  • Rank
  1. neneboricua19

    HLSL storing for the next step

    You cannot modify a texture you are reading from in a pixel shader. It seems that you are always adding a constant value to the texture pixel. In this case, you can upload a shader constant from your applicaiton. Your applicaiton can increase this constant over time. The code would look something like this. // I assume you're using D3D10 due to your shader syntax... // Main applicaiton init D3DXVECTOR4 gColorIncrement(0.0f, 0.0f, 0.1f, 0.0f); ... // During rendering. gColorIncrement.b += 0.1f; pEffectColorIncrementVariable->SetFloatVector( &g_ColorIncrement ); // Draw mesh... //Shader float4 colorIncrement; float4 main( PS_INPUT psInput ) { .... float4 texColor = texture.Sample(samLinear, psInput.Tex); return texColor + colorIncrement; } neneboricua
  2. Yes, the way you're doing it is correct. It's common to do this sort of thing when you're using a texture to store look-up values. One thing to keep in mind is that you will probably want to offset your texture fetches by half a pixel so that you sample in the center of the pixel instead of on the exact border. That way you can be sure you're fetching the value you expect. neneboricua
  3. neneboricua19

    RGB is actually BGR...!

    Quote:Original post by Ashkan You can "get used to it" if you're targeting one platform, but if you want to write an application that runs on, say both of those processors, you have to know the architectural differences by heart. Not necessarily. You just have to figure it out once and write macro's for each platform/processor. That's what we do for PC, Xbox 360, and PS3. We use macro's that handle bit orders when messing with the bits of a texture. It's much like setting up all the Windows framework code; you write it once and then never look at it again (until there's a bug in it somewhere :P) Some of the enumerations may be switched around (like D3DFMT_A32B32G32R32F and DXGI_FORMAT_R32G32B32A32_FLOAT), but the underlying bits remain the same as they've always been. neneboricua
  4. neneboricua19

    RGB is actually BGR...!

    If you look at the code sample on the ID3D10Texture1D::Map doc page, you'll see that if you get a pointer to the bits of an RGBA texture, you walk the memory in A, B, G, R order for the same reasons that Namethatnobodyelsetook stated. neneboricua
  5. neneboricua19

    GeForce3 and Vertex Shader Problem(Solved)

    Quote:Original post by RWThurman I've already run the shader with identity matrices. When I'm using the reference device on the suspect GeForce3, the shaders all render just fine. This means that tracing the shaders won't help me. Right? Not necessarily. The fact that it works with the reference device is good, but that doesn't automatically mean the problem is a hardware bug. It could be that the driver is very picky about how it wants data. I've run into bugs with the way some drivers treat QNAN's, INF, and other kinds of things. In the end, you still have to get it working (unless you're able to mandate > Geforce 3 hardware) and I doubt Nvidia is going to release new drivers for a card that's already 5+ years old. If you've already run it with identities for bone matrices, then you have an idea as to where the problem is. You should really take a look at it in PIX and watch the number go through your shader so you can verify that you get the data you expect at each step of the process. PIX will tell you if data is getting trashed somewhere. neneboricua
  6. neneboricua19

    GeForce3 and Vertex Shader Problem(Solved)

    First thing I'd suggest is to run this through Pix to help you see what's going on. Step through the shader and make sure all the values are reasonable. I doubt the vertex shader is actually crashing. What's probably happening is that there is garbage data somewhere and the vertex doesn't get transformed correctly or it's transformed to somewhere outside the screen bounds and therefore doesn't get rendered. You say the blendedPosiiton seems to be giving your problems. As a test, set the bone matrix in your for loop to be identity and see if you get the rigid pose of your model. If that works, then you know the problem lies in how you access your bone matrices. If that doesn't work, then you know the problem lies in the normalizedBoneWeights. It's all about Divide & Conquer. My guess is that data isn't being interpreted correctly. Another tip is to try to use D3DDECLTYPE_UBYTE4 for the blend indices and not worry about D3DCOLORtoUBYTE4 conversions. Set your verices to use int's for the blend indices. neneboricua
  7. neneboricua19

    Vertex buffer and Dynamic memory

    To read and/or write the data in a vertex/index buffer you must call Lock. There is no way around that. You cannot render from a buffer while it is Lock'ed because the device needs to be sure that the data is ready to be rendered, is not changing, and is in a location in memory the GPU can access easily. If you need access to the data and don't want to call Lock on the buffers, you can make a seperate copy at load time from whatever your source data is. Or perhaps you can call Lock on the buffer, copy the data out to some other location, and Unlock it. What is it you're trying to do? Perhaps with a bit more info, people would be able to point you in the right direction. neneboricua
  8. This isn't as big of a problem as it first seems. When a device becomes lost in the middle of a frame, most calls to the device will still succeed and everything will work just fine. The proper functionality is emulated won't cause a problem during rendering. The problem will show up when you call Present. That's when you'll get a Device_lost kind of error. At that point, you can call TestCooperativeLevel and see if the device just needs to be Reset or if it is indeed lost and needs to be recreated from scratch. When you're restoring all of your resources, it is possible for the device to be lost again (although extremely unlikely). The bright side is that you don't have to do anything in particular to handle this case. If the device is lost during resource restoration, all of your normal render calls will still work without a problem. What will happen is that things will be fine until you call Present again, at which point you'll get another device lost message, which will then cause you to call TestCooperativeLevel and take the appropriate action. If you dig deep, this is what DXUT does. DXUT's handling of device lost/reset is meant to be the example of how to properly handle these things in a professional environment. Everything in DXUT's Core folder has been and is meant to be used in shipping games. neneboricua
  9. neneboricua19

    Scissor rect issue

    Because of the way RECT's work, they don't include the very last pixel. This is for consistency with Win32. Try to set the rect to [0,0],[1,1]. That will probably give you what you want. neneboricua
  10. Keep in mind that by convention, the region you specify using the RECT structure does NOT include the pixel at location (right,bottom). For example, when RECT is passed to the FillRect function in Win32, the rectangle is filled up to, but not including, the right column and bottom row of pixels. See the RECT page on MSDN for more info ( This convention is also applied in D3D. So your rounding of screen coordinates may be off, which would account for why you see the problem intermitantly. neneboricua
  11. neneboricua19

    HLSL Flow Control Quirks

    Depending on your graphics card, the driver may try to do some trickery with control statements like these. To give the driver a better hint as to how you want the code generated try using the D3DXSHADER_PREFER_FLOW_CONTROL flag when you create the shader. You could also try using the [branch] directive in the HLSL code itself. It would look something like this. [branch] if (nRenderMode == 0) y = r * r + i * i; else if (nRenderMode == 1) y = r; else if (nRenderMode == 2) y = i; This would give the driver stronger hints about what you really want to do. neneboricua
  12. neneboricua19

    Retrieving a region of render target

    Sounds like a good plan. The only "gotcha" might be that if you want to use multiple render targets, all of the targets have to be the same dimensions and format. Keep in mind that if you write out the ID's for the entire buffer and call GetRenderTargetData on it every frame, you will take a pretty large performance hit. If at all possible, you should at least double, if not tripple buffer this data. In a particular frame, you should access the results of the GetRenderTargetData call you issued 2 or 3 frames before. This is to avoid stalling the pipeline. Hopefully by the time you actually try to look at ID's, the copy will be done and you won't incur such a large performance cost. neneboricua
  13. neneboricua19

    Retrieving a region of render target

    If you want to accelerate picking, you could render to a 1x1 render target and give each object a unique ID (ID could be something as simple as the object index in your master array). That ID is what is rendered out by the pixel shader to the target. Then you could use GetRenderTargetData and read back that one pixel to see which object is getting picked. I did this a few years ago in a research project and it worked pretty well. The drawback is that it adds another render pass. However, the main expense here is transforming the vertices; the pixel shader will run on just one pixel per object. Since most applications are fill-rate bound, the transformation of extra vertices probably won't affect performance much. If you want to avoid processing the vertices twice, you could look at using ProcessVertices to save the results of the transformations so you can reuse it. neneboricua
  14. neneboricua19

    Performance of multiple buffer Lock's

    Quote:Original post by sirlemonhead Quick question about the D3Dx functions if the OP doesn't mind me thread hijacking momentarily...I have an old app here using pre-SSE matrix translation assembly functions (think it's mmx optimised assembly). If D3Dx makes use of SSE/SSE2 then it'd be worth my while changing the code over to use D3Dx? If the code is PC-only, then yes, it would be worth while to use the D3DX math functions. They will take advantage of the best assembly instructions possible for whichever CPU architecture the application runs on. That being said, you should probably take a look at how much of a bottleneck this is for you right now. If you have a small number of math routines that are getting called many, many times per frame, then switching to D3DX might be worth it because the change wouldn't take that long and the potential benefit is high. In our case, we were spending over 30ms in CPU skinning originally. Way too much time for comfort, so we optimized the math routines as much as we could and then went to GPU skinning in all but a few special cases. neneboricua
  15. neneboricua19

    Performance of multiple buffer Lock's

    Conclusion: Using one large dynamic vertex buffer for all vertex types works just fine. There is no need to allocate one buffer for each vertex type. The only change to existing code is that each object needs to keep the byte offset into the large vertex buffer of where it's data starts. This offset is then used in a call to SetStreamSource. All draw calls stay the same. I ended up dong one lock operation at the beginning and an unlock when all processing threads were done and before I start rendering. I don't want to take the chance of bad drivers messing things up. So at least in this case, it's possible to emulate console behavior; you allocate a large vertex buffer and parcel it out to different objects reguardless of vertex type. Just keep track of the byte offset into the buffer and you're good to go. Note about AGP memory. It's not *really* seperate memory. The concept of AGP memory is that a small part of system RAM is designated for use by the graphics card. It is still physically located in system RAM and must be uploaded to the GPU through the AGP bus when needed. Yes, the AGP bus is pretty fast compared to standard system memory transfers, but it's not as fast as direct fetches from GPU memory. This is why you can't use a dynamic texture as a render target. It's because the actual memory is stored in system RAM and the GPU can't write to it directly, but it can pseudo-read from it via transfers over the AGP bus to GPU memory. neneboricua
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!