Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


buggypixels

Member Since 16 Mar 2010
Offline Last Active Today, 02:17 AM

Posts I've Made

In Topic: The "action" systems that 2D game frameworks all now have...

Yesterday, 02:37 AM

It is interesting to see that most frameworks will force you to use a pattern that you should clearly avoid. We all have learned that

having something like GameObjects and call an update method in every object is bad due to cache misses and so on. This is the gap

that actually ECS tries to eliminate. So in general it is bad practice to do it like Cocos2d.

On the other hand how would you do it when you are such a framework designer? This is the only currently somehow accepted solution.

Since there still is no common vision how a ECS should be designed and there are many different solutions out there it is safe to

fall back to such an approach. But still it is bad design.


In Topic: [C++] Looking for feedback on my event system

13 September 2011 - 02:25 AM

I have recently reworked by event system completely and it now looks totally different.
First of all I did the same design flaw that you can find in many solutions. There is something like
void fireEvent(EventData* evn) {
   foreach ( Listener l : listeners ) {
    onEvent(evn);
  }
}

First using a raw pointer here is awfull. But the major problem is that every event will be processed immediately when they are fired.
This leads to unpredictable circumstances in your code. You actually never know WHEN an event will be fired and therefore you cannot
know the states of your objects.
So what I did was to buffer the events and then at a certain point in my engine (right after the big update loop) I process ALL events and
send them to the listeners.
Also in my opinion using a base class for an event is awfull. An event contains only data. You are just sending plain data around.
So I removed this completely and just using structs. This makes the code much leaner and cleaner.
The entire solution now looks completely different.
I got the idea after reading this:
http://bitsquid.blogspot.com/2011/02/managing-decoupling-part-2-polling.html
It took me quite a while to finally get it and then it just hit me how awfully right the author is.

Actually I now have a buffer where I store the events like:
[header1][event data][header2][event data2]
The header is a simple struct:

struct Header {
    uint32 index;
    uint32 id;
    size_t size;
};  

The ID is the actual ID of the event and the size is the size of the event data struct. The index is the actual index in my buffer.
The entire buffer is sent to any listener and the listener can grab any data he likes from the buffer like:
size_t get(void* p, size_t size,uint32 index);

Example:
Here is the event data when the ship is hit by a projectile:
struct ShipHit {
  Vec2 pos;
  int damage;
  int rocketType;
}

Now I fire the event:
ShipHit sh;
sh.pos = Vec2(100,100);
sh.rocketType = 1;
sh.damage = 100;
evnetManager->fireEvent(100,&sh,sizeof(sh);

In the listener I do something like:
// check if we have a ship hit event in the buffer
if ( buffer.containsID(100) ) {
  // yes so grab the data
 ShipHit sh;
 buffer.get(100,&sh,sizeof(sh));
}


I hope I could actually shed some light on my approach. It is actually not easy and I am not sure I could get the point across.
Just ask if you have any questions.

In Topic: String IDs for objects, events etc.

21 March 2011 - 07:00 AM

You might take a look here: http://gamesfromwithin.com/managing-data-relationships.
Since your example is about resource management this might fit perfectly.
Overall using strings and std::map is not the best solution here.
If you still need to support strings (better to say to support name lookups) you can easily
extend the system described above to include a name/handler mapping.

In Topic: DX9: Generic VertexBuffer using template

19 January 2011 - 05:48 AM

I've one concern with your implementation, though: You're fixed to 16-bit indices. I'm not very much C++, but you could probably just use a second type parameter for your template ;)


You are right. Right now I only need 16-bit indices in my engine. But it should be straight forward to use the index type as second template type.

My next step is to support subsets within the vertex buffer. Basically the same as you have when using the IDXMesh object. So I can activate or deactivate certain subsets
and do not take care of rendering any particular subset individually. Someone might argue that I could use the said IDXMesh. But hey, I am doing it for the fun of it.

As you can see that actual part of setting textures/shaders/materials are not part of the vertex buffer since the engine during the render stages takes care of this already.
So probably this is not as generic as it could be. I just wanted to share the idea of using a template here.



In Topic: DX9: Generic VertexBuffer using template

18 January 2011 - 02:16 PM

I have posted the code along with some short explanations at my webset buggypixels.com
Hope you find it interesting.

PARTNERS