Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / Ported DBP code not working properly (uses Sparky's collision)

Author
Message
Zotoaster
19
Years of Service
User Offline
Joined: 20th Dec 2004
Location: Scotland
Posted: 20th Apr 2008 16:25
Hey, I'm trying to port some of my DBP code to DGDK, and it's not working in the same way. It's a basic physics lib that has the exact same code in DGDK as in DBP (using some of C++'s features to cut it down a bit), but it doesn't work. The parameters I use to test it are all identical.

The problem is that in the DBP version the ball moves around nice and smooth, but in the DGDK one it's very jerky. I've tried making more levels for testing, but to no avail.

Here is the DBP code:


And the DGDK code (it doesn't use the same arrays are stuff, but the data all matches up in the end):


The basic order of things is (in both sources):
- Calculate weight force
- Calculate drag force
- Add all forces together (in the C++ version I use a vector class for this. I've tested it over and over and it doesn't have any problems)
- Get the acceleration from the force, get the velocity from the acceleration, apply friction on collision (tested this too, not the problem), and then get new positions
- Collision: If there is a collision (using Sparky's SphereSlide function), then position object at sliding positions, and handle the collision and sliding force
- Position and update the object


Obviously the jerking would occur in positioning the object. As you can see in the code, I only position the object once, but I set the position coordinates in two seperate parts. The first part is where I add on the velocity, and the second where I assign the sliding positions (from Sparky's plugin). Obviously when adding on values to gradually affect the position it would not give any jerking (and tbh, I don't see any problem there with the velocity code). It only jerks on collisions, and the only other place where I position the object is on the collision, so that must be the root of the problem. Either I have been really stupid and made a big mistake, or it's a problem with Sparky's collision functions.

I've revised the code over and over and this is the only problem I can find. I guess this naturally leads to this question too: Are there perhaps any really easy and basic physics libs out there that I could use? I only need it for spheres really.

Thanks

Don't you just hate that Zotoaster guy?
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 21st Apr 2008 18:38
Hi Zotoaster! Welcome to GDK LOL

Um, try making a timer based heart beat for this code. Like every 100milli seconds or something.

I think your jerkyness is from the code running kinda fast - and you see the differences in how fast the code runs in in one situation (no collide) and then the Collide code takes a bit more and its visually upsetting. The Heartbeat technique might "Hide" this by the DELAY for each call being longer than the both the best and worst case (code run time for a given situation) scenarios.

Effectively polishing what you've already got working. I've seen your physics code in the past and its VERY useful for many things... light weight too.

I hope you do something cool with this - because sometimes Dark Physics doesn't play nice and its nice to have light weight alternatives that can be used along side Dark Physics or instead of.

I remember your physics were pretty easy to implement in DBPro. I had jiggly issues with it - but I think I could have resolved if I played with it some more... before I jumped to DarkGDK

Zotoaster
19
Years of Service
User Offline
Joined: 20th Dec 2004
Location: Scotland
Posted: 21st Apr 2008 18:58
Quote: "Hi Zotoaster! Welcome to GDK"

Thanks. Been using it for a while actually, but never actually got round to trying to make a game with it.

Quote: "Um, try making a timer based heart beat for this code. Like every 100milli seconds or something."

I considered this, but the problem with that is that it will stop checking for collisions and then will fall right through the floor, which would look even less realistic, heheh.

I'm not sure what you mean when you say it happens because it's fast. By jerking really I mean that the ball flickers between different places around where it's supposed to be, and quite significantly.

The odd thing is that the camera is set to follow the positions of the object, and doesn't yet have any smoothing in it. Surely this would mean that the camera would flicker around with the object, but for some reason it doesn't. It's as if it is at a certain position but is rendering elsewhere for some strange reason.

Don't you just hate that Zotoaster guy?
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 21st Apr 2008 19:03
Quote: "I'm not sure what you mean when you say it happens because it's fast. By jerking really I mean that the ball flickers between different places around where it's supposed to be, and quite significantly.
"


I was having ZFighting issues in Iron infantry - and the solution was to SHRINK EVERYTHING!!!! And my Water line meeting the shore stopped that annoying flicker. Was a rounding thing.

Now I'm cam range 100, and a meter is a 0.01 db pro unit, and life is better. I'm still trying to find the sweet spot.. but this has resolved my water zfighting.

In short, could be rounding errors or whatever.

Zotoaster
19
Years of Service
User Offline
Joined: 20th Dec 2004
Location: Scotland
Posted: 21st Apr 2008 19:21
OK I tried that, and if anything the problem just becomes more highlighted by the bigger looking jerks.

I'm still not entirely convinced that my code is ported correctly, it's just that I can't find any problems on the surface.

Don't you just hate that Zotoaster guy?
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 21st Apr 2008 19:24
What's with all the underscore names? Can you format that code so it reads a little nicer? (Just asking)

Zotoaster
19
Years of Service
User Offline
Joined: 20th Dec 2004
Location: Scotland
Posted: 21st Apr 2008 19:30 Edited at: 21st Apr 2008 19:31
I put underscores on private members of classes. Makes it easier for me to know what's what.

Here are the commented private variables:



[edit]

TGC posts undo all my awesome indentation

Don't you just hate that Zotoaster guy?
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 21st Apr 2008 19:33
makes sense. I use something much more wordy: pvt_

Yours confused me cuz _static for example reminded me of something that is a keyword... Microsoft and whomever the C++ makers are use underscores like that. I didn't know what was going on

Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 21st Apr 2008 19:47
Typically the underscore as a leading character to an identifier is supposed to help identify a system identifier. It's not a language requirement nor is it limited to compiler originated identifiers. It's just the way M$ tends to do things and, I'd gather, a number of others.

@Jason
I like your idea of using pvt_ but I'm not that organized to maintain the discipline. Do you have something similar to it for protected members? One of my weak points is that I'm not very creative when it comes to coming up with names for my identifiers.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 21st Apr 2008 20:10
I never use protected members ... should I? (I don't know) ... if I did... prm_ would be a canidate, and so would cop_ just because protected - police - cop...



I find it hard to believe you're not a disciplined coder - you are to knowing to not be to some degree at least.

BTW - IanM is the guy to ask when you get tough stdlib problems. He seems to know that stuff really good.

Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 21st Apr 2008 20:46
Quote: "I find it hard to believe you're not a disciplined coder - you are to knowing to not be to some degree at least."


I'm really pretty much a fly by the seat of my pants programmer. A lot of people will talk about top down programming. I consider my style of programming as more inside out programming. I work out the inner details, the ones that I know are not only easiest to do but also will need to be available for testing rather than using some sort of stub. I may not use an animated sprite initially, for example, but I will use a full sprite instead of a drawn box. I'll make sure that I know how it moves and then write my logic around it, working outward. I'll have some sense of how any given piece is going to relate to the larger picture but I'm not going to write the bigger code without something for it to work towards first. An example would be the layout development of my current project. I had it running as the main loop inside DarkGDK(). Once I got the bugs mostly exterminated I created a selection routine that is capable of going to other modules but for the moment goes direct to the layout module and nothing else. This tells me that the selection process is workable now all I have to do is create the other modules.

Does that make sense? My take is that top down programming was in vogue when it cost a lot just to test a program and you couldn't afford to run too many tests. It cost less to have dozens of humans review and revise the code before committing it to test.

Write code down? Nope. I usually finding myself wanting to re-write it and I suddenly get lazy.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 21st Apr 2008 21:02
I never do Top down Coding. I code like you. I Always prefer to make a library of things I know I'll need, and then make those solid as I can, because I then build on those, and that, and then that... getting towards that place where you have a ton of low and highlevel tools at your disposal - same flavor - and you tie them together writing your app.

Zotoaster
19
Years of Service
User Offline
Joined: 20th Dec 2004
Location: Scotland
Posted: 22nd Apr 2008 18:08 Edited at: 22nd Apr 2008 18:30
OK, the problem is definitely in here:



I tried this with yet another level. Instead of sliding along the wall, it just sticks there, and jumps when I turn the player. The strange thing is that it slides on the floor perfectly fine.

Don't you just hate that Zotoaster guy?
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 23rd Apr 2008 14:34
I dunno man. Not dissing you, last time I tried to help someone with a sparky issue it was 8 hours of realizing the mako model (girl tgc direct.x animated model) was hosed. Didn't seem to be sparky's so much.

You're running into one of those problems I don't want to get into for fear it will be a endless nightmare making me question my understanding of phyics, time, life etc

Zotoaster
19
Years of Service
User Offline
Joined: 20th Dec 2004
Location: Scotland
Posted: 23rd Apr 2008 18:40
Haha no problem. It probably does have something to do with the model. After sme further testing I have concluded that it works in some places but not in others

Don't you just hate that Zotoaster guy?

Login to post a reply

Server time is: 2024-09-29 17:20:28
Your offset time is: 2024-09-29 17:20:28