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

luca-deltodesco

Members
  • Content count

    468
  • Joined

  • Last visited

Community Reputation

638 Good

About luca-deltodesco

  • Rank
    Member

Personal Information

  1. I think the best example of that is triangulation:   Triangulating a polygon 'can' be done in O(n) time, but the algorithm to do this is so incredibly complex that unless you have a polygon with 100000000000000 (*number pulled out of my arse) vertices, an O(n.log(n)) or O(n^2) algorithm is going to do it faster.
  2. inverse_inertia = inertia.inverse();   Anyways, if it aids:   By choosing the correct coordinate system for the object (For basic objects, the obvious one), you can always diagonalise the inertia tensor, and so it, and its inverse can be stored in a vector instead of a matrix, and then the inverse is just the component wise inverse: (Ix, Iy, Iz)^-1 = (1/Ix, 1/Iy, 1/Iz)
  3. It is not that there is less trig involved when using x-y vectors, but that there is NO trig involved.   I already showed you earlier how to do bouncing.  
  4. What reason do you have to say that using x/y vectors would not permit you to have anything but right-angle ramps? Using angle/magnitude for vectors is almost NEVER the good way of doing things, it quite simply makes everything more complicated.
  5. That you say you have done bouncing, but cannot figure out this, plus that you talk about the 'angle' of the slope tells me you are using trigonometry to do the bouncing... *sigh* :) The solution is incredibly simple, using simple vector operations. You have the slope normal vector (As opposed to its angle) You have the incident velocity. The outgoing velocity is then: newVelocity = velocity - normal*(1+e)*dot(velocity, normal) where e is the coefficient of restitution. For a perfectly elastic bounce e = 1, for a perfectly inelastic bounce (your 'slide') e = 0. If you're struggling to compute the normal vector. Assuming you have two positions for the slope 'a' and 'b' that you're using to compute your angle like atan2(b.y-a.y, b.x-a.x), then the normal for this slope is instead: unit(a.y-b.y, b.x-a.x). The normal is a unit-length vector that points 'out' (or 'in' for these purposes, makes no difference to the result) of the surface, so the left side of a box will have normal (-1, 0) etc.
  6. sounds like an XY situation: http://www.perlmonks.org/index.pl?node_id=542341 Why don't you describe what your actually trying to do?   You want to write a shader, a shader to do what?    You mention lighting, you mean that you want to write a shader to emulate how opengl would do its lighting?   You're talking about 'vector tangent to a point', do you mean the surface normal? You need to specify those for opengl lighting in the first place, so lighting is not really the question here, it seems to me you have a mesh, and you want to find the normals for each vertex of the mesh's triangles.
  7. When you say: x' = x*cos(A) - y*sin(A) y' = y*cos(A) + x*sin(A) Does your code happen to 'actually' do: x = x*cos(A) - y*sin(A) y = y*cos(A) + x*sin(a) aka, you update the value for x, then you are using the new value for x in the computation for y isntead of the old one?
  8. Well in that case (Having a triangulation) then you can just use paradigm's solution of removing all lines that are shared between 2 triangles. My solution is for the general case of having a set of points and lines that are connected (Or can be used on disconnected components also with some extension).
  9. It seems to simply mean that, given the triangle of a model which is specular, it casts a caustic; the caustic it casts when projected onto the plane is also a triangle (the caustic triangle) and the volume that the original specular triangle, and the projected caustic make is the caustic volume.
  10. Well if you think about what is actually happening: In the first case, it is in the worst scenario doing a loop that has nothing to do; the local int is going to have been assigned to a register and at worst a space on the stack. In either case setting it to 0 is like nothing at all. Most likely your compiler is not even bothering to set it since it's unused, and may even be removing the loop altogether as it's not doing any work. In the second case, each time you call 'new int' it's calling the operating system to ask it for space and performing lots of computations to choose the best place to allocate the int, with perhaps further logic to maintain the heap, same with delete in reverse.
  11. Further examples shown with results in red (additional number being number of times in total that vertex appears in output) http://www.zimagez.com/zimage/screenshot-031212-021000.php
  12. For fun, I implemented my solution in Haxe and checked it worked with a somewhat degenerate case as well of having a dangling vertex connected outside the main exterior set http://pastebin.com/uyu2ZehA
  13. Your step doesn't really need a triangulation. Eitherway given purely a set of lines you need to determine what the triangles are in the first place; and that same step can be used to simply determine the sub-polygons which would then lead to the same rule of an internal line has more than one sub-polygon using it and the triangulation step is pointless. Eitherway, I don't see how you could determine those internal sub-polygons any faster than just traversing the exterior directly.
  14. Paradigm shifter, that only works if the lines always form triangles.. eg: http://www.zimagez.com/zimage/screenshot-021212-225045.php here, your solution would choose to remove the crossed-out red line. My algorithm would give us the green polygon.
  15. One way to identify the exterior shell of your set of points (so we're assuming there are not any 'holes' that should be considered exterior to the volume). a) Identify a point on the exterior of the line set. b) Walk around the exterior of the line set till you get back to start. This identifies all the lines required to define the exterior; and then ones that you can remove are all those not belonging to the exterior. For a) you can choose the lexicographically minimal point (a, b) < (c, d) iff a < c || (a == c &amp;amp;&amp;amp; b < d) For b) you need to be able to; from any given point of the exterior identify the next point of the exterior. This comes in two cases; the initial case where you have 2 exterior lines to choose and you have to pick one of them (for this, abuse that your start point is lexicographically minimal), and in the other case you can make use of the point of the exterior you have just came from to order the outgoing edges. Presume that we choose, as a result of the first case of b) the point that is clockwise around the exterior (We'll come back to this after). If you label the previous point 'p' and the current point 'c'; then you can order the outgoing edges based on their relative rotation from the vector (c - p) http://www.zimagez.com/zimage/screenshot-021212-223758.php here, we want to pick vertex v0. We can do this by computing the perp-dot products of (v[i] - c) with (c - p) normalised by the length of (v[i] - c); and choosing the minimal (or maximal depending on coordinate system); since the perp-dot of two vectors u,v is |u||v|sin(theta). We can also avoid any division if sorting of the outgoing edges uses a comparison function instead of a key. Back to the first case of b); choosing the second vertex of exterior we can use the same technique, and use the vector (1, 0) instead of (c - p) above. This is valid given that our first vertex was lexicographically minimal since the clockwise direction of the next vertex can in the worst case be in the direction (1, 0) and there cannot exist any vertex of the set that would give us a 'negative' perp-dot since that point would need to have a lower y-coordinate and would have been chosen as the lexicographically minimal one. ^^ this is very similar to gift wrapping algorithm for computing a convex hull and is exactly equivalent if we join every vertex to every other one using this algorithm.