• Advertisement

MisterFuzzy

Member
  • Content count

    24
  • Joined

  • Last visited

Community Reputation

161 Neutral

About MisterFuzzy

  • Rank
    Member
  1. You see, the first comment you post that actually follows forum rules should not openly rant against the moderators that locked your violating topic, and surely your second and third shouldn't lash out against those who pointed out your mistake. You asked for a job. You almost had one. Then you decided to post a smart-ass reply, and pretty much sank your reputation. Just because a job is simple, doesn't mean that it's demeaning. If you did well, I probably would have asked you to make some music for my game Xenith, a 3D RPG that is nearing completion. But whatever. Your choice.   Anyway, I should probably delete this old account. Too much spam.
  2. Let's say your draw region is 100x100, and positioned from the topleft corner at 256x256. To get the mouse position in the box, you would just subtract the measure of the top-left corner from the mouse XY position to get a relative value. Then, you can use simple checks ( if newX < 0 || newX > 100, then mouse.X is not in the box's x bounds and therefore cannot be in the box, else check newY etc. etc.). That's all there is to it! Really. That's all.
  3. Why are you ending your gameloop? In your loop, it would be far more efficient to have a boolean value DoUpdate that defaults to true. All motion and calculation would be done only if DoUpdate is true, else everything becomes static - just sits there. It still draws (You could use the boolean to control this, too), but nothing will move until DoUpdate was set back to true. Bam! Paused.
  4. Thanks, Daaark! That's exactly what I was looking for .   Yeah, I plan on having each mesh hold a collision sphere, and for each particular mesh collision (on a character or vehicle) the "weight" of damage to be applied will be determined by what mesh in a model was "hit." Of course, a shotgun to a car's bumper shouldn't stop it, but the engine? Not so much. A rocket would kill a vehicle if it hit anywhere :D.   From there, I plan on having an undrawn "collision model" that handles any per-vertex collision that is the same shape as the model, but is far less detailed. It will cover the general area, but with far fewer vertices. It will be subdivided into meshes, so I can handle the "weight of damage" I mentioned earlier.
  5. Aye, I've already been considering the "narrow it down" apporoach, I can detect which mesh in a model was hit to appropriately apply damage (A head shot would be an instant kill, whereas a shot to the toe should do little to no damage): But what I really would like is an article on collision detection of actual Models/volumes. I can't seem to find one that involves just the models without the bounding boxes or spheres. Thanks, though!
  6. Hey!   I'm not exactly proficient with 3D collisions. 2D is fine, but 3D volumes are, needess to say, quite a bit different. I've been reading around the interwebs on 3D collision, and all seem to say the same thing: "Using bounding spheres..." The thing is, for my experimental FPS, bounding spheres can be too inaccurate: Players could be frustrated when they die when a bullet whizzes just in front of their face, or a clear hit travels straight through their target without ever touching the bounding box. My question is, how can I get accurate collision detection without sacrificing speed or accuracy?   (An article would be great, too)
  7. 3d sprites - is it worth it?

    Rendering objects to a render target does have it's perks over traditional spritework. For one, as already stated, it can potentially take a lot less memory to store than large or numerous graphics or spritesheets. Animation can be done by simply iterating through the model's frames, and bones can be moved manually to add functionality that would otherwise be extremely difficult to achieve, such as preserving the character's running animation while holding a large object in their hands (animation blending) or looking at something in the world (bone transformation). Single parts of the body can be scaled and twisted, so that you could easily incorporate things like "shrink potions" or "giants" for the player to fight. Because of the perk of easy scalability (no detail is lost when the image is scaled up), you can easily write a small algorithm that makes the sprites look the same on any computer, taking up X percent of the screen's viewport resolution.
  8. First off, you will never find a game programming book that will specifically cover "making things explode." The purpose of the books is to teach you the general concepts of programming interactive media, not spoon-feed answers to it's readers. Making things explode is something that howto authors expect the reader to figure out on their own using the general concepts discussed in the book. For example, if a book discusses rigid body physics you can use that general info to make an explosion by instantiating smaller models of the vehicle's parts (body, wheels, engine, what have you) and apply an initial velocity to each part based on the car's last speed. Add a few particles and some spiffy sound effects and whammo! You have a car exploding.       Even though this seems a simple enough task, depending on how you want to do this you will need quite a bit of math. First, using a completely transparent "overtexture," you will have to use some fancy formulas to correspond where the mouse/pointer/whatever is over your model to the UV coordinates on the texture. If you want to have part-by-part coloring options (color the door, hood, et cetera), you could have a simple checklist of each part and corresponding color (and simply change the hue of certain parts of the texture). For decals, you will need to find the UV coordinates as stated above and apply the decal in real-time. A little complicated, to be sure, but easy enough for an intermediate programmer to be able to work out. Then, there's directly painting the cars. Not only will you have to calculate the UV coordinate relations with the model, but also skew the paint zone depending on the angle of the camera. If the user sees a circular brush icon, but are looking at the car at a forty-five degree angle, just drawing a circle at the coordinates would produce undesireable results: To fit the brush shape, the new shape would have to be an ellipse!   . . . I guess all I'm really trying to say here is that you can't expect books to address your needs specifically: Just use trial and error to make your own solution that's tailored to your own needs.
  9. Everything is working now :).   I'd recommend normalizing the input from the keyboard to make the player move the same speed in every direction.
  10. Restricting Camera

    Whee-hee. So did many of the other users here. Heck, I'm pretty sure some of the people who post around here are STILL 10-11 years old. However, as stated before, you are asking for someone to just give you the code you want. All that will do is force you to come back to the forums and beg when you can't do the same thing later on. MJP gave you a REALLY easy way to do it, L. Spiro, although somewhat curtly, gave you the answer you needed as well. Just... Listen.
  11. Have you considered NOT drawing the tiles that are not visible on-screen? I'm constantly forgetting to do this myself...
  12. Win7 with AMD Vision A8 laptop, unable to start correctly (0xc000007b). That is all.
  13. You should probably move that bool to when the player[b][i] releases [/i][/b]the jump button, because if it only triggers at the 50px mark, you could make a half-jump but then press the button again to hover.
  14. The root usually isn't your Content folder, it's the application root... So you still need to navigate to your content folder. This may or may not be the case (I usually have to set the directory myself), but try printing a debug string with the value "content.RootDirectory" to see where it's going.
  15. Is there a problem with simply modifying the wheel mesh by rotating it 90 degrees in an external editor? Can't really tell you much if you don't post code...
  • Advertisement