Fission - A simple, object-component based game engine

[foobarbaz]

.

[Tank]

GUI with SFGUI (works great - thanks, Tank!)

You're welcome, but don't forget the other contributors.

Speaking of myself, I often miss screenshots and/or videos from project announcements. Can't you provide some?

[binary1248]

Bah... this means I still have a reason to work on SFGUI -_-

jk Nice job, it's always a good feeling to see the library put to good use

[Tank]

Nice, that project actually looks like you are working on it for quite a long time. I'm not a fan of the graphics style, but that's just eyecandy.

Oh btw, are you accepting shirts?

[foobarbaz]

Nice, that project actually looks like you are working on it for quite a long time. I'm not a fan of the graphics style, but that's just eyecandy.

Well, this is actually a rewrite, so up to this point I've known exactly where to go next. Last semester, I worked on this game for like 2 months and ended up giving after I couldn't resolve the lag issues. But now all is well! Also, having Fission always helps - last semester the game had it's own game engine. I did have Fission last semester, but I felt like the game deserved its own game engine. It doesn't. Haha.

You can take the art up with my roommate

Oh btw, are you accepting shirts?

Ehh. It's hot here in Hawaii.

Bah... this means I still have a reason to work on SFGUI -_-

jk Nice job, it's always a good feeling to see the library put to good use

Haha, thanks! I am putting it to very good use. I hate GUI programming so, so much. But SFGUI is like my ibuprofen

[Lo-X]

Hell Yeah !

I'll definitely follow that github page, perhaps fork it if I think I can add something =)

A BIIIIGGG thank you !

[ZackTheHuman]

Get it here: https://github.com/DrSuperSocks/Fission

This is cool; thanks for posting it. I'm poking through the code now.

I think there may be a problem in your example client/server files: https://github.com/DrSuperSocks/Fission/blob/master/mainClient.cpp#L16

int main()
{
    Game *game = new Game(800, 600);
    game->run(new GameState(game));    // where do I get deleted?
    delete game;

    return 0;
}

It looks like a memory leak -- how does the "new GameState" get deleted?

[Nexus]

In general, don't use raw new and delete. Rather use RAII.

[foobarbaz]

States are deleted when they are popped from the state stack. So, you could have a main menu state, then push a game state. Then when the game state is popped, it will be deleted and you will return to the main menu. You were right though, there was a scenario in which the state wouldn't be deleted, but I just uploaded the fix

[eXpl0it3r]

Have read the posts Nexus linked?
It doesn't really matter whether you think you've covered it all or not, because it's near impossible to cover ecerything (see link above).
With a std::unique_ptr around every state you're guaranteed, that it will get destroyed when it runs out of scope, no matter what.

[FRex]

Because memory management using new and delete is what all the cool kids do.
I knew this thread was gonna end like this after I've seen the code on github using bare news and deletes.

[foobarbaz]

I glanced at it and will probably implement the smart pointers soon, but it's not an urgent issue as it's not a professional game engine If it turns out that a ridiculous amount of people want to use it maybe I will take my memory management more seriously haha.

Thanks for the suggestions though, I will definitely get around to implementing it, as I do plan on releasing my current project on Desura, and hopefully it'll be good enough where I can sell it for at least a buck

[Nexus]

Note that using RAII is much simpler than manual memory management, so you spend less time on it, make fewer errors and thus develop faster

I have taken a closer look at your code, here are some more tipps:

• Use constructor initializer lists instead of assignments.
• To iterate over a sequence, prefer iterators over indices. It allows more flexibility to choose another container, and may be faster.
• Pass big objects like std::string per const-reference.
  
• Combining new[] with delete is undefined behavior (Scene.cpp). Use std::vector instead.
  
• Use the fixed-size types like sf::Int32 when working with packets. It is not guaranteed that int has the same size everywhere.
  
• Replace C casts with the C++ cast operators (mainly static_cast, const_cast, reinterpret_cast).
  
• For indices, take std::size_t instead of int or unsigned int, this avoids also conversion warnings. Or at least be consistent.
  
• Declare member functions that do not change the object (i.e. all getters) as const.
  
• By not making all the managers to singletons, you allow other uses. I don't see why they need to be a singleton, the alleged convenience has many disadvantages, which are not necessary with a clean design.
• You can reduce compile time if you do not include <SFML/Graphics.hpp>, but specific headers.
  
• I recommend to make member variables private instead of protected. Derived classes should have access via public/protected member functions.
• You don't need to re-declare the virtual destructor in every class, it is inherited.

[ZackTheHuman]

I knew this thread was gonna end like this after I've seen the code on github using bare news and deletes.

I didn't mean to derail the thread -- it's just that the files containing the most basic example of how to use the OP's code have unclear object ownership, which makes me worry about any other part of the code.

...maybe I will take my memory management more seriously haha.

I am in favor of this idea. If you want other people to use your code (and it's awesome that you do!) then you have to work hard at making it clear how it works.

I think there is a lot of cool stuff in Fission, and I'm still going through it to see how it works. Thanks again for sharing with us.

[FRex]

I knew this thread was gonna end like this after I've seen the code on github using bare news and deletes.

I didn't mean to derail the thread -- it's just that the files containing the most basic example of how to use the OP's code have unclear object ownership, which makes me worry about any other part of the code.

You didn't , in presence of Nexus any post that is traceable to manual memory management(and especially bugs in it) is derailed by definition.