RAZORUNREAL

Members
  • Content count

    618
  • Joined

  • Last visited

Community Reputation

567 Good

About RAZORUNREAL

  • Rank
    Advanced Member
  1. Your pixel collision functions are wrong. You don't take into account the relative positions of the sprites, for starters. Even with the generous assumption that both sprites are the same size and at the same location, your function checks all pixels against all pixels. This means that if both sprites have a non transparent pixel it will return true, regardless of where the pixel is within the sprite. I expect every sprite to have a non-transparent pixel.   I've taken the time to write a highly optimized version of your function: return true;
  2. Code Review ::Pong Clone::

    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
  3. 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.
  4. Curves 2

    How smooth do you really need it to be? Surely you could just convert the curve to a series of line segments and move along that? You could sample in a simple fashion to begin with, then go through and find pairs of line segments with too great an angle between them and subdivide if it is necessary for the desired quality. Once you have your "smooth enough" line strip it's very straightforward to move along it at constant speed, and if you like you can determine your speed based on the length of the whole strip.
  5. Faster Collisions Circles or Squares? Advice. (Fixed)

    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.
  6. Faster Collisions Circles or Squares? Advice. (Fixed)

    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.
  7. Mountains and Ridges

    Looking good! I do think, though, that you'd be better off taking those same lines and treating them is rivers instead of ridges. You could start of with a generic smooth mound, then cut away at it with increasing strength moving away from peak, and perhaps decrease the strength every time you split. I think it would look more realistic when they meet that way.
  8. Tech lives!

    Very impressive. I'd been thinking for a while about a game very like this. Oh well, I guess I'll just follow your progress instead. One thing: How do you determine the price of components people code for themselves? Giving people an ide seems like it's asking for trouble in terms of balance.
  9. AngelScript JIT/AOT implementation details (technical)

    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.
  10. Seed Random, Global objects, and SDL_Threads

    There are several options. Option 1: Pass anything you need to into the thread. That data pointer is there for a reason. You'd just have to do something like: if (data == NULL) ; // Die horribly EnemyShip* myEnemy = (EnemyShip*)data; myEnemy->functionA(); // Or better: EnemyShip& myEnemy = *(EnemyShip*)data; I don't see why you'd be passing just one ship, but that's the basic idea. Option 2: Handle seeding in the constructor of your ship using static variables either in the class or in the method. Like this: EnemyShip::EnemyShip() { static bool seeded = false; // This variable is shared between all enemy ships if (!seeded) { srand(time(0)); seeded = true; // By setting this shared variable to true, I ensure srand is only called once. } // Use rand() } Option 3: Global pointer or data structure. The fact that something is globally accessible doesn't mean you have to construct it straight away. You can have a global pointer which is initially null, or a global vector which starts out empty, and you can fill them out later on. Make sure they're constructed before you start your threads. People generally frown on global variables though.
  11. Quaternion, again

    You shouldn't have to extract the x axis like you're doing. For an fps camera you should be able to just create quaternions representing rotations on the x and y axes and combine them in the correct order (I'm not sure which order that is, but there are only 2 options).
  12. Quaternion to Euler

    There are several different sorts of euler angle (you can do the rotations in different orders). Are you sure that both of your conversions deal with the same flavour?
  13. Giblets round 3 - redux

    It's a bit of a catch-22. On the one hand, you want the interface done as soon as possible so you can put in stubs like this. On the other hand, it's easier to design a good interface if you know how it's going to be used. It's also easier to implement the interface at the same time (or shortly after), while it's fresh. So here's what I propose. The first few times it comes up, just leave a // TODO: Sound. After an unspecified number of those it's probably time to actually implement sound. So you go and do that, and fill in all your TODO's with sound code (note that they'll all be different, search replace won't help you here). It's important that you do that before things get too out of hand. These TODO's serve as the first practical tests, and you can continue on writing actual sound code when it comes up. If for whatever reason it's not practical to actually implement sound right away, then you settle for adding an interface and continue with stubs as suggested. But I don't think it's a good idea to interrupt what you're working on to write an interface the very first time sound comes up. By writing the interface early you run the risk of a bad design, and could end up changing all (or worse, half) your stubs anyway. Of course, I'd be lying if I said I always do exactly that.
  14. Time of intersection?

    Swept test between circles is fairly simple. First, testing for intersection between 2 circles is the same as testing for intersection between a larger circle (radius r1 + r2) and a point. Say the point was moving and the circle was stationary. The point then becomes a ray (ray direction being the velocity direction, and distance along the ray being proportional to time). At this point you can use a garden variety ray-circle intersection test to find the time of intersection. Given time and velocity, you can figure out where the moving circle is when it hits. If both circles are moving, you just set up the ray using the relative velocity. It may take time to figure out the details, but it's a good exercise.
  15. Self deleting?

    It's no different to calling a member function on a pointer whose object hasn't been allocated yet. If you've never done that, keep it up. Somewhat misleadingly, it can get through quite a lot of code and go a couple of functions deep before it blows up attempting to access a member variable and finding the this pointer is invalid. Some time I'll have to try to write a class that allocates it's own memory. Just for fun.