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

nmi

Members
  • Content count

    1178
  • Joined

  • Last visited

Community Reputation

978 Good

About nmi

  • Rank
    Contributor
  1. Quote:Original post by alvaro I get 222. *** Source Snippet Removed *** EDIT: nmi's argument is correct, but 32+16+16+16+16+16 is 112, not 224. Hehe, you are right, I doubled it twice. :) I was a bit distracted today...
  2. Quote:Original post by Jethro_T I looked at your method but I'm failing to see how it works exactly. I derived something from it though that makes sense to me... perhaps you could explain to me why yours is the correct one (assuming it is)? If you consider the cases, where there are at least five 1s in the bitstring, then you have these choices: 11111yyyyy 011111yyyy x011111yyy xx011111yy xxx011111y xxxx011111 So either it starts with 11111 (first case), or it is prefixed by something not containing 11111 (other cases). The pattern of a lower line must not be included in the possible configurations created by all lines above, so that is why there is an additional 0. The free bits x and y can be used to form an arbitrary prefix/suffix. So in the first line we have five free bits, so 32 possible combinations. The other lines have four free bits, so 16 combinations each. No you also count the number of configurations created by 00000 instead of 11111. This number is the same, the bits are just inverted. And then there are 1111100000 and 0000011111, which are counted twice, so we subtract two. A more interesting task would be to find out that number of bitstrings if the total length were 20 instead of 10.
  3. Would you also like to share how you obtained that result ? From what I see we can calculate the number of possibilities like this: 11111yyyyy -> 32 011111yyyy -> 16 x011111yyy -> 16 xx011111yy -> 16 xxx011111y -> 16 xxxx011111 -> 16 gives 224 possibilities for five consecutive 1s invert and it gives another 224 possibilities for five consecutive 0s we counted those strings twice 1111100000 0000011111 so in the end there should be 2*224-2=446 possibilities
  4. Quote:Original post by Brodyaga p1i=pTri->m_vertexIndices[p1i]; p2i=pTri->m_vertexIndices[p2i]; p1j=pTrj->m_vertexIndices[p1j]; p2j=pTrj->m_vertexIndices[p2j]; P1i=((p1i+p2i)-abs((int)(p1i-p2i)))/2; P2i=((p1i+p2i)+abs((int)(p1i-p2i)))/2; P1j=((p1j+p2j)-abs((int)(p1j-p2j)))/2; P2j=((p1j+p2j)+abs((int)(p1j-p2j)))/2; if((P1i==P1j) && (P2i==P2j)){ //they are neighbours pTri->neigh[ki] = j+1; pTrj->neigh[kj] = i+1; } So p1i,p2i,p1j,p2j are the indices of the vertices from the two edges. Then you check if the edge is shared by calculating P1i,P2i,P1j,P2j and checking if those value are equal ?? Don't mind, but that looks a bit weird to me. If you have a triangle mesh where you cannot be sure that every location in space is represented by exactly one vertex and everything is properly indexed (for instance when the mesh was imported from an OBJ file), then you would need to compare the 3D-location of the vertices of each edge. If they are close enough together then you can conclude that the edges match and you found a neighbour relation between two triangles. In case you don't know that triangle order is correct (i.e. CCW for front-face/visible and CW for back-face/invisible), then you would also have to compare for both cases of edge orientation. If you have a triangle mesh that is properly indexed, then you can just compare indices directly, so the lines with the abs(..) should not be needed. Also your algorithm for finding neighbours has quadratic time requirement, which may be fast for meshes with less than 1000 triangles, but can become slow for meshes with 10k, 100k or more triangles. The search for neighbours can be accelerated by using some spatial hash data structure. For instance you could divide space into a grid of cells and sort all vertices into the correct grid cell together with an info to which triangle that vertex belongs. Then when searching for a neighbour triangle along a given edge, just consider the vertices from the correct grid cells (and their associated triangles).
  5. In the pictures you posted it looks like from each silhouette edge there are two triangles drawn having a common edge instead of a single quad. This is just because of the wrong vertex order, as explained above. The article I linked above is very good and self-explanatory. To draw the shadow volumes, stencils are not needed. Only if you want to show the shadows you need them. Extending the shadow volume by scaling with a factor of 100 is also fine, but extending to infinity is more robust. Besides this article there is another one: http://developer.nvidia.com/object/fast_shadow_volumes.html Here they explain how to use the algorithm for more practical purposes. But I would recommend fully working out the first article before you start with this one.
  6. Perhaps another approach can be to randomly place vertices on the sphere, then use some force based simulation let them move around until equilibrium is reached. Then perform Delaunay triangulation to get triangles. If the vertices are evenly distributed, then the triangles produced that way should be more or less similar I think.
  7. Your problem is here: Quote:Original post by Brodyaga glVertex3f(x1 + xl1, y1 + yl1, z1 + zl1); glVertex3f(x1, y1, z1); glVertex3f(x2 + xl2, y2 + yl2, z2 + zl2); glVertex3f(x2, y2, z2); Your vertices should be in the order ABCD, but you provide ABDC. So if you change the order it should work. BTW a very good reference for shadow volumes is the article from Everitt and Kilgard: http://developer.nvidia.com/object/robust_shadow_volumes.html
  8. In OpenGL you can ask for the vendor of the card etc via glGetString(GL_VENDOR) and the result can be checked for nvidia or amd,ati.
  9. Just a thought, but what about a bisection method to find the intersection point. That should work well even for long lines. If the two endpoints of a line segment are on different sides of a line (for instance y=-x), the line segment must intersect the line somewhere. So just compute the point in the middle of the line segment (division by two is simple even for integer arithmetic) and check if it is inside. If so, repeat bisection with the line segment made up by that point and the endpoint that was outside, otherwise that point and the endpoint that was inside. Repeat this until converged. So for each condition you can find an intersection point. The intersection points found this way are the endpoints of the clipped line, unless one or both of the endpoints of the line segments were already inside the region. Also note that in your conditions y>0, y>+x and y>-x the y>0 implicitly holds because of y>+x and y>-x, so y>0 is not needed.
  10. Quote:Original post by diablos_blade Possibly the best solution would first test for intersection and if that fails, use projection? I do not want to sound picky, but consider the line as before, but slightly shifted out of the circle's plane. It will then not intersect the circle, but the closest points will remain the same as in the original example and not the center of the circle.
  11. Quote:Original post by diablos_blade Well, if I think about this the other way around, i.e., finding the point on the line closest to the circle, I think I can give you an answer because I can also safetly assume that this point is also the closest to the center of the circle. Really ? Take for instance a line in the plane of the circle passing through the center of the circle. The closest points of the circle to the line would be the intersection points, while your method would consider the center of the circle instead.
  12. Quote:Original post by AntiGuy For years I've been lumping the two together and it's become very clear that they're two very separate topics. Even so, I've yet to find a clear paper that really lays out the process in general. What about a book ? I found "Game Physics Engine Development" from Ian Millington very good to start with.
  13. So assuming you have an indexed mesh, which is recommended anyways, you can calculate neighbourship information (handy if you want to use geometry shaders). Just use the pair of the two vertex indices of an edge as key into a hash table and store as value the triangle that owns this edge. When you encounter a second triangle with that edge (look up in the hash table beforehand), you know the two triangles sharing this edge. This should be done once in a preprocessing step. If you delete the entry in the hash table when the second triangle was found, what remains when all triangles are done are the edges of the outer triangles.
  14. Search for "n body simulation" and read this paper from Barnes&Hut: http://www.nature.com/nature/journal/v324/n6096/abs/324446a0.html This should give you some ideas how to speed up calculation.
  15. Hodgman, how do you intend to allow dynamic addition/exchange of components, for instance when your unit/entity learned a new ability or when the EasyAI component is replaced by a DifficultAI component.