• 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.


GDNet+ Basic
  • Content count

  • Joined

  • Last visited

Community Reputation

1028 Excellent

About baldurk

  • Rank
  1. Oh I see. Is there any reason that a dummy interface has to be returned instead of the actual one? Or do you mean in cases where that flag isn't set? It isn't like it's a big deal (to me anyway) in any case; I usually use RenderDoc for more specific debugging purposes where the debug layer won't give any (meaningful to the problem at hand) output anyway. Checking the "Create debug device" box apparently makes it work like you say as well, that I didn't think to try that... I assumed it would just create the device if my application didn't by itself. In any case, all good.   Right this is the issue - when the debug checkbox is enabled in renderdoc, it will force on the debug flag even if the application didn't request it. If that checkbox isn't enabled, then renderdoc will remove the flag even if the application requested it. The idea being what you're talking about - generally when you're running through renderdoc you're not in a position to look at the debug output anyway, so if renderdoc isn't set up to save it then why pay the cost of the overhead? In this case I should return a dummy interface so that the application isn't any wiser.
  2. Ah, upon checking the docs it seems like it's only valid when D3D11_CREATE_DEVICE_DEBUG is enabled, but RenderDoc 'takes control' of that flag and will remove it if you didn't check 'create debug device' when capturing. I'll do the same as I do for ID3D11InfoQueue and return a dummy interface that does nothing.   Yeh mostly I haven't done it because I haven't given it too much thought. I want to make sure I do it right rather than confusing people a lot, and so far there's been higher priority stuff to implement.
  3. Fixed and I've snuck that into the new v0.29 I was in the middle of preparing. Long story short, I recently moved InputLayouts so they were reference-tracked for inclusion into captures rather than just all being included. When I did that, I failed to mark that initial-state layout as referenced, so it got trimmed from the log. This actually also exposed a bug where any executable with 'renderdoc' in the filename wouldn't capture due to an overly aggressive filter on which modules to hook. I'll fix that at some stage but it's unlikely to trip many people up.   Which debug interface is that? Querying for ID3D11Debug should work just fine, is there another one?   Hmm, could be a few things I guess. If you do manage to spot a pattern file an issue on github and I'll look into it   Yes editing states and resource contents is a common request and one that I have on my roadmap. The implementation isn't too bad actually, but it's a question of how to display it in the UI - and with D3D11 when you edit a state does it just apply at that drawcall? or until the next time the state changes? or is it retroactive further back elsewhere in the frame, where the same state object is used. At different times you might want all three options, so it's a complex UX task to solve.
  4. This case should be handled, although I imagine there can be edge cases that are buggy. RenderDoc keeps track of the current state at any point on the immediate context, and serialises that out at the start of the frame, when replaying it restores it again. Do you have an example that reproduces the missing tracking?   "Save All Initials" just overrides an optimisation heuristic that makes RenderDoc skip the initial frame contents of render targets that look like they're entirely overwritten in the frame.       This is mostly there so that I can catch any cases where objects have QueryInterface called for some GUID I'm not handling. This can lead to non-wrapped D3D handles leaking out that can lead to crashes or just bad behaviour. In this case it's some internal secret GUID that's queried inside D3D, so it's harmless.   Yep, I'm aware of that, thanks for pointing it out though.     I'm not aware!  :). Do you notice this happening consistently in some situations? or is it just every now and then something seems overly cached and needs a repaint.   I'm glad it's useful, hopefully I can make it a little more bug-free :wink:.
  5.   If there's reasonable doubt that it's a bug in RenderDoc I don't mind taking a look at it - oftentimes even when it ends up not being a RenderDoc bug I can point you in the right direction.   Sharing an executable is better than sending a capture because it gives me more ability to investigate - I might look at the capture, see the problem is 'oh, X is missing', but then need to go back to the executable to add logging or debug it to figure out where X got to during capture. Not everyone is comfortable sharing executables all the time though, so I help with whatever they can share.
  6. Likewise, reporting RenderDoc bugs will get the swiftest response if you report them directly to me on github :). Do you have an example capture or runnable executable you can share to demonstrate the problem?
  7. Do you have another repro project to share that still runs out of memory with smaller images? It's expected to see higher memory usage while using RenderDoc since it is storing shadow (CPU-side) copies of graphics resources. The memory for those graphics resources for the GPU is not counted in task manager, so it's 'invisible'.   Also just in case there is some confusion you mention that you reduce the image size to "2.5MB" which doesn't quite make sense. Even though your image is stored as a .jpg, the disk size makes no difference and compressing it further will not change the memory usage in D3D11. The memory usage is entirely determined by the resolution, format and number of mip levels - in this case the .jpg in the example project you uploaded is 5184x3456 and it is created as uncompressed R8G8B8A8 with a full set of mipmaps. That's where the memory use comes from not the file size on disk.   btw, this might be more appropriate to move to a github issue.
  8. Thanks, I repro'd the crash. It's actually simply running out of memory - the program is creating a ~90MB texture every second or so. By default renderdoc saves a copy of this data on the CPU in case the texture is modified (so it can track changes in-place rather than needing to save every delta), eventually the allocation fails. I guess since it's a 32-bit process. I'm surprised how soon it fails actually as it only hits ~1.3GB for me, but maybe memory has fragmented enough that there isn't a large enough contiguous block. That's a complete guess.   I'll maybe see if I can add a heuristic so that large textures aren't shadowed unless absolutely necessary, but that still might not help depending on how many of the images are referenced in a frame. If they're all referenced, renderdoc will still allocate memory to readback their contents, and will be back to square one. I'd suggest either switching to 64-bit or using smaller textures if possible :).
  9. Do you have any repro details you can share for the RenderDoc crash? e.g. is your application available online anywhere to test?   I found some source project that was using D3DX11CreateShaderResourceViewFromFile(), but it works OK - so I guess it's something particular that's crashing. If you download one of the latest nightly builds it comes with pdbs too, so getting the callstack with file:line information would be helpful.
  10. Send me an email (baldurk@baldurk.org) and I can help debug it. v0.25 has broken DDS loading (whoops...) but for earlier versions there shouldn't be any dependency on VS2012 since I make the builds from VS2010.
  11. FYI - If you don't specify a working directory, RenderDoc defaults to setting the working directory to the directory the exe is in. For visual studio that might not be the same as when you hit F5 to run, as the exe often lives in a Debug/ directory.   But if it's only GL functions that are failing, and your own code to load your shaders from disk is fine, then that sounds like a bug in RenderDoc. If you can give me the program that triggers it I can probably fix it.
  12. Wow that's crazy, I didn't realise it had a different meaning on output signatures. I've fixed it so that it's not so confusing :).
  13. The shader seems fine to me, the only part of it that will actually have any effect is the position calculation, as the pixel shader isn't using any of the other inputs.   If you say that the grid of vertices seems fine, what exactly is showing as 'unshaded' in the mesh view? By default it's just a wireframe view of the triangles, so the only thing I can think you mean is you have 'flat shaded' selected on the output and one face is showing up black - that would imply the winding order is incorrect on that face (meaning the normal is calculated backwards).
  14. On the mesh view, if the input vertices are all identical that means something is likely wrong with your index buffer set up. The first column shows the vertex ID, ie. linearly increasing from 0. The second column shows the index from the index buffer, which should be different (e.g. for a triangle list it might be 0, 1, 2, 1, 2, 3, 4, 5, 1 or whatever). Double check your indices are as you expect them to be. If the output vertices are all the same but the input vertices are OK, it's something in your vertex shader, so you could try right clicking -> debug selected vertex and step through two different vertices side by side to see what's wrong.   The raw "buffer contents" view is for when you have just a chunk of memory that you'd like to view in an arbitrary format, and the text box near the bottom lets you enter the format - by default it is probably showing the data as int4s (possibly in hex depending on the version you're using). You could always manually enter your input layout, e.g. "float3 pos; float2 texcoord;" and see it that way to verify that the vertex buffer is correct, but if you're just looking at mesh data the mesh view should show you everything you need as it interprets the vertex buffers and input layouts as D3D11 will.   If clicking Go next to the index slot in the InputAssembler doesn't do anything that suggests perhaps there isn't an index buffer bound somehow. It should open up the "buffer contents" for the index buffer itself. Is it highlighted in red? If so then there isn't an index buffer set. I've noticed it's not as clear as it could be (it says 'buffer 0' and suggests it's 1 byte long), I'll fix that.   The numbered slots are your vertex buffers, vertex shader data is on the vertex shader tab, under constant buffers. The vertex inputs come from the elements in your input layout, each element can point to a vertex buffer with a given offset. The concept is fairly analogous to modern opengl's vertex attributes and vertex buffers (where attributes have an offset, format, and binding to a vertex buffer slot, and vertex buffer slots bind the actual buffer as well as its stride).
  15. If you're willing to share it or email to me, I'd be interested to run the program myself or look at a capture. I don't mind assembly shaders :). Getting the wrong inputs in the pixel shader means a bug in renderdoc and I'd like to fix it if I can!