Simple & Fast Game Engine

Pages: 12
Hello everybody,

I'm proud to present my first library: SFGE. It's been under development for a little over 2 weeks now. It's built on top of the sfml library.

Features:
- Event System
- Collision detection and response (AABB or convex shapes)
- Logging
- StateManagement
- Animated Sprites
- ResourceManager
- Menu System

The project can be found on google code: http://code.google.com/p/sfgengine/

Here's a little video about the collision detection & response in my testbed for SFGE. http://www.youtube.com/watch?v=RZbSB2M-BP0

If you have suggestions for new features I'm happy to hear them.
Constructive criticism is much appreciated :)
Are the red boxes in the demo hitboxes or something?
Yes.
Didn't have time to look into it right now, how do you handle collision response? That one's still giving me headaches (less the physical reactions than the issue of objects of different types causing different reactions, like damage, healing, starting swimming etc - I couldn't think of a good solution to that so far).
Well, for the collision response it gives the MTV (Minimum Translation Vector). It doesn't do physics, but provides you with enough information to resolve the collision. Every object that can be added to a CollisionDetector needs to derive from Collidable. Collidable has a virtual method which returns the shape and holds a std::string member variable which is returned via std::string getName();

It also has a virtual method onCollision(Collidable* obj, sf::Vector2f mtv) which can be reimplemented if you want to actually do something with the collision.
You can quickly check for the type of object you've collided with, and if necessary you can cast it to the appropriate type:
1
2
3
4
5
6
7
8
void Player::onCollision(Collidable* obj, sf::Vector2f mtv)
{
    if(obj->getName() == Monster)
    {
        Monster* monster = static_cast<Monster*>(obj);
        hp -= monster->getDamage();
    }
}
good, get to the code.
What do you mean?
Very nice. I'm always jealous when I see things like this because I feel I'll never be able to do anything like it. Great job never the less. :)
The latest revision now uses Spatial Hashing which results in a significant improvement performance-wise!

http://n1ghtly.blogspot.com/2012/05/spatial-hashing-for-improving.html
Last edited on
Wow, I can't believe you signed up just to say that :o :D

EDIT: 600!
Last edited on
That's because it was a spambot ;)
Thought so xD
But then I wondered, why would a spambot say "good job" and not some advertising crap?
spambot == spoon licker ;)
Thought so xD
But then I wondered, why would a spambot say "good job" and not some advertising crap?

They put the links in the "Homepage" field of their profile instead.
closed account (zb0S216C)
How about implementing a scene graph?

Wazzak
What's a scene graph supposed to do?

EDIT: nvm, wikipedia did it's job. (http://en.wikipedia.org/wiki/Scene_graph#Scene_graphs_in_games_and_3D_applications)

So if I understand this right I'd implement a class Node to which other nodes can be added and removed. What other functionality should I incorporate in this class?
Last edited on
closed account (zb0S216C)
There's no true definition as to what a scene graph is and how is should be implemented as it depends entirely on the project. In your case, however, I would suggest incorporating these features:

- Draw the sprite/mesh (the obvious one)
- Draw particles and/or light, ect
- Play sounds
- Update physics
- Update the frame of an animation or play the animation

As I said, there's no true definition as to how a scene graph is implemented.

Wazzak
Last edited on
I was thinking of something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
class Node
{
	public:
		Node(const std::string& name = "Node") : name(name), parent(NULL) {}
		~Node()
		{
			for(Node* node : children)
				delete node;
		}

		virtual void draw(sf::RenderWindow& window)
		{
			drawChildren(window);
		}

		virtual void update(sf::Time frameTime)
		{
			updateChildren(frameTime);
		}

		void addNode(Node* node)
		{
            node->setParent(this);
			children.push_back(node);
		}

		void removeNode(Node* node)
		{
			for(auto itr = nodes.begin(); itr != nodes.end(); itr++)
			{
				if(node == (*itr))
				{
					nodes.erase(itr);
					return;
				}
			}
		}

		Node* getParent()
		{
		    return parent;
		}

		void setParent(Node* node)
		{
		    parent = node;
		}

	protected:

		void drawChildren(sf::RenderWindow& window)
		{
			for(Node* node : children)
				node->draw(window);
		}

		void updateChildren(sf::Time frameTime)
		{
			for(Node* node : children)
				node->update(frameTime);
		}

	private:
		std::vector<Node*> children;
		Node* parent;
		std::string name;
};


Does that look OK to you?
The user should not forget to call the updateChildren and drawChildren method when they override the function though...

PS: Sorry for the messed up spacing. Notepad++ didn't convert tabs to spaces, I noticed -.-
PPS: We can later derive a PhysicsNode and more specific nodes
Last edited on
closed account (zb0S216C)
xander333 wrote:
"Does that look OK to you?"

Seems fine at a glance.

xander333 wrote:
"The user should not forget to call the updateChildren and drawChildren method when they override the function though..."

If they forget, it's their fault. The result would only be a scene that never gets updated; easily fixed. How hard can it be to invoke 2 functions?

Wazzak
If you want to ensure that children are always updated/drawn...

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class Node
{
public:
  void draw(sf::RenderWindow& window)
  {
    drawChildren(window);
    doDraw(window);
  }

  virtual void doDraw(sf::RenderWindow& window)
  {
    // overridable function
  }
};



Also, you really should use RenderTarget and not RenderWindow unless you need something specific to the window (doubtful).
Pages: 12