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

melbow

Members
  • Content count

    43
  • Joined

  • Last visited

Community Reputation

221 Neutral

About melbow

  • Rank
    Member
  1. I'm using Chrome for iPhone and when I quote someone it places the HTML in the reply, but as text and not as HTML. Additionally, when then editing a post with HTML in it, the HTML is duplicated. Lastly, I suggest placing a "To Bottom of Page" button at the top of the mobile site when viewing a post, because having to manually scroll to the bottom every time using the phone is pretty annoying.
  2. OpenGL

    OFF TOPIC: And gamedev.net desperately needs to update the mobile site. It has some very annoying design flaws and bugs...
  3. OpenGL

    <blockquote class='ipsBlockquote'data-author="Aks9" data-cid="5022808" data-time="1358498689"><p> <blockquote class='ipsBlockquote'data-author="melbow" data-cid="5022767" data-time="1358482777"><p>I'm sure there has to be a similar thread somewhere, but I can't find it. I was wondering, is there any reason not to use a VAO? And in the latest version of OpenGL, are all other forms of rendering deprecated?</p></blockquote> <br /> In core profile VAO is mandatory. But it can be created, selected and forgotten. It is the way I'm using VAO. <span rel='lightbox'><img src='http://public.gamedev.net//public/style_emoticons/default/smile.png' alt='Posted Image' class='bbc_img' /></span><br /> VAO is not always the best way to do things. Try to make several VAOs and select them and compare to changing just one attribute in a single VAO. If you have to change many attributes at once, than just selecting a VAO is better. For a single attribute, or few of them... hm, I wouldn't bet. Also, mixing VAO and NVIDIA bindless is not a good idea.</p></blockquote> Thank you! That is exactly what I needed to know.
  4. OpenGL

    Thanks Irreversible. I know fixed-function is dead (as it should be), but wasn't sure if there was some scenerio where it might be better to call glVertexAttribPointer and not use a vertex array object. I'm writing a wrapper for GL ES (for educational as well as practical applications) and was considering forcing the usage of VAOs. I guess I will go ahead with my plan then. Thanks again.
  5. I'm sure there has to be a similar thread somewhere, but I can't find it. I was wondering, is there any reason not to use a VAO? And in the latest version of OpenGL, are all other forms of rendering deprecated?
  6. So I think I've managed to go full circle from virtual Draw methods to a Render Command Queue back to virtual Draw methods. It just doesn't seem worth it to do all this work just for a unified renderer when you could have a virtual Draw method and call it a day. If renderable objects are managed and batched prior to being made into RenderItems then as far as I can tell, you could just give the batch a Draw method and enqueue the batch. I guess I don't really see the point of the Commands. I am at a loss because I want to do this the right way, but I have too little experience with coding rendering APIs to know what that is. And please don't say, "There is no 'right way.'" Could anybody recommend a book that covers render queues similar to what has been described by Hodgman?
  7. Is the reason for storing StateGroups as a header and chunk of States that you make it more cache friendly due to locality? Also, you say you store StateGroups in Resources. Am I correct in assuming some StateGroups must still be created at runtime, e.g. geometry instance transforms. And therefore RenderItems creation also cannot be done when the game object is initialized, but must be done every frame. Is this correct or am I completely off base?
  8. While I am not Hodgman, I will say that, broadly speaking, templates increase the compiled code's size. If the function is inline though (which I assume it is in your case, TiagoCosta), there should not be any negative performance penalties.
  9. Thanks again Hodgman. I really appreciate how detailed yet concise your responses are. The only thing that is still not completely clear to me is the generation of RenderItems. Are they allocated each frame from a data cache (like what is described here http://docs.madewithmarmalade.com/native/api_reference/iwgxapidocumentation/iwgxapioverview/datacache.html )? And would a higher level object like a GLShader or GeometryPacket class then maintain their respective Commands? I am not seeing a way to to check for duplicate states by comparing pointers unless the Commands are maintained by global, shared resources, or I guess if Commands ARE global shared resources, but the first option seems cleaner. Again, I really appreciate everyone's input on this thread, it has helped me a great deal.
  10. I too am puzzled by how redundant state changes are eliminated in this model. Am I correct in that states may be submitted in any order? And if this is the case, then states may be sorted and then linearly compared. However, this seems expensive considering how many states may be set per frame. I'm sure you have a much more clever way of doing this.
  11. All this talk of unpredictable behavior has me questioning this approach. What if a Command was simply a sort of container, like: struct Command { Commands::Type id; union { Foo* foo; Bar* bar; } u; };
  12.   So if everything is a command, do you batch ahead of time like Noizex? Say for example, geometry instancing, how would you collect each instance for creation of the commands? And thanks for such a good example. You've helped clarify a ton already :D
  13. Hodgman, are your states then inheritted from a State base class? If not, how do you determine how to set the state the correct way? I would think you would want to avoid the overhead of virtual functions on something so low level on the engine.
  14. Thanks for replying Noizex. You gave some great input. I was wondering if you perform any batching of your Render Tasks and if so, how? I don't see any place for attributes that aren't in your VAO.
  15. Let me preface this by saying I have read everything I could find on the web on this topic, but have been unable to answer my question. This list includes most notably: http://realtimecollisiondetection.net/blog/?p=86http://realtimecollisiondetection.net/blog/?p=86 http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter05.html http://www.gamedev.net/topic/604899-frostbite-rendering-architecture-question/ http://www.gamedev.net/topic/605065-renderqueue-design-theory-and-implementation/#entry4828468 http://www.gamedev.net/topic/602839-whats-the-point-of-having-a-single-render-device/#entry4815585 I understand sorting the draw calls and how to use this system under the fixed-function pipeline. However, when I change to a programmable pipeline, I can't seem to come up with how a "Render Operation" would be structured.   The best solution I could come up with was an object list for both uniforms and attributes. However, I can't see how a VAO or VBO would fit into this scheme.   Roughly, my code might look like: class ShaderProgram { public: void Create(char*,char*); void MakeCurrent(); ShaderAttributeInfo const & GetAttribute(const char* name); ... private: List<ShaderAttributeInfo> m_Attributes; List<ShaderUniformInfo> m_Uniforms; }; class ShaderAttribInfo { GLint handle; GLenum type; public: Set(void* data); }; class ShaderAttrib { ShaderAttribInfo* info; void* data; ... }; ... // Same basic structure for Uniforms class RenderOperation { List<ShaderAttrib> m_Attributes; List<ShaderUniform> m_Uniforms; ShaderProgram* m_Program; };   I'm trying to make my system as versatile, yet efficient as possible.   To reiterate, my question is: How would a "Render Operation" be formatted for a Render Queue using a programmable pipeline? The operation should allow for any sort of uniform or attribute and allow for VAOs and VBOs. And I don't feel the need to support a fixed function pipeline, so don't worry about that.   I hope I made my confusion clear enough. Thanks a ton.