Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Rexou

Pages: [1]
SFML projects / Re: Feather Kit - A C++ Game Framework
« on: March 06, 2014, 10:09:11 am »
Yeah there are a lot of ECS terminology/architecture/implementation hehe

What i mean is that you've put the behavior & data in the components and i wanted to know if that was originally intended and if something prevented you from decoupling data (into components) and behavior (in systems) and let the different Systems/Controllers iterate over the entities it's interested in (using bitmasks or keepEntity()-like fonctions to check if it has the right components like you did).

That's just a bit of curiosity on constraints encountered while implementing something like that, I have done a very simple one for learning purpose but never tried to layout the underlying type in order to avoid cache misses and optimize the performances. Your implementation seems to be very flexible and that's why I am very curious about the difficulties/choices happening during the development.

Maybe i am a little bit off-topic just let me know if that's the case,

EDIT : Nevermind, just saw your post on your blog explaining this part !

SFML projects / Re: Feather Kit - A C++ Game Framework
« on: March 05, 2014, 02:07:00 pm »
Hi there,

Again, nice work on the entity system ! The API seems very intuitive to me now especially on the entities template.

I was wondering : Is there a specific reason not to have Systems in your framework ? I mean is that only a design choice to put the behavior in components or are there any constraint that forced you towards that architecture ?

Ty for the sample about entities and keep up the good work.

SFML projects / Re: Feather Kit - A C++ Game Framework
« on: January 29, 2014, 03:48:24 pm »
Interesting to see a macro to define message types, that is clever. Maybe I could incorporate such a message creation macro in the actual framework haha.

Actually I didn't even know we could create empty std::tuples before that macro (it would be impossible to use this macro for messages without parameters) I just wanted to test my memory about preprocessor tricks
but im glad if i can contribute !

Regarding your sample, if it is done like that it would be not fun to maintain indeed. But it seems to me like you are mixing two techniques. Messaging and callbacks. Whenever I have used the messaging system, I don't use it to call callbacks, but I let the final object that is meant to react to the message actually receive the message. So in your example, I would skip the callbacks all together and just have the prints in the handleMessage functions.

Yep, it seems to be the legit way to handle messages and after reflexion about this, it could probably be done by splitting these handleMessages functions into subfunctions, you're right there is no need for callbacks there !

Here is an example on how I have used the messagebus to subscribe to many messages (sorry if the code is messy, it was written during a game jam haha):

Ok so it's also registration through inheritance and one function per message type, I don't think we can do better if we want to keep compile-time dispatching.

But yeah, I'll definitely consider providing some macros for the message typing you have to do. It seems really potentially handy!

Not sure if that answers your question, feel free to ask more if you need more clarifications. :)

No more questions for now, I'll keep reading the sources during my free time, thanks for the answers !

SFML projects / Re: Feather Kit - A C++ Game Framework
« on: January 29, 2014, 01:15:49 pm »
Hi there, i've been reading this topic since its creation but haven't been able to give your framework a real try like i wished i could but i wanted to say that what i saw in the sources seems to be very useful, well organized and cool. Well done !

I've already tried the messaging part and looked at the examples for the basics but I can't wait to see tutorials on your entity system / Emscripten / other advanced parts.

I wanted to ask how would you do a class listening to several events/messages using your API ? I have created a working example but it's obviously not fun to maintain if we're listening for more than a dozen of messages.

Here's the code of my sample http://codepad.org/anuJSWAQ
Basically just a macro helping me to create the different structures & typedefs for the Message tag/data in Event.hpp and a HeroPet class containing 2 vectors<std::function>> filled in the ctor (one for each Message type). In the handleMessages functions i iterate over the two callback_vectors to call the associated functions and that's pretty much it.

I am not in a hurry so take your time it's ok if i have to wait for the documentation to be completed hehe.

Keep it up  ;) !

SFML projects / Re: Looking for a newby partner(s)
« on: July 13, 2012, 10:13:27 am »
Hi there,

I've got to say that it's kinda a great idea, if the opportunity is still available i'd like to join you guys.
You talked about several tools im currently using on my spare time/work :

- Github / git
- Irc

I started learning C++ about 2 years ago so i'm not a rookie but there are so many things to learn and joining a team will help me in my future projects' management.

Little Question : Is there a motivation/project idea behind this team ? I mean we could think about a bigger project if things keep going well.

I went on the irc channel but there were nobody on it, anyway, Please drop me a pm if it's possible
Regards, Rexou.

SFML projects / Re: SFGUI
« on: June 12, 2012, 03:35:07 pm »
Hi guys,

How do you load a *.theme file? I noticed the entire GUI looks Steam by default  ::)

After reading the documentation and the samples, i guess it would be something like this :


Btw, i was wondering, have you got any idea about the release date of the new engine ? BREW is efficient but i had like to customize the differents widgets with images.

You're doing a great and useful job guys, keep it up :)

Pages: [1]