• Advertisement

arabesc

Member
  • Content count

    20
  • Joined

  • Last visited

Community Reputation

171 Neutral

About arabesc

  • Rank
    Member

Personal Information

  1. The new index data gets corrupted after discarding previous index buffer through the glBufferData(GL_ELEMENT_ARRAY_BUFFER, size_, 0, GL_DYNAMIC_DRAW) call. Some parts of the scene have missing triangles, other parts are looks like a chaotic triangles soup. I have tested it on ATi HD3850, Catalyst 9.5, WinXP SP3. I will test tomorrow on nVidia board, but I think there are should not be any problems. This is a lock method of my dynamic index buffer class: CDynamicIndexBuffer::write_lock CDynamicIndexBuffer::lock_for_fill(std::size_t stride, std::size_t count, std::size_t &start_offset) { const std::size_t lock_size = stride*count; if (lock_size > size_) throw std::runtime_error("dynamic index lock size is too large"); if (!size_) return write_lock(); glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, buffer_id_); CHECK_GL_ERRORS(); const std::size_t offset = (stride - (offset_ % stride)) % stride; offset_ += offset; const bool discard = offset_ + lock_size > size_; void *data = 0; if (GLEW_ARB_map_buffer_range) { GLbitfield access = GL_MAP_WRITE_BIT; if (discard) { offset_ = 0; access |= GL_MAP_INVALIDATE_BUFFER_BIT; } else access |= GL_MAP_INVALIDATE_RANGE_BIT; data = glMapBufferRange(GL_ELEMENT_ARRAY_BUFFER, offset_, lock_size, access); CHECK_GL_ERRORS(); } else { if (discard) { offset_ = 0; glBufferData(GL_ELEMENT_ARRAY_BUFFER, size_, 0, GL_DYNAMIC_DRAW); // discard old buffer CHECK_GL_ERRORS(); } data = glMapBuffer(GL_ELEMENT_ARRAY_BUFFER, GL_WRITE_ONLY); CHECK_GL_ERRORS(); data = data ? advance_pointer<void>(data, offset_) : data; } if (!data) return write_lock(); start_offset = offset_; offset_ += lock_size; return write_lock(*this, unlock_wrapper, data); } The GLEW_ARB_map_buffer_range branch is working as it should. The problem is with else branch. It is not working normally. But it will work without any side effects if I remove glBufferData call. Is it a driver bug or my incorrect usage of OGL?
  2. I need to upgrade DX SDK which one?

    Quote:Original post by Zipster but if it's a problem for you, then just use the compiler from an older SDK. Are you talking about external compiler - fxc.exe? I am using ID3DXEffectCompiler from static library.
  3. I need to upgrade DX SDK which one?

    Quote:Original post by Evil Steve Care to expand on why not? Because of problems with the HLSL shader compiler. I explained it in this post. DXSDK from Aug2007 till now are useless for me, because it broke the HLSL code that were working before.
  4. I need to upgrade DX SDK which one?

    Personally, I do not recommend DXSDK updates from August and November 2007. June 2007 is somewhat ok for me.
  5. November 2007 DirectX SDK out now!

    I think this version has serious problems with the new shaders compiler. Stable shaders either can't be compiled now or stopped working properly. For example: for (int i = 0; i != 4; ++i) { float4x3 transform = bones_matrices[input.blend_indices[i]]; local_position.xyz += mul(input.position, transform)*input.blend_weights[i]; float3x3 inverse_transpose_transform = inverse_transpose(transform)*input.blend_weights[i]; binormal += mul(input.binormal, inverse_transpose_transform); tangent += mul(input.tangent, inverse_transpose_transform); normal += mul(input.normal, inverse_transpose_transform); } This part of shader will not compile under the vs_2_0 profile with the following error: "error X4505: maximum temp register index exceeded". Under the vs_3_0 profile it will compile but gives incorrect result. Unrolling the loop solves the problem. p.s.: Sorry for mistake. The problem exist from the august 2007 DXSDK update. The last stable SDK for me is june 2007. [Edited by - arabesc on December 5, 2007 9:44:25 AM]
  6. GeoMipMap Implementation

    Quinnie Just small hint. Use (1 << AdjustingMipMapLevel) instead of pow(2, AdjustingMipMapLevel). And & ((1 << AdjustingMipMapLevel) - 1) instead of % (int)(pow(2, AdjustingMipMapLevel)). It's much faster.
  7. Integration in Physics

    Integration Basics
  8. VSM and ATI

    Quote:Original post by Guoshima Any info btw on fetch4 The only cards that have support for fetch4 are x1300, x1600 and x1900. x1800 does not support this feature.
  9. Cube Mapping Gone Bad

    Try to disable mipmapping: MipFilter = None; It seems that low mip levels in the cubemap texture are completly black.
  10. Packing depth components

    To encode the depth: pixel.z = depth; pixel.w = frac(depth*256.0); To decode: depth = dot(pixel.zw, float2(1.0, 1.0/256.0));
  11. Ain't it Terragen-like ?

    How about procedural rivers now?
  12. Quote:Original post by deffer On the other hand - my app crashes. And you're saying that it helped, so there was a problem to be solved. In my case the problem exist on Win2K system and does not exist on WinXP. So the problem may be in the OS/drivers but not in the DirectX.
  13. Quote:Original post by deffer Yeah, that was obvious ;\ It's XP btw. I had the similar problem some time ago, but it appears only on the W2K system. Quote:If pData points to a random location, it could be my program's memory space, in which case IsBadWritePtr will return TRUE. If the return value of the IsBadWritePtr is TRUE then the memory pointer is not valid for writing. So, IsBadWritePtr does not really help you solve the problem? In my case it helped. Edit: spelling. [Edited by - arabesc on September 2, 2005 8:57:29 AM]
  14. Quote:Original post by deffer I'm a window guy (well most of the time). If you are using the DirectX it's obvious that you are using Windows OS too. But which version? I'm assume that it's Win2000. Quote:I don't know what the returned pointer means, really. It could be an invalid location, or it could be a random location, which could point to a valid(but still, incorrect) memory location. And what stops you from doing this check? VOID* pData = NULL; hr = IDirect3DVertexBuffer9::Lock(0, SizeToLock, &pData, 0); if (SUCCEEDED(hr) && FALSE == IsBadWritePtr(pData, SizeToLock)) ... Quote:I would like to know what really happens there. Is there any info about locking (not managed) buffers while device is lost? From DX SDK Doc's: Quote:Locking Operations Internally, Direct3D does enough work to ensure that a lock operation will succeed after a device is lost. However, it is not guaranteed that the video-memory resource's data will be accurate during the lock operation. It is guaranteed that no error code will be returned. This allows applications to be written without concern for device loss during a lock operation.
  15. What operating system do you use? After successful buffer lock try to check returned memory pointer with Win32 API function IsBadWritePtr.
  • Advertisement