Jump to content
  • Advertisement

RAZORUNREAL

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

    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.
  3. RAZORUNREAL

    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.
  4. RAZORUNREAL

    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.
  5. RAZORUNREAL

    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.
  6. RAZORUNREAL

    Mooving Parts

    Do the platforms really need to change direction suddenly? If they moved more smoothly it wouldn't be an issue.
  7. RAZORUNREAL

    Shadowing part II

    Ouch... Reading that, are you sure shadow volumes are such a bad trade-off? They take a lot of fillrate, sure, but compared to rendering huge chunks of the scene into high resolution textures, it might not be so bad. Maybe you could extrude shadows different distances depending on the size of the object? I'm just guessing of course. You'd probably have to make low resolution models of everything to generate shadows from, which would be a pain. But robust volume generation isn't that hard, I know of a paper about a simple algorithm that can generate an optimal volume no matter how many triangles share an edge. Haven't got it bookmarked on this pc though. I don't know, it just seemed like you discarded them out of hand.
  8. RAZORUNREAL

    Blender character animation

    I've written an exporter from blender into my own keyframe animated format, but a skeletal format would probably be harder. I didn't look into it too deeply, but blenders skeletal format seemed fairly daunting. One thing to watch out for is that there's no easy way to tell (or specify within blender for that matter) how long actions (blenders name for animations) are. You can, however, find the first and last frame with a bit of effort, which was good enough for me. If you've got any questions I might be able to help, just bear in mind I don't know python (my exporter is horrible as a result).
  9. RAZORUNREAL

    Anisotropic lighting

    Erm. It's a game, looking cool should be more important (imo) than making perfect sense. People play to escape reality right?
  10. RAZORUNREAL

    And teh winnar is...

    I hate to say it, but APC's comments about schooling, while needlesly harsh, are very appropriate. They show you diagrams of the solar system, but barely mention how much of a pain the orbits are, let alone how breathtaking the scale is. I'll put it this way. You want to make a pipe between 2 planets? You'd better be prepared to sacrafice a planet to make it out of. And that's ignoring all the other problems.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!