• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

3635 Excellent

About Adam_42

  • Rank

Personal Information

  • Interests
  1. There are various tools that can do this for you. Here's a couple of examples: - http://www.fraps.com/ Can capture screenshots and videos. - https://renderdoc.org/ - This is a graphics debugger, that can be very handy for other things too, but it also lets you save any render target out as an image. If you're using Windows 10, you can also just press Windows Key + G to capture images and videos from games.
  2. Running x86 build crashes

    Those two instructions load the edx register with the contents of the "__that" parameter to the ModelPart move constructor, and then load 16 bytes from there into xmm0. It looks like that's where it has crashed. That isn't going to be an alignment issue, as movups (as opposed to movaps) won't crash for misaligned addresses. I'm thinking that the contents of __that is actually NULL, or otherwise an invalid pointer. You can check what the pointer is by looking at the contents of the edx register at the point it crashes. However, since it's a reference, and not a pointer, it really shouldn't be NULL. Could your custom allocator have returned nullptr?
  3. Running x86 build crashes

    One thing worth noting, is that on x86 the standard Windows memory allocator only returns 8 bytes aligned memory. On x64 it's 16 byte aligned. That could be causing you problems. I'd suggest overriding global operator new and delete (don't forget the array and nothrow variants) to use _aligned_malloc() to force 16 byte alignment for everything. Having said that, if you want to debug a crash in optimized code, then what you really need to be looking at is the disassembly. I'd also recommend using the /Zo compiler option (which requires edit and continue to be disabled). In addition, you want to disable the "just my code" option. This will let you see more details on what's going on as you have some external code in your crash callstack. I also wouldn't fully trust the diagnosis of "_that is 0x1". I have seen incorrect messages there before, especially for uncommon crash reasons like data misalignment. Looking at the assembly instruction that it crashed on, and the registers used to calculate the memory address that it's accessing can give a more reliable answer. If you're not familiar with reading x86 assembly, then I found a basic guide at: http://www.cs.virginia.edu/~evans/cs216/guides/x86.html. You probably won't need to read past the section on data movement instructions to get started with debugging your crash. If need be you could, post the contents of the disassembly window and registers window here for someone else to look at.
  4. Windows actually provides an API for retrieving the names of keys - GetKeyNameText(). A quick search found some old C++ example code at: http://www.setnode.com/blog/mapvirtualkey-getkeynametext-and-a-story-of-how-to/ - you probably don't need to worry about XP compatibility any more. To use it from C# you'll probably want something like the example code at: https://stackoverflow.com/questions/38584015/using-getkeynametext-with-special-keys
  5. Clang will happily accept the first example with one small change: struct Point2 { Point2() = default; Point2(int a, int b) {x = a; y = b;} // extra constructor for ease of use int x, y; }; Adding the "=default;" in place of {} makes different C++11 rules apply to it and makes it a POD type. To make gcc happy, you need to go one step further: struct Point2 { Point2() = default; int x, y; }; // Non-member function that works like a constructor inline Point2 Make_Point2(int a, int b) {Point2 result; result.x = a; result.y = b; return result;} I'm not sure if gcc is being overly strict here, or if Clang is being lenient in regards to the standard.
  6. The default stack size on Windows is 1MB. 1. The stack size doesn't change on different computers. Maybe some people don't use the feature that consumes lots of stack space, or its stack consumption depends on the input data? 64-bit code will also consume more stack space than 32-bit. 2. Windows supports any stack size that will fit in RAM. You can change it in the linker settings, or as a parameter when creating a thread. I guess 1MB is a reasonable trade off between how much space the program gets to use, and the memory that's consumed by creating a thread, but if you have different requirements you can change it. Also if your stack is too big buggy recursive functions could take a long time before they fail with a stack overflow. 3. When it's crashed in the debugger add the esp (or rsp for x64) register to the watch window. That's the stack pointer, and you can watch it change as you move up and down the call stack in the debugger. Looking at how much it changes by will tell you how much stack is used. Alternatively just look at the size of the local variables in each function on the call stack until you find the big ones - you can use sizeof(variableName) in the watch window to see how big something is.
  7. I'd also recommend turning on the compiler warning that will catch this, by increasing the warning level to 4 in Visual Studio. You could even go as far as turning that warning into an error by doing: #pragma warning(error : 4706)
  8. I've reproduced the behaviour, and simplified the case that goes wrong. Here's my minimal failing case: groupshared uint tempData[1]; void MyFunc(inout uint inputData[1]) { } [numthreads(2, 1, 1)] void CSMain() {     MyFunc(tempData); } It looks like just passing the argument to the function is enough to make it fail to compile. Here's a workaround for the problem - don't pass the array as a function argument: #define ElementsCount 256 groupshared uint tempData[ElementsCount]; void MyFunc(in uint3 gtID) { tempData[gtID.x] = 0; } [numthreads(ElementsCount/2, 1, 1)] void CSMain(uint3 gID: SV_GroupID, uint3 gtID: SV_GroupThreadID) { MyFunc(gtID); }
  9. https://blogs.msdn.microsoft.com/chuckw/2012/05/07/hlsl-fxc-and-d3dcompile/ explains all the details of how the compiler DLL works. If you want to check which version of the DLL your program is using, then just pause it in the debugger and look through the modules window for the DLL. I believe the latest version is D3dcompiler_47.dll Have you tried compiling the shader using fxc.exe?
  10. Based on a quick search I found these:   https://www.gamedev.net/topic/594131-dx11-compute-shader-race-condition-error-when-using-optimization-level-2-or-3/ http://xboxforums.create.msdn.com/forums/t/63981.aspx   Based on those it sounds like there might be a bug in certain versions of the compiler. I'd suggest trying to use either command line fxc.exe or a more recent version of the d3dcompiler dll to see if it makes any difference.
  11. ground quad and ground texture sizes

        It sounds like you really want to be using DXT compressed textures. DXT1 is 4 bits per pixel (i.e. 8 times smaller than RGBA). You do lose a bit of image quality, but it usually not significant. If you need an alpha channel, then you want DXT5 instead of DXT1, which doubles the size to 1 byte per pixel.   Note that they don't only save space on disc, they also stay compressed in video memory. Because of that rendering with them can also be quicker than uncompressed textures.
  12. DX11 Reading one texel from depthbuffer

    Picking is often done entirely on the CPU. You construct a 3D ray and intersect it with objects / triangles in the scene.   I found a basic tutorial at: http://www.rastertek.com/dx11tut47.html   If you're using a physics engine of some kind, it should be able to handle the hit testing of the ray for you. Here's an example that uses the Bullet Physics library: http://halogenica.net/ray-casting-and-picking-using-bullet-physics/
  13. Image resources and textures

    While you can write code to load any image format you want to, I'd strongly recommend using .dds files. They support many features that many standard image file formats like jpeg don't always handle:   - Mip maps. You want to generate high quality ones offline, and not try to generate them at load time. Especially if your textures are compressed. - Texture compression (BC1-BC7 formats in DX11, DXT1/DXT5 in D3D9). These can make your textures up to 8 times smaller in video memory as well as reducing the file size. - Floating point textures. - Cubemaps. - Alpha channels.   If you want to convert images to DDS format programatically, then you can use https://github.com/Microsoft/DirectXTex   If you prefer a Photoshop plugin, then Nvidia have made one: https://developer.nvidia.com/nvidia-texture-tools-adobe-photoshop
  14. It varies. In some cases it can speed things up, and in others it can reduce performance. You need to test for your specific usage, on the hardware that you care about, and see what happens.   One way it can speed things up is when you're hitting memory bandwidth limits on writing to the frame buffer. In my experience this mostly affects lower end graphics cards. In those cases using discard to implement an alpha test so you don't write out fully transparent pixels can improve performance. This might apply to the rendering of a particle system, for example.   On the other hand, in shaders that write to the depth buffer, using discard can hurt performance. This is because using discard has a side effect of disabling some of the hardware's depth buffer optimizations, because it makes the depth output of the shader impossible to predict before the shader runs. Disabling those optimizations can make future draw calls go more slowly, especially ones that would fail the depth test.   In addition note that enabling alpha blending can also have a performance cost - it uses more memory bandwidth than opaque rendering, because it has to do a read-modify-write of the frame buffer instead of just a write.
  15. You need to be able to reproduce the bug yourself to identify the problem, and be confident that any fix you make has solved the problem.   If you can't reproduce the problem another way, you could always buy yourself a second hand 9500 GT. A graphics card that old won't be expensive.
  • Advertisement