# Bow_vernon

Member

454

323 Neutral

• Rank
Member

• Interests
Art
Design
DevOps
Education
Production
Programming

## Recent Profile Visitors

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

1. ## Random terrain generation with fixed elevation

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. ## 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. ## Problem implementing soft collision contact (and impulse based spring)

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.

5. ## 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. ## 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. ## 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. ## The tick rate of old console games

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. ## raycast vehicle physics problem

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. ## 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. ## That old dos game

I believe it was vga, cause it uses 256 colors and was smooth enough to me.
12. ## 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. ## 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. ## 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. ## 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.
×

## Important Information

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!