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

AnthonyB

Members
  • Content count

    9
  • Joined

  • Last visited

Community Reputation

150 Neutral

About AnthonyB

  • Rank
    Newbie
  1. That makes sense. I was blindly ignoring the fact that some classes may not have move constructors. Thanks.
  2. Out of curiosity, I've been looking into how std::vector works in detail. Something I've discovered has me completely baffled. When a vector is reallocated as a result of growing in size beyond its capacity, it creates a new array, moves (Thanks to C++11 capabilities.) the data over, then deletes the old array. When the old array is deleted, all of the destructors are called for the classes in the array. Considering the classes were just moved (not copied) to a new memory location, what purpose can calling the destructors serve? Even if these classes had dynamically allocated memory, the addresses of that memory are still retained, no copy of that memory has been made, so no leak can occur. I absolutely cannot think of any reason that the destructors need to be called in this scenario, and I'm hoping there's just something I'm ignorant of. If you know why this is done, or have any theories, please share.
  3. Quote:Original post by Dom_152 Quote:Original post by AnthonyB Quote:Original post by Dom_152 Quote:Original post by AnthonyB Quote:Original post by Dom_152 // Which texture will this tile use? float TextureID; How would you go about utilizing this value in the shaders? If I understand the way Direct3D works, this would also limit you to 8 (?) textures per draw call, wouldn't it? You bind it using the TEXCOORDn semantic where n matches the usage index you designated for it in your vertex declaration. In that case, wouldn't the value(s) need to be a series of texture coordinates and not just IDs? Quote:I think the 8 texture limit only exists if you use Direct3D's built in texture stages. You could have an array of Texture2D variables to have more than 8 textures in your pixel shader should your GPU be able to handle it (I believe the upper limit of samplers is 16 in SM 3.0). I didn't remember that the shaders have their own limit on samplers. Shader model 2.0 has a limit of 8 still, but you were right, 3.0/4.0 is 16. Still, this is fairly limiting if you want to use this method in a 2D-only environment with lots of random elements. (Which is why I was asking.) Oh, and sorry if it seems like I'm somewhat derailing the thread. The TEXCOORD semantic is generally used for arbitrary data as well as actual texture coordinates. You would have a normal set of texture coordinates for the vertex and the ID would simply be used as an index to select which texture to sample from. Is there any special reason for using TEXCOORDs for this data? I can't remember off of the top of my head if there are any alternatives. Quote:If you needed to have a very large number of textures the best way would be to use a texture atlas where you have all of the texture you would want for the tiles all in a single texture. Isn't there a performance cost for using a very large texture? If so, I have no idea how it would compare to the cost of switching textures and calling Draw*Primitive more often. I appreciate the responses, and again, I apologize to the original poster if this is distracting.
  4. Quote:Original post by Dom_152 Quote:Original post by AnthonyB Quote:Original post by Dom_152 // Which texture will this tile use? float TextureID; How would you go about utilizing this value in the shaders? If I understand the way Direct3D works, this would also limit you to 8 (?) textures per draw call, wouldn't it? You bind it using the TEXCOORDn semantic where n matches the usage index you designated for it in your vertex declaration. In that case, wouldn't the value(s) need to be a series of texture coordinates and not just IDs? Quote:I think the 8 texture limit only exists if you use Direct3D's built in texture stages. You could have an array of Texture2D variables to have more than 8 textures in your pixel shader should your GPU be able to handle it (I believe the upper limit of samplers is 16 in SM 3.0). I didn't remember that the shaders have their own limit on samplers. Shader model 2.0 has a limit of 8 still, but you were right, 3.0/4.0 is 16. Still, this is fairly limiting if you want to use this method in a 2D-only environment with lots of random elements. (Which is why I was asking.) Oh, and sorry if it seems like I'm somewhat derailing the thread.
  5. Quote:Original post by Dom_152 // Which texture will this tile use? float TextureID; How would you go about utilizing this value in the shaders? If I understand the way Direct3D works, this would also limit you to 8 (?) textures per draw call, wouldn't it?
  6. Apparently I didn't look as thoroughly for a solution as I thought. I'll check into those options and see if they're suitable. Thanks. Edit: Wow, I feel retarded. I have no idea how I missed any of these. I guess I just assumed past researching was complete when it obviously wasn't.
  7. Is it possible to do clipping on polygons within your viewport, rather than manually changing the vertex positions yourself to accomplish the same appearance? I'm not entirely sure if I'm using the right terms to make this clear, but I can clarify if needed. For example, if you're doing something like an editbox and you don't want the text (drawn with multiple rectangles, of course) to be drawn outside of the editbox rectangle's boundaries.
  8. Quote:Original post by darkelf2k5 Vertex caching, however, is not there for multiple reuse of geometry data, you have instancing for that. If it's not there to speed up re-use of vertices, what purpose DOES it serve? Quote:Original post by XVincentX It results that index buffer saves preformance every time. The only reason to not use it it's a single triangle drawing. I was hoping this wouldn't be the case, but I had a feeling it was. Thanks for the input from both of you.
  9. If you're using vertex data that never needs to be drawn more than once per frame, does an index buffer provide any benefit? As I understand it, the vertices can be cached, but if they're never being re-used, I'm not sure if that cache is beneficial in any way. If you're wondering why nothing would ever be re-used, it's for a 2D-only project. I didn't want to have to make a SetTransform and DrawPrimitive call for every single drawn rectangle. I don't anticipate many groupings of them to be used (as in small groups of rectangles to form a larger image), so that's why it's designed this way. This may not be ideal though, and I'm certainly open to discussion/suggestions.