Jump to content
  • Advertisement
  • entries
    232
  • comments
    1463
  • views
    960655

Back to programming

Sign in to follow this  
Ysaneya

247 views

Happy new year 2006!

I've back to do more programming. I've been trying to implement collision detection in ODE for the Minas Tirith project (which incidently, is using Infinity's engine: combo hit). It didn't work quite well. As soon as two objects were colliding, they ended up with a NaN (not-a-number) position/velocity. I tracked down the problem into ODE to find a very strange thing..

Picture this: a structure dContact, contains collision detection informations about the contact, its position, normal, penetration, etc.. I've got an array of these (in C++: dContact contacts[64]). Easy, huh ?

Hell no: typing in the debugger sizeof(dContact) returned 196, while sizeof(contacts[0])) returned 200. An offset of 4 bytes, coming from nowhere, while the two are "logically" equivalent.. how is that possible ?

Well, the thing is, it's perfectly possible. After spending a couple of hours debugging that thing, i found the cause of the problem: in another DLL, a header file was setting the pack alignment of structures to 1, then setting it back to the default, 4. Excepting that.. the default in VC is not 4, but 8 :) A stupid mistake which caused the dContact structure to be defined virtually twice: one with a pack alignment of 4 (the one included by the application, which is using the other DLL); and the one with a pack alignment of 8, included by ODE.

Cool, isn't ? I love programming.

In other news, i've received a first version of the space station Shawn is modelling. It's full of mapping errors, but as it appears correctly in 3ds max, it means i've got a serious bug in my exporter code. That's weird, too, because i've exported tons of models with that exporter before, and the texture coordinates has always looked good. More debugging to come.. sic.
Sign in to follow this  


11 Comments


Recommended Comments

Really, that bug is a very nice one!
In a nice-bug-list, it would surely be in the top-10.
Did you set the pack alignment or was it an ODE flaw?
In VC, it's possible to put the pack alignment on a stack, should be something like this:

// Store
#pragma pack( push, oldPackValue )

// Set value to 1
#pragma pack( 1 )
// Some includes etc.

// Restore
#pragma pack( pop, oldPackValue )

Share this comment


Link to comment
It was a bug in my own code (nothing to do with ODE: it was located in the TGA image loader!). NOW i am aware of that pragma stack trick.. that's how i "solved" the bug :)

Yeah, it was a pretty subtle bug. I consider myself lucky to have found it in less than 4 hours..

Share this comment


Link to comment
Hey, I just downloaded your latest video and your engine is very impressive, and i have a little question about it.

I recall reading that all the planets are created procedurally, but is it possible to "save" a planet and load it up later? I would assume that's alot of data to store.

Share this comment


Link to comment
Sir Sapo, I assume Ysaneya is using a pseudo-random number algorithm of some kind to generate the planets. This all comes from a seed value.

What this means, is that to "store" a planet, you only need to store the seed value, and if you ran it through the same code, you would get the same planet generated every time. This seed value may simply be a single integer value :D

Chaning the seed value by, say, 1, would generate a totally different planet.

Share this comment


Link to comment
Exactly (actually i'm not using a single seed, but a "descriptor" which contains many parameters and seeds). Given the same seeds you end up with the same planet, so i fail to see the interest of storing the planet data directly.

Share this comment


Link to comment
Keep up the good work, I just love this project. I know how hard this stuff can be at times. What I really hate is when I change some of my code to make one planet look better and the rest of the planets just go wacko. I have "lost" alot of my favorite locations that way.

Share this comment


Link to comment
Guest Anonymous Poster

Posted

Hey there, just a quick question not really related to the topic but ah well...

How much memory does each planet take up roughly? And how long does it take to 'generate' a planet.

For example, what kind of delay/memory usage are you looking at while generating textures etc when you 'jump' into a system with 9 planets and 37 moons such as our solar system?

Share this comment


Link to comment
I would guess that he uses some LOD algorithm to only generate and store the data he needs; instead of entirely generating all of the planets, he only loads the low detail far-out view, and only generates more data as the view moves closer to a particular planet.

I don't have the source code, of course, it just seems like no current system has the RAM to store an entire solar system at full detail, and that seems like a good way to get around that.

Share this comment


Link to comment
Guest Anonymous Poster

Posted

Lol... i can't believe i didnt think of that straight away. It occured to me after i posted and it was so obvious...

*bows head in shame and runs away*

Phew! Glad it was an anonymous post!!

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • 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!