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

Radikalizm

Members
  • Content count

    615
  • Joined

  • Last visited

Community Reputation

4807 Excellent

About Radikalizm

  • Rank
    Advanced Member

Personal Information

  1. I guess if you want realistic shading on any type of foliage you'll want to have a look at subsurface scattering solutions. Standard BRDFs give you surface shading, which only gets you so far for organic materials where light can usually permeate quite a bit underneath the surface. Performance-wise I don't know if you'll want to go for a full-blown SSS solution for foliage though, you might want to find a cheap approximation to get a similar effect. For pure surface shading I guess you should use whatever fits the rest of your scene. If everything in your rendering pipeline uses standard Blinn-Phong, then shade your foliage in the same way unless you can find a valid reason not to. Switching to a physically based model like Cook-Torrance is not going to give you more visually pleasing results out of the box.
  2.   This is still very true sadly enough. The first year of D3D12 was extremely rough in terms of driver and tool availability/stability. Vulkan seems to be going through this right now. That said, the only way for an API like this to reach maturity is for more devs to use it, back it and give feedback!     I had a chance to have a chat with some of the people in charge of Khronos' SPIR-V compiler efforts not too long ago. It seems like native HLSL support in glslang is a pretty high priority to them, so I hope that this will become a viable workflow very soon. They also seemed pretty excited about Microsoft's efforts to push out their new HLSL compiler infrastructure out into the open. This only means good things for them as well :)
  3.     Don't worry, I was completely aware that they were working on this, just not aware of when it would actually make it out to the public ;) The fact that the future development of HLSL is out in the open will help slim down a lot of shader codebases, as I'm sure a robust compiler from HLSL to SPIR-V will follow soon (aside from the work that's already being done in glslang). Also as you mentioned the language now has the freedom to evolve towards more modern concepts.
  4. There's been so many exciting things happening lately. First the release of PIX for PC, and now an open LLVM-based HLSL compiler! This is great news for the graphics development community :)
  5. DX12

      AFAIK the current build isn't robust against invalid usage of the D3D12 API, so make sure you're not getting any debug layer issues.   Also congrats to the PIX team for getting this thing shipped!
  6.   me? which ?? !! i didn't notice      I was talking about the original post :) It's been edited
  7. You might want to be careful with adopting a logo used in a popular live AAA game as your studio/company logo. The one you're using is from the Forge editor in Halo 5 :)
  8. As mentioned above, this is pretty much exactly what gsl::span does. In addition to this gsl also provides string_span and multi_span. If you haven't played around yet with gsl, I definitely suggest you give it a try. It's been incredibly useful for us so far.   EDIT:   I also remember seeing a Microsoft implementation of array_view, and am quite sure that an implementation of array_view was suggested for an upcoming C++ standard. I also believe that boost provides a similar implementation.
  9. There's no such thing as a staging or readback texture anymore in D3D12, so you'll have to copy your texture over to a readback buffer first using ID3D12GraphicsCommandList::CopyTextureRegion. Have a look at D3D12_TEXTURE_COPY_LOCATION to see how you can set up your buffer as a texture copy destination.
  10. DX11

    You need to explicitly call ID3D11DeviceContext::GenerateMips to generate mipmaps for your texture   https://msdn.microsoft.com/en-us/library/windows/desktop/ff476426(v=vs.85).aspx
  11. I'm always impressed when I read any of your journal entries. Awesome job!
  12.   No, they don't. pbrt is the name of the framework they walk you through in the book. You can find the accompanying source code here: https://github.com/mmp/pbrt-v3   The book walks you through the implementation of a ray tracing framework which uses physically based shading models. This doesn't mean that physically based shading is exclusive to ray tracing.    As mentioned before, physically based rendering is just an approach to shading and lighting with a foundation in the actual physics behind lighting and reflections, rather than working backwards from "what looks right" like we used to do in previous generations.
  13. DX12

      As far as I'm aware you won't be able to retrieve a root signature from your bytecode if you don't explicitly define it in your shader code. One type of validation you could do is to get information of SRV/CBV/UAV/Sampler bindings using shader reflection. You can cross-reference this data against your root signature to see whether the root signature has the appropriate descriptors, descriptor tables, constants or static samplers to support your shader.   Other than doing that I don't think you can actually extract explicit root signature information out of a shader without defining it in your HLSL code.
  14.   Honestly, you're going to run into a ton of actual rendering-related bottlenecks before a decently architected game object/entity/"whatever buzzword you want to use" system gets in your way. Don't start theoretically optimizing things. Solve the problems you have at hand to get to the desired frame time for your specific game.         You've obviously never worked on any type of shooter before. Try telling that to people designing any type of competitive game which supports split-second inputs. 16ms in a game update tick can definitely make a difference.           What are you talking about? There's a ton of games doing async rendering? The era of single-threaded update and render is over!         This is still a very useless comparison to make. You're acting like every engine is comparable in some shape or form when it comes to performance. They're not. Focus on what your requirements and goals are. Do some profiling, find your bottlenecks, fix them. Rinse and repeat. 
  15. +1 for all three of those. Especially Real Time Rendering is a must-have!   The GPU Pro series is neat as well, but it's all very specialized and focused towards a specific set of techniques and their implementations.