Just guessing: why GenerateContacts expects objects with GetObject method? Maybe simpler and much flexible solution is to pass to GenerateContacts container of Flatland::Object objects?
Surely there is reason for your solution, but I don't see it yet...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It doesn't take a container of Flatland::Object objects because a game engine (or simulation) might define classes that bundle physics with other app-specific data. For instance, a game engine might have a Sprite class like this:
class Sprite
{
Flatland::Object physics;
int left, top, right, bottom;
int textureId;
int hitPoints;
vec velocity;
// ...
};
I want to allow people to thoroughly separate their physics engine from their graphics engine. For example, the demo application defines its own object class that has a Draw() method and a GetObject() method. Flatland itself completely avoids dealing with graphics since it's physics-only.
If GenerateContacts simply took a container of Flatland objects as you suggest, then the client application would need to maintain a separate list for its physics objects. Hmm... Maybe I could simply provide both methods to allow people to do it either way.
I should at least provide comments in the code explaining this. Also I should rename GetObject to GetFlatlandObject. Unfortunately I'm too busy with my real job to work on Flatland much these days.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Woops, my sprite example has mistakes because Flatland::Object is an abstract class. Also, "velocity" is obviously already encapsulated within the "physics" member. Oh well, you get the point.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Right, separation of physics and gfx components is important but, like for me, required GetObject method is "too fixed". If we can push to GenerateContacts container of, simply, Flatland::Objects then our "visual" classes may derive directly from Flatland::Object, for example:
class VisualLine: public Flatland::Dynamic<Flatland::Line>
{
Draw();
// ...
};
I hope you can understand my pseudo-english :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No problem, I understand. This is a classic inheritence vs composition (ie, containment) problem. My method uses composition, your method uses inheritence. Rather than debating the issue, I think I should support *both* methods in the next version of Flatland. Unfortunately I don't have any time to work Flatland these days...
By the way, I chose containment rather than inheritence because I figured that I might have "drawable" objects that don't necessarily contain physical properties, and shouldn't be processed by the physics engine (eg, a background sprite).
Here are some good sites about the inheritence vs composition debate:
Anyway I think the consumer of Flatland shouldn't be forced to use containment, so I'll try to fix that in the next version. Sorry about that. In fact, I'm surprised that someone out there is actually using Flatland!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the links. You have right - both versions solves this problem completely.
About using Flatland - I'm programmer and main game desinger in small game development group from Poland. We have some published titles already and now we are working on two new projects. One of them need good 2d physics engine and, after long searching, I haven't found nothing better than Flatland...
One more question - do you really plan to drop completely ODE dependency? It will be great to have "pure" 2d optimized engine rather than ODE wrapper...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>I'm programmer and main game desinger in small game development group from Poland
Cool! That sounds like fun, I'm jealous.
>do you really plan to drop completely ODE dependency
If I ever have time to return to Flatland, that's definitely one of the things I want to do. Unfortunately I'm too busy with my "real" job at 3Dlabs.
Flatland is really just a toy right now -- I'm not sure if it can be used when writing real games. There's lots of stuff missing. Like you said, it's really nothing more than an ODE wrapper, except for the intersection routines, which I wrote expressly for 2D.
Anyway I wish you luck!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just guessing: why GenerateContacts expects objects with GetObject method? Maybe simpler and much flexible solution is to pass to GenerateContacts container of Flatland::Object objects?
Surely there is reason for your solution, but I don't see it yet...
It doesn't take a container of Flatland::Object objects because a game engine (or simulation) might define classes that bundle physics with other app-specific data. For instance, a game engine might have a Sprite class like this:
class Sprite
{
Flatland::Object physics;
int left, top, right, bottom;
int textureId;
int hitPoints;
vec velocity;
// ...
};
I want to allow people to thoroughly separate their physics engine from their graphics engine. For example, the demo application defines its own object class that has a Draw() method and a GetObject() method. Flatland itself completely avoids dealing with graphics since it's physics-only.
If GenerateContacts simply took a container of Flatland objects as you suggest, then the client application would need to maintain a separate list for its physics objects. Hmm... Maybe I could simply provide both methods to allow people to do it either way.
I should at least provide comments in the code explaining this. Also I should rename GetObject to GetFlatlandObject. Unfortunately I'm too busy with my real job to work on Flatland much these days.
Woops, my sprite example has mistakes because Flatland::Object is an abstract class. Also, "velocity" is obviously already encapsulated within the "physics" member. Oh well, you get the point.
Right, separation of physics and gfx components is important but, like for me, required GetObject method is "too fixed". If we can push to GenerateContacts container of, simply, Flatland::Objects then our "visual" classes may derive directly from Flatland::Object, for example:
class VisualLine: public Flatland::Dynamic<Flatland::Line>
{
Draw();
// ...
};
I hope you can understand my pseudo-english :)
No problem, I understand. This is a classic inheritence vs composition (ie, containment) problem. My method uses composition, your method uses inheritence. Rather than debating the issue, I think I should support *both* methods in the next version of Flatland. Unfortunately I don't have any time to work Flatland these days...
By the way, I chose containment rather than inheritence because I figured that I might have "drawable" objects that don't necessarily contain physical properties, and shouldn't be processed by the physics engine (eg, a background sprite).
Here are some good sites about the inheritence vs composition debate:
http://www.gotw.ca/publications/mill06.htm
http://www.object-arts.com/EducationCentre/Patterns/InheritanceVsComposition.htm
Anyway I think the consumer of Flatland shouldn't be forced to use containment, so I'll try to fix that in the next version. Sorry about that. In fact, I'm surprised that someone out there is actually using Flatland!
Thanks for the links. You have right - both versions solves this problem completely.
About using Flatland - I'm programmer and main game desinger in small game development group from Poland. We have some published titles already and now we are working on two new projects. One of them need good 2d physics engine and, after long searching, I haven't found nothing better than Flatland...
One more question - do you really plan to drop completely ODE dependency? It will be great to have "pure" 2d optimized engine rather than ODE wrapper...
>I'm programmer and main game desinger in small game development group from Poland
Cool! That sounds like fun, I'm jealous.
>do you really plan to drop completely ODE dependency
If I ever have time to return to Flatland, that's definitely one of the things I want to do. Unfortunately I'm too busy with my "real" job at 3Dlabs.
Flatland is really just a toy right now -- I'm not sure if it can be used when writing real games. There's lots of stuff missing. Like you said, it's really nothing more than an ODE wrapper, except for the intersection routines, which I wrote expressly for 2D.
Anyway I wish you luck!