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

Yourself

Members
  • Content count

    177
  • Joined

  • Last visited

Community Reputation

1961 Excellent

About Yourself

  • Rank
    Crossbones+
  1. I think it depends on the type of job you wish to apply for. wanna be a gameplay programmer? do some really cool gameplay mechanics (like assassins creed style parcour, spiderman style flying, 3rd person shooter cover system, ...). wanna be an AI programmer? do an AI intensive project (RTS ?). wanna do tool programming? make a simple game but with a 'full' (in-game) editor. wanna be a graphics programmer? drop the gameplay and make a techdemo.
  2. you can also provide an initial state (member of VkImageCreateInfo) but it has to be VK_IMAGE_LAYOUT_UNDEFINED or VK_IMAGE_LAYOUT_PREINITIALIZED.
  3. InterlockedExchangeSubtract is actually a utility function using InterlockedExchangeAdd. It only has been added a couple of years ago so untill then, you simply had to pass the negative value.
  4. frame buffers will most likely remain in VRAM. You would have to use specific tools/APIs to be sure though. It all depends on the amount of memory you use, you can have 100s of frame buffers in the GPU as long as the memory they occupy isn't needed for other resources/applications. It is good idea to allocate large resources (like framebuffers) as soon as possible to prevent eviction) Yes, you can 'freely' copy resources (buffers, texture, ..) on the GPU. notice the quotes are all API depened. for example some APIs have the constrain that textures need to have the same dimension and a compatible format while other APIs are pretty mutch memcpy style (very powerful but possible headache introducing :) )
  5. Depending on the api you use, you should try a single memory buffer combined with a specific allocator. I recently had great success using this on a buffer of about 512mb and a buddy allocator That 512 is the highest setting (medium was 256, low 128) and on a higher level I made sure that you never need more memory (aka bias on culling/LODs etc). Cool thing is that you always know the exact amount of memory needed and only have a single allocation at loading time It does depends on your graphics api as not all of them allow you to use a 'random' memory address as IB/VB/... 
  6. My bet is that one (or more) pixel storage modes are invalid (as in, not valid with the data you supply)
  7. it is not a bad idea at all, it is how most implementations work. you simply keep an array (or any data structure you think is better) for each render type. one for opaque, one for transparent, one for a custom fancy rendering effect (skin ?) it is both simple to implement and effecient to travers
  8. yes, when switching a resource between input and output of the pipeline, you have to manually unset the other state. This will do insert some barriers to guarantee correct results. for example, it will make sure that the data is written before it is read again (in case of a RT->SRV transition). Note that this guarantee is part of the d3d11 driver, in newer APIs you have to do this explicitly.
  9. typically this is solved with an abstract device interface. Create an IDevice class that has virtual functions to create/destroy ITexture/IBuffer/IShader/... objects Each rendering API can implement them as it sees fit while the high level code can work on abstract handles. The renderer will also work on those abstract handles and only do the translation to API specific resources when actually submitting the commands to the specific API. Note that the IDevice implementation can still use some sort of buffermanager (for example to provide suballocations into larger buffers) as long as it returns an abstract interface
  10. part of a mail that was send to previous attendees (although 2016 was the first one in three years I didn't attend)    
  11. You store the quadtree data in the mips of a texture. As your mips half in size on each level, this maps nicely to the quadtree design (as-in each node has 4 child nodes)   On specific details you should just look at the code as the entire code seems to be available
  12. I have not found time to read it myself, but I heard 'Computer Graphics: Principles and Practice (3rd Edition)' is a good introduction into graphics programming
  13. IMHO Maya LT is actually pretty decent priced at $30/month (+ you get a Stringray subscription so you can build experience in that as well)
  14. For example in Dx11, you have to make sure that your ID3D11SamplerState is created correctly. For example, setting both minLOD and maxLOD to zero will always sample level 0 (as in do not use mipmaps). Also the filter on your sampler has influence on the miplevel calculations (bilinear vs trilinear for example)   Inside your shader, you can also control the default 'automatic' mip map calculation As mentioned, you can use a different sample functions (dx11 syntax): - SampleLevel -> sample a specific level (and that level is a float so you can have nice interpolation) - SampleGrad -> sample with specific derivatives (witch are used to control the 'default' mip calulation). (for other functions see msdn)
  15. Inside the pixel shader, the default texture lookup functions use screen space derivatives to calculate the mip level required. In other shader stages, you typically specify the exact level you wish to sample. Also note that your texture and/or sampler object should be configured correctly