Reply to topic

Item collision

User avatar dpalacio
Registered Member
Posts
237
Karma
2
OS

Item collision

Sun Oct 25, 2009 2:25 pm
I welcome the new design for integration with Box2D, making separate Physics classes. But in the process collision detection was lost for the not physics classes. Maybe some Box2D algorithms could be used to provide this feature.

Of course, there is no need for KGLEngine to check collision between all items. It should be done manually by the developer.


// Debian Sid amd64 KDE 4.6.5.
// Debian Squeeze i386. KDE 4.4.5.
connect(post,SIGNAL(readSignature()),qapp,SLOT(quit()));
User avatar dpalacio
Registered Member
Posts
237
Karma
2
OS

Re: Item collision

Wed Oct 28, 2009 7:54 pm
Anyone?

I think that having a virtual method for this in KGLItem or KGLBaseItem is a better design than using external helpers.


// Debian Sid amd64 KDE 4.6.5.
// Debian Squeeze i386. KDE 4.4.5.
connect(post,SIGNAL(readSignature()),qapp,SLOT(quit()));
ahiemstra
Moderator
Posts
6
Karma
0
OS

Re: Item collision

Wed Oct 28, 2009 8:12 pm
The plan is actually to completely separate the two, so that we can create a Sprite Render Component and a Collision Component, which do not depend on eachother. This will allow us to swap these things around and not have them depend on eachother, so you can have a KGL rendered game with ODE collision components or a 3D-rendered game with Box2D collisions.
User avatar dpalacio
Registered Member
Posts
237
Karma
2
OS

Re: Item collision

Wed Nov 04, 2009 2:10 pm
Thanks. It seems interesting that kind of flexible design. I'll have to rethink my solution.


// Debian Sid amd64 KDE 4.6.5.
// Debian Squeeze i386. KDE 4.4.5.
connect(post,SIGNAL(readSignature()),qapp,SLOT(quit()));

 
Reply to topic

Bookmarks



Who is online

Registered users: Baidu [Spider], Bing [Bot], claydoh, farid, Google [Bot], jacksong, joebuckley, koffeinfriedhof, Moldmaker, Section_8, Sogou [Bot], zfazylz