Wohoo!
10 lines of code changed = splitscreen :) (Up to 4 cameras will be supported by the engine)
Showing posts with label 2D. Show all posts
Showing posts with label 2D. Show all posts
Monday, January 23, 2012
Saturday, January 21, 2012
Generic 2D collision system.
Today I want to explain the system I use in my engine for collision detection.
I tried to keep the collision system as generic as possible.
My engine provides a class called "CollisionComponent". You can add one or more components to a game objects to make them collidable. (Collision detection is done via collision rectangles).
To make the collision handling as generic as possible I decided to realize the handling "response" (the point where it'll get decided what to do with the collided objects) with function pointers.
You can "subscribe" gameobjects via typename (String) or a specific id (int) and with a pointer to a function that receives two pointer to game objects(first is the object that did "the impact" and the second is the object that got hit) and returns void.
Here's a little code snippet to make it more clear how that works:
The difference between subscription via type and id is that multiple game object can have the same type (for very generic collision handling like "bullet hits player" or "weapon hits enemy").If you want to make more specific collision handling you can use the subscribe function that uses ids because the ids of the objects are unique.
The only problem is that each tick each game object gets checked with every other game object.
That's not very performant, but I don't know how to do it better, yet.
I tried to keep the collision system as generic as possible.
My engine provides a class called "CollisionComponent". You can add one or more components to a game objects to make them collidable. (Collision detection is done via collision rectangles).
To make the collision handling as generic as possible I decided to realize the handling "response" (the point where it'll get decided what to do with the collided objects) with function pointers.
You can "subscribe" gameobjects via typename (String) or a specific id (int) and with a pointer to a function that receives two pointer to game objects(first is the object that did "the impact" and the second is the object that got hit) and returns void.
Here's a little code snippet to make it more clear how that works:
void collision_handler(GameObject *object1,GameObject *object2) {//...Do fancy stuff here} int main() { GameObject object1("Type1"); GameObject object2("Type2");//... //...CollisionComponent *collComp = new CollisionComponent(); CollisionComponent *collComp2 = new CollisionComponent(); object1.addComponent(collComp); object2.addComponent(collComp2);//.. //subscription with typeCollisionManager::subscribe(object1.getType(),object2.getType(),collision_handler);//.. //subscription with idCollisionManager::subscribe(object1.getID(),object2.getID(),collision_handler);//..}
The difference between subscription via type and id is that multiple game object can have the same type (for very generic collision handling like "bullet hits player" or "weapon hits enemy").If you want to make more specific collision handling you can use the subscribe function that uses ids because the ids of the objects are unique.
The only problem is that each tick each game object gets checked with every other game object.
That's not very performant, but I don't know how to do it better, yet.
Monday, June 27, 2011
Particle implementation.
Hi internet!
I've just successfully finished my oral exam (damn that sounds dirty).
So my time as an apprentice is officially over, which means I have more time now to focus on my 2D engine.
In this post I want to show you how I implemented the particle system in my engine using the decorator pattern.
First some UML:
As you might see here I decided to derive the particle emitter into a finite and an infinite subclass. The finite emitter stopps after it spawned n particle (determined by the setParticleAmount() method) whereas the infinite emitter runs as long as isStarted() return true.
The most difficult thing was to cover all the things a particle system must do (e.g. transparency, spreading, collision detection, etc.).
To provide all those contingencies I decided to use the decorator pattern (I just read the book Head First Design Patterns (a really good book), so all that stuff was still in my mind ;) ).
The particle system runs pretty well, although some of the subsystems (especially the transparency) don't work as expected yet.
I've just successfully finished my oral exam (damn that sounds dirty).
So my time as an apprentice is officially over, which means I have more time now to focus on my 2D engine.
In this post I want to show you how I implemented the particle system in my engine using the decorator pattern.
First some UML:
As you might see here I decided to derive the particle emitter into a finite and an infinite subclass. The finite emitter stopps after it spawned n particle (determined by the setParticleAmount() method) whereas the infinite emitter runs as long as isStarted() return true.The most difficult thing was to cover all the things a particle system must do (e.g. transparency, spreading, collision detection, etc.).
To provide all those contingencies I decided to use the decorator pattern (I just read the book Head First Design Patterns (a really good book), so all that stuff was still in my mind ;) ).
The particle system runs pretty well, although some of the subsystems (especially the transparency) don't work as expected yet.
Thursday, March 10, 2011
New video of the current state (finally!)
I finally managed it to create and upload a new video of the current state of the leveleditor. As you can see, I added several new features like the toolbar (on the left - with the ugly icons ;) ), multilayer drawing, event creation and several other things.
I once again recommend to watch it in fullscreen.
I once again recommend to watch it in fullscreen.
Subscribe to:
Posts (Atom)
