Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 07 Nov 2010
Offline Last Active Yesterday, 10:09 PM

#5147829 SVG - Anybody using Scalable Vector Graphics and how?

Posted by CulDeVu on 18 April 2014 - 01:12 AM

Because I prefer to use Adobe Illustrator for vector art, and because the game I'm making is primarily vector-based, I export art as .svg instead of parsing .ai files. SVG files also contain lots of superfluous information in the form of XML, so I only use it as an in-between, translating it into my own data format better suited to my purposes.

Actually as long as the closed paths in your art don't have holes in the middle of them, triangulation is relatively straightforward. Ear clipping is the most common method, if you don't care about the slight performance hit.

My biggest qualm about SVG is animation support (for Illustrator at least, I can't speak for inkscape or the other vector art programs), and texturing support, primarily multitexturing. I would have liked the texturing problem to be nonexistent, but texturing everything makes the entire piece look a lot nicer :-)

So, long story short, it's a nice format for static, minimalist art, but it has serious drawbacks that should be looked at before you ditch rasterized graphics completely.

#5108339 Cylinder-Triangle Collision?

Posted by CulDeVu on 10 November 2013 - 02:26 PM

anyone have any good material for doing cylinder-triangle collision?




I agree with HappyCoder. It'd actually be easier if you use a capsule. What I'd do is: I'd turn it into a triangle-to-line-segment test. I'd shrink the capsule until it had a radius of zero (a line segment that extended from the base of each of the hemispheres on the end, going through the center of the capsule), and then find the minimum distance between that line segment to the triangle. Once you find that distance, you do a check to see if the radius of the capsule is larger than they distance between the capsule and triangle, just like you do with a cylinder-to-point test.


Also, I'd use an existing physics engine if I were you. It makes problems like these much simpler.

#5097069 Latest trends in procedural quest generation

Posted by CulDeVu on 26 September 2013 - 01:55 PM

Just BTW I have no authority in this subject. I've never any papers, and I've gotten into this stuff, but here's a link to an article I read a while ago. It talks about generating interesting questlines by reference that is used in Malevolence: The Sword of Ahkranox


#5094365 Calculus Vs Algebra based Physics

Posted by CulDeVu on 15 September 2013 - 08:11 PM

Well most physics engines have an integration phase. Here's an article:

Since both classes will probably cover vector algebra, it probably wouldn't matter much.

You'll find, when doing physics in a game you usually go ahead and use a third party library. The reason being that making a physics engine is very hard, and usually a lot less calculus in it than you'd expect. Calculus likes to deal in time steps very close to zero, which is something computers end up having a hard time doing.

Best of luck! :)

#5088398 GJK Simplex Caching and Circles

Posted by CulDeVu on 23 August 2013 - 09:41 AM

Ooooh Ok I see what the problem you were having is.

What I saying about redundancy checks is that, given a previous simplex, how would you know that it's the same one that you would generate on this frame? For slow moving and stationary objects, it most likely will be, but it won't always. Because you can't be sure if the simplex will be generated in the same way as last time, you can't discount certain sides of the simplex as you normally would. It was just my thought that storing the previous closest point might be your best bet, at the very least because it's a good starting point for GJK. Because remember, you can start from anywhere on the shape, not just a vertex.

I guess if you're not planning on supporting curves or any sort of user-defined paths, then you can go ahead and store vertices for simplexes. But for any sort of curves and paths, you can't.

How are you dealing with simplexes in your code? Are you passing indecies or points? You should base the cached data around what's easiest for you algorithm to use.

Hope I made sense

#5088206 GJK Simplex Caching and Circles

Posted by CulDeVu on 22 August 2013 - 04:06 PM

Ok let me see if I can explain this coherently, as I'm messaging from my phone right now.

My physics engine doesn't do any sort of caching of collision information because of the memory hell that would ensue. My engine uses only quadtrees because, for the purposes of my games, I don't usually need anything else. I wouldn't discard caching as an option though without testing.

But as for your question, you want to store the simplex of *each collision detected by the broadphase*, because each manifold might have multiple GJK tests a frame. The inherent problem with trying to reduce redundancy, however, is detecting the redundancy that you're trying to minimize. The question is how would you use the simplex information that you're storing if you don't know if it's the same one you would generate on the next frame?

What I would do is store the previous closest point generated by GJK, and use that as the starting point for the next frame's GJK test, which would solve your circle problems. The reason I would advise against storing a full simplex is that, in addition to the redundancy check, the simplex would only be more helpful is when two shapes are actually colliding, which is an extremely small percentage of objects usually tested in games. It'd be more worth your while to speed up the part of your code that throws out false collisions than the part that detects the true ones. That's just my opinion though.

Hope this helped!

#5087923 "Each vs. any" collision shape implementation

Posted by CulDeVu on 21 August 2013 - 04:08 PM

My personal favorite, one that satisfies your requirement for abstraction, is the GJK algorithm. There's a good write-up I found once, but I can't seem to find it. This one seems fine, though: http://www.codezealot.org/archives/88

Basically, the magic is in the support function. In the GJK algorithm, the only piece of information used to determine collision is the furthest point along a ray for any given shape .

class Shape 
  virtual void furthestPointAlongRay(vec3 ray) ;
All you have to do is overload the function for any convex hull. This method is extremely versatile and fast, far worth whatever evils you may have heard about virtual function calls ;)

Best wishes on your physics engine!

#5077508 Corner/Edge Collision Detection

Posted by CulDeVu on 13 July 2013 - 11:14 PM

Like most math problems, this one can easily be solved by looking at it differently.


The way I would approach this problem is completely opposite. I would find the closest point on the box to the circle you're testing against. From there it becomes a trivial matter of finding the distance from closest point on the box's edge to the center of the circle, and testing against the circle's radius.


I hope that made sense. The nice thing about this technique is that the vector from the box's closest edge point to the circle's center also serves as the edge (or corner) normal for intersection, making the "pushing the player back" part of the code also relatively simple if your have a small intersection. If you don't, then things could get a little hairy.


But, of course, all these things (like collision correction, bullet-through-paper problems, etc), can be turned into a slightly simpler problem, if you're willing to settle with close-enough-to-look-right accuracy. If so, I will always redirect to Paul Firth's excellent blog post:



Hope this helped!


#5017738 Searching for a specific game theory about basic interaction

Posted by CulDeVu on 05 January 2013 - 07:46 AM

I don't think that there's any particular name for the theory. It's pretty much the general view of interactive game "science", if you could call it that. Maybe this might help:


In fact, a lot of the articles posted on Lost Garden deal with this very topic. You should check them out.

#4959559 One-Step vs Two-Step Initialization (C++)

Posted by CulDeVu on 16 July 2012 - 06:11 AM

Game consoles are the platforms that have bad C++ exception support. Microsoft/Sony tell you to disable exception support on their compilers in order to produce better binary code. Even x86/Win32 is pretty crap here, though x64 Windows is a lot better.

Even x64 Windows has had serious problems in its exception and critical error handling in the past (and present). One such example was described recently by Bruce Dawson on AltDevBlogADay:

#4953538 Please test it my first project really need reviews

Posted by CulDeVu on 27 June 2012 - 08:39 PM

Please don't double post. People don't like being tricked into reading the same post twice with just a different name. And from what you said in the post, your game isn't really as completed or as 'epic' as you make it seem from the title of your other post.

About the actual game, though: I will try it out next time I'm around my computer.

#4937659 Platformer Physics - what to do with multiple resolves?

Posted by CulDeVu on 05 May 2012 - 02:22 PM

Sounds like a problem of over-compensation: http://www.wildbunny.co.uk/blog/2011/03/25/speculative-contacts-an-continuous-collision-engine-approach-part-1/