Jump to content
  • Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

323 Neutral

About Bow_vernon

  • Rank

Personal Information

  • Interests

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi folks, a fellow gamedev here. So recently I've been trying to make a business simulation games (similar to Holiday Island or Sim City), and start moving on the vital element of the game: terrain generation and manipulation. The terrain is a simple heightmap with a randomly generated height values (I haven't implemented the random generation part, cause of this issue I'm talking about). Basically, in my game the terrain has to have fixed elevation, so when you compare a terrain vertex to its neighbors, they could either: have similar height have a 0.5m height difference (higher or lower). It must not have more than 0.5m difference. I need to do that to simplify the terrain manipulation (the game kinda heavily relies on it). I was thinking on simply generate the random height first, and then loop over every vertex to force its offending neighbors to lower/heighten itself accordingly. But alas it just doesn't seem to be the right way. Perhaps any of you ever done similar things in the past? I hope you could give me any advice on this matter. It's been boggling my mind. basically this is the game that inspires me.
  2. Bow_vernon

    raycast vehicle physics problem

    That would be the black arrow in your drawings, right?   Yes sir. I apply the force along the black arrow (normal of ray hit)
  3. Hi people, so I'm trying to implement the impulse based spring (soft constraint in general). I read erin paper, where it talks about CFM (constraint force mixing) and ERP (error reduction parameter). I just cannot make sense out of it. I tried looking at the Box 2D source code, to no avail. Can anyone give some explanation? basically when solving for impulse P, the equation is divided into two parts, I call them the velocity solver part and the position error projection part. For example, here's how the collision impulse is calculated in my engine (inelastic collision): impulseNormal = (-velocity . contactNormal + posError) * massNormal; // velocity is velocity at contact point // contactNormal is normal vector // posError is the bias term (the penetration depth adjusted with small slop) // massNormal is the effective mass along the normalDirection at contact point // I call the (-velocity . contactNormal) the velocity solver part, and // posError the position error projection part Now my goal is to make the collision resolution "spongy" or soft. Basically in general I wanna make my engine capable of simulating soft constraint. But I just cannot fathom how the CFM and ERP affect the impulse calculation. Perhaps there's some good books that explain this in an easier way? perhaps a naked/stripped down implementation that I can take a look at? sorry if this is too much to asks. I've been losing sleeping over this things.
  4. Bow_vernon

    Car skidding behavior

    Damn, I really wished I had a car lel. I didn't know that car brakes are applied on all 4 wheels (albeit at different rate). Thanks pal, this is gonna change my perspective on this matter.        I already factored the wheel load (using suspension force as wheel load) at the calculation. But I also cap the wheel load so it would not reach infinity, instead it will be capped to a maximum value (the wheel has "maximum load" property. But what would actually happen when the wheel get excessive load? (I know it will pop off lel) But I mean, how would it affect the lateral force? I tried re read the old physics books of my sisters, didn't find anything related there :(       Ah I see. But seriously, that game's physics still struck me with awe, even today. I haven't found anything similar. Well perhaps DiRT rally, but that's rally game though. Project cars doesn't feel the same.       Yes, I should have stated it more clearly. Sorry.       Yes, I meant to talk about pure driving without assistance. Learnt new things: "lifting" and "flooring". That's why I was confused about the driving videos. I thought "lifting" means the chassis doing "back-leaning" (like a plane about to take a lift lel).       This is why sometimes I envy western people. Most of those cars are considered luxurious here (South East Asia).       Ah the physics of racing. Thanks pal. This is some good quality readings here.       Yes, at the moment the friction model was "pyramid" (shoud be conical / circle right?) I am at a loss though because I'd like the wheel to have more longitudinal friction than sideway friction (wouldn't this make the friction "cirlce" look more like ellipsoid?).   EDIT: Of course, I didn't mean to "hack it" till it just works, just trying to find the logic in skidding. Anyway, now the lateral and longitudinal forces are both using Pacejka magic formula, and both are affected by the driving force (i.e, player hit the pedal) in a way. The lateral force input are the Pacejka magic constants (for lateral force), friction coefficient, max loading of the wheel, real wheel loading (already calculated when solving suspension force), and the slip angle (this one is affected by the difference of speed on the contact patch (between the wheel and ground), and is heavily affected by driving force, since applying driving force changes the contact patch velocity difference. The longitudinal force is also affected by driving force, because its input are Pacejka constants (for longitudinal force), friction coefficient, max loading of the wheel, real wheel loading (already calculated when solving suspension force), and the slip ratio (this one is affected by the driving force, since applying driving force would cause wheel and ground speed difference, which is used to calculate slip ratio). Now it feels good, but I haven't done any kind of combination / mixing, other than factoring the driving force into the equation. Does Pacejka magic formula need to be mixed or what (perhaps limiting the friction circle)? I'm at a lost now, but my opinion is when one use Pacejka magic formula one doesn't need to do some mixing because the curve is already dictating the behavior of the tire, including the mixing between lateral and longitudinal force, but I'm not sure though.    EDIT2: I've read Brian Beckman physics of racing, also taken a look at RACER implementation of this. Turns out there are various ways of combining lateral and longitudinal forces. I use one of the modified method (it's called the circle method in RACER), and it works well enough for me. Thanks people for the suggestion and contribution.
  5. Bow_vernon

    Car skidding behavior

    Hiya fellow gamedevs!   So I finally implemented the so called Pacejka "magic" formula (correctly). It allows the car to steer around like a car supposed to. However I only use Pacejka for lateral (cornering) force so far, the longitudinal is still using simple formula that works well enough. But that's not my problem. My problem is the car now can skid (spin uncontrollably), and of course a countersteer is sometimes enough to alleviate it. But I haven't factored the driving force in skidding behavior. The question boils down to this: suppose a rear wheel drive car (2WD) is spinning to the right, so we do a counter-steer, but suppose this is not enough to stop the car from spinning. in that situation, what is the effect of hitting the pedal to the metal? would that make the car spin even worse?  in that situation, would hitting the brake (slowly perhaps) helps the driver taking back control of the car? I wonder because: I don't have a car nor a skidpad or a wide field to test it myself lel  :P This video  basically stated that just let go of the gas(let the wheels free rolling?) or was it to push the pedal slightly(reduce drive force?) damn my listening skill is not good :( The behavior of the car in Need For Speed Porsche Unleashed ™  is kinda against the tips in number (2). Usually in the game, when you corner without hitting the pedal (turning while the wheels are free rolling), your car would spin, and hitting the gas in that situation would help reduce the spin (you gain back control). While in the video in number (2) states that hitting the gas while spinning would make your car go 180. Also what I don't understand is, in the game (NFS PU), it's basically impossible to have your car spinning when you turn around the corner while hitting the pedal. Your car would instead do a high speed, understeer turn. What is the true behavior of a car in such situation in real life? Thanks pal. I've been trying to play the old games again (it has seriously the most realistic physics for the car game in that time IMO), but to no avail. It keeps crashing because it uses DX7 for rendering.
  6. Bow_vernon

    raycast vehicle physics problem

    Ah, finally the problem was solved. I simply apply the "suspension force" along the normal direction of collision. This works well enough for my purpose. Thanks pal.
  7. Bow_vernon

    The tick rate of old console games

    Wow, that's a lot of information. Btw I made a typo. I meant to compare n64 vs psx (not amiga vs psx). But I got my question answered. Thanks.
  8. Hi all, since I'm not sure if my question belongs in specific sectiin, I'll ask here. Does anyone know the common tick rate of old console games (amiga64, psx). I wonder because recently I watched several longplays (where people play games until it's finished), and noticed that some of the games were rendered @ 60fps. Holy molly. I thought amiga64 < psx in term of processing power? Also, some of the early car sim game (gran turrismo anyone)? And some dude's name rally games were available back then at psx, which was amazing simulating all those at 30(felt like) hz. Also does the console (specifically psx) dictates that the tick is hardwired to 30hz? I know that this is not the case with ps4, but since I never saw any psx games with >30fps render rate, I'm not sure.
  9. Hi people, I am now attempting to implement the ol' famous raycast vehicle physics. Based on several readings, particulary:  http://blog.spaceduststudios.com/space-dust-racing-unreal-engine-4-arcade-vehicle-physics-tour/ https://docs.blender.org/manual/en/dev/game_engine/physics/types/vehicle.html It works fine most of the time, as long as I satisfy these constraint: the raycast have to be of similar length (the suspension+wheel radius) cannot differ from one another. the suspension properties must be uniform (the spring coefficient(k) and damping coefficient(c)) cannot differ from one another. Here's how I do the vehicle physics: for each wheel, each frame: shoot a ray from the wheel suspension start position (in absolute frame) towards the absolute ray direction. Usually this is down (0, -1, 0) in local frame. from the raycast detection routine, I got several useful information (the "time of impact" of the ray hits [0..1], the ray hit position (where the ray hits), the hit normal (the normal of the ray hit position). then I calculate the suspension force (Ignoring the side slip friction and forward/brake force atm, focusing on the "hovering" first). the suspension force is then applied at the chassis @ suspension "start" position, and the opposite force is applied to "ground" @ rayhitpos. The force direction is parallel to the suspension direction (ray direction). As I said, as long as the rays are uniform (similar length, spring coeff and damping coeff), it will works fine. Thing is, I'm trying to simulate a dune buggy, where the back suspension would have longer travel distance, also the back wheels are bigger in diameter than the front ones. Now that means I have to Make the back "ray wheels" have longer suspension travel and bigger radius, resulting in non uniform suspension length and spring properties. Also, the buggy suspension is not uniform. The back suspension is directed a bit backward, and the front suspension is directed a bit forward (this is called "caster angle", usually configured like that to smoothen up the ride). Now because of this, the vehicle would gain forward speed most of the time, because the net force applied would cause the chassis to move forward a bit. I am thinking of instead of applying the suspension force along the suspension travel direction, perhaps it would be better to apply the force along the ray hit normal. This would cause the chassis to "float" along the ground just fine, since all the force are acting along the ground normal ("up" usually), so no lateral force would emerge. But is it the right thing? how did the vehicle physics in GTA 2 Vice City was implemented? Because one of the vehicle there (the "harley" bike) exactly configured like this (the front wheel's suspension is slanted @ 45 degree, not totally "down"), and the bike would ride just fine.   Here's an image that depicts the problem: in the non-working case, the vehicle would move to the left, this is without side friction or forward/brake force (it shouldn't, right?). the red line is the ground, the blue is the ray, the black box is the chassis, the black arrow is the ground normal (rayhitNormal), and the brownish arrow is the suspension force, which is applied at the "raystart" (which is the end of the blue line inside the chassis)
  10. Bow_vernon

    That old dos game

    Yes it was topview like zelda are you sure it was originally a dos game and not a port from some other platform, like amiga or something? it doesn't sound like your typical dos first game from the VGA era. more like a port. as i recall, mode13H was the big deal about VGA 320x200x256 palletized colors. combined with a 386, and you could write a raycaster like doom in a couple of man years or so.Now this is what I suspect. I've searched thru the dos games list @ dosgamesarchive.com which provides screenshot, and I didn't find it there. Now I think it might be port from amiga. Gonna search again! EDIT: FOUND IT!! turns out it was originally released for amiga and sega cd. The game title was "Legends". Here's the detail of the game: http://www.lemonamiga.com/games/details.php?id=1767
  11. Bow_vernon

    That old dos game

    I believe it was vga, cause it uses 256 colors and was smooth enough to me.
  12. Bow_vernon

    That old dos game

    Ahh sadly that's all I remember.you started at plain meadow, so green. Also the indian boy wore a bird feather in the back of his head. The art style is like zelda (cute/chibi). All I can say is the protagonist pretty much looks like disney's Hiawatha
  13. Bow_vernon

    That old dos game

    Hi people. I've lost sleep over that old dos games that I still can't remember. It was an old adventure game like zelda, but the protagonist was a young indian, like disney Hiawata. The first weapon was bow and arrow, and the enemies were like wild animals and such. Do you know its name? I've been googling with no luck. Even seeing the old dos games compilation on youtube didn't help.
  14. Bow_vernon

    Inflat/Deflate convex shape for gjk core shapes

    After tinkering a bit, I implemented iterative solution for this problem, and it worked nice! but perhaps non optimal, but since it's an offload process, it's fine. Anyway, here it is showing the "core shapes" + pure gjk for contact generation (at around 34 seconds mark)   Thanks for the reply! after toying a bit, I implemented the iterative version of this. Basically, each vertex has to satisfy a series of linear equation, and then I solve it using gauss seidel iteration.   The quick hull!! it really helps tremendously in visualizing the CSO. Thanks for the share. But in the end, I yield to iterative solution, I'm gonna read your solution thoroughly later though!   Thank you for the link! gonna read em.
  15. Bow_vernon

    Inflat/Deflate convex shape for gjk core shapes

    Uh... Hi Mr. Gregorious, happy new year!! Btw I can't seem to follow the dual space thingy. I've been reading the article at wikipedia, but aaghh, I just don't understand. I can push the faces inside by specified margin, this will result in faces that is overlapping with each other, as shown in these pictures:   the red is the original convex shape, the light blue one is with the face "pushed in" along its normal as far as the specified margin. Is this what you mean at step 1? I reckon you meant to push the faces back by dividing the normal plane +/- margin? but at step 2 you said to build convex hull? doesn't that mean step 1 should produce clouds of points? ugh, I got confused....can you maybe...show some pictures? sorry if I bother you.
  • Advertisement

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!