• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.


  • Content count

  • Joined

  • Last visited

Community Reputation

805 Good

About Mr_Fox

  • Rank
  1. Hi Guys, IIRC, before dx12, we can create texture array (textures have to be the same format, same reso) and dynamically index into them in shader. But it is impossible to dynamically index 'texture array' which texture have different size (actually you can't create texture array of different reso).   Now, from what I know, it seems with Dx12 rootsig, resource heap model, we can dynamically index 'texture array' of different size, format(same channel, same data type), right?  Here is the link talk about that: https://msdn.microsoft.com/en-us/library/windows/desktop/mt186614(v=vs.85).aspx   However, the above link only use textures has same format, reso. And it didn't mention whether it support texture array of different reso. So I think it's better first ask here before I write my test code (It will be frustrating if I spend half hour coding only get to know index into texture array of different size is not supported, while you guys already know it)   Also if it is supported, is there anythings I should be aware of?    Thanks in advance~
  2. "The D3D12 device being used only supports copies to/from row major textures." Does that means there are certain DX12 device could support other ways to access row major textures? BTW, my GPU is GeForce GTX TITAN X
  3. Well, I tried Custom heap with row major texture, but get this error The D3D12 device being used only supports copies to/from row major textures.  Neither D3D12_RESOURCE_FLAG_ALLOW_RENDER_TARGET nor D3D12_RESOURCE_FLAG_ALLOW_UNORDERED_ACCESS may be set. [ STATE_CREATION ERROR #599: CREATERESOURCE_INVALIDMISCFLAGS] So it seems we can't set allow uav, so means at least for texture with row major(UNKNOWN layout still works), compute shader can't directly write to cpu mapable resource 
  4. Thanks Jesse and Adam. I think I will just create texture on such Custom heap to be able to directly map to CPU read. But are there any caveats for map texture buffer? (Texture is ROW_MAJOR) I tried map structured/typed buffer they are straight foreword. But I bet texture (even row_major) is different 
  5. Thanks Adam, but if such Custom heap could share all the flags/properties of a Readback heap while without aforementioned restriction, why readback heap have that restriction at the first place? 
  6. Correct me if I am wrong, I don't think we could have compute shader directly write to structured/typed buffer in readback heap?
  7. Thanks Jesse, I will try that later~       Thanks  Adam, just curious, if a texture is mapped, with data layout in a swizzled way, what the advantages for mapped texture2D over mapped structured buffer? (I feel we have to spend extra CPU cycle to 'decode' data for further CPU process) And what the potential use case for map a texture2D by CPU? Thanks in advance
  8. Hi Guys, Are there any straight forward way to copy texture2d data into CPU readable array? IIRC, we can't create texture2d on readback heap right?  Copy upload heap buffer to texture2d require lots of bookkeeping, so I guess do a revers task is also very tricky.   Right now I use a compute shader to copy texture2D to a structured buffer in default heap first, and then use CopyBufferRegion to copy it to buffer in readback heap, and finally do a map on it to read data back to CPU.   I feel my approach is overly complicated, there must be a much convenient way to copy texture2D to CPU readable array (otherwise how we do capture screen to a file?)   Thanks in advance.  
  9. So it seems 'cross-platform' Vulkan could only work on windows, linux/unix (for desktop/laptop)? Feel really bad to see that 'cross-platform' is narrowing down....     If I got it correctly writing driver for Vulkan should be easier than writing for OpenGL( since lots responsibilities is moving from driver to developer) Why mac os have opengl support but not Vulkan? (I don't have any experience with mac before....)
  10. Sorry for my laziness,  I thought since I already ask a lot, it may not be super annoying to add such easy-to-find question, maybe someone work for renderdoc could reveal their real 'future plan' in this thread...... well, I really wish to be exposed to explicit resource barrier (handling resource transition by myself) which IIRC is not available in openGL 
  11. Hey Guys,   I have being playing around directx since dx9 to dx12, and haven't touch any other graphics APIs yet. For all those years, I really enjoy developing dx with all its helping tools/libs: dx debuglayer, GPU-validation layer, GPUView, VSGD, and recently, the PIX. Now I have to switch to use mac os (and ios maybe?) exclusively in the near future. So I need to pick up another compatible graphics API to play with. What I really enjoy is DX12 style lower level APIs, and have heard that there are maybe only two choices for me: Vulkan (not sure mac os support it or not?) and Metal.   Since I haven't touched either APIs, I really wish to know what you guys think of it: is it in a mature state for beginner? (I remember when I work on my first DX12 project when DX12 just coming out, driver bugs drives me crazy....) are there any good GPU debug tools available for the API? (does Metal get renderDoc support?) are there any good profiling tools? (like GPUView for DX) are there plenty of tutorials/samples on the internet for beginners?   Also it will be great if anyone could talk about the general pros and cons for using Vulkan/Metal on apple devices.   Thanks in advance 
  12. So you suggest that the internal counting won't cause noticeable slow down? I always feel that doing counting is expensive when the number is huge. For example in an extreme case like for rendering to a 4k RT, there maybe around 8M serialized counter update (I guess internal counter is doing interlockedAdd), and will that cause serious perf drop? (though I haven't test that...). Or even for a 1080p RT, I feel that counting the updated pixels will have a very bad perf impact (Or the internal counter updating is not totally serialized?) Do we need to do a reduction after this to get the actual count? or the counter is per pixel?
  13. So I guess, right now there isn't any better approach than using macro to achieve what I really want   ¯\_(?)_/¯  I totally agree that in general globals are bad, but I was wondering: for example in a graphic engine, static buffers are well-defined, and persistent every frame (like depth buffer, velocity buffer, SSAO, etc..), I feel having them become globals made render loop much more clear and easier to manage and easier to tune (for example: move passes around for better async compute perf). So it will be great if you could share you thought on why globals are bad in my case. Thanks~
  14. Hi Guys,   This thread may not be super relevant to DirectX and XNA, however it's about GFX buffer management, so I guess most of you guys probably have encountered this before, and that's why I asked here. But if site admin think this should be in a different sub forum, please feel free to move it.   So my problem is maintaining a static 'list' of GPU RTs,  I want to have a central place to write down all the configurations  of each RTs (which also contains render irrelevant information like debug name, resize policy, debug viewable, etc), so it is easy for me to add/remove/edit RTs. I also wish to use simple container to hold them, but still want to use debug name to index them.   When I first start my project, there is only few RTs, so I use naive separate arrays to manage my RTs : a string array to store RT debug name,  a enum to map Idx to a readable name, an array of descriptor for each RTs. etc.. But as the number of RTs grows, the naive way won't work anymore since it's getting harder to ensure the consistence between all these arrays.. So I switch to use macro with def header to handle all these like the following:   surBuf_def.h #ifndef DEF_SURFBUF #error "DEF_SURFBUF() undefined" #endif DEF_SURFBUF(KINECT_COLOR, COLOR_SIZE, DXGI_FORMAT_R11G11B10_FLOAT, DXGI_FORMAT_UNKNOWN) DEF_SURFBUF(KINECT_DEPTH, DEPTH_SIZE, DXGI_FORMAT_R16_UNORM, DXGI_FORMAT_UNKNOWN) DEF_SURFBUF(KINECT_INFRA, DEPTH_SIZE, DXGI_FORMAT_R11G11B10_FLOAT, DXGI_FORMAT_UNKNOWN) DEF_SURFBUF(KINECT_DEPTH_VIS, DEPTH_SIZE, DXGI_FORMAT_R11G11B10_FLOAT, DXGI_FORMAT_UNKNOWN) DEF_SURFBUF(CONFIDENCE, DEPTH_SIZE, DXGI_FORMAT_R8G8B8A8_UNORM, DXGI_FORMAT_UNKNOWN) DEF_SURFBUF(KINECT_NORMAL, DEPTH_SIZE, DXGI_FORMAT_R10G10B10A2_UNORM, DXGI_FORMAT_UNKNOWN) DEF_SURFBUF(TSDF_NORMAL, DEPTH_SIZE, DXGI_FORMAT_R10G10B10A2_UNORM, DXGI_FORMAT_UNKNOWN) DEF_SURFBUF(FILTERED_DEPTH, DEPTH_SIZE, DXGI_FORMAT_R16_UNORM, DXGI_FORMAT_UNKNOWN) DEF_SURFBUF(TSDF_DEPTH, DEPTH_SIZE, DXGI_FORMAT_R16_UNORM, DXGI_FORMAT_UNKNOWN) DEF_SURFBUF(VISUAL_NORMAL, VARI_SIZE1, DXGI_FORMAT_R10G10B10A2_UNORM, DXGI_FORMAT_UNKNOWN) DEF_SURFBUF(VISUAL_DEPTH, VARI_SIZE1, DXGI_FORMAT_R16_UNORM, DXGI_FORMAT_D32_FLOAT) DEF_SURFBUF(DEBUG_A_DEPTH, DEPTH_SIZE, DXGI_FORMAT_R16_UNORM, DXGI_FORMAT_UNKNOWN) DEF_SURFBUF(DEBUG_A_NORMAL, DEPTH_SIZE, DXGI_FORMAT_R10G10B10A2_UNORM, DXGI_FORMAT_UNKNOWN) DEF_SURFBUF(DEBUG_B_DEPTH, DEPTH_SIZE, DXGI_FORMAT_R16_UNORM, DXGI_FORMAT_UNKNOWN) DEF_SURFBUF(DEBUG_B_NORMAL, DEPTH_SIZE, DXGI_FORMAT_R10G10B10A2_UNORM, DXGI_FORMAT_UNKNOWN) DEF_SURFBUF(DEBUG_CONFIDENCE, DEPTH_SIZE, DXGI_FORMAT_R8G8B8A8_UNORM, DXGI_FORMAT_UNKNOWN) main cpp file: //================================================================================================= // I still have separate arrays of my RT info, but consistency is ensured by the surfbuf_defs.h file //================================================================================================= struct SurfBuffer { ViewSize sizeCode; DXGI_FORMAT colorFormat; DXGI_FORMAT depthFormat; ColorBuffer* colBuf; DepthBuffer* depBuf; }; enum SurfBufId : uint8_t { #define DEF_SURFBUF(_name, _size, _colformat, _depthformat) _name, #include "surfbuf_defs.h" #undef DEF_SURFBUF SURFBUF_COUNT }; const wchar_t* _bufNames[] = { #define DEF_SURFBUF(_name, _size, _colformat, _depthformat) L"SURFBUF_" #_name, #include "surfbuf_defs.h" #undef DEF_SURFBUF }; CASSERT(ARRAY_COUNT(_bufNames) == SURFBUF_COUNT); SurfBuffer _surfBufs[] = { #define DEF_SURFBUF(_name, _size, _colformat, _depthformat) \ {_size, _colformat, _depthformat, nullptr, nullptr}, #include "surfbuf_defs.h" #undef DEF_SURFBUF }; CASSERT(ARRAY_COUNT(_surfBufs) == SURFBUF_COUNT); .... .... .... //========================================================================================= // then in the application code, I can use enum to easily use all these RTs very efficiently //========================================================================================= // Request depthmap for ICP _tsdfVolume.ExtractSurface(gfxCtx, GetColBuf(TSDF_DEPTH), _vis ? GetColBuf(VISUAL_DEPTH) : nullptr, GetDepBuf(VISUAL_DEPTH)); cptCtx.ClearUAV(*GetColBuf(CONFIDENCE), ClearVal); if (_vis) { // Generate normalmap for visualized depthmap _normalGen.OnProcessing(cptCtx, L"Norm_Vis", GetColBuf(VISUAL_DEPTH), GetColBuf(VISUAL_NORMAL)); _tsdfVolume.RenderDebugGrid( gfxCtx, GetColBuf(VISUAL_NORMAL), GetDepBuf(VISUAL_DEPTH)); } // Generate normalmap for TSDF depthmap _normalGen.OnProcessing(cptCtx, L"Norm_TSDF", &*GetColBuf(TSDF_DEPTH), GetColBuf(TSDF_NORMAL)); // Pull new data from Kinect bool newData = _sensorTexGen.OnRender(cmdCtx, GetColBuf(KINECT_DEPTH), GetColBuf(KINECT_COLOR), GetColBuf(KINECT_INFRA), GetColBuf(KINECT_DEPTH_VIS)); cmdCtx.Flush(); _tsdfVolume.UpdateGPUMatrixBuf(cptCtx, _sensorTexGen.GetVCamMatrixBuf()); // Bilateral filtering _bilateralFilter.OnRender(gfxCtx, L"Filter_Raw", GetColBuf(KINECT_DEPTH), GetColBuf(FILTERED_DEPTH), GetColBuf(CONFIDENCE)); // Generate normalmap for Kinect depthmap _normalGen.OnProcessing(cptCtx, L"Norm_Raw", _bilateralFilter.IsEnabled() ? GetColBuf(FILTERED_DEPTH) : GetColBuf(KINECT_DEPTH), GetColBuf(KINECT_NORMAL), GetColBuf(CONFIDENCE)); It works as I wish, and satisfied all my requirement, but it really confuses VS intellisense, and I end up get annoy intellisense errors (these errors are harmless, but really annoy)   Given the fact that the use of macro is discouraged after C++11, and all these intellisense errors. I hope to know how you guys dealing with buffer management in your engine.   I was thinking of having a structure contains all configure RT info, and then use an advanced container like unordered_map to relate debug name with actual RT to avoid using Macros, but string with those container like map is way too slower than the one I am currently using.   Please let me know what's your solutions: if you think the macro way is bad,  why it's bad? and what are better solutions for my case?  or if you think the macro way is good, then how to deal with the intellisense error?   Thanks in advance 
  15. Could you tell more about that? I've heard bindless resources long time ago, but IIRC it's only available on some version/extension OpenGL back then. So does DX12's descriptor heap stuff essentially a bindless model or it's something different? I feel I always miss the essential part of the differences between the terms bind/bindless resource, so it will be great if you could briefly talk about the differences, and along with pros, cons. Thanks :-)