• 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

1413 Excellent

About Funkymunky

  • Rank
  1. I guess that's as clear cut as it gets.  Thanks!
  2. Is it a necessity per list though?  Wouldn't putting in a fence to ensure the correct setup has been processed be less work for the GPU than calling OMSetRenderTargets, RSSetViewports, and RSSetScissorRects for every list?  To clarify, I'm making those calls per list now, but I'm just wondering if there's a better way to do it...
  3. Let's say I have three command lists, A B and C.  They are guaranteed to be submitted in order.  If I call OMSetRenderTargets on list A, can I then ignore calling it on the B and C lists and assume they will be writing to the same render target?
  4. That's the conclusion I'm coming to as well, and upon further review you are correct about using /std:c++latest. Ah well, thanks for the help!
  5. I had found that and tried it, but I figured it was just deciding which version of the standard library to include.  It doesn't make a difference for this, I still get a compiler error like it can't understand "if constexpr".
  6. I just upgraded to Visual Studio 2017, because I wanted to use "if constexpr" in my code.  It seems like it's not supported: If I just do something like "if constexpr(true)", I get an error of "expected a '('"   Does anyone have experience with this?  Is there some setting I need to flip to get C++17 compilation enabled?  I didn't see anything in the project settings...
  7.   No my friend, that's not how this works.  Nobody has to execute your vision for you.  You won't even fully detail what it is; you just keep reiterating how much experience you have, as if that means we'll accept you as the authority on game design.  If your idea doesn't see the light of day, then it's entirely YOUR fault for not being able to work with people.   Also, stop calling us arrogant when you make statements like that.  That is like the epitome of arrogance.
  8. Hey man, I was just trying to give you some friendly advice.  I've watched you consistently get this type of reaction.  The reason for it is that you come off as extremely disrespectful.  I'm sure you have your reasons, your frustrations about not being understood or taken seriously for the magnitude of your game idea.  Or the fact that you feel like your experience in game design makes you an authority.  That you clearly feel like you know better than the people on this site.  But just... as a word to the wise... it's not working.  Again, this is why you have "30 years of banging my head against a brick wall."  You're being rude, disrespectful, and you're belittling the people that you are apparently reaching out to.  It's one thing to be confident in one's ability and knowledge; it's quite another to tell people that their experience is less valuable and that they should just shut up and listen to you.
  9. Wow, this is nuts.  So you're angry that no-one is jumping on board to help you create your vision of "Rube"... even though you won't really describe it in detail.  The best you'll offer is that it's a "functioning simulation of God"... and yet your issue is that everyone else is arrogant.  Even though you've responded with statements like: "An attempt by the adults to explain the current height of the field of game and simulation design to the spoiled little children playing in the sandbox at the edge of our field" and "You could learn a lot if you put down your bucket and shovel and listened to your betters" Pirate Lord man... I remember your first epic meltdown.  You haven't learned yet that you need to do a better job interacting with people?  "30 years of banging my head against a brick wall" and you haven't stopped to think that maybe it's how you approach people?  It's great that you're enamored with your idea, it really is.  Passion is a valuable thing in life.  But if you turn people off by being rude to them, or getting exasperated that they won't just blindly trust your vision... then they aren't going to help you...
  10. DX12

    After some deliberation, I think I'm going to adopt the following scheme:   I'll create one or more "offline" heaps to create descriptors in, as this will let me create resources in separate threads.  For the "online" heap, I'll use a freelist allocator to give me descriptor ranges.  I'll track three lists for maintaining this.  The first will be a list of available allocations, sorted by size (a normal freelist).  The second will be a list of allocated and deallocated ranges, sorted by their offset from the start of the heap.  The third will be a list of just the deallocated ranges, also sorted by their offset from the start of the heap.  (The second and third lists will use the same structures, with each structure having pointers to its neighbors).   Every frame I will run a basic defragmentation pass.  It will look at the first entry in that third list (deallocations).  If the neighbor to the right of that entry is also a deallocation, then I will coalesce the two into a single deallocation.  If the neighbor is instead already-allocated, then I will shuffle that allocated range to the left, essentially bubbling the deallocation toward the end of the heap.   In practice, I'll probably split the "online" heap into multiple regions (one for each frame).  This way I can shuffle descriptors after a fence without disrupting something that's being used.  I think as long as I don't hammer the heap with constant allocations and fragmenting deallocations, this should keep me relatively well managed.  And even if I do, I can always increase the number of defragmentation passes to keep things in check.
  11. DX12

    Until now I've just been creating two descriptors for any per-frame resources (mostly buffers that are constantly updated),  But I've also been calling SetGraphicsRootDescriptorTable for every bound resource, rather than batching things into contiguous regions and minimizing those calls.  This has worked fine for the relatively small shaders I've tested my scenes with, but it's clear now that this strategy could quickly hit a wall.   It's pretty much a classic allocation problem, except there's no reason not to apply extra memory/processing power to making the allocations/deallocations as fast as possible.  I am trying to dream up a faster scheme, but so far it seems like the ring buffer / stack allocator strategy is the way to go.   That bindless strategy is intriguing.  That approach would use a common root signature with access to every descriptor, right?  It might be tricky getting root constants to work with that, but the tradeoff for not having to manage the descriptor heap is enticing...
  12. DX12

    I feel like a lightbulb has just turned on over my head.  That makes a lot more sense.  Thanks for the insights!
  13. DX12

    I guess what I don't understand is why there would be a lot of objects with transient lifetimes.  It seems like most textures and constant buffers are going to stick around for awhile.  In fact it seems like adding new descriptors/removing old ones would happen pretty infrequently.  Can you describe a use case where a majority of objects would require new descriptors every frame?  And also, are you saying to call CreateShaderResourceView/CreateConstantBufferView every frame?
  14. A lot of DX12 articles talk about implementing the descriptor heap entries as a ring buffer (notably the nVidia Do's and Don'ts).  I've also read in these forums that some people prefer a stack-allocated scheme.  I don't see why these methods would be the preferred way of solving this problem.  A ring buffer of descriptors is great if you're always adding new descriptors while deleting the oldest ones.  But what happens when you want to remove a descriptor from the middle of the active set?  And as for a stack-allocated scheme, wouldn't that involve copying in the descriptors every frame?  Why wouldn't something like a free-list or buddy allocator be preferable to either of these setups?
  15.     Is that something I can manually direct it to do, or is that managed by the driver?