• 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

112 Neutral

About 7zSuperiorCompressionServ

  • Rank
  1. Nevermind, I just figured it out. In case anyone else is stumped in the future, here's the solution:   // The amount of increments we need to make for each dimension, so we have the (potentially) shared points between patches int stepWidth = ( face->size[ 0 ] - 1 ) / 2; int stepHeight = ( face->size[ 1 ] - 1 ) / 2; int c = 0; for ( int i = 0; i < face->size[ 0 ]; i += stepWidth ) for ( int j = 0; j < face->size[ 1 ]; j += stepHeight ) patchRenderer.controlPoints[ c++ ] = &map->vertexes[ face->vertexOffset + j * face->size[ 0 ] + i ]; patchRenderer.Tesselate( subdivLevel ); patchRenderer.Render(); stepWidth and stepHeight specify how much their respective iterators need to be incremented by in order to find the correct control point for each patch. If there are multiple patches for a face, these iterations will land on the correct control points which are shared between patches.
  2. Hey, everyone. I've been working on a BSP Renderer, using information given from here and here.   All in all, they're pretty solid, and seem to be the most common used references for the .bsp format out there (which I am aware of). Anyway, I'm having some trouble wrapping my head around the following statement (from the second link, in the Faces section):   From what I gather, the author states that, since adjacent patches share a line of three vertices (with each patch having 9 control points each), we can use the (i, j) indices to find a total of 9 shared control points from the total number of vertices, which are then used for the triangulation. However, I'm not sure what the "2n/m, n/m" bits actually mean in the bold portion. Can someone clarify this? The current rendering implementation does the following for the patches:   else if ( face->type == FACE_TYPE_PATCH ) { const int subdivLevel = glm::min( 10, glm::abs( 10 - ( int )glm::distance( pass.view.origin, boundsCenter ) ) ); const int controlStep = face->numVertexes > 9 ? face->numVertexes / 9 : 1; int i = 0; for ( int j = 0; j < face->numVertexes; j += controlStep ) { patchRenderer.controlPoints[ i ] = &map->vertexes[ face->vertexOffset + j ]; i++; } patchRenderer.Tesselate( subdivLevel ); patchRenderer.Render(); } Note the controlStep: if we have more than 9 verts, we have to compensate and find 9 control points out of those vertices to send to the patchRenderer. As a result, we divide the number of vertices by 9, iterate through the loop, and use that quotient for the increment portion. If we only have 9 verts, then all the vertices can be used, so we just increment by 1. But I'm pretty certain that's the wrong way to go about it, since the control points are likely to be arbitrary and won't just be shared as multiples of 3 in the event that there is more than one region. tl;dr What is the proper way to attain the control points of the vertices, such that the amount of vertices is greater than 9,and given that the patchRenderer requires 9 control points exactly in order to tesselate the regions properly? I appreciate any help.
  3. OpenGL

    [quote name='Lauris Kaplinski' timestamp='1350670310' post='4991852'] What sorts of meshes are you trying to parse? Terrain/large static structures should be handled differently from character models and small props. You probably need octree for the first but not for the others. Start simple - write loader that generates single object/buffer. Once this works you may try octrees. [/quote] I haven't even gotten to that point yet. I guess I've been thinking character models as well as terrain and large static structures. I'll probably continue just working through these tutorials until I've at least grasped the basics, and then work towards mesh parsing from there. Just so I understand this correctly: The file format will contain the vertex/geometry/fragment data, as well as, probably, which primitives (likely triangles, I'd imagine) to use as a basis for rendering the mesh. Once I have the mesh data structure taken care of in my C++ code, I could simply parse the file, store the vertex data in c-style structures or something like glm::vec4, and then pass those to my renderer in a loop - correct? If that's the case, I assume that this wouldn't really take much math at all apart from a good understanding of the matrices, etc involved (unless, of course, I was using physics to do this, which will likely be a while from now). I appreciate the advice.
  4. I'd like to learn how to write a Mesh Parser, using features in OpenGL from 3.3 and up (my drivers should support 4.3, I'm currently running 4.2). The question is, I'm not sure what techniques/concepts would be good to understand first. I know how to write a binary search tree, if that helps - but maybe a QuadTree or even an OcTree would be more useful? I've been studying from [url="http://www.arcsynthesis.org/gltut/"]Learning Modern 3D Graphics Programming[/url], and am currently at the [i]Objects At Depth[/i] section. Also what would be good to know is what kind of file formats are most common in the OpenGL world. Should I use blender to draw meshes, export the files, and render them in OpenGL? Is it possible and pragmatic to write a single mesh parser which would just render whatever kind of mesh I throw at it? I'm aware of prewritten libraries such as GLMesh which help with this (though I'm not sure to what extent they do), but alas my goal is to learn so I'd like to avoid using something like that :3. Thanks.