• Advertisement

Mete

Member
  • Content count

    36
  • Joined

  • Last visited

Community Reputation

127 Neutral

About Mete

  • Rank
    Member
  1. There are a couple of different ways to load mipmapped textures in Vulkan. I use this way: create a buffer that is big enough to contain all mipmap levels bind it to pre-allocated scratch memory that is VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT copy the mipmaps into the buffer using vkMapMemory, memcpy, vkUnmapMemory create an image with VK_IMAGE_TILING_OPTIMAL and bind it to VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT memory use vkCmdCopyBufferToImage with VkBufferImageCopy entries for each mipmap that contain the offset into the buffer to point to the mip data. Also make sure to use vkGetBufferMemoryRequirements and vkGetImageMemoryRequirements. The scratch host visible memory size is 6mb, which is enough for most textures and all the device local textures go into one huge memory.   This works well for mipmapped textures and also mipmapped cube maps.
  2. MSVC problem?

    Thank you very much for your explanations! Now I also know, that the linker isn't required to report all violations of the ODR, which makes sense. - Mete
  3. MSVC problem?

    Thanks for your help! The possible fix 1 (with copy constructor and assignment operator) didn't help, but the possible fix2 (with anonymous namespace) helped. I can't explain this. If I rename the struct names, then it works. But the structs are define in that file only and shouldn't be visible outside the .cpp. Also, I'm quite sure that it's not a debugger problem only. Because, when I add a test: if (arrObjectInfo[i].nDestinationLod != 1) MessageBox(0, "", "", 0); and compile it in release mode: - without the anonymouse namespace: the messageboxes come and it crashes at exit. - with the anonymouse namespace: no messageboxes come and exits fine. It looks to me, like the compiler or linker gets confused. - Mete
  4. This happens in MSVC 6.0, 7.1 and 8.0 Express. What's wrong with that code? I don't see anything wrong with it. Neither the compiler nor the linker give an error message. Here is a screenshot, which shows it: http://www.swissquake.ch/chumbalum-soft/images/msvc-bug2.png As you can see, I have the class file1 and file2. Each of them use a struct tObjectInfo, which are only visible in file1.cpp/file2.cpp respectively. Nowhere else. However, when I step into file2::doit(), the contents of the local variable 'oi' are correct, but after the push_back(), the content of the first element of arrObjectInfo is wrong! The nDestionationLod member has not been copied! It looks like the compiler took the tObjectInfo from file1.cpp, instead of the tObjectInfo of file2.cpp? Can somebody explain that? - Mete
  • Advertisement