Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 17 Jan 2004
Offline Last Active Aug 19 2013 11:52 PM

Posts I've Made

In Topic: Code Review ::Pong Clone::

07 April 2013 - 03:11 AM

I haven't read the whole thing, but based on the ball class my main piece of advice would be this:

Try to reduce the number of conditions. The more similar code paths you have, the more opportunities there are for mistakes, particularly copy&paste errors. For example, rather than your 4 "moving..." booleans use a single velocity Vector2. You can add that to your position every update, avoiding 4 if statements. Then to bounce off the walls you just do velocity.x = -velocity.x

In Topic: Stencil shadow volumes - constraints on models too delicate?

15 January 2013 - 12:52 AM

There is a better algorithm for producing shadow volumes. Check out this paper: http://hungryspoon.com/PX_web/paper/paper.pdf


Not sure why it isn't more commonly known, I implemented it years ago in my hobby engine and it worked great. I didn't have to worry about the meshes at all, if it looked solid from the lights point of view it would cast a proper shadow.

In Topic: Faster Collisions Circles or Squares? Advice. (Fixed)

08 September 2009 - 12:56 AM

Ah, you want to test between hollow squares rather than solid boxes? I don't see why you need that for asteroids. Anyway, lets look at determining that they don't intersect. There are only a few options:

1. The squares are separated on the x or y axes (you know how to check this already)
2. Square a is entirely inside square b
3. Square b is entirely inside square a

If none of those are true, then the squares are intersecting.

In Topic: Faster Collisions Circles or Squares? Advice. (Fixed)

07 September 2009 - 02:54 AM

For circles, you don't need the square root. Just compare the square of the distance with the square of the radius. You also don't need to make sure you're subtracting the smaller value from the larger when finding the distance, because if you do it the other way around you'll just end up with a negative, and (-x)^2 = x^2 so it makes no difference after you square it. So you get something like this:
if (square(a.x - b.x) + square(a.y - b.y) < square(a.radius + b.radius))

Your idealic (whatever that means) square solution seems fine, for determining that the squares are NOT intersecting. Depending on your coordinate system I suppose, I'm assuming positive right and up. You lost me with the flaw stuff.

As for square (axis aligned box) vs circle tests, it's really just a case of finding the point within the square closest to the centre of the circle. I'll let you think about it.

In Topic: AngelScript JIT/AOT implementation details (technical)

04 July 2009 - 03:31 AM

Is there a reason you can't simply have the JIT code natively call a function which then executes the correct script function? So all calls to script functions in JIT code would be compiled as a call to this single wrapper function, with arguments determining which script function to execute. There would probably be tricky details, like I don't know enough about angel script to know what to do with the context, and the wrapper function would have to do something with return values, but I thought it seemed feasible.