SFML community forums

General => SFML projects => Topic started by: Lolilolight on December 06, 2013, 10:26:57 pm

Title: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on December 06, 2013, 10:26:57 pm
A small presentation

Hi, for those who don't know me.

I'm Laurent Duroisin, I'm Belgian so sorry if my English isn' always at his top level.
I've a master in computer sciences and I've already cotribuated at some opensource games developpement.
Everytime I try hard to get a job but without any success since the 2 last years so I decide to continue to developp my own project that I launched some years ago. (A framework for my own game, and, I hope so to create my own company and have success, it seems at the moment I've not the chooise anyway. (Even if I find a job I'll continue this project as a passion.)

ODFAEG and Sorrok presentation.

ODFAEG is a framework based on my first rpg project in 3D iso. (Sorrok)
http://fr.sfml-dev.org/forums/index.php?topic=12616.0 (http://fr.sfml-dev.org/forums/index.php?topic=12616.0)

But rather than work on the gameplay of Sorrok and let the framework in a garbage.

I decided to share the framework.

The main purpose of the framework is to build an opensource library who'll be used by the most of games developpers as possible, to have people's returns and to build the simpliest and fastest game framework.

The creation of multiplayers games and of full 3D games  will be also possible in the next versions.

For the moment, an entity system is implemented and I've just begun to write a 3D support with SFML.

But actually we are working hard to launch the first version of the framework.

But I think over 1 mounth we'll be able to launch the first release. (Just the time to create the documentation and tutorials)

The main interests of the framework are :

-The use of the framework is not limited to 2D/3D or a particular kind of game, you'll be able to create any games as you want in a simple way, even small games who don't needs to have an entity system. (You can also draw sfml objects with the framework, but I think SFML only can do the trick then, I don't have plan of implementing the support of other's libraries like SDL, Ogre, Irrlicht, etc...)

-The framework allows the developpers to create the entity manager, and all the entities that he wants, he's not forced to use the entities or the entity manager provided by the framework. (The entity system are like the Qt widgets, they are components who can contains other entities and it'll be the same for the entity managers who'll manage collisions, the storage and the generation of any kind of entities in the world of the game. (lights, shadows, etc...)
But if you want to do your custom Entities and entity managers, you'll have to inherits from some classes and to redefines some members fonctions. (The entity class for entities of the framework by example)

-With the state system, the user'll be able to set the game in pause, this feature is not implemented in many rpg's or mmorpg, and often, you must disconnect of the game if you have to do a break (a phone call or something like that), it's very embarassing.

-The framework'll always using cutting edge tehnologies like the new c++11 feature to provide a framework who'll stay alive in time, so, you don't have to worry about the framework compatibility and maintenance.

If you want to contribuate at the projet, giving your advices or improve it, you can find the source code on githhub by searching and dowloading the repository.

The repository name is ODFAEG. :)

You can also visit my devblog if you want to have more news about the project advancement.

http://laurentduroisin.wordpress.com/ (http://laurentduroisin.wordpress.com/)

PS : it's my first project and I want to create my own game developpement company so, I hope that the project'll become great!
Title: AW: SFGL (Simple and fast game library)
Post by: eXpl0it3r on December 07, 2013, 09:25:14 am
Seems like you didn't get a lot of attention oved at the French forum. ;)

The screenshots thers look quite nice!

For a first game the goal is quite ambitious and I wish you all the best. Usually it's better to start small, so one can learn all the details of game development in a smaller and more controllable way.
I also hope that you're focusing on making the game itself and not trying to make an all general engine first, because that way you'll most likely fail. Writting a general engine is hard and making it in a good fashion is even harder, especially if the experience is missing. See the famous article Write Games, Not ENGINES (http://scientificninja.com/blog/write-games-not-engines). ;)
Title: Re: SFGL (Simple and fast game library)
Post by: Lolilolight on December 07, 2013, 10:06:26 am
Hi, it seems I forgot to explain some things.

-I've a master in computer sciences.
-I've already developped a lot of small games, and I even contribuated to developp big 3D or 2D opensource games (like holyspirit, yildiz, etc...) but, I was quite disappointed of the complexity of some engines used by the developper and also of the source code of these projects who was too draft. (Even if the game was running well)

So, i'm not so new, it's just the first project when I'm the author. ^^

It's why I decided to create my own engine who is based on the SFML book. ^^

So don't worry.

I think I'll update the topic with a brief presentation of me.

I'm sure when I'll launch the first version, I'll get a lot of attention.
Title: AW: Re: SFGL (Simple and fast game library)
Post by: eXpl0it3r on December 07, 2013, 10:47:14 am
Yeah I thought you knew already a few things more, but given the pattern where everyone wants to ths most awesome game anx thus develops the most awesome and as general as possible engine, I tend to be careful. ;)

-I've already developped a lot of small games, and I even contribuated to developp big 3D or 2D opensource games
Well technically it's not your first game then. ;)

-I've a master in computer sciences.
To be honest that doesn't say anything about programming skills nor experience, actually it even often goes in the other direction. But maybe your university is one of the few that actually teach good and practical programming stuff and doesn't just hammer through theory, so who am I to judge? You'll certainly have a better understanding of certain aspects. ;)
Title: Re: SFJL (Simple and fast joke library)
Post by: G. on December 07, 2013, 11:09:19 am
I even contribuated to developp big 3D or 2D opensource games (like holyspirit, yildiz, etc...)
And they don't seem very happy about what you did back then on those projects. (thankfully, very little)
The most hilarious part was when you kept telling everyone that the project leader of holyspirit was jealous of you.  :D (and when you were convinced that League Of Legends is absolutely not a 3D game) (and when you faked being invited to some video game festival to show your not even delopped game)
Title: Re: SFGL (Simple and fast game library)
Post by: Lolilolight on December 07, 2013, 11:44:54 am
Yes you're right eXploit3r, at my university they didn't teach us only a lot of theory but also programming methods, UML, structurogrammes, etc...

@ G. yes you're maybe right but :

-I was influenced by the ex co-foundator of the sorrok projet. (The famous project detractor)
-And anyway the past is the past then I don't want to reset that on the table.

Then don't pollute the topic please or I'll just ignore you and if you've some things to regle with me, do it by mp.

I'm sorry but lol is not a fully 3D game.



Title: Re: SFGL (Simple and fast game library)
Post by: Lolilolight on January 08, 2014, 11:23:10 am
The first version'll be released soon (in February or March probably), I just to have to do some tests and some example, purge the code a bit and genrate a the documentation with comments, I"ve just begun to write the tutorials. (See the French forum)
I'll write an English tutoriel later.

But don't forget that you can check the source code on github if your are impatient. ^^

https://github.com/Lolilolight/SFGL (https://github.com/Lolilolight/SFGL)

I don't think I'll have the time to build my own website now (because I've to adapt the source code of the framework with the Sorrok project too), thus I'll build some tutorials on a tempory website to don't wasting time.

I'll set all the links here to the source code and the tutorials.
Title: Re: SFGL (Simple and fast game library)
Post by: Nexus on January 08, 2014, 01:37:06 pm
Do you really not want to choose a more original name than SFGL, which is essentially a cheap SFML rip-off? It will only create confusion and people may accidentally associate it with SFML. Why don't you create a unique name that represents the philosophy behind your library?
Title: Re: SFGL (Simple and fast game library)
Post by: Lolilolight on January 08, 2014, 05:33:24 pm
Yes I have to change the name because the philosophy is not the same than SFML.

The philosophy of SFML is : We create a simple and fast multimedia library but not more, it's you who must modify and adapt the libary to create your own game.

SFGL is a framework, then, the philosophy is very different and the source code have to change a lot to be directly usable by a wide range of games developpers.

I think I'll change the name and call it GSAF) Game specific adapted framework, we can even propose and vote for a name if you want. :)

Title: Re: SFGL (Simple and fast game library)
Post by: Grimshaw on January 08, 2014, 07:00:09 pm
I don't even want to comment on this topic or enter a flame war, but:

League of Legends is a pure 3D game. It is a 3D game as much as anything that comes out of the Unreal, CryEngine, Unity, you name it.. :)
Title: Re: SFGL (Simple and fast game library)
Post by: Lolilolight on January 09, 2014, 09:34:17 am
There's a missunderstanding between us I think, because, a 3D game for me is not a game who use a 3D engine but a game where you can rotate the camera to see the objects from every angles. (Like wow or rift)

Well, the name of the framework'll change, I found a good name who represent really better the philosophy of the framework : ODEGAF (Opensource Developpement for Every Games Adapted framework)
Title: Re: SFGL (Simple and fast game library)
Post by: eXpl0it3r on January 09, 2014, 10:23:47 am
I don't think there's a clear definition of "3D Game".

A great example would be Age of Empires II vs Age of Empires III. While both are set to simulate a 3D environment, I wouldn't call Age of Empires II a 3D game, because it uses flat sprites for everything, the fact that the sprites might have been generated from 3D models before getting into the game doesn't matter. However Age of Empires III use full 3D models in-game, thus making it a 3D game, even though the isometric "look" is being kept in most situations.
Could one now say a game is a 3D game as soon as it uses 3D models in-game? Kind of but then you'll run into games with pre-rendered 3D scenes, where you're essentially in a 3D environment like in any first person shooter, except you only get full 360° sphere to look at and can move from certain locations to others. Such techniques can be found in the Myst games. For me they sure are 3D games, even though the environment doesn't use 3D models, but instead has pre-rendered scenes you can navigate from one to the next and it will give you the feeling of "being" in a three dimensional world.
But if we define 3D games based on the simulation of a 3D environment, we'd have a problem with Age of Empires II again, since that is certainly a simulation of a 3D environment.

Further more I think whether the view is locked at a certain position/angle doesn't matter. Regardless whether your body in the real world was locked into only moving left and right or up and down, you'd still be in an 3D environment. Your movement is limited to a 2D space, but it won't turn the whole world into a 2D world.

Thus I think there's no clear definition of "3D Game", personally however I'd call games that render 3D models in real-time "3D Games" and thus LoL is most certainly a 3D game. The whole terrain is based on 3D models, all the characters are 3D models, etc. - i.e. you can't make a LoL clone just with simple and flat 2D sprites and still get the same effect. If you had a debug version of LoL I'm sure you could use a debug camera to freely move around in the 3D environment.

But again, as we've seen it's hard to make a clear definition and everyone values certain aspects more than others. I respect others opinions, even if for me their view is rather illogical. :)

BUT back to the topic!

You might want to edit the original title with the new name.
Also you might want to think about the title a bit more, because currently it's a bit bumpy and contains some mistakes: OpenSource Development for Every Games Adapted Framework

Maybe something more into the direction: Open Source Development Framework Adapted for Every Game?
It at least is a lot easier to understand. ;D
Title: Re: [ODFAE] (Open Source Developpement Framework Adapted for Every Game)
Post by: Lolilolight on January 09, 2014, 01:17:10 pm
Ok, title updated.  :)
Title: Re: [ODFAE] (Open Source Developpement Framework Adapted for Every Game)
Post by: Nexus on January 09, 2014, 01:33:08 pm
Just a little hint: Other than in French, in English it's written "Development" ;)
Title: Re: [ODFAE] (Open Source Developpement Framework Adapted for Every Game)
Post by: Grimshaw on January 09, 2014, 02:05:33 pm
I disagree a little bit on the "There is no clear definition of 3D game".. At least in my opinion, a game which uses 3D assets to represent most of its world its a 3D game, but more importantly, a game who projects its geometry into perspective is even more a 3D game. That's the crucial part I guess.

For example, league of legends is a full 3D game, everything about it is made in regular 3D code and assets, so there is no room for guessing and having opinions on this, it is as 3D as any FPS shooter or any other 3D game, but has a constrained camera, for the RTS perspective they wanted to achieve. There are mods for that game which make it work with 3rd person cameras and make it as any other game camera-wise.

Another great example is Trine I think, its a classical platformer, made in full 3D, and it doesnt cease to be so just because you can only see from the side at all times.

And now I notice I spent all my budget for 2014 for using the word "3D" and I will shut up. Ups, I said it again!
Title: Re: [ODFAE] (Open Source Developpement Framework Adapted for Every Game)
Post by: eXpl0it3r on January 09, 2014, 02:15:09 pm
I disagree a little bit on the "There is no clear definition of 3D game".. At least in my opinion, a game which uses 3D assets to represent most of its world its a 3D game, but more importantly, a game who projects its geometry into perspective is even more a 3D game. That's the crucial part I guess.
Well then you didn't fully get my argument. Relying only on "3D assets" doesn't work, because of games like Myth, that use pre-rendered scenes and thus no 3D assets in the end. Or if you mean 3D assets in development, then most of the modern 2D games are 3D games as well, because many sprites you see, will be rendered from 3D models.
If you'd want to go with "projects its geometry into perspective" you'd still have problems with games that give you the illusion of 3D, while not having much to do with 3D (e.g. most isometric games, including Age of Empires II).

On the other hand I should've made it clear, that games using 3D assets are of course 3D games.

Then again 2D is a subset of 3D, so all 2D games are essentially also 3D games, just without making use of one dimension, j/k. :D
Title: Re: [ODFAE] (Open Source Developpement Framework Adapted for Every Game)
Post by: Grimshaw on January 09, 2014, 02:47:51 pm
I see what you mean, but I meant displaying 3D geometry on runtime in particular, as pre rendered graphics are still sprites for all means.

And when I talked about projection, I was referring directly to projection matrices and their use in the ingame cameras. A 2.5D game as they call it, that looks 3D but really isn't, is usually a orthogonal projection with sprites for geometry, while other games actually "fake" that same look but use actual 3D projection matrices with 3D geometry.

In sum, what I am trying to say is that it doesn't matter what it looks to the consumer. What matters is what math is being performed internally and how the geometry is represented :D

PS: http://imgur.com/7eacZ3T,vIwX44M,V4gsvky,rVe3kg9 as you can see, I rendered LoL models and map, and they were full 3D, the only difference to the actual LoL client is the fixed camera angle in it.
Title: Re: [ODFAE] (Open Source Developement Framework Adapted for Every Game)
Post by: eXpl0it3r on January 09, 2014, 03:25:14 pm
True, one has to differentiate between "technical perspective" and "experienced perspective".
The "experience" is personal thus one can argue forever, while the "technical" can be determined rather easily, even though one might find some 3D math tricks within 2D math calculations. :)

Anyways I'll leave it at that, it has polluted the topic enough already (if only I were I mod, I could move the stuff...). ;)

On Topic
It's "Development" not "Developement" - there's an 'e' too much. ;)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on January 12, 2014, 11:28:16 am
New update :

-Action and signal improvements :

-We can know create combined actions in a easier way with the logical operators.
-I reduced the template arguments. (To create signals)

It should cloturate the first version, the next updates'll be most of all bug corrections/optimisations.
I've to clean the code also and generate documentation and exemples.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on January 21, 2014, 01:28:10 pm
I've created a devblog, then, I'll avoid to post in this forum for small updates. (But you can visit my devblog if you want to have more news about this project.)

I'll post only to annonce the launch of the releases or answer to the questions.

The first release'll be released soon I've just to generate documentation with doxygen, configuring the library to provide a shared verson of the library, and, finishing the tutorials. (In french and next in English)

PS : see the first post to find the link of my devblog. (I've updated it)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: G. on January 21, 2014, 07:37:53 pm
Quote
Welcome to my devblog! I’m Laurent Duroisin,  one of the most experienced c++ developper in the world
Awesome.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on January 30, 2014, 04:19:34 pm
The version RC has just been released. (it's the version without the tutorials and documentations)
See on my git-hub repository for the source code.
I've still to configure the library for the shared build, and make the documentation before the launch of the first release!

The library contains now :

-An entity system. (Scene nodes, animations, a grid for entity storage, updaters and the world who conains everything.)
-A lighting system.
-A listener system. (For the events  and actions, you can even make and connect your own triggers!)
-Some classes to manage collision detection with 2D bounding areas.
And a states system to store and restaure states without reload everything.
-A lightweight resource management system.

The next version'll come  very soon, it'll implement these new functionnalities :

-Safe Networking.
-Movement prediction.
-A particule system.

I've already test the 2 first points, I've just to re-order the code and put it into the framework.
Thus, just the last point (the particule system) remains but to do it faster, I'll take a look at the particule system of the thor library.

I've implemented my own tuple system but I don't recommend to use it, it was just for learning purpose. (Maybe I'll improve it later when I'll have better knoledges about the D language)

PS : Creating some guis looks like buttons shoud be nice if someone is interessed.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: eXpl0it3r on January 30, 2014, 04:53:49 pm
In case anyone else is wondering: https://github.com/Lolilolight/ODFAEG

Manually managed C arrays of pointer of manually managed states. I mean if it was a C library we could talk about it again, but this... nope - but as we all know, you don't like RAII. ;)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on January 30, 2014, 05:14:41 pm
Quote
In case anyone else is wondering: https://github.com/Lolilolight/ODFAEG

Manually managed C arrays of pointer of manually managed states. I mean if it was a C library we could talk about it again, but this... nope - but as we all know, you don't like RAII. ;)

It isn't the fact that I don't like RAII, but smart_pointers are not pointers, so you can't pass them to a pointer to a function... (And they are not copiable too, they only encapsulate a pointer who's destroyed when the object is destroyed, this is RAII)

References are also causing a lot of problems when we want to store them into a container to pass them to a function pointer. (So I can't pass smart pointers)
But anyway I use std::vectors of pointers and std::array, and, they use RAII it seems. (No ?)

So, I've no problems with the memory management.

Thus it joins what I've said on another topic, every classes should have a class with a destructor. (And essentially containers like std::vectors who can store anything)
And should use the move semantic to pass adresses to function pointers. (Instead of the RAII mecanism)

Here, I use the std::vectors because I don't have to pass them to a function pointer but..., in other case..., it's very paintfull with RAII.
I tried to use a std::reference_wrapper to pass smart pointers to function pointers but it didn't worked, and if I pass a pointer I've to delete them manually...

PS : It would be nice if the std::vectors can also have a forward_as_vector function like std::tuples who are very helpfull.
So I prefer to use the move semantic who's less paintfull. (To move the pointers from my first list, to the pointers to my second list)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on January 30, 2014, 07:21:38 pm
Why can't you pass a reference to a smart pointer to a function, so it doesn't get copied?
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on January 30, 2014, 08:16:53 pm
Because it's too paintfull to store reference into a container :

I'll show you a source code exemple later.

But I had to use something like this :

std::map<std::string, ResourceManager<void*>&>

I don't know if it's very well but I want to avoid copy. (I've objects who are non copiable)





Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on January 31, 2014, 08:28:53 am
I know how I'll do that, I'll create a class like boost any and delete the pointer in the destructor.

It should do the trick. :)

I've just to know how to pass reference arguments in a function template, to store them in a tuple.

I've to do some tests and check information about that for the next realease...., but if someone knows it'll really help me.
I've to do some test with the tuple too, to try to use a typed bind class with a placeholder system. (With type erasure)
I've found the insterter to insert elements into a tuple but I don't know really how it works.
 
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: zsbzsb on January 31, 2014, 02:30:00 pm
I know how I'll do that, I'll create a class like boost any and delete the pointer in the destructor.

And you just described those hated smart pointers which are already there for you to use.............................
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 01, 2014, 11:29:51 am
Yeah smart pointers are made for that, but, I prefer the move semantic, you don't even need an object to encapsulate the pointer.

With the forward_as_tuple method, I even don't need to use smart pointers, and I can pass references and const references without any problem. (With tempaltes)

Anyway I prefer use my proper class to manage that, than the smart pointers.
Because smart pointers don't offers us the type erasement.
So I'll use a base class for my resource manager class I think, rather than a smart pointer with a pointer to void.

The same technique that I've used to store triggers,signals and actions into the listener.

I think it's really better.

And I'll use the move semantic for the template.




Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 04, 2014, 10:00:07 am
Hi!

I've found a solution for the storage of multiple resources types with multiple identifiers, it'll be updated in the next realease.

I simply use the type erasure.

I've also added a wait method in the listener, because I had assynchroneous problems.

And I've fixed a deadline for the launch of the first release, so the first realease should goes out on the first March! (Just the time for me to finish the documentations and tutorials)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: MorleyDev on February 05, 2014, 06:24:14 am
std::shared_ptr<void> voidPtr = std::make_shared<int>(10);
std::shared_ptr<int> intPtr = std::static_pointer_cast<int>(voidPtr);

std::shared_ptr<int> intPtr = std::make_shared<int>(10);
std::weak_ptr<void> voidPtr = intPtr;
std::shared_ptr<void> sharedVoidPtr = voidPtr.lock();
std::shared_ptr<int> otherIntrPtr = std::static_pointer_cast<int>(sharedVoidPtr);

As I understand the term, shared_ptr offers a fairly safe type-erasement, because the shared_ptr will pass the correct destructor functor to std::shared_ptr<void>, meaning if it falls out of scope everything will still get deconstructed safely. shared_ptr supports move semantics, and for avoiding circular references you can always weak_ptr.

A cache can nowadays just store the weak_ptrs, it then tried to lock the weak_ptr when someone requested the resource. If the lock returned a valid shared_ptr, just return that. If not, reacquire the resource.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 05, 2014, 10:13:33 am
Oki, I was just thinking of using something like this for loading the resource.

But I've a question, can I use a shared pointer and retrieve the pointer from the encapsulation objet ?

I don't really need it, I just need it to free the resource when the loading fails :

std::shared_ptr<void> resourcePtr = std::make_shared<sf::Texture>();
if (!resourcePtr.getPtr().loadFromFile(...))  {
    //We launch an exeption and delete the pointer.
   // (The shared pointer does it, it would be usefull if I've a lot of exceptions or return cases)
}
Resource *resource = new Resource(resourcePtr.getPtr());
 
And I remove all the resources in the destructor, when the ResourceManager is destroyed.

Most of all : my resources are stored in a map in the resource manager class who use any kind of identifiant type who's associate with the resource. (Because I can't pass 2 templates argument in the shared pointer)
So I think it's simplier to have a base class (ResourceManagerBase for exemple), and ResourceManager<R, I> inherit from ResourceManagerBase.
So I store pointers to ResourceManagerBase objects into the cache, it avoids me to have a more complex system.
template <typename R, typename I>
void ResourceCache::addResourceManager(ResourceManager<R, I>& rmi, std::string name) {
    ResourceManagerBase* rmb = &rmi;
    std::map<std::string, ResourceManagerBase*>::iterator it = resourceManagers.find(name);
    if (it != resourceManagers.end())
        resourceManager<R, I>(name) = rmi;
    resourceManagers.insert(std::pair<std::string, ResourceManagerBase*>(name, rmb));
}
template <typename R, typename I>
ResourceManager<R, I>& ResourceCache::resourceManager(std::string name) {
    std::map<std::string, ResourceManagerBase*>::iterator it = resourceManagers.find(name);
    if (it == resourceManagers.end())
        throw Erreur (12, "Resource manager not found!", 0);
    if (dynamic_cast<ResourceManager<R, I>*> (it->second) == nullptr)
        throw Erreur (13, "Bad cast!", 0);
    return dynamic_cast<ResourceManager<R, I>&> (*(it->second));
}
 

I used a dynamic_cast but we can use a static_cast too.

Of course if we want to retrieve the resource manager we have to specify the types of the resources and the type of the resources identifiers who are stored in the manager.

But it's not very a problem for me.



Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lo-X on February 05, 2014, 10:24:33 am
std::shared_ptr<void> resourcePtr = std::make_shared<sf::Texture>();
if (!resourcePtr.getPtr().loadFromFile(...))  {
    //We launch an exeption and delete the pointer.
   // (The shared pointer does it, it would be usefull if I've a lot of exceptions or return cases)
}
Resource *resource = new Resource(resourcePtr.getPtr());
 

Try this instead :

void YourObject::YourMethod()
{
     std::shared_ptr<sf::Texture> resourcePtr(new sf::Texture(...));
     if(!resourcePtr->loadFromFile(...)) {
          throw your::exception(...); // This will AUTOMAGICALLY delete the texture since it get out of scope
     }
}

Smart pointers are magic.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 05, 2014, 10:40:33 am
Ok, I'll try this, thanks!
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 12, 2014, 05:17:41 pm
Big changements for the first release. (It'll be updated on the 1rst March)

-The cache'll be improved to  be able to store any kind of ResourceManager type.
-The entity class'll have a state, then you'll be able to redefine the entity class for common attributes (exemple : a class caracter) and add custom attributes to the entity's state. (exemple : if the caracter is a magician, you can add an attribute called mana for example)
To interact between the entities, you'll need to redefines two function of the abstract StateExecutor class (one to apply a special entity's state and the other to unapply a special entity's state), these functions take one parameter : the current entity state. (You can so retrieve and change the parameters of the current entity's state in the executor's functions)
And you have just to pass your state executor to the entity manager, if you want to change a special attribute of an entity.
This system was designed  to avoid you to have to do too much inheritance. (If you have a lot of different weapons types, skills, caracter classes, ... in your game, and some classe can equipe only one type of weapon, use only some skills, etc....)

This new feature'll also improve the moves storage for movement prediction in the next version. (When I'll introduce the network and physic aspects)

PS : I've also corrected some points.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 13, 2014, 02:15:44 pm
I forgot to mention it, but this should interest you, in the last chapter of the tutorials, they'll be an example small game which'll be created with ODFAEG, it'll not be an awesome game (just a caracter, a monster and an xp system) but it'll give the base to create a game with ODFAEG.
The tutorial and the small game example'll be integrated to the git-hub repositories, because I haven't the time to do a website for the moment, I'll probably create one later, when the sorrok project well be finished, but, I've also my own project (Sorrok) to finish so, I've a lot of work.

The last version (with will implement the 3D part) will only be coded when the first version of the Sorrok project will be released. (Because the second version of the Sorrok project'll be coded in full 3D)
The first version off Sorrok'll just be a test. (To know if I'm in the right way to add the 3D or if I've to review some points in the gameplay)
So the feedback'll always be appriciate. (But only feedback who have sense, and not messages only made to attack my own reputation and troll (like some members have tried to do in the past))
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 17, 2014, 12:09:20 pm
Major optimisation, so I've updated the git-hub repositry  :

-The scene node : the combinaison of transformations are now made in the odfaeg::Transformable class instead of in the draw function. (So you can choose if you want to combine the transfation, rotation and scale when you're drawing the entity nodes and his children :

By default the transformations of the parent node and its children are combined but if you don't want to combine them you can redefines these functions and let them empty :

class ParentNode {
void onMove(Vec2f& t) {}
void onScale(Vec2f& s) {}
void onRotate(float angle) {}
};

If you have to update informations when your entity is transformed you can do this in these 3 functions, but, if you want to also combine transformations in the children nodes and other informations on theses functions you have to call the Entity::onMove(t), Entity::onRotate(angle) and Entity::onScale(s) functions in the function redefinitions like this :
class ParentNode {
void onMove(Vec2f& t) {Entity::onMove(t);}
void onScale(Vec2f& s) {Entity::onScale(s) ;}
void onRotate(float angle) {Entity::onRotate(angle);}
};

This'll pass the transformation at the children nodes and apply this transformation to the children nodes.

The same technique is used with the onDraw function.

I had to do this because the example shown in the SFML tutorials wasn't very practice in my case.

The entities have also two origin (the position for the translation) and the center for rotation and scale, instead of SFML which provides only one origin.

I've also optimised the entity manager (the class Map), the function containsVisibleEntity was too slow so I compared the pointer instead of the entities themself.
I think I'll delete the class tGround because it's quite uselless. (For the ground I  add now tiles directly in the entity manager in the generate_map function.)

I've also optimized animations. (and animations who have entity's which can move throw the screen like a caracter for exemple or a monster)
I've added a gravity center and the entity manager use it to check entities which are before or behind the movable animation, and so find the layer position of the movable entity automatically.)

You can change the gravity center of a model by calling the changeGravityCenter method.

An a lot of improvement are coming : (I wonder if I'll have finish it to the first March)

I've still a displaying bug with the current entity of the movable animation.(Sometimes it doen't display, sometimes it display 2 superposed entities of the animation)

I'll change the std::string to a void* in the entity manager to count how many time a resource is used in the entity manager. (To avoid to have to pass a template, I just need the adress of the resource in the entity manager to count how many time a resource is used)

And that's all, when I'll find this last bug with animations, I think I'll can launch the first release, and implement the network, the video of the Sorrok project shouldn't give a lag impression anymore.

But the optimisation is not an easy point, I've first to improve the entity system, and only after if it's enought fast, I can introduce the network and it must stay fast with a movement prediction system.

But event if an object isn't heavy like a view, when we have to retrieve it very often in the source code, I've noticed that returning a reference (even on a small object) is a important gain of performance in a big project.

So I've change some of my functions to return a reference.
I think I'll change it for the view in the source code of SFML.

I've also to do some changement in the Action class to perform the event correctly when a type of event is defined (PRESSED_ONCE or HELDOWN) and clear the event buffer of the action  in function of the type of the event.
I though to set -1 to the event type to clear the buffer but it result to a compilation error so I need to find another idea, I think I'll change the source of SFML to add a variable for an empty sf::Event.

So I shoudn't have optimisation and transformation computations of the entities problems with SFML anymore. (It was very paintefull)

PS 2 : I'll also improve the World class to store systems and entity managers.
Screen an movies are comming soon.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 17, 2014, 03:31:27 pm
I've fixed the bugs with the animations. (And I've updated them on the got-hub)

For the second one it wasn't a bug I've just forgot to replace the animation in the gridmap when the caracter moved.

But now everything is fine :
Here is an example of source code which moves a caracter accross the map.

#ifndef MY_APPLI
#define MY_APPLI
#include "ODFAEG/Core/application.h"
#include "ODFAEG/Graphics/2D/tile.h"
#include "ODFAEG/Graphics/2D/map.h"
#include "ODFAEG/Graphics/2D/world.h"
#include "ODFAEG/Graphics/2D/decor.h"
#include "ODFAEG/Graphics/2D/anim.h"
#include "ODFAEG/Graphics/2D/ambientLight.h"
#include "ODFAEG/Core/actionMap.h"
#include "ODFAEG/Core/system.h"
#include "ODFAEG/Core/entitiesUpdater.h"
#include "ODFAEG/Core/animationUpdater.h"
#include "caracter.h"
using namespace odfaeg;
using namespace sf;

class MyAppli : public Application {
    private :
    const int speed = 50;
    Map* theMap;
    Clock realTime;
    EntitiesUpdater *eu;
    RenderTexture *renderTextShadows, *renderTextLights;
    RectangleShape rect;
    AnimUpdater *au;
    bool running;
    ActionMap *closedAction;
    ActionMap *moveAction;
    Listener listener;
    TileGround *tg;
    Wall *w;
    Caracter* caracter;
    sf::Keyboard::Key actualKey, previousKey;
    enum TEXTURES {
        GRASS, WALLS, HOUSE, FIRE1, FIRE2, FIRE3
    };


    public :
    MyAppli(sf::RenderWindow &window) : Application (window) {
        running = false;
        actualKey = sf::Keyboard::Unknown;
        previousKey = sf::Keyboard::Unknown;
    }
    void close () {
        getWindow().close();

    }
    void keyHeldDown (sf::Keyboard::Key key, sf::Time elapsedTime) {
        sf::View view = getWindow().getView();
        float t = speed * elapsedTime.asSeconds();
        if (actualKey != sf::Keyboard::Key::Unknown && key == sf::Keyboard::Key::Z) {
            view.move (0, -t);
            if (!caracter->isMoving()) {
                if (actualKey != previousKey) {
                    Vec2f dir(0, -1);
                    caracter->setDir(dir);
                }
                caracter->setMoving(true);
            }
            theMap->moveEntity(caracter, caracter->getDir().x * t, caracter->getDir().y * t);
        } else if (actualKey != sf::Keyboard::Key::Unknown && key == sf::Keyboard::Key::Q) {
            view.move (-t, 0);
            if (!caracter->isMoving()) {
                if (actualKey != previousKey) {
                    Vec2f dir(-1, 0);
                    caracter->setDir(dir);
                }
                caracter->setMoving(true);
            }
            theMap->moveEntity(caracter, caracter->getDir().x * t, caracter->getDir().y * t);
        } else if (actualKey != sf::Keyboard::Key::Unknown && key == sf::Keyboard::Key::S) {
            view.move (0, t);
            if (!caracter->isMoving()) {
                if (actualKey != previousKey) {
                    Vec2f dir(0, 1);
                    caracter->setDir(dir);
                }
                caracter->setMoving(true);
            }
            theMap->moveEntity(caracter, caracter->getDir().x * t, caracter->getDir().y * t);
        } else if (actualKey != sf::Keyboard::Key::Unknown && key == sf::Keyboard::Key::D) {
            view.move (t, 0);
            if (!caracter->isMoving()) {
                if (actualKey != previousKey) {
                    Vec2f dir(1, 0);
                    caracter->setDir(dir);
                }
                caracter->setMoving(true);
            }
            theMap->moveEntity(caracter, caracter->getDir().x * t, caracter->getDir().y * t);
        }

        getWindow().setView(view);
        renderTextShadows->setView(view);
        renderTextLights->setView(view);
        BoundingRectangle br (view.getCenter().x - view.getSize().x * 0.5f, view.getCenter().y - view.getSize().y * 0.5f, view.getSize().x, view.getSize().y);

        eu->setViewRect(br);
        au->setViewRect(br);
        eu->update();
    }
    bool mouseInside (Vector2f mousePos) {
        BoundingRectangle br (0, 0, 100, 100);
        if (br.isPointInside(Vec2f(mousePos.x, mousePos.y))) {
            return true;
        }
        return false;
    }
    void onMouseInside (Vector2f mousePos) {
        std::cout<<"Mouse inside : "<<mousePos.x<<" "<<mousePos.y<<std::endl;
    }
    void load() {
        ResourceManager<sf::Texture, TEXTURES>* tm = new ResourceManager<sf::Texture, TEXTURES>();
        tm->fromFile("tilesets/herbe.png", GRASS);
        tm->fromFile("tilesets/murs.png",  WALLS);
        tm->fromFile("tilesets/maison.png", HOUSE);
        tm->fromFile("tilesets/flemmes1.png", FIRE1);
        tm->fromFile("tilesets/flemmes2.png", FIRE2);
        tm->fromFile("tilesets/flemmes3.png", FIRE3);
        getCache().addResourceManager(*tm, "TextureManager");
    }
    void init () {
        addClock(realTime, "RealTime");
        TextureManager<TEXTURES> &tm = getCache().resourceManager<sf::Texture, TEXTURES>("TextureManager");
        View view = getWindow().getDefaultView();
        view.setCenter(0, 0);
        Vec2f pos (view.getCenter().x - view.getSize().x * 0.5f, view.getCenter().y - view.getSize().y * 0.5f);
        BoundingRectangle rect (pos.x, pos.y, view.getSize().x, view.getSize().y);
        theMap = new Map (100, 50, 30, "Map test");
        eu = new EntitiesUpdater(theMap, rect);
        eu->launch();
        au = new AnimUpdater(theMap, rect);
        au->setInterval(seconds(0.01f));
        au->start();
        std::vector<Tile*> tiles;
        std::vector<Tile*> walls;
        tiles.push_back(new Tile(tm.getResourceByAlias(GRASS), Vec2f(0, 0), Vec2f(120, 60),IntRect(0, 0, 100, 50), 0));
        walls.push_back(new Tile(tm.getResourceByAlias(WALLS), Vec2f(0, 0), Vec2f(100, 100), IntRect(100, 0, 100, 100), 1));
        walls.push_back(new Tile(tm.getResourceByAlias(WALLS), Vec2f(0, 0), Vec2f(100, 100), IntRect(100, 100, 100, 100), 1));
        walls.push_back(new Tile(tm.getResourceByAlias(WALLS), Vec2f(0, 0), Vec2f(100, 100), IntRect(100, 200, 100, 100), 1));
        walls.push_back(new Tile(tm.getResourceByAlias(WALLS), Vec2f(0, 0), Vec2f(100, 100), IntRect(100, 300, 100, 100), 1));
        walls.push_back(new Tile(tm.getResourceByAlias(WALLS), Vec2f(0, 0), Vec2f(100, 100), IntRect(100, 400, 100, 100), 1));
        walls.push_back(new Tile(tm.getResourceByAlias(WALLS), Vec2f(0, 0), Vec2f(100, 100), IntRect(100, 500, 100, 100), 1));
        BoundingRectangle mapZone(0, 0, 1000, 1000);
        theMap->generate_map<TEXTURES>(tiles, walls, mapZone);
        Decor* decor = new Decor(new Tile(tm.getResourceByAlias(HOUSE), Vec2f(0, 0), Vec2f(250, 300), IntRect(0, 0, 250, 300), 2), AmbientLight::getAmbientLight());
        decor->setPosition(Vec2f(100, 100));
        decor->setShadowCenter(Vec2f(0, 60));
        decor->changeGravityCenter(Vec2f(50, 50));
        theMap->addEntity<TEXTURES>(decor);
        PonctualLight* light = new PonctualLight(Vec2f(50, 150),100,50,0,200,sf::Color(255,255,0),16,0);
        theMap->addEntity<TEXTURES>(light);
        Anim* fire = new Anim(0.1f, Vec2f(0, 100), Vec2f(100, 100), 2);
        Decor *fire1 = new Decor(new Tile(tm.getResourceByAlias(FIRE1), Vec2f(0, 100), Vec2f(100, 100), IntRect(0, 0, 150, 200), 2), AmbientLight::getAmbientLight());
        Decor *fire2 = new Decor(new Tile(tm.getResourceByAlias(FIRE2), Vec2f(0, 100), Vec2f(100, 100), IntRect(0, 0, 150, 200), 2), AmbientLight::getAmbientLight());
        Decor *fire3 = new Decor(new Tile(tm.getResourceByAlias(FIRE3), Vec2f(0, 100), Vec2f(100, 100), IntRect(0, 0, 150, 200), 2), AmbientLight::getAmbientLight());
        fire1->setShadowCenter(Vec2f(80, 100));
        fire2->setShadowCenter(Vec2f(80, 100));
        fire3->setShadowCenter(Vec2f(80, 100));
        fire1->changeGravityCenter(Vec2f(50, 50));
        fire2->changeGravityCenter(Vec2f(50, 50));
        fire3->changeGravityCenter(Vec2f(50, 50));
        fire->addEntity(fire1);
        fire->addEntity(fire2);
        fire->addEntity(fire3);
        fire->play(true);
        theMap->addEntity<TEXTURES>(fire);
        au->addAnim(fire);
        Tile *t = new Tile(walls[3]->getTexture(), walls[3]->getPosition(), walls[3]->getSize(), walls[3]->getTextureRect(),3);
        w = new Wall(3, 80, t,AmbientLight::getAmbientLight());
        w->setPosition (Vec2f (0, 130));

        theMap->addEntity<TEXTURES>(w);
        caracter = new Caracter("Sorrok", "Nagi", "M", "Map test", "Brain", "Green", "White","Normal","Novice", 1);
        std::string path = "tilesets/tilesetnovice.png";
        getCache().resourceManager<sf::Texture, TEXTURES>("TextureManager").fromFile(path);
        const Texture *text = getCache().resourceManager<sf::Texture, TEXTURES>("TextureManager").getResourceByPath(path);
        int textRectX = 0, textRectY = 0, textRectWidth = 50, textRectHeight = 100;
        int textWidth = text->getSize().x;
        int textHeight = text->getSize().y;
        for (unsigned int i = 0; i < 24; i+=3) {
            Anim* animation = new Anim(0.1f, Vec2f(0, 0), Vec2f(50, 100), 0);
            for (unsigned int  j = 0; j < 3; j++) {
                IntRect textRect (textRectX, textRectY, textRectWidth, textRectHeight);
                Tile *tile = new Tile(text, Vec2f(0, 0), Vec2f(textRectWidth, textRectHeight), textRect, 0);
                Decor *decor = new Decor(tile, odfaeg::AmbientLight::getAmbientLight());
                decor->setShadowCenter(Vec2f(80, 130));
                decor->changeGravityCenter(Vec2f(50, 50));
                textRectX += textRectWidth;
                if (textRectX + textRectWidth > textWidth) {
                    textRectX = 0;
                    textRectY += textRectHeight;
                }
                animation->addEntity(decor);
            }
            caracter->addAnimation(animation);
            au->addAnim(animation);
        }
        theMap->addEntity<TEXTURES>(caracter);
        theMap->computeIntersectionsWithWalls();
        renderTextShadows = new RenderTexture();
        renderTextShadows->create(view.getSize().x, view.getSize().y);
        renderTextLights = new RenderTexture();
        renderTextLights->create(view.getSize().x, view.getSize().y);
        renderTextShadows->setView(view);
        renderTextLights->setView(view);
        MemberFunction<void(MyAppli*)> f1 (&MyAppli::close);
        closedAction = new ActionMap(f1, this);
        Action *a = new Action(Action::EVENT_TYPE::CLOSED);
        closedAction->addAction(a);
        MemberFunction<void(MyAppli*, sf::Keyboard::Key, sf::Time)> b2 (&MyAppli::keyHeldDown);
        moveAction = new ActionMap(b2, this, sf::Keyboard::Key::Unknown, realTime.restart());
        Action *a1 = new Action (Action::EVENT_TYPE::KEY_HELD_DOWN, sf::Keyboard::Key::Z);
        Action *a2 = new Action (Action::EVENT_TYPE::KEY_HELD_DOWN, sf::Keyboard::Key::Q);
        Action *a3 = new Action (Action::EVENT_TYPE::KEY_HELD_DOWN, sf::Keyboard::Key::S);
        Action *a4 = new Action (Action::EVENT_TYPE::KEY_HELD_DOWN, sf::Keyboard::Key::D);
        Action *combined = new Action(*a1 || *a2 || *a3 || *a4);
        moveAction->addAction(combined);
        MemberFunction<bool(MyAppli*, sf::Vector2f)> trigFunc (&MyAppli::mouseInside);
        MemberFunction<void(MyAppli*, sf::Vector2f)> onTrigFunc(&MyAppli::onMouseInside);
        listener.connect("MouseInside", this, trigFunc, this, onTrigFunc, Vector2f(-1, -1));
        listener.connectAction("CloseAction", closedAction);
        listener.connectAction("MoveAction", moveAction);
        listener.listen();
        getWindow().setView(view);
        eu->update();
    }
    void render() {
        if (getWindow().isOpen())
        {
            // clear the window with black color
            getWindow().clear(sf::Color::Black);
            std::vector<Entity*> entities = theMap->getVisibleEntities("E_TILE");// draw everything here...

            for (unsigned int i = 0; i < entities.size(); i++) {
                    getWindow().draw(*entities[i]);
            }
            entities = theMap->getVisibleEntities("E_WALL+E_DECOR+E_ANIMATION+E_CARACTER");
            renderTextShadows->clear(Color::White);
            for (unsigned int i = 0; i < entities.size(); i++) {
                if (entities[i]->getType() == "E_SHADOW_WALL" || entities[i]->getType() == "E_SHADOW_TILE") {
                    renderTextShadows->draw(*entities[i]);
                }
            }
            View view = getWindow().getView();
            Vector2f v2 (view.getCenter().x - view.getSize().x * 0.5f, view.getCenter().y - view.getSize().y * 0.5f);
            rect.setPosition(Vector2f(v2.x, v2.y));
            rect.setFillColor((Color(100, 100, 100, 128)));
            rect.setSize(Vector2f (view.getSize().x, view.getSize().y));
            renderTextShadows->draw(rect, RenderStates(BlendAdd));
            renderTextShadows->display();
            Sprite shadows (renderTextShadows->getTexture());
            shadows.setPosition(v2.x, v2.y);
            getWindow().draw (shadows, RenderStates(BlendMultiply));
            for (unsigned int i = 0; i < entities.size(); i++) {
                if (entities[i]->getType() == "E_TILE")
                    getWindow().draw(*entities[i]);
            }
            for (int n = 0; n < w->getSegments().size(); n++) {
                 Segment *s = w->getSegments()[n];
                 VertexArray line(Lines, 2);
                 Vertex origin, ext;
                 origin.position = Vector2f (s->getOrig().x, s->getOrig().y);
                 ext.position = Vector2f(s->getExt().x, s->getExt().y);
                 origin.color = Color(255,0,0);
                 ext.color = Color(255, 0, 0);
                 line.append(origin);
                 line.append(ext);
                 getWindow().draw(line);
            }
            AmbientLight::getAmbientLight()->setColor(Color(255, 255, 255));
            Color ambientColor = AmbientLight::getAmbientLight()->getColor();
            renderTextLights->clear(ambientColor);
            entities = theMap->getVisibleEntities("E_PONCTUAL_LIGHT");
            for (unsigned int i = 0; i < entities.size(); i++) {
                renderTextLights->draw(*entities[i], BlendAdd);
            }
            renderTextLights->display();
            Sprite lights (renderTextLights->getTexture());
            lights.setPosition(v2.x, v2.y);
            getWindow().draw(lights, BlendMultiply);
            // end the current frame
            getWindow().display();
        }
        realTime.restart();
    }
    void update () {
        // check all the window's events that were triggered since the last iteration of the loop

        sf::Event event;
        if (getWindow().pollEvent(event))
        {
            listener.pushEvent(event);
            if (event.type == sf::Event::Closed) {

                running =false;
            }
            if (event.type == sf::Event::KeyPressed) {
                previousKey = actualKey;
                actualKey = event.key.code;
                listener.setActionParams<MyAppli, sf::Keyboard::Key, sf::Time>("MoveAction", this, event.key.code,realTime.restart());

            }
            if (event.type == sf::Event::KeyReleased) {
                caracter->setMoving(false);
                previousKey = event.key.code;
                actualKey = sf::Keyboard::Key::Unknown;
            }
            if (event.type == sf::Event::MouseMoved) {
                Vector2f mousePos = Vector2f(event.mouseMove.x, event.mouseMove.y);
                listener.setParams<MyAppli, MyAppli, Vector2f> ("MouseInside", this, this, mousePos);

            }
        }
    }
    void stop() {
        running = false;
    }
    int exec () {
        load();
        init();
        running = true;
        while (running) {
            render();
            update();
        }
        return EXIT_SUCCESS;
    }

    ~MyAppli () {

    }

};

#endif // MY_APPLI
 

And the carater which is a custom entity :
#include "caracter.h"

using namespace std;
using namespace sf;
Caracter::Caracter (string factionName, string pseudo, string sex, string currentMapName, string hairColor,
                  string eyesColor, string skinColor, string faceType, string classs, int level) : AnimatedEntity (Vec2f(-50, -25), Vec2f (100, 50), Vec2f(50, 25), 0, "E_CARACTER") {
    currentAnimIndex = 0;
    this->factionName = factionName;
    this->pseudo = pseudo;
    this->sex = sex;
    this->currentMapName = currentMapName;
    this->hairColor = hairColor;
    this->eyesColor = eyesColor;
    this->faceType = faceType;
    this->skinColor = skinColor;
    this->classs = classs;
    this->level = level;
    currentPointIndex = 0;
    speed = 100;
    moving = false;
    dir = Vec2f(0, 1);
    this->life = 100;
    this->maxLife = 100;
    range = 50;
    attackSpeed = 1.f;
    attack = 10;
    fightingMode = attacking = false;
    alive = true;
    xp = 0;
    xpReqForNextLevel = 1500;
    regenHpSpeed = 1.f;
    regenHpAmount = 1;
}
void Caracter::onMove(Vec2f& d) {
    for (unsigned int i = 0; i < anims.size(); i++) {
        anims[i]->move(d);
    }
}
float Caracter::getRegenHpSpeed () {
    return regenHpSpeed;
}
void Caracter::setRegenHpSpeed(float regenHpSpeed) {
    this->regenHpSpeed = regenHpSpeed;
}
Time Caracter::getTimeOfLastHpRegen() {
    return clockRegenHp.getElapsedTime();
}
void Caracter::setLevel(int level) {
    this->level = level;
}
void Caracter::setCurrentXp(int xp) {
    this->xp = xp;
}
void Caracter::setXpReqForNextLevel(int xpReqForNextLevel) {
    this->xpReqForNextLevel = xpReqForNextLevel;
}
void Caracter::up (int xp) {
    this->xp += xp;
    if (this->xp >= xpReqForNextLevel) {
        level++;
        this->xp = this->xp - xpReqForNextLevel;
        xpReqForNextLevel *= 2;
    }
}
int Caracter::getCurrentXp () {
    return xp;
}
int Caracter::getXpReqForNextLevel () {
    return xpReqForNextLevel;
}
void Caracter::setSpeed(int speed) {
    this->speed;
}
int Caracter::getSpeed() {
    return speed;
}
int Caracter::getRegenHpAmount() {
    return regenHpAmount;
}
void Caracter::setRegenHpAmount(int regenHpAmount) {
    this->regenHpAmount = regenHpAmount;
}
void Caracter::setLife(int life) {
    this->life = life;
    clockRegenHp.restart();
}
int Caracter::getLife() {
    return life;
}
void Caracter::setRange(int range) {
    this->range = range;
}
int Caracter::getRange() {
    return range;
}
void Caracter::setAttackSpeed (float attackSpeed) {
    this->attackSpeed = attackSpeed;
}
float Caracter::getAttackSpeed () {
    return attackSpeed;
}
void Caracter::setAttacking(bool b) {

    this->attacking = b;
}
void Caracter::setAlive(bool b) {
    alive = b;
}
bool Caracter::isAlive () {
    return alive;
}
bool Caracter::isAttacking() {
    return attacking;
}
void Caracter::setFightingMode(bool b) {
    this->fightingMode = b;
}
bool Caracter::operator== (Entity &other) {
    if (getType() != other.getType())
        return false;
    Caracter& caracter = static_cast<Caracter&>(other);
    if (anims.size() != caracter.anims.size())
        return false;
    for (unsigned int i = 0; i < anims.size(); i++) {
        if (anims[i] != caracter.anims[i])
            return false;
    }
    return true;
}
bool Caracter::isInFightingMode() {
    return fightingMode;
}
void Caracter::setAttack(int attack) {
    this->attack = attack;
}
int Caracter::getAttack() {
    return attack;
}

Time Caracter::getTimeOfLastAttack() {
    return clockAtkSpeed.getElapsedTime();
}

void Caracter::setDir (Vec2f dir) {
    anims[currentAnimIndex]->setCurrentTile(0);
    float angleRadians = const_cast<Vec2f&>(Vec2f::yAxis).getAngleBetween(dir);
    int angle = Math::toDegrees(angleRadians);
    //Sud
    if (angle >= -10 && angle <= 10)
        currentAnimIndex = 0;
    //Sud ouest
    else if (angle > -80 && angle < -10)
        currentAnimIndex = 3;
    //Ouest
    else if (angle >= -100 && angle <= -80)
        currentAnimIndex = 6;
    //Nord ouest
    else if (angle > -170 && angle < -100)
        currentAnimIndex = 1;
    //Nors est
    else if (angle > 100 && angle < 170)
        currentAnimIndex = 7;
    //Est
    else if (angle >= 80 && angle <= 100)
        currentAnimIndex = 2;
    //Sud est
    else if (angle > 10 && angle < 80)
        currentAnimIndex = 5;
    else
        currentAnimIndex = 4;

    if (attacking)
        currentAnimIndex += 8;
    this->dir = dir;
}

Vec2f Caracter::getDir () {
    return dir;
}
void Caracter::setMoving (bool b) {
    this->moving = b;
    if (moving) {
        anims[currentAnimIndex]->play(true);
    } else {
        anims[currentAnimIndex]->stop();
        anims[currentAnimIndex]->setCurrentTile(0);
    }

}
bool Caracter::isMoving () {
    return moving;
}

Vec2f Caracter::getPosition () {
    return anims[currentAnimIndex]->getPosition();
}

void Caracter::setPath(vector<Vec2f> path) {
    this->path = path;
}
vector<Vec2f> Caracter::getPath() {
    return path;
}
void Caracter::addAnimation (Anim *anim) {
    anims.push_back(anim);
}
Anim* Caracter::getAnimation(int index) {
    if (index >= 0 && index < anims.size())
        return anims[index];
    return NULL;
}
unsigned int Caracter::getCurrentPathIndex() {
    return currentPointIndex;
}
void Caracter::setCurrentPathIndex (unsigned int currentPointIndex) {
    this->currentPointIndex = currentPointIndex;
}

void Caracter::setMaxLife(int life) {
    this->maxLife = maxLife;
}

int Caracter::getMaxLife() {
    return maxLife;
}
int Caracter::getLevel() {
    return level;
}
string Caracter::getClass () {
    return classs;
}
void Caracter::onDraw(sf::RenderTarget &target, sf::RenderStates states) const {
    target.draw(*getCurrentEntity(), states);
}
Entity* Caracter::getCurrentEntity() {
    return anims[currentAnimIndex]->getCurrentEntity();
}
Caracter::~Caracter() {

}

 

In the main we just have to do this :
#include <iostream>
#include "myApplication.h"
using namespace odfaeg;
using namespace sf;
int main () {
    sf::RenderWindow window (sf::VideoMode(800, 600), "ODFAEG DEMO");
    MyAppli appli (window);
    return appli.exec();
}
 

Screenshot and movies are coming! (I'll include some tilesets and a demo on the git-hub repository as soon as possible)


Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 18, 2014, 12:43:50 pm
Finally, the first release'll be probably for april, I've still a lot of thing to do before launching a real optimized framework :


-The main is that I've to change the signal class to support also std::functions and I'll try to make only one class to store every type of functions so the signal class'll be renamed as "delegate".

Because it's exactly what I'm trying to do.

The delegate class'll store the right pointer to the object (if it's a member function), and function parameters.

I'll improve it to store also an object of type std::function.

And when we'll invoke the function it'll invoke the right function pointer.

I've read this article and it's seems to be a very interessant article! (More interessant than the std::function mechanism execpts that I've to depend on std::function if I want to store pointer to lambda functions, I don't know how to alocate a function pointer with c++ I even don't know if it's possible to do something like this :

Function<void()> ptreFunc(new void(){});
 

But apparently it isn't possible so I checked this article :

http://msdn.microsoft.com/en-us/library/c320cx3h.aspx (http://msdn.microsoft.com/en-us/library/c320cx3h.aspx)

And I had a new idea.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 18, 2014, 07:02:08 pm
And another article which explain why deleguates rocks and why using them instead of std::function.
I mention that because many of you adviced me to use std::function.

http://www.codeproject.com/Articles/7150/Member-Function-Pointers-and-the-Fastest-Possible (http://www.codeproject.com/Articles/7150/Member-Function-Pointers-and-the-Fastest-Possible)

And curiously I had the same idea, but I had to reimplement that which variadic templates. (because he didn't use them)

The heavy part is that we must define a template specialisation for each type of function :

-Non member function. (With and without return type)
-Normal or static function.(With and without return type)

It makes already 4 specialisations.

And there are of course other specialisation for lambda functions. (If I want that my delegate system support them...)

It makes 8 differents template specialisations...

If everyone have the same source code but with varaidic template and whiwh support also lamba functions, I'm very interested!
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: therocode on February 19, 2014, 07:58:13 am
That seems to include a lot of complications and workarounds for just the tradeoffs of a bit of performance over the otherwise very flexible std::function.

Sure, in certain cases where performance is very crucial, such approaches can be worth it, but have you actually measured the std::function solution to be a bad performance bottleneck in your project? If not (and I doubt it would be) then it seems to me like a bad approach to introduce that complexity for practically not really any gain.

What you are trying to achieve kind of sounds like a messaging system and if that is what you want to do, then you can also get away by having pointers not to functions, but to objects, and then call a method on them directly which depending on what you want to do, might be more reasonable.

But key point is: Never sacrifice simplicity over complexity for performance reasons that are not measured or known from experience.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: panithadrum on February 19, 2014, 08:40:07 am
Totally agree with the user above. Always go for simplicity unless you can't for crucial reasons.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 19, 2014, 11:14:57 am
Yeah this code seems to be ve very complex, I've downloaded the source because it's a bit project and I really need performance.

I use this for a messaging system. (When a function (a signal) return true I call another function (a slot) and I store signal and slot parameters into the delegate class. (Later I eventwould like to have a place holder system with the tuples)

But I want to do this with any kind of function (std::function, ...) so i've created a template class with encapsulate all function type and an object if they are member functions, and I store them into a class wich call a callback function to invoke each type of functions.
#ifndef PLACE_HOLDERS_H
#define PLACE_HOLDERS_H
#include <functional>
#include "function.h"
namespace odfaeg {

template <typename R, typename O, typename ...A> R callback (MemberFunction<R(O*, A...)> func, O* object, A... args) {
    return func(object, args...);
}
template <typename R, typename ...A> R callback(Function<R(A...)> func, A... args) {
    return func(args...);
}
template <typename R, typename O, typename ...A> R callback (std::function<R(O*, A...)> func, O* object, A... args) {
    return func(object, args...);
}
template <typename R, typename ...A> R callback(std::function<R(A...)> func, A... args) {
    return func(args...);
}
template <class T> class DelegatePrototype {
    public :
    virtual bool operator== (T& other) const = 0;
};
class Delegate : public DelegatePrototype<Delegate> {
    public :
    virtual void operator()() = 0;
    virtual bool hasReturn() const = 0;
};
template <typename R, typename O, typename ...A> class FastDelegate3 : public Delegate {
        friend class FastDelegate;
        FastDelegate3 (R(O::*func)(A...) ,O* object) {
            typedef R(*CB)(MemberFunction<R(O*, A...)>, O*, A...);
            CB cb = &callback;
            funct = new Functor<R(MemberFunction<R(O*, A...)>, O*, A...)> (cb, MemberFunction<R(O*, A...)>(func), object);
        }
        void setParams (A... args) {

            params = std::make_tuple (args...);
        }
        void operator()() {
             ret = (*funct)(params);
        }
        R getReturn () {
            return ret;
        }
        bool operator== (Delegate& other) const {

            if (&dynamic_cast<FastDelegate3<R, O, A...>&>(other) == nullptr) {
                return false;
            }
            FastDelegate3<R, O, A...>& delegate3 = dynamic_cast<FastDelegate3<R, O, A...>&>(other);
            return *funct == *(delegate3.funct);
        }
        bool hasReturn() const {
            return true;
        }
        std::tuple<A&&...> params;
        Functor<R(MemberFunction<R(O*, A...)>, O*, A...)> *funct;
        R ret;
};
template <typename O, typename ...A> class  FastDelegate2 : public Delegate {
        friend class FastDelegate;
        FastDelegate2 (void(O::*func)(A...), O* object)  {
            typedef void(*CB)(MemberFunction<void(O*, A...)>, O*, A...);
            CB cb = &callback;
            funct = new Functor<void(MemberFunction<void(O*, A...)>, O*, A...)> (cb, MemberFunction<void(O*, A...)>(func), object);

        }
        void setParams (A&&... args) {
            params = std::make_tuple (args...);
        }
        void operator()() {
            (*funct)(params);
        }
        bool operator== (Delegate& other) const {
            if (&dynamic_cast<FastDelegate2<O, A...>&>(other) == nullptr) {
                return false;
            }
            FastDelegate2<O, A...>& delegate2 = dynamic_cast<FastDelegate2<O, A...>&>(other);
            return *funct == *(delegate2.funct);
        }
        bool hasReturn() const {
            return false;
        }
        std::tuple<A...> params;
        Functor<void(MemberFunction<void(O*, A...)>, O*, A...)> *funct;
};
template <typename ...A> class FastDelegate0 : public Delegate {
        friend class FastDelegate;
        FastDelegate0 (void(*f)(A...), A... args) {
            typedef void(*CB)(Function<void(A...)>, A...);
            CB cb = &callback;
            funct = new Functor<void(Function<void(A...)>, A...)> (cb, Function<void(A...)>(f), args...);
            params = std::make_tuple (args...);
        }
        void setParams (A... args) {

            params = std::make_tuple (args...);
        }
        void operator()() {
             (*funct)(params);
        }
        bool operator== (Delegate& other) const {

            if (&dynamic_cast<FastDelegate0<A...>&>(other) == nullptr) {
                return false;
            }
            FastDelegate0<A...>& delegate0 = dynamic_cast<FastDelegate0<A...>&>(other);
            return *funct == *(delegate0.funct);
        }
        bool hasReturn() const {
            return false;
        }

        std::tuple<A...> params;
        Functor<void(Function<void(A...)>, A...)> *funct;
};
template <typename R, typename ...A> class FastDelegate1 : public Delegate {
        friend class FastDelegate;
        FastDelegate1 (Function<R(A...)> func, A... args) {
            typedef R(*CB)(Function<R(A...)>, A...);
            CB cb = &callback;
            funct = new Functor<R(Function<R(A...)>, A...)> (cb, func);
            params = std::make_tuple (args...);
        }
        void setParams (A... args) {

            params = std::make_tuple (args...);
        }
        void operator()() {
             ret = (*funct)(params);
        }
        R getReturn () {
            return ret;
        }
        bool operator== (Delegate& other) const {

            if (&dynamic_cast<FastDelegate1<R, A...>&>(other) == nullptr) {
                return false;
            }
            FastDelegate0<R, A...>& delegate1 = dynamic_cast<FastDelegate1<R, A...>&>(other);
            return *funct == *(delegate1.funct);
        }
        bool hasReturn() const {
            return true;
        }

        std::tuple<A&&...> params;
        Functor<R(Function<R(A...)>, A...)> *funct;
        R ret;
};
class FastDelegate {
    public :
    FastDelegate () {

    }
    template <typename R, typename O, typename ...A> FastDelegate(R(O::*f)(A...), O* object) {
        delegate = new FastDelegate3<R, O, A...>(f, object);
    }
    template <typename O, typename ...A> FastDelegate(void(O::*f)(A...), O* object) {
        delegate = new FastDelegate2<O, A...>(f, object);
    }
    template <typename R, typename ...A> FastDelegate(void(*f)(A...)) {
        delegate = new FastDelegate1<R , A...>(f);
    }

    template <typename ...A> FastDelegate(void(*f)(A...), A... args) {
        delegate = new FastDelegate0<A...>(f,args...);
    }
    template<typename ...A> void* operator()(A... args) {
        if (static_cast<FastDelegate0<A...>*>(delegate)) {
            static_cast<FastDelegate0<A...>*>(delegate)->setParams(args...);
        }
        return (*delegate)();
    }
    template<typename R, typename ...A> R operator()(A... args) {
        if (static_cast<FastDelegate1<R, A...>*>(delegate)) {
            static_cast<FastDelegate1<R, A...>*>(delegate)->setParams(args...);
        }
        (*delegate)();
        return static_cast<FastDelegate1<R, A...>*>(delegate)->getReturn();
    }
    template<typename O, typename ...A> void* operator()(O* object, A... args) {
        if (static_cast<FastDelegate2<O, A...>*>(delegate)) {
            static_cast<FastDelegate2<O, A...>*>(delegate)->setParams(object, args...);
        }
        (*delegate)();
    }
    template<typename R, typename O, typename ...A> R operator()(O* object, A... args) {
        if (static_cast<FastDelegate3<R, O, A...>*>(delegate)) {
            static_cast<FastDelegate3<R, O, A...>*>(delegate)->setParams(object, args...);
        }
        (*delegate)();
        return static_cast<FastDelegate3<R, O, A...>*>(delegate)->getReturn();
    }
    template<typename R> R operator()() {
        return (*delegate)();
    }
    void* operator()() {
        (*delegate)();
    }
    template<typename ...A> void setParams(A... args) {
        if (static_cast<FastDelegate0<A...>*>(delegate)) {
            static_cast<FastDelegate0<A...>*>(delegate)->setParams(args...);
        }
    }
    template<typename R, typename ...A> void setParams(A... args) {
        if (static_cast<FastDelegate1<R, A...>*>(delegate)) {
            static_cast<FastDelegate1<R, A...>*>(delegate)->setParams(args...);
        }
    }
    template<typename O, typename ...A> void setParams(O* object, A... args) {
        if (static_cast<FastDelegate2<O, A...>*>(delegate)) {
            static_cast<FastDelegate2<O, A...>*>(delegate)->setParams(object, args...);
        }
    }
    template<typename R, typename O, typename ...A> void setParams(O* object, A... args) {
        if (static_cast<FastDelegate3<R, O, A...>*>(delegate)) {
            static_cast<FastDelegate3<R, O, A...>*>(delegate)->setParams(object, args...);
        }
    }
    bool operator==(FastDelegate &other) {
        return *delegate == *other.delegate;
    }
private :
    Delegate* delegate;
};
}
#endif // PLACE_HOLDERS_H

 


I looked for this article to do do it work with inheritance, if I've a base class and derivated components for exemple. (Because it doens't work in this case)

funclist[6] = FastDelegate(&CBaseClass::SimpleVirtualFunction, &d);
 

Because CBaseClasse::SimpleVirtualFunction and d aren't in the same class, d is an objectwhiwh derive from the CBaseClass.
But this forum is certainly no appropriate to discuss about low level programming so I think I'll check for another one.



Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lo-X on February 19, 2014, 11:58:32 am
My game/lib developer point of view :

I really need performance.

I highly doubt you need such things... If your framework make the game to drop below 60fps, that's not std::function fault. If it does not, then you don't need to worry about optimisations and performances (well, not too much)

Plus, let me doubt that you own implementation of std::function is so much better than a feature that has been developped by the best C++ programmerS across the world for many years now (because it was in gestation in boost for years before being added to c++, just as well as nearly all other c++ features that were added in c++11).

I agree with my mates above that said you're not looking for the simplest way to do your messaging system or whatever your doing.


My lib user point of view :

Your example code looks too massive. It doesn't make me feel comfortable in using your framework. Indeed if I use a lib I like to do minimal things. Here you have 25 lines of code to init/declare things at the same place, you are handling events at the same place, etc.
I would like to have actions, just like Thor, that are linked to some kind of event/messaging system and are triggered automatically. I don't want to make my movements actions in raw in the handleEvents(), imagine the size it will be when I will have to handle at least 50 different entities ? (I don't even see how that's possible).

You tend to present the code inside the black box, but what the user want to see is the exposed API. He generally doesn't care how things are implemented. Try to present some more things about the API, that we can have an idea about what your framework look/will look like.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 19, 2014, 01:02:59 pm
I've find a solution which works and which is less complex, you can so define every type of pointer to functions (and it works also if you pass derived objects to a pointer to a function member. ;))

#include <stdio.h>
#include "ODFAEG/Core/signal.h"
// Demonstrate the syntax for FastDelegates.
//                              -Don Clugston, May 2004.
// It's a really boring example, but it shows the most important cases.

// Declare some functions of varying complexity...
using namespace odfaeg;
void SimpleStaticFunction(int num, char *str) {
        printf("In SimpleStaticFunction. Num=%d, str = %s\n", num, str);
}

void SimpleVoidFunction() {
        printf("In SimpleVoidFunction with no parameters.\n");
}

class CBaseClass {
protected:
        char *m_name;
public:
        CBaseClass(char *name) : m_name(name) {};
        void SimpleMemberFunction(int num, char *str) {
                printf("In SimpleMemberFunction in %s. Num=%d, str = %s\n", m_name, num, str);  }
        int SimpleMemberFunctionReturnsInt(int num, char *str) {
                printf("In SimpleMemberFunction in %s. Num=%d, str = %s\n", m_name, num, str); return -1;       }
        void ConstMemberFunction(int num, char *str) const {
                printf("In ConstMemberFunction in %s. Num=%d, str = %s\n", m_name, num, str);   }
        virtual void SimpleVirtualFunction(int num, char *str) {
                printf("In SimpleVirtualFunction in %s. Num=%d, str = %s\n", m_name, num, str); }
        static void StaticMemberFunction(int num, char *str) {
                printf("In StaticMemberFunction. Num=%d, str =%s\n", num, str); }
};

class COtherClass {
        double rubbish; // to ensure this class has non-zero size.
public:
        virtual void UnusedVirtualFunction(void) { }
        virtual void TrickyVirtualFunction(int num, char *str)=0;
};

class VeryBigClass {
        int letsMakeThingsComplicated[400];
};

// This declaration ensures that we get a convoluted class heirarchy.
class CDerivedClass : public VeryBigClass, virtual public COtherClass, virtual public CBaseClass
{
        double m_somemember[8];
public:
        CDerivedClass() : CBaseClass("Base of Derived") { m_somemember[0]=1.2345; }
        void SimpleDerivedFunction(int num, char *str) { printf("In SimpleDerived. num=%d\n", num); }
        virtual void AnotherUnusedVirtualFunction(int num, char *str) {}
        virtual void TrickyVirtualFunction(int num, char *str) {
                printf("In Derived TrickyMemberFunction. Num=%d, str = %s\n", num, str);
        }
};



int main(void)
{
        // Delegates with up to 8 parameters are supported.
        // Here's the case for a void function.
        // We declare a delegate and attach it to SimpleVoidFunction()
        printf("-- FastDelegate demo --\nA no-parameter delegate is declared using FastDelegate0\n\n");

        FastDelegate noparameterdelegate(&SimpleVoidFunction);

        noparameterdelegate(); // invoke the delegate - this calls SimpleVoidFunction()

        printf("\n-- Examples using two-parameter delegates (int, char *) --\n\n");

    // By default, the return value is void.
    FastDelegate MyDelegate;

        // If you want to have a non-void return value, put it at the end.
    FastDelegate newdeleg;


        FastDelegate funclist[12]; // delegates are initialized to empty
        CBaseClass a("Base A");
        CBaseClass b("Base B");
        CDerivedClass d;
        CDerivedClass c;

        newdeleg = FastDelegate(&CBaseClass::SimpleMemberFunctionReturnsInt, &a);

        // Binding a simple member function
        funclist[0] = FastDelegate(&CBaseClass::SimpleMemberFunction, &a);

        // You can also bind static (free) functions
        funclist[1] = FastDelegate (&SimpleStaticFunction);
        // and static member functions
        funclist[2] = FastDelegate (&CBaseClass::StaticMemberFunction);
        // and const member functions (these only need a const class pointer).
        //funclist[11] = FastDelegate (&CBaseClass::ConstMemberFunction, (const CBaseClass *)&a);
        funclist[3] = FastDelegate( &CBaseClass::ConstMemberFunction, &a);
        // and virtual member functions
        funclist[4] = FastDelegate(&CBaseClass::SimpleVirtualFunction, &b);

        // You can also use the = operator. For static functions, a fastdelegate
        // looks identical to a simple function pointer.
        funclist[5] = FastDelegate(&CBaseClass::StaticMemberFunction);

        // The weird rule about the class of derived member function pointers is avoided.
        // For MSVC, you can use &CDerivedClass::SimpleVirtualFunction here, but DMC will complain.
        // Note that as well as .bind(), you can also use the MakeDelegate()
        // global function.
        funclist[6] = FastDelegate(&CBaseClass::SimpleVirtualFunction, &d);

        // The worst case is an abstract virtual function of a virtually-derived class
        // with at least one non-virtual base class. This is a VERY obscure situation,
        // which you're unlikely to encounter in the real world.
        // FastDelegate versions prior to 1.3 had problems with this case on VC6.
        // Now, it works without problems on all compilers.
       funclist[7] = FastDelegate(&CDerivedClass::TrickyVirtualFunction, &c);
        // BUT... in such cases you should be using the base class as an
        // interface, anyway.
       funclist[8] = FastDelegate(&COtherClass::TrickyVirtualFunction, &c);
        // Calling a function that was first declared in the derived class is straightforward
        funclist[9] = FastDelegate(&CDerivedClass::SimpleDerivedFunction, &c);

        // You can also bind directly using the constructor
        FastDelegate dg = FastDelegate(&CBaseClass::SimpleVirtualFunction, &b);

        char *msg = "Looking for equal delegate";
        for (int i=0; i<12; i++) {
                printf("%d :", i);
                // The == and != operators are provided
                // Note that they work even for inline functions.
                if (funclist[i]==dg) { msg = "Found equal delegate"; };
                // operator ! can be used to test for an empty delegate
                // You can also use the .empty() member function.
                if (!funclist[i]) {
                        printf("Delegate is empty\n");
                } else {
                        // Invocation generates optimal assembly code.
                        funclist[i](i, msg);
                };
        }
        return 0;
}

 

So know you'll be able to connect every kind of function pointers to an action. :) (Static/normal function or members function (even const member function) or lamba expressions, and pass the object and the arguments at different execution times to call the function)

You just need to instanciate an object of type FastDelegate and pass it a pointer to a function (or a lambda expression) and the parameters. (And there is only one object type to build every kind of function and later you'll also be able to pass placeholders at the FastDelegate object initialisation)
This make the code very more simple to use. (And you don't have to worry about the type of the function pointer and you can strore everything because the type isn't unspecified like the std::bind class.

You talek about the thor::action system but the thor::action system of thor is not sufficient, imagine that you have to click in a button you'll have to define a thor::action for each pixel of the button.

So you need to define a trigger function which'll return true if the mouse is in the button. (when the left mouse button is pressed)
So you need to connect a trigger function with'll invoke a slot when an sf::Event is generated.

This is exactly why I need this system. :)

I'm sure that recent language like java are using a trick like this to call the functions of their interfaces when an event is triggered.








Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lo-X on February 19, 2014, 01:31:43 pm
You almost convinced me, but I read that :

You talek about the thor::action system but the thor::action system of thor is not sufficient, imagine that you have to click in a button you'll have to define a thor::action for each pixel of the button.

WHHAAAAT ? Stop to say crap... Some years ago I implemented a GUI with buttons and callback working with std::function and std::bind (well, it was perhaps boost at the time, but result's the same) and it worked very well. No question of pixels... I don't see any link anyhow, nor from close, nor from far.

Edit : the code of the said button should be in my Engenesis repo on my GitHub no it's not since I wiped the repo
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: therocode on February 19, 2014, 01:35:50 pm
I really need performance.

I take my bet on that you have not measured a bottleneck still.

I agree with the above poster too. A messaging system in a framework should not be the bottleneck, in that case, something is wrong.

In my framework, I use the method I described here: blog.therocode.net/2013/09/messaging-using-variadic-templates/ (http://blog.therocode.net/2013/09/messaging-using-variadic-templates/). This approach uses neither function pointers nor std::functions but instead calls the receiving function directly which for me has proven to be more than fast enough. This is also a very clean approach and the message bus is less than 100 lines of code.

If you don't believe that it is fast enough, I wrote this to profile:

#include <featherkit/messaging.h>
#include <chrono>

FEA_DECLARE_MESSAGE(NumberMessage, int32_t);  //message carrying one int

class NumberKeeper : public NumberMessageReceiver
{
    public:
        NumberKeeper() : total(0)
        {
        }
        void handleMessage(const NumberMessage& message) override
        {
            total += std::get<0>(message.mData);;
        }
       
        int32_t total;
};

int main()
{  
    using namespace std::chrono;

    fea::MessageBus bus;
    NumberKeeper keeper;

    bus.addSubscriber<NumberMessage>(keeper);


    std::cout << "total number is now " << keeper.total << " and will start sending messages!\n";

    high_resolution_clock::time_point before = high_resolution_clock::now();

    for(uint32_t i = 0; i < 300000; i++)     //send 300000 messages
        bus.send(NumberMessage(5));

    high_resolution_clock::time_point after = high_resolution_clock::now();

    std::cout << "now done, total number is " << keeper.total << ". The time it took was " << duration_cast<milliseconds>(after - before).count() << " milliseconds. Cya mate!\n";
}
 

Output:
tobbe@archosaurus ~/projects/messagingtest % ./bin/messagingprof
total number is now 0 and will start sending messages!
now done, total number is 1500000. The time it took was 13 milliseconds. Cya mate!
 

In other words, it sends 300000 messages to one receiver just fine in less than one game frame (one frame is typically ~16ms). I think the cases when you need more performance from the messagebus than this is really rare and will probably be slow due to other factors, and wouldn't be feasible for a real time application such as a game anyway.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on February 19, 2014, 02:51:09 pm
Usually when someone claims to need performance without being directly looking for solutions to a very specific bottleneck, that means they aren't even using that tech anywhere..

People have been asking _why_ is all this performance needed, and that wasn't really answered. Chances are you're saving a little bit of CPU on these little quirks, only to waste most of its potential on bad code later in the project.. It's what usually happens, slowness coming from inappropriate use of containers, bad allocation patterns etc..

I'd advice to focus on giving actual usable functionality with some value. If your library is providing less or even the same as its competitors, chances are no one will use it.. The best of luck for it, but I'd really focus on providing something worth people's times in it. SFML with the currently existing community extensions is more than enough for most indie projects you can think of.

As far as signals go, I've been happily married with libsigc++ for years now. It rocks so much! The c++11 alternatives seem more than promising as well. In sum, I don't think you can do better than either one, as most developers couldn't either..
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 19, 2014, 05:35:22 pm
It's not a question of optimisation but also a question of needing functionnalities.

I need  it to use a signal and a slot system. (the user create  two functions pointers, (the first is a signal, the second is the slot), and I store them in a structure and map them with a connexion name)

I have a class which stores all signals, slots and actions. (I can't use std::bind because the type is undefined so I can't store them)
I want also to change the parameters of the slot and the signals (hey have always the sames parametes like in QT) when I want. (At their creation or at they execution)
So I need to pass parameters like we do this with std::bind. (The better solution that I've found is to create two tuples and to concat them, but I don't know if it's possible to change the elements types into a tuple to replace the ones wich are placeholders)
So I've created a class witch contruct function pointers, pass parameters to the functions and call them with the operator().
All class that store and call function pointers inherit from a single class and I do a cast when I need to change parameters. (The operator() call the pointer to the fonction with the parameters given in the tuple)

Ok, it works fines excepts with the return type, I can't have a generic calling function because the return type is always different :

 virtual void* getReturn() const = 0;
 

 template <typename R> R invoke() {
        (*delegate)();
        if (delegate->hasReturn()) {
            return reinterpret_cast<R>(delegate->getReturn());
        }
        return 0;
    }
 

It gives me an error because it can't cast bool to void* (I can't make a template function virtual too. :/)

I can't also store the type of the template and retrieve it at the execution time. :/
If everyone as an idea ...

PS : I have a base class (Delegate) and severals child delegates classes wich store different pointers to functions. (And each derived classes redefines the void operator() to clall the function pointer.) (With the given parameters that I stored into the tuples)




Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lo-X on February 19, 2014, 05:56:54 pm
So :

There's plenty of sigslot libs that uses std::function. One was given in another post above.

Using std::function or your function system doesn't allow a compile-time definition of messages. It's executed in live (well, don't think that's an issue, but since you want to optimize everything, you must know it). Therocode has a framework that allow compile time messages with any parameter you need, not matter their type.

Usually, you don't need  return type for sigslots. The principal is that some part of the program wants to notify that a event happened, without knowing what other part of the program will catch that. It can be one part that do the catch, none, or a lot. So a return means nothing... In what order will they return things ? It's unhandlable.
If you know what part of the program will return back something and what type it will be, so why do you call it directly... ?
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on February 19, 2014, 07:28:34 pm
If you don't want to lose time you could pass an argument by reference and use it as return value
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 19, 2014, 07:34:57 pm
Yes you're right, I've made two generic class so, once with a FastDelegate for return type functions, and one with a delegate for void functions and it works. ;)

Anyway the signal returns always a bool and the slot returns always a void :

Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 20, 2014, 05:40:53 pm
Ok now I've fixed the last bugs and I must say that's it's very faster!!!

Before I had to have a speed of 10 to move the caracter, and the framerate of the animations wasn't very high too.
The clock returns also seconds to move the view in realtime.

Now, I had to define a speed of 50 000 otherwise the caracter don't move fast enougth so unlike as you said before there's a real difference of performance!

I'll update the gith-hub this evening. ;) (Or this night :D) (In other word, befor tommorrow.)

I'm happy, this'll really upgrate the performances comparing as before when i used the networking..., it was too slow!

That's why I've decided to build a framework, to optimise source code and have some goods advices. :)





Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 20, 2014, 10:04:03 pm
I've updated the git-hub repository.

Now, the signals and slots must be objects of type FastDelegate, a FastDelegate object encapsulate a pointer to a function of any type (excepts anonymous function I haven't finish all code implementation yet), and functions arguments.

The fast delegates are the benefits to be faster and to allow you to pass derived objects properly by casting a derivate object pointer to a base object before calling the virtual member function of a base class.

It avoids to have to call directly the virtual member function of the base class on an object of a derived class whith the operator ->, the code may be unportable and the behaviour can be undefined when the base class inherits from several classes with a virtual inheritance. (and also if thoses classes have abstract virtual functions)

The delegate'll be even introduced in next C# version it seems. :)

To create a FastDelegate object you have just to past the return type of the function pointer as a tempalte argument and the adress of the function to call. :)

Like this :

FastDelegate<bool> delegate(&MyCall::MyFunction);
 

Don't forget to pass the arguments to the functions before calling it if the function takes argument, and, the object if it's a member function : (Otherwise it result to a crash, it's the inconvenient of the using of tuples but the advantages are powerfull because the code is generate at the compilation time and the function call result to only 2 ASM instructions.)
delegate.setParams(object, argument1, ...);
 

And you have just to class the operator() to execute the function :
delegate();
 

Later you'll be able to pass default arguments when you'll create the delegate the defautl arguments well be set in a tuple, and be concataned with another tuple that contains arguments passed before calling the delegate. (And a placeholder system maybe'll be avalaible in a next version if I can do this technique with tuples (and not with std::bind any more))

The actions can know have a signal function, I can't use the emit key word here because this feature is only avalaible in Qt, so, the alternative is to pass a FastDelegate object which a pointer to a function whiwh return true or false if the signal is triggered. (This function is called a trigger function)

With the new system we can call a slot if one or more sf::event and a trigger function are triggered.

A system like the java listener'll be implemented later with the guis components in the next version. (I'll certainly take example on the source code of sf::GUI. :) )

It should rox. (And I'll finally have a framework which guis, opengl and sfml are compatible. (This is not the case with the actuals games framework so it's also why I've decided to create ODFAEG.)
I've also tried with java and JOGL, but JOGL and java classes weren't very compatible, it was resulting to thread concurrent exception most of the time.

This is not the case with ODFAEG. :)
I'm happy to have finally found a solution to my problems. (But know I'have to reimplementing all)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: zsbzsb on February 21, 2014, 01:22:42 am
The delegate'll be even introduced in next C# version it seems. :)

I have no clue what you mean by this... considering you can already write the following code (in C# or any CLI language for that matter).

var callback = new Func<bool>(MyFunction); // Create callback/delegate
var result = callback(); // Invoke callback/delegate

// Or for that matter lets have fun using lambda expressions

var firstCallback = new Action(() => { Console.WriteLine("First callback"); });
var secondCallback = new Action(() => { Console.WriteLine("Second callback"); });
var combinedCallbacks = firstCallback + secondCallback; // Combine callbacks
combinedCallbacks(); // Invoke both callbacks

// Output
/* First callback
   Second callback */
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 21, 2014, 09:18:59 am
Ha it's already implemented in C#.

Sorry then.

C# seems to be a nice language too. ^^

Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 21, 2014, 07:49:31 pm
The place holder system is not for now, because, I tried to retrieve the type of the specific delegate like this instead of using a static cast on the template parameters of the functions because the size of the values passed and the size of the arguments function types are not the same when I use palceholders so I need to store the type of the delegate somewhere and retrieve it to do the cast when I change the params of the delegate, so I tried something like this :

template <class T> class DelegatePrototype {
    public :
    virtual bool operator== (T& other) const = 0;
};
typedef void DefaultVoid;

class Delegate : public DelegatePrototype<Delegate> {
    public :
    virtual void operator()() = 0;
    virtual bool hasReturn() const = 0;
    virtual void* getReturn() const = 0;
    std::type_info& getType() {
        return typeid(this);
    }
};
 
And int the fast delegate class :
template<typename... V> void setParams(V... vals) {
        if (static_cast<delctype(delegate->getType())>(delegate)) {
            static_cast<delctype(delegate->getType())>(delegate)->setParams(vals...);
        }
    }
 

It work well with fast delegates with unvoid functions but it doesn't work with delegates which void functions and I have this error message :

Code: [Select]
C:\ODFAEG\include\ODFAEG\Core\signal.h|256|error: 'class odfaeg::Delegate' has no member named 'setParams'|

The most strange thing is that I can retrieve the fast delegate like this :

FastDelegate<void*> fd = static_cast<decltype(delegate)>(delegate);
fd->setParams(args...)
 
Works with static function delegates but not with member function delegates.

But I can't call member function on the delegate :
static_cast<decltype(delegate)>(delegate)->setParams(vals...)
 

Works with unvoid functions but not with void functions.

Is it a c++ bug ?







Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Nexus on February 21, 2014, 08:15:12 pm
Is it a c++ bug ?
Yeah, sure.

Lolilolight, before always blaming libraries, compilers and programming languages for having bugs, have a deeper look at your code, make sure you really understand it, and then find out what you did wrong. If you just invested 20 seconds to actually read the code you wrote, you would see that you're casting something to the type of itself, which is clearly not how conversions work.

Concerning the whole delegate mess, we've already had an endless discussion in the French forum where I wanted to show why you should use std::function instead of reinventing it in a worse way, apparently you didn't learn from it.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 21, 2014, 10:08:30 pm
You are wrong, I don't cast an object of type Delegate to itself but an object of type Delegate to objects of type FastDelegate1<FunctionTYPE>, FastDelegate2<FunctionTYPE>, etc...

I don't kno if you're looking at my code yet but.

template <typename R> class FastDelegate {
    public :
    FastDelegate () {
        delegate = nullptr;
    }
    bool operator!() {
        return delegate == nullptr;
    }


    template <typename O, typename ...A> FastDelegate(R(O::*f)(A...) const) {
        delegate = new FastDelegate3<R, O, A...>(f);
    }
    template <typename O, typename ...A> FastDelegate(R(O::*f)(A...)) {
        delegate = new FastDelegate3<R, O, A...>(f);
    }
    template <typename ...A> FastDelegate(R(*f)(A...)) {
        delegate = new FastDelegate1<R , A...>(f);
    }


    R operator()() {
        (*delegate)();
        return reinterpret_cast<R> (delegate->getReturn());
    }
    template<typename ...A> void setParams(A... args) {
        if (static_cast<FastDelegate1<R, A...>*>(delegate)) {
            static_cast<FastDelegate1<R, A...>*>(delegate)->setParams(args...);
        }
    }
    template<typename O, typename D, typename ...A> void setParams(D* derived, A... args) {
        if (static_cast<O*>(derived)) {
            static_cast<FastDelegate3<R, O, A...>*>(delegate)->setParams(static_cast<O*>(derived), args...);
        }
    }
    template<typename O, typename ...A> void setParams(O* object, A... args) {
        if (static_cast<FastDelegate3<R, O, A...>*>(delegate)) {
            static_cast<FastDelegate3<R, O, A...>*>(delegate)->setParams(object, args...);
        }
    }
    bool operator==(FastDelegate &other) {
        return delegate == other.delegate;
    }

private :
    Delegate* delegate;
};
 

It's not dramatic if it don't work I can do it without placeholders it work also well. (The only thing it that i'll have to do is to pass all parameters at the delegate creation.)

I just do that for learning purpose. (And to see what can I do which this language and what can I not do.

type_info wirks only when I cast an object of type delegate into objects of type FastDelegate3<FuncTYPE> and FastDelegate1<FUNCTYPE> objects.

Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 22, 2014, 12:12:45 pm
I've found why it's simply because I didn't used a fast delegate with return something in the code so..., I forgot that I've wiped some code.

Anyway  T type and typeid(type) aren't of the same types, T is replace by a type and typeid(type) is of type typeinfo.

I don't think that exists a safe way to store the type of a template and to retrieve if at compilation time to do a static_cast in c++ like this.

template <class T> class DelegatePrototype {
    public :
    virtual bool operator== (T& other) const = 0;
};
typedef void DefaultVoid;

class Delegate : public DelegatePrototype<Delegate> {
    public :
    virtual void operator()() = 0;
    virtual bool hasReturn() const = 0;
    virtual void* getReturn() const = 0;
    const std::type_info& getType() {
        return typeid(*this);
    }
};
template <typename R, typename O, typename ...A> class FastDelegate3 : public Delegate {
        public :
        FastDelegate3 (R(O::*func)(A...)) {
            typedef R(*CB)(MemberFunction<R(O*, A...)>, O*, A...);
            CB cb = &callback;
            funct = new Functor<R(MemberFunction<R(O*, A...)>, O*, A...)> (cb, MemberFunction<R(O*, A...)>(func));

        }
        FastDelegate3 (R(O::*func)(A...) const) {
            typedef R(*CB)(MemberFunction<R(O*, A...)>, O*, A...);
            CB cb = &callback;
            funct = new Functor<R(MemberFunction<R(O*, A...)>, O*, A...)> (cb, MemberFunction<R(O*, A...)>(func));

        }

        void setParams (O* object, A... args) {

            params = std::make_tuple (object, args...);
        }
        void operator()() {
             ret = reinterpret_cast<void*>((*funct)(params));
        }

        bool operator== (Delegate& other) const {

            if (&dynamic_cast<FastDelegate3<R, O, A...>&>(other) == nullptr) {
                return false;
            }
            FastDelegate3<R, O, A...>& delegate3 = dynamic_cast<FastDelegate3<R, O, A...>&>(other);
            return *funct == *(delegate3.funct);
        }
        bool hasReturn() const {
            return true;
        }
        void* getReturn() const {
            return ret;
        }
        std::tuple<O*, A...> params;
        Functor<R(MemberFunction<R(O*, A...)>, O*,  A...)> *funct;
        void* ret;
};
template <typename R> class FastDelegate {
    public :
    FastDelegate () {
        delegate = nullptr;
    }
    bool operator!() {
        return delegate == nullptr;
    }


    template <typename O, typename ...A> FastDelegate(R(O::*f)(A...) const) {
        delegate = new FastDelegate3<R, O, A...>(f);
    }
    template<typename O, typename ...A> void setParams(O* object, A... args) {
        if (static_cast<decltype(delegate->getType())>(delegate)) {
            static_cast<decltype(delegate->getType())>(delegate)->setParams(object, args...);
        }
    }
    ...
};
 

I'm forced to do that so :
template<typename O, typename ...A> void setParams(O* object, A... args) {
        if (static_cast<FastDelegate3<R, O, A...>*>(delegate)) {
            static_cast<FastDelegate3<R, O, A...>*>(delegate)->setParams(object, args...);
        }
    }
 

But is everyone has an idea he's welcome. :)

Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 22, 2014, 01:24:29 pm
I've found this : http://en.wikipedia.org/wiki/Curiously_recurring_template_pattern

But I can't combine this design pattern with the type erasure design pattern. (So I conclude that this is really no way to do this)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: panithadrum on February 22, 2014, 01:38:30 pm
Maybe you should use std::function and forget all this headaches :P
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on February 22, 2014, 02:11:04 pm
Don't try to convince him, let him try and fail, its not like he is in a hurry for anything :p

He clearly has no idea of how many problems a library like qt signals, libsigc++, or even std::function to a lesser extent solve..

Even if he gets the type issues clean and smooth, there will still be performance optimizations, special case handling for some platforms and tracking premature destruction of the slot object, among other things..
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 22, 2014, 03:41:21 pm
I'll add the possibility to use an std::function into the fast-delegate class. :P

(But not objects with placeholders)

Because their type is always different and there are not of type std::function.

auto binder = std::bind(&myFunction, _1, "2");
//It'll not work because binder is not of type std::function.
FastDelegate<void>(binder);
 

auto binder = std::bind(&myFunction, "1", "2");
FastDelegate<void>(binder);
 

This one will work because there are no place holders used so binder is of type std::function.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lo-X on February 22, 2014, 04:45:46 pm
Because their type is always different and there are not of type std::function.

auto binder = std::bind(&myFunction, _1, "2");
//It'll not work because binder is not of type std::function.
FastDelegate<void>(binder);
 

#include <iostream>
#include <functional>
using namespace std::placeholders;
using namespace std;
struct C
{
    int callback(int a, int b, int c) {
        return a+b+c;
    }
};

int main(int argc, char *argv[])
{
    C myC;
    auto f1 = std::bind(&C::callback, &myC, _1, _2, 42);
    std::cout << "f1(5, 3) = " << f1(5, 3) << std::endl; // = 50
    std::function<int(int,int)> f2 = f1;
    std::cout << "f2(5, 3) = " << f2(5, 3) << std::endl; / = 50
    std::cout << typeid(f2).name() << std::endl; // = std::function

    f2 = std::bind(&C::callback, &myC, _1, _1, _1);
    std::cout << "f2(5, 2354, 4567) = " << f2(5, 3) << std::endl; // = 15
    std::cout << typeid(f2).name() << std::endl; // = std::function

    f2 = std::bind(&C::callback, &myC, 1, 2, 3);
    std::cout << "f2(5, 3) = " << f2(5, 3) << std::endl; // = 6
    std::cout << typeid(f2).name() << std::endl; // = std::function

    return 0;
}
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 22, 2014, 05:21:47 pm
It's not so simple like that, I need to store the object f1 in a std:map if I take your example.

But I don't think that it's possible.

PS : with boost it seems that it's possible : http://stackoverflow.com/questions/7757096/how-can-i-store-a-boostbind-object-as-a-class-member (http://stackoverflow.com/questions/7757096/how-can-i-store-a-boostbind-object-as-a-class-member)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 22, 2014, 09:06:38 pm
I've tried one last thing (just for testing the new c++ features) but the c++11 function style cannot be virtuals :

class Base {
       public :
       virtual auto getType() = 0;
};
template <typename T> class Derived : public base {
      Derived (T t) : t(t) {}
      auto getType() -> Derived<T> {
              return this;
      }
      void function() {
      }
      T t;
};
class Container {
     template <typename T> void create(T t) {
            base = new Derived<T>(t);
     }
     void callFunction() {
            static_cast<decltype(base->getType())>(base)->function();
     }
     Base *base;
};
 

I thought that the compiler would choose the right function to parse base in Derived<T> but it's not the case.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: panithadrum on February 22, 2014, 09:09:10 pm
Can you define a pure virtual function with the auto return type? It doesn't make sense to me...
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 22, 2014, 09:23:37 pm
Quote
Can you define a pure virtual function with the auto return type?

No. ^^

I just tried do something like this :
class Base {
       public :
       virtual auto getType() = 0;
       virtual void* operator();
};
template <typename F, typename ...AV> Bind {
};
template <typename R, typename O, typename... AT, typename ...AV> class Bind<R(O, AT...), AV...> : public Base {
      Bind (R(O::*f)(AT...), AV... vals) : f(f) {
             params1 = std::tuple<AV...>(vals....)
      }
      auto getType() -> Bind<R(O, AT...)> {
              return this;
      }
      template <typename V...> void setParams (V... vals) {
              std::tuple<V...> params2 = std::make_tuple(vals...);
              params3 = std::tuple_cat(params1, params2);
      }
      void* operator()() {
              return f(params3);
      }
     
      std::tuple<AT...> params1;
      std::tuple<AV...> params3;
      (R(O::*f)(AT...);
};
template <typename R=void*> class Binder {
     template <typename R, typename O, typename AT... typename AV...> Binder((R(O::*f)(AT...), AV... vals) {
            base = new Derived<R(O, AT...), AV....>(t);
     }
     template <typename ...AV> void changeParams(AV... vals) {
            static_cast<decltype(base->getType())>(base)->setParams(vals);
     }
     R operator()() {
           return static_cast<R>((*base)());
     }
     Base *base;
};
class Listener {
    std::map<std::string, std::pair<Binder<bool>, Binder<>>> sigslots;
};
 

But, I don't think it's possible, it tells me also that he can't convert R(O::*f)(AT...) to R(*)(AT...). (or comething like this)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 23, 2014, 04:18:06 pm
Hi, I've tried to pass an std::function to a template class but it fails to compile and it's the raison why I don't want to use an std::function.


template <typename ...A> class FastDelegate0 : public Delegate {
        friend class FastDelegate;
        FastDelegate0 (void(*f)(A...)) {
            typedef void(*CB)(Function<void(A...)>, A...);
            CB cb = &callback;
            funct = new Functor<void(Function<void(A...)>, A...)> (cb, Function<void(A...)>(f));
            stdFunct = nullptr;
        }
        FastDelegate0 (std::function<void(A...)> func) {
            typedef void(*CB)(std::function<void(A...)>, A...);
            CB cb = &callback;
            stdFunct = new Functor<void(std::function<void(A...)>, A...)> (cb, func);
            funct = nullptr;
        }
};
 
template <typename R=void> class FastDelegate {
 template <typename ...A> FastDelegate(void(*f)(A...)) {
        delegate = new FastDelegate0<A...>(f);
    }

    template <typename ...A> FastDelegate(std::function<void(A...)> func) {
        delegate = new FastDelegate0<A...>(func);
    }
};
 

std::function<bool(Vector2f)> sigFunc = [](Vector2f mousePos){
                                                            BoundingRectangle br (0, 0, 100, 100);
                                                            if (br.isPointInside(Vec2f(mousePos.x, mousePos.y))) {
                                                                return true;
                                                            }
                                                            return false;};
        std::function<void(Vector2f)> slotFunc = [](Vector2f mousePos){
                                            std::cout<<"Mouse inside : "<<mousePos.x<<" "<<mousePos.y<<std::endl;};
        listener.connect("MouseInside", FastDelegate<bool>(sigFunc), FastDelegate<void>(slotFunc));
 

And I don't want to have an headache anymore with template arguments.
I don't also want to pass the std::function as a template argument, because I need to reduce the template arguments of my FastDelegate class to store my fast delegates objects into an std::map.

The only inconvenient of that it's that annonymous functions could'nt be used for signal and slot but I don't thing that's a real problem anyway. :)

PS : In C# there is a way to do that with the FastDelegate class event with anonymous functions but I really don't know how to do that in c++.




Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 24, 2014, 10:30:16 am
Hi!
I'll take over about the c++11 a bit and I've found an idea for the game that I'll present in this tutorial.

It'll be a shooting game. ^^

But before I need to have a particule system for the projectiles.

I'll take the ones of the thor library, the source code doesn't seems to be very complex.

And then I'll present the example game.  :)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 25, 2014, 12:47:55 pm
Hi, I've fixed a bug which causes sometimes a deadlock. (Because the mutex was unlocked twice)
I've updated the git-hub and the version rc is normally stable now. (If you encounter another bugs let me know :) )

But the demo runs without any problems on my PC.

So I'll post an example of game and some videos soon! (Just the time to manage missiles)







Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 25, 2014, 03:16:02 pm
Here is a first preview of what can we do with ODFAEG. (But I've still to rework the caracter's animation and adding ennemies) :
http://www.youtube.com/watch?v=nkzkRWISFN4&feature=youtu.be

The first exemple of a fully game is coming soon (I've just to add ennemies and projectiles.)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on February 25, 2014, 04:28:07 pm
What exactly are you showing in the video that can't be done with vanilla sfml as quickly? :p
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 25, 2014, 04:58:19 pm
The same things can be done with SFML but not so quickly. :P

So I know that the video doesn't show any difference but without a framework you have to all this tasks manually and it takes me a very long time to do all of this :

-Implementing the intersections between lights and walls system yourself.
-Implementing a resource management system into your program yourself.
-Implementing the culling and other optimisations techniques for faster rendering yourself.
-Implementing yourself an entity management system and a scene node system.
-Implementing yourself a collision detection and a particule system.
And implementing yourself a secure network connection with assynchrone message reception.

Maybe should I make another video (a video tutorial) in which I'll show you how I encode all  of this in a fast way ?

It think this would be be most clear. (I think I'll make that)
Once I'll have finished the IA.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: panithadrum on February 25, 2014, 05:07:50 pm
I think that some documentation would be more useful than videos
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 25, 2014, 05:40:14 pm
Ok, I'll do that. :P

I just have to finish the last chapter. (creating a full game with ODFAEG)

But I thing I'll put the PDF this evening on git-hub. :) (Only the last chapter is still missing anyway)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: panithadrum on February 25, 2014, 05:43:47 pm
I'm not sure if you already know doxygen, but it's an amazing tool that generates documentation from your source comments (I think SFML still uses it)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lo-X on February 25, 2014, 06:01:51 pm
When we asked for examples, it was source code examples along with you lib. We can't see anything about your framework on the video, except that the shadow is reversed or something
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on February 25, 2014, 06:35:21 pm
I think your library would work better if it had some twist in it, something unique.. You're just implementing what other libraries do too and will take a lot of time to mature your systems to the level of your competitors..

My suggestion: Pick a game with something REALLY unique about it and implement a system to aid the development in your library. That would be a decent way to provide some value ;D
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Deathbeam on February 25, 2014, 06:49:08 pm
Hmm that video looks a bit choppy. Atleast fix your character sprite, becouse it is looking like some weird graphics artifacts :D.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 25, 2014, 07:22:56 pm
Mmm...., graphism is very a problem for me but I'll try at least to fix my caracter sprite.

For the shadow I need to reverse it but I need to find another way than flipX which is no more avalaible with SFML 2.0.

And I don't need to reverse all the render texture....

Mmm...., I'll look into the code of SFML 1.6 I think and implement flipX and flipY method.

I'll also rmove this video so and makes one with a full game.

Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Deathbeam on February 25, 2014, 07:29:34 pm
Mmm...., graphism is very a problem for me but I'll try at least to fix my caracter sprite.

For the shadow I need to reverse it but I need to find another way than flipX which is no more avalaible with SFML 2.0.

And I don't need to reverse all the render texture....

Mmm...., I'll look into the code of SFML 1.6 I think and implement flipX and flipY method.

I'll also rmove this video so and makes one with a full game.
Try this graphics: http://www.reinerstilesets.de/ They are free to use and isometric and your demo game will be looking hundred times better
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: zsbzsb on February 25, 2014, 07:46:29 pm
Mmm...., I'll look into the code of SFML 1.6 I think and implement flipX and flipY method.

Its called negative scale.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 25, 2014, 08:15:23 pm
Quote
Its called negative scale.

Ok thanks. :)
Title: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: The Terminator on February 26, 2014, 02:05:54 am
I honestly don't think anyone is going to go for this library due to its over complication. We all came to SFML for its simplistic, clean, and modern design that is useful and beautiful. It seems to me that you're programming a lot of things just to be able to say that you did it, when you're actually reinventing a much more complicated wheel. I advise you to take a step back and actually design before you program. It will help a lot too if you listen to the more experienced members of the community too. *cough* Nexus and Grimshaw *cough*
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: therocode on February 26, 2014, 08:35:54 am
I've been following this thread for a while and I've also viewed your recent showcase video, and I am wondering about something.

You aim for this framework to be _the_ framework to use regardless of which type of game you want to make. This is even in the framework name (Adapted for Every Game). But what I've seen so far really only looks like it deals with top down isometric style 2D graphics. What I wonder is if I'd want to make a 3D FPS game, or a big MMO, or even a fast platformer, would this be possible with your framework? I would kind of expect that it would be, since that is what it promises, but I have not seen many things mentioned related to such types of games.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 26, 2014, 10:25:29 am
Don't say that I'm doing another framework like my competitors again, please, when you don't know what I'm doing, thor don't use a 2D isometric perspective!!! (And the SFM-game book too)
So It's not that I don't want to listen to the advices of the other which have made a good framework. (I don't want to blame them)
But one library use a particule system, a resource holding system and a good action system (the thor library) but not 2D isometric perspective and an entity manager, another library use only GUIs (SfGui), another only the network (sfNul), others one only entity managers and other only the 3D without the SFML phylosophy and code design. (Irrlicht, Ogre, etc...)
I want to regroup all this libraries into a framework, that's why I've created ODFAEG, to simplify the things and to make it all faster.

And I don't thing there is actually a framework which do all of that with SFML.
For the moment you are just able to create small 2D or 2D isometric games, that's right.
But as I say, 3D games and multiplayers games'll come in the next versions, so, plz be patient.

I want to make a framework adapted for every game as you said, it's something unique because I don't know a framework which allow us to do that. (2D, 2D isometric and 3D game with the same framework)

You are always forced to use a different framework for each kind of game and sometimes several frameworks, and their simplicity and code design doesn't always follow the phylosophy of SFML)

So don't worry about that, later, you'll be able to create 3D FPS and big 3D mmorpgs like in this example :

http://linor.fr/tutoriaux/sommaire-3-creation-un-jeu-video.php (http://linor.fr/tutoriaux/sommaire-3-creation-un-jeu-video.php)

I've just to implement the code of all my projects into the framework but before to do that I want to have a stable version with only one kind of game. :)

But my priority for the moment is my Sorrok project, and even without an example for another kind of game you should be able to do another kind of 2D game (and  3D game in the next framework version) with the framework. :)

The use of the framework isn't so complex, I'll post a pdf on the git-hub. :)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: eXpl0it3r on February 26, 2014, 10:46:37 am
I want to make a framework adapted for every game as you said, it's something unique because I don't know a framework which allow us to do that. (2D, 2D isometric and 3D game with the same framework)

So don't worry about that, later, you'll be able to create 3D FPS and big 3D mmorpgs
I won't stand in your way of doing anything, I can just say, that it's impossible to have one framework for all types and genres of games. But I guess you want to find out yourself, so go ahead. ;)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on February 26, 2014, 11:33:28 am
^ what eXpl0it3r said.. I also don't want to stop you from doing your thing. I find it a great thing that you are willing to contribute to the community. All the "advice" I try to give is towards giving more value to your time spent on the project.

You simply _cant_ have a good MMO or 3D game or even some kinds of 2D games unless you have an architecture tailored for that purpose. What AAA game engines do is to provide a strict workflow pipeline which happens to work for many things, but not for others. This is also made possible by the intense optimization they do.

Many, many people have tried to create frameworks that work for every game type and they all failed to some extent. The results are usually too low level, therefore making the developer's life easier to a small extent, who still needs to code a lot of basic things to have his game up and running. The other ones simply never happen, because making a system that is that flexible, optimized and capable will probably take a LONG time to make and turn out so complex that no one will ever use it.

That's why you should create a tool that has its own place in the market, filling a gap the others don't fill. For example, if I want a full fledged 3D game, I probably pick Unity or something like that. If I want a really experimental 2D game, I pick SFML and prototype it right away with all the freedom. And so on.. If you don't attend a particular need of the developers, they will probably never use your tool, because there will be always a better solution.

Also remember a developer probably doesn't pick your library unless it has been proven. As in, a game was previously made with your framework, that at least slightly resembles what he/she wants to make. Will you do all these fully-polished types of games yourself? How many lives will you need to complete them?
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on February 26, 2014, 11:34:31 am
Also, don't forget, if you fail to make it work for _every_ type of game, your acronym becomes ODFAG and no one wants to make games with an odd fag ^^ (no offense intended)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 26, 2014, 12:06:15 pm
Ok if you're not convinced that we can create a common framework for every kind of games and if you thing it'll fail, it's your problem, but it's sure it'll take a long time and I don't force another ones to use another framework for 3D games or 2D games if they are not convinced but the'll have to re-encode everything if they need to create a new game.

The actual gaming industry is so varied now, that we cannot survive which only one kind of game.
Moreover it becomes very difficult to find a king of game which is unique.
Each studio now have at least 2 different game to offer to they clients.
If I remember the discussion about the Sorrok project it takes severals mounths to find out an unique gameplay.
So I think that it's no more the use of the library and the kind of game which can make the difference in the market actually.

What is different in each kind of game results on only three things : (If I resume everything)

-The gameplay.
-The graphisms.
-The sounds.

So I just want to have to change only this think if I want to create a new game, and not to have to reimplement all the networking and physic's if I pass from a 2D to a 3D game by example. (And to readapt the code because the libraries are not the same, it's really a wast of time to do that)

So I need more flexibility as you said just above. :)





Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 26, 2014, 03:53:44 pm
Re, in the next version (I'll include the 3D, and I've already begin to do that and modifying SFML to do that)

I'll try to rewrite the depth with a fragment shader to also do a test with the alpha component of each  pixels, and try to do only one draw for all entities using the same texture without having artefact effects with textures which are semi-transparent.
Because having so much draws to draw the ground I don't thing it's really good for the performances.

So I'll use the odfaeg::RenderTarget and odfaeg::RenderWindow in the 3D module classes to optimize the render time I think rather than using the sfml classes of the sfml graphic module.

I've found in interessant technique at this link :
http://www.gamedev.net/topic/546977-how-to-perform-depth-test-in-pixel-shader/ (http://www.gamedev.net/topic/546977-how-to-perform-depth-test-in-pixel-shader/)

But I don't know if it's possible, I've never tested.







Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lo-X on February 26, 2014, 04:04:53 pm
Wait... I thought your framework was... a framework, meaning that it would work with our default SFML installation ...? If you do need to alter SFML, does it mean we have to have this altered version ? If yes, sorry but nobody will do that.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: MadMartin on February 26, 2014, 04:33:09 pm
For someone's own learning purposes (learning by doing) it could be a good idea to write such a framework. But from a possible user's point of view I only can say that this project grows more and more into YAGNI.
I'm sorry, Lolilolight, but with your current development philosophy I guess there won't be many persons interested in your framework.

Asides, I wish you good luck and motivation to continue  ;)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Jesper Juhl on February 26, 2014, 04:56:09 pm
I'm sceptical.
I don't think it's possible to create a framework that will work equally well to implement tic-tac-toe, pacman, a MUD, World of Warcraft, Kings Quest, Myst, Quake and more. But please, do surprise us.
At the very least - if you want to gain users - you should write example games of extremely different genres using your framework, to show that it is possible.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on February 26, 2014, 07:38:34 pm
Quote
I'm sceptical.
I don't think it's possible to create a framework that will work equally well to implement tic-tac-toe, pacman, a MUD, World of Warcraft, Kings Quest, Myst, Quake and more. But please, do surprise us.
At the very least - if you want to gain users - you should write example games of extremely different genres using your framework, to show that it is possible.

Ok, I'll do that I've just to finish the 3D part for the games like quake for example. ^^

And for those who thinks that this framework'll not interess everyone, I'll just answer this : I don't care if this framework allow me to create games of different extremely different genres.



Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Deathbeam on March 01, 2014, 01:26:14 pm
Don't say that I'm doing another framework like my competitors again, please, when you don't know what I'm doing, thor don't use a 2D isometric perspective!!! (And the SFM-game book too)
So It's not that I don't want to listen to the advices of the other which have made a good framework. (I don't want to blame them)
But one library use a particule system, a resource holding system and a good action system (the thor library) but not 2D isometric perspective and an entity manager, another library use only GUIs (SfGui), another only the network (sfNul), others one only entity managers and other only the 3D without the SFML phylosophy and code design. (Irrlicht, Ogre, etc...)
I want to regroup all this libraries into a framework, that's why I've created ODFAEG, to simplify the things and to make it all faster.

And I don't thing there is actually a framework which do all of that with SFML.
For the moment you are just able to create small 2D or 2D isometric games, that's right.
But as I say, 3D games and multiplayers games'll come in the next versions, so, plz be patient.

I want to make a framework adapted for every game as you said, it's something unique because I don't know a framework which allow us to do that. (2D, 2D isometric and 3D game with the same framework)

You are always forced to use a different framework for each kind of game and sometimes several frameworks, and their simplicity and code design doesn't always follow the phylosophy of SFML)

So don't worry about that, later, you'll be able to create 3D FPS and big 3D mmorpgs like in this example :

http://linor.fr/tutoriaux/sommaire-3-creation-un-jeu-video.php (http://linor.fr/tutoriaux/sommaire-3-creation-un-jeu-video.php)

I've just to implement the code of all my projects into the framework but before to do that I want to have a stable version with only one kind of game. :)

But my priority for the moment is my Sorrok project, and even without an example for another kind of game you should be able to do another kind of 2D game (and  3D game in the next framework version) with the framework. :)

The use of the framework isn't so complex, I'll post a pdf on the git-hub. :)


(y) If I will know atleast a bit of C++, I can safely say that I would choose this your framework for my game. I like what you are doing, and who cares if it is a bit more complex. When anyone wanna make game, they should not be lazy ****** to avoid some complexity when it will work.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: therocode on March 01, 2014, 02:29:36 pm
(y) If I will know atleast a bit of C++, I can safely say that I would choose this your framework for my game. I like what you are doing, and who cares if it is a bit more complex. When anyone wanna make game, they should not be lazy ****** to avoid some complexity when it will work.

There is a difference between good complexity and bad complexity. Also, what the complexity in ODFAEG makes to "work" would work as well with much less complexity with no drawback in practice. When using external libraries and even working with your own code, avoiding complexity saves so much time and headaches.

Whenever I look for a library to use, the complexity of the API is a key thing that I look at to pick the one that is easiest to work with (while still working etc of course!)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 01, 2014, 02:41:33 pm
The framework is not so complicated to use, I've put a tutorial in the tutorial folder. (on the git-hub)

(Only the last chapter is remaining but I'll write a little 2D isometic game and then Write a 3D fps for the next version.)

Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 02, 2014, 01:00:33 pm
Hi!

New functionnality : an alpha test and a depthtest with shaders!

I was trying hard to find a solution to get rid of the depth sorting.

And I thing that I've found one, but, it needs the support of shaders and fbo.

So I've kept the two possibilities into the framework :

The first possibility is simply by doing a z-sorting like I do yet in the map class. (It's less optimized because you have to do more calls to the draw methods but compatible with the old PCs which does'nt support shaders)

The first possibility is to choise if your PC does'nt support shaders and fbo so.

The second possibility is to use a shader to store the depth value and the colors of the pixels of the screen into rendertextures like this : (The class with do that is called TileMap and we just have to pass to the tilemaps objects, a pointer to the current view, and optionnally a zorder (tilemaps can also be drawn with a special order))
A tilemap is flat so there is no depth value. (It's just represent the current framebuffer and depthbuffer values)


#ifndef TILEMAP
#define TILEMAP
#include "renderTexture.h"
#include "tile.h"
namespace odfaeg {
    namespace g3d {
class TileMap : public Drawable, public Transformable
{
public:
    TileMap (View* view, int zOrder = 0) :
        Transformable (Vec3f (view->getPosition().x, view->getPosition().y, zOrder), Vec3f(view->getSize().x, view->getSize().y, 0), Vec3f(view->getSize().x * 0.5f, view->getSize().y * 0.5f, 0)) {
        this->zOrder = zOrder;
        depthBuffer.create(view->getSize().x, view->getSize().y, true);
        frameBuffer.create(view->getSize().x, view->getSize().y, true);
        depthBufferGenerator->loadFromFile("Shaders/vertex_shader.vert", "Shaders/depthTextGen.frag");
        frameBufferGenerator->loadFromFile("Shaders/vertex_shader.vert", "Shaders/fragment_shader.frag");
        depthBuffer.setView(view);
        frameBuffer.setView(view);
    }
   
    static void clearBufferBits(sf::Color color) {
        frameBuffer.clear(color);
    }
    static void clearDepthBits() {
        depthBuffer.clear(sf::Color(0, 0, 0, 0));
    }

    bool load(const std::string& tileset, sf::Vector2u tileSize, std::vector<Tile*> tiles, unsigned int width, unsigned int height)
    {
        // load the tileset texture
        if (!m_tileset.loadFromFile(tileset))
            return false;

        // resize the vertex array to fit the level size
        m_vertices.setPrimitiveType(sf::Quads);
        m_vertices.resize(width * height * 4);

        // populate the vertex array, with one quad per tile
        for (unsigned int i = 0; i < width; ++i)
            for (unsigned int j = 0; j < height; ++j)
            {
                // get the current tile number
                int tileNumber = i + j * width;
                // get a pointer to the current tile's quad
                Vertex* quad = &m_vertices[(i + j * width) * 4];
                Vec2f position (tiles[i]->getPosition().x, tiles[i]->getPosition().y);
                float zOrder = tiles[i]->getPosition().z;
                Vec2f size = Vec2f(tiles[i]->getSize().x, tiles[i]->getSize().y);
                sf::IntRect subRect = tiles[i]->getTextureRect();
                // define its 4 corners
                quad[0].position = sf::Vector3f(position.x, position.y, zOrder);
                quad[1].position = sf::Vector3f(position.x + size.x, position.y, zOrder);
                quad[2].position = sf::Vector3f(position.x + size.x, position.y + size.y, zOrder);
                quad[3].position = sf::Vector3f(position.x, position.x + size.y, zOrder);

                // define its 4 texture coordinates
                quad[0].texCoords = sf::Vector2f(subRect.left, subRect.top);
                quad[1].texCoords = sf::Vector2f(subRect.left + subRect.width, subRect.top);
                quad[2].texCoords = sf::Vector2f(subRect.left + subRect.width, subRect.top + subRect.height);
                quad[3].texCoords = sf::Vector2f(subRect.left, subRect.top + subRect.height);
            }

        return true;
    }
private:
    virtual void draw(RenderTarget& target, RenderStates states) const
    {
        // apply the transform
        states.transform = getTransform();

        // apply the tileset texture
        states.texture = &m_tileset;
        states.shader = frameBufferGenerator;
        //Update the depth buffer and the frame buffer of the current frame.
        frameBufferGenerator->setParameter("depthBuffer", depthBuffer.getTexture());
        frameBufferGenerator->setParameter("frameBuffer", frameBuffer.getTexture());
        frameBufferGenerator->setParameter("texture", sf::Shader::CurrentTexture);
        frameBuffer.draw(m_vertices, states);
        sf::IntRect subRect(frameBuffer.getView()->getPosition().x, frameBuffer.getView()->getPosition().y, frameBuffer.getView()->getSize().x, frameBuffer.getView()->getSize().y);
        const_cast<TileMap*>(this)->tile = new Tile (&frameBuffer.getTexture(), frameBuffer.getView()->getPosition(), frameBuffer.getView()->getSize(), subRect, zOrder);
        states.shader = nullptr;
        target.draw(*tile, states);
        //Update the depth buffer.
        depthBufferGenerator->setParameter("depthTexture", depthBuffer.getTexture());
        states.shader = depthBufferGenerator;
        depthBuffer.draw(m_vertices, states);
    }
    VertexArray m_vertices;
    sf::Texture m_tileset;
    Tile *tile;
    static RenderTexture depthBuffer;
    static RenderTexture frameBuffer;
    static sf::Shader *depthBufferGenerator;
    static sf::Shader *frameBufferGenerator;
    int zOrder;
};
}
}
#endif // TILEMAP
 

The alpha tests and depthtests are performed into the shaders and you can re-program them, very usefull because the depth test of the default opengl pipeline is not programmable.

The vertex shader is unchanged :

/*Vertex shader utilisé pour généré la depth texture.*/
void main () {
    //Transforme la position.
        gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
        // transforme les coordonnées de texture
    gl_TexCoord[0] = gl_TextureMatrix[0] * gl_MultiTexCoord0;
        //Passage de la couleur au fragment shader.
        gl_FrontColor = gl_color;
}
 

The interressant part is in the fragments shaders : the first one update the depthbuffer, the second one do the depth and the alpha test and affect the final color of the pixel if the pixel isn't hidden by another object.

//The depth texture.
uniform sampler2D depthTexture;
/*Génère une texture de profondeur, plus le pixel est noir, plus il se situe en fond d'écran.*/
void main () { 
    // récupère le pixel dans la depth texture       
        vec4 pixel = texture2D(depthTexture, gl_TexCoord[0].xy);
        /* Si la profondeur du pixel de ce qu'on veut dessiner est plus grande que celle de la depth texture,
           alors on remet à jour notre depth texture, sinon, on laisse comme ça.*/

        float depth = 1 - gl_FragCoord.z;
        if (depth >= pixel.r)
                gl_FragColor = vec4(depth, depth, depth, depth);
        /*Voilà nous avons maintenant une rendertexture contenant la profondeur de tout les
        pixels qui ont été dessinés (dans les composantes rgba de la rendertexture)
        nous avons donc créer un depthbuffer dans une texture, c'est note depthTexture!*/

}
 
//The current depth buffer texture.
uniform sampler2D depthBuffer;
//The current frame buffer texture.
uniform sampler2D frameBuffer;
//The current texture.
uniform sampler2D texture;

void main () { 
    // récupère le pixel dans la depth buffer texture.        
        vec4 depth = texture2D(depthBuffer, gl_TexCoord[0].xy);
        // récupère le pixel dans la frame buffer texture.
        vec4 color = texture2D(frameBuffer, gl_TexCoord[0].xy);
        vec4 pixel = texture2D(texture, gl_TexCoord[0].xy);
        vec4 finalColor = gl_color * pixel;
        if (color.a < finalColor.a) {
                gl_FragColor = finalColor;
        } else if (gl_FragCoord.z >= depth.z) {
                gl_FragColor = finalColor;
        }                      
}
 

So you'll just have to test if your pc support shader and fbo, if it's the case you can put all your tiles in the tilemap and draw it, otherwise you should draw all the tiles one by one.

PS : I haven't tested this technique yet but it should works, I simply hope that the renderTexture of SFML'll support it.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: panithadrum on March 03, 2014, 07:33:19 pm
Be careful about the include guards. I would prepend ODFAEG in all the include guards (ODFAEG_TILEMAP for example).
Title: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: The Terminator on March 04, 2014, 01:46:36 pm
Why are you still using raw pointers rather than utilizing RAII? There's no argument really against using it, and it will make the library a whole lot more attractive to users.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: eXpl0it3r on March 04, 2014, 01:48:56 pm
Why are you still using raw pointers rather than utilizing RAII? There's no argument really against using it, and it will make the library a whole lot more attractive to users.
Ahh don't start it again! :D
Instead go back a few pages, he somewhere mentioned his "reasons".
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 05, 2014, 11:18:20 am
Hi, I've finished to implement my own depthtest, alpha test and blending  in a fragment shader and the result is very much better.

I thing I'll add the possibility to use the 3D even to draw 2D stuff. (It'll avoid me to do a z sorting)

It draws each semi-transparent textures without any problem.

I had just to correct the source code in my shader :

#ifndef TILEMAP
#define TILEMAP
#include "renderTexture.h"
#include "tile.h"
#include "shader.h"
namespace odfaeg {
    namespace g3d {
class TileMap : public Drawable, public Transformable
{
public:
    TileMap (View* view, int zOrder = 0) :
        Transformable (Vec3f (view->getPosition().x, view->getPosition().y, zOrder), Vec3f(view->getSize().x, view->getSize().y, 0), Vec3f(view->getSize().x * 0.5f, view->getSize().y * 0.5f, 0)) {
        this->zOrder = zOrder;
        this->view = view;
    }
    static void genBuffers(int screenWidth, int screenHeight) {
        resolution = Vec2f(screenWidth, screenHeight);
        depthBuffer.create(resolution.x, resolution.y);
        frameBuffer.create(resolution.x, resolution.y);
        const std::string vertexShader = \
        "void main () {" \
            "gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;" \
            "gl_TexCoord[0] = gl_TextureMatrix[0] * gl_MultiTexCoord0;" \
            "gl_FrontColor = gl_Color;" \
        "}";
        const std::string  depthGenFragShader = \
        "uniform sampler2D depthBuffer;" \
        "uniform vec2 resolution;" \
        "void main () {" \
              "vec2 position = ( gl_FragCoord.xy / resolution.xy );" \
              "vec4 pixel = texture2D(depthBuffer, position);" \
              "if (gl_FragCoord.z > pixel.z) {" \
                "gl_FragColor = vec4(0, 0,  gl_FragCoord.z, 1);" \
              "} else {" \
                 "gl_FragColor = gl_Color * pixel;" \
              "}" \
        "}";
        const std::string frameBufferGenFragShader = \
        "uniform sampler2D depthBuffer;" \
        "uniform sampler2D frameBuffer;" \
        "uniform sampler2D texture;" \
        "uniform vec2 resolution;" \
        "void main () { " \
            "vec2 position = ( gl_FragCoord.xy / resolution.xy );" \
            "vec4 depth = texture2D(depthBuffer, position);" \
            "vec4 color = texture2D(frameBuffer, position);" \
            "vec4 pixel = texture2D(texture, gl_TexCoord[0].xy);" \
            "vec4 finalColor = pixel;" \
            "if (gl_FragCoord.z >= depth.z) {" \
                "float delta = color.a - finalColor.a;" \
                "gl_FragColor = color + vec4(finalColor.r * delta, finalColor.g * delta, finalColor.b * delta, delta);" \
                "gl_FragColor = finalColor;" \
            "} else if (color.a < finalColor.a) {" \
                "float delta = finalColor.a - color.a;" \
                "gl_FragColor = color + vec4(finalColor.r * delta, finalColor.g * delta, finalColor.b * delta, delta);" \
            "}" \
            "}";
        if (!depthBufferGenerator->loadFromMemory(vertexShader, depthGenFragShader))
            throw Erreur(50, "Failed to load depth buffer generator shader", 0);
        if (!frameBufferGenerator->loadFromMemory(vertexShader, frameBufferGenFragShader))
            throw Erreur(51, "Failed to load frame buffer generator shader", 0);
         depthBufferGenerator->setParameter("resolution",resolution.x, resolution.y);
         frameBufferGenerator->setParameter("resolution",resolution.x, resolution.y);
    }
    static void clearBufferBits(sf::Color color) {
        frameBuffer.clear(sf::Color(color.r, color.g, color.b, 0));
    }
    static void clearDepthBits() {
        depthBuffer.clear(sf::Color(0, 0, 0, 255));
    }

    bool load(const Texture& tileset, std::vector<Tile*> tiles)
    {
        // load the tileset texture
        m_tileset = tileset;

        // resize the vertex array to fit the level size
        m_vertices.setPrimitiveType(sf::Quads);
        m_vertices.resize(tiles.size() * 4);

        // populate the vertex array, with one quad per tile
        for (unsigned int i = 0; i < tiles.size(); i++) {
                // get a pointer to the current tile's quad
                Vertex* quad = &m_vertices[i * 4];
                Vec2f position (tiles[i]->getPosition().x, tiles[i]->getPosition().y);
                float zOrder = tiles[i]->getPosition().z;
                Vec2f size = Vec2f(tiles[i]->getSize().x, tiles[i]->getSize().y);
                sf::IntRect subRect = tiles[i]->getTextureRect();
                // define its 4 corners
                quad[i].position = sf::Vector3f(position.x, position.y, zOrder);
                quad[i+1].position = sf::Vector3f(position.x + size.x, position.y, zOrder);
                quad[i+2].position = sf::Vector3f(position.x + size.x, position.y + size.y, zOrder);
                quad[i+3].position = sf::Vector3f(position.x, position.y + size.y, zOrder);

                // define its 4 texture coordinates
                quad[i].texCoords = sf::Vector2f(subRect.left, subRect.top);
                quad[i+1].texCoords = sf::Vector2f(subRect.left + subRect.width, subRect.top);
                quad[i+2].texCoords = sf::Vector2f(subRect.left + subRect.width, subRect.top + subRect.height);
                quad[i+3].texCoords = sf::Vector2f(subRect.left, subRect.top + subRect.height);
            }

        return true;
    }
    static Tile& getFrameBufferTile () {
        sf::IntRect subRect(0, 0, frameBuffer.getView()->getSize().x, frameBuffer.getView()->getSize().y);
        Tile* tile = new Tile (&frameBuffer.getTexture(), frameBuffer.getView()->getPosition(), frameBuffer.getView()->getSize(), subRect, 0);
        //tile->setCenter(Vec3f(frameBuffer.getView()->getPosition().x, frameBuffer.getView()->getPosition().y, 0));
        return *tile;
    }
    static void update () {
        sf::IntRect subRect(0, 0, depthBuffer.getView()->getSize().x, depthBuffer.getView()->getSize().y);
        Tile tile (&depthBuffer.getTexture(), depthBuffer.getView()->getPosition(), depthBuffer.getView()->getSize(), subRect, 0);
    }
    static Tile& getDepthBufferTile() {
        sf::IntRect subRect(0, 0, depthBuffer.getView()->getSize().x, depthBuffer.getView()->getSize().y);
        Tile *tile = new Tile (&depthBuffer.getTexture(), depthBuffer.getView()->getPosition(), depthBuffer.getView()->getSize(), subRect, 0);
        return *tile;
    }
private:
    virtual void draw(RenderTarget& target, RenderStates states) const
    {
        // apply the transform
        states.transform = getTransform();
        states.texture = &m_tileset;
        states.shader = frameBufferGenerator;
        //Update the depth buffer and the frame buffer of the current frame.
        frameBufferGenerator->setParameter("depthBuffer", depthBuffer.getTexture());
        frameBufferGenerator->setParameter("frameBuffer", frameBuffer.getTexture());
        frameBufferGenerator->setParameter("texture", Shader::CurrentTexture);
        frameBuffer.setView(view);
        frameBuffer.draw(m_vertices, states);
        frameBuffer.display();
        sf::IntRect subRect(0, 0, view->getSize().x, view->getSize().y);


        //Update the depth buffer.
        depthBuffer.setView(view);
        depthBufferGenerator->setParameter("depthBuffer", depthBuffer.getTexture());
        states.shader = depthBufferGenerator;
        depthBuffer.draw(m_vertices, states);
        depthBuffer.display();
        states.shader = nullptr;
        Tile& tile = getFrameBufferTile();
        //tile.setCenter(Vec3f(view->getPosition().x, view->getPosition().y, 0));
        target.draw(tile, states);

    }
    VertexArray m_vertices;
    Texture m_tileset;
    static RenderTexture depthBuffer;
    static RenderTexture frameBuffer;
    static Shader *depthBufferGenerator;
    static Shader *frameBufferGenerator;
    int zOrder;
    static Vec2f resolution;
    View* view;
};
}
}
#endif // TILEMAP
 

So I've a depthTexture (the blue component is the z value of my pixels) and a frameBufferTexture which contains all pixels which are previously drawn on the screen.

So, when I want to draw the textures I just have to do that :

#include "ODFAEG/Graphics/3D/renderWindow.h"
#include "ODFAEG/Graphics/3D/tile.h"
#include "ODFAEG/Graphics/3D/tileMap.h"
#include "ODFAEG/Graphics/3D/cube.h"
#include "ODFAEG/Math/projMatrix.h"
using namespace odfaeg;
using namespace odfaeg::g3d;

int main() {

    g3d::RenderWindow window(sf::VideoMode(800, 600), "TestODFAEG", sf::Style::Default, sf::ContextSettings(32));
    View view (800, 600, 10, Vec3f(0, -1, 0));
    window.setView(&view);
    view.scale(-1, 1, 1);
    TileMap::genBuffers(view.getSize().x, view.getSize().y);
    Texture text;

    std::vector<Tile*> tiles1, tiles2;

    text.loadFromFile("tilesets/herbe.png");
    TileMap tm1(&view), tm2(&view);



    Tile tile1 (&text, Vec2f(0, 0), Vec2f(120, 60), sf::IntRect(0, 0, 100, 50),0);
    tiles1.push_back(&tile1);
    tm1.load(text, tiles1);
    Texture text2;
    text2.loadFromFile("tilesets/dalles.png");



     //std::cout<<text2.m_cacheId<<std::endl;
     //std::cout<<text2->m_cacheId<<std::endl;
    Tile tile2 (&text2, Vec2f(50, 25), Vec2f(120, 60), sf::IntRect(0, 0, 100, 50),-1);
    tiles2.push_back(&tile2);
    tm2.load(text2, tiles2);
    BoundingRectangle rect (0, 0, 1000, 1000);
    //tiles = generate_floor(tiles,rect);
    Cube cube(Vec3f(-1, 1, 1), 2, 2, 2, sf::Color(255, 0, 0));

    while(window.isOpen()) {
        //}

        sf::Event event;
        while(window.pollEvent(event)) {
            if (event.type == sf::Event::Closed)
                window.close();
        }
        window.clear(sf::Color(0, 0, 0));
        TileMap::clearBufferBits(sf::Color(0, 0, 0));
        TileMap::clearDepthBits();
        window.draw(tm1);
        window.draw(tm2);
        TileMap::update();
        window.display();

    }

    return 0;
}
 

The view : the two first parameters are the view's width and height, the thirst is the max Z value, and the last the direction of the head of the view.

So -1 as y gives me a view which point at the bottom.

I do a scale(-1, 1, 1) on the view them because otherwise the x coordinates are inverted.

Then I gen the buffers of the TileMap. (And I pass it the resolution)

After I create the tileMaps and I pass them the current view and the Tiles.
Finally I clear the depth and framebuffer textures before drawing the tilemaps at render Time.
I've to call the TileMap::Update() function otherwise the first tilemap doesn't display. (I don't know why)

PS : this is -1 and not 1 for the z value of the second tile because the zAxis point to us with opengl.






Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 05, 2014, 01:26:34 pm
I've found the bug!!!

The states.transform = getTransform() was in the wrong place :

virtual void draw(RenderTarget& target, RenderStates states) const
    {
         states.texture = &m_tileset;
        states.shader = frameBufferGenerator;
        //Update the frame buffer and draw the current frame.
        frameBufferGenerator->setParameter("depthBuffer", depthBuffer.getTexture());
        frameBufferGenerator->setParameter("frameBuffer", frameBuffer.getTexture());
        frameBufferGenerator->setParameter("texture", Shader::CurrentTexture);
        frameBuffer.setView(view);
        frameBuffer.draw(m_vertices, states);
        frameBuffer.display();
        //Update the depth buffer.
        depthBuffer.setView(view);
        depthBufferGenerator->setParameter("depthBuffer", depthBuffer.getTexture());
        states.shader = depthBufferGenerator;
        depthBuffer.draw(m_vertices, states);
        depthBuffer.display();
        states.shader = nullptr;
        states.transform = getTransform();
        Tile& tile = getFrameBufferTile();      
        target.draw(tile, states);

    }
 

So now to optimizate that I've just to reimplement the cllmap, gridmap and map classes for the 3D. (And I can get rid of the z sorting)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lo-X on March 05, 2014, 01:39:08 pm
to optimizate

Well done for your bug.

Now, Nathalie tells me "optimizate" is not defined, did you mean "optimize" :) ?
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: zsbzsb on March 05, 2014, 02:08:38 pm
const_cast<TileMap*>(this)->tile = new Tile (&frameBuffer.getTexture(), frameBuffer.getView()->getPosition(), frameBuffer.getView()->getSize(), subRect, zOrder);

Lolilolight, I really doubt you understand how bad this code is, you really need to use smart pointers (at the moment you have a major memory leak) and learn how to correctly use const_cast. This is just one of the many examples throughout this thread as to why people will most likely not be using your framework.

Even about the z-order sorting, its really not that difficult if you use some of the already built stl containers instead of reinventing the wheel using some crazy shader workaround (hack in my book).

states.transform = getTransform();

Even this is not really the correct way to use the transform, you should be using the *= operator.  :P

And take this from a mainly C# dev, even I can see major issues with your code.  ;)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 05, 2014, 03:11:04 pm
 I've no memory leaks on my PC so, I don't know exactly what you mean...., I can't use smart pointer everywhere because of premature destruction. (With the signal and slot functions)

I do already the * in the odfaeg::transformMatrix class instead of the sf::Transform class (because I need also to have 3D transform) :P

And I've get rid of all the const_cast.

PS : I don't do a z-sorting but I've to do a vector of vector so I prefer reduce the number of std::container used by using a shader.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: eXpl0it3r on March 05, 2014, 03:43:56 pm
I've no memory leaks on my PC so, I don't know exactly what you mean...., I can't use smart pointer everywhere because of premature destruction.
At least you have a fitting nick: Lol ;)

How exactly are you cleaning up your allocation mess, because I can't find any delete anywhere:
(http://i.imgur.com/qwjjKWr.png)

Plus, you can ask any C++ programmer and they will tell you, that things like the following are not how you write proper C++ (see here (http://stackoverflow.com/a/7167674/1034248) and here (http://stackoverflow.com/a/19394522/1034248)):
static Tile& getX()
{
    Tile *tile = new Tile(...);
    return *tile;
}

You should seriously go through the book list provided in that SO thread (https://stackoverflow.com/questions/388242/the-definitive-c-book-guide-and-list). It's not like we pull all this advice from thin air, but they come from people that do scientific research on all of these topics, or people that keep shaping the C++ standard or even from the creator of C++ himself. ;)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 05, 2014, 07:40:52 pm
I have still to change the view right, I'll return a reference of the view instead of a pointer.

For static variables, aren't there destroyed automatically ?

I can't destroy them because there are not linked to an object...
But, I think I'll add a function which'll destroy the static variables when I'll close the appi. (I need some of static variables anyway for the Network, the World, the Pipeline and other objects which have to be unique in the framework)

And, I suppose I have to read some threads a bit.

But I already know that I'had to clean up my code a bit, all that I wanted to have until now was something with works. (And which is amore optimized)
Because my previous code was too slow. --' (And with the networking it was worth)

Even with the STL container it was still a bit too slow. (Because I had too many draw and I have a lot of matrix multiplication to do with the scene node, and then I'll have to implement the particuel system, the network and the rest of the 3D, so I need to have a fast rendering time. ;) )

And faster than what the default SFML functions and opengl pipeline does.

It's not like blender or other opensource projects when they don't care about the rendering time which can be very very long.
And I'm sure that every games use their own pipeline. (Except on PCs which doesn't support shadersof course)

I've played at many f2p games but it was very too slow and sometimes I'had memory leaks too.

So my Pc was very slow at the end of the day. (Because the games consume too much resources)

I've not this problem with ODFAEG. :)

I've not a big game yet but framework is finish soon so, if the root is solid, the rest should be good.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: wintertime on March 05, 2014, 09:19:20 pm
For static variables, aren't there destroyed automatically ?
Thats a static function, not a static variable. :-X
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on March 06, 2014, 11:57:25 am
I've played at many f2p games but it was very too slow and sometimes I'had memory leaks too.

So my Pc was very slow at the end of the day. (Because the games consume too much resources)

I've not this problem with ODFAEG. :)

Mate, when you close an application, pretty much any major OS will cleanup all resources used by the process.. That doesn't make a lot of sense (except perhaps if you're saying the memory was a bit too fragmented?)..
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 06, 2014, 10:11:26 pm
Quote
(except perhaps if you're saying the memory was a bit too fragmented?)..

Yes.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 07, 2014, 02:19:38 pm
Hi guys.

Finally I don't think I'll launch a release yet, I'll finish all the functionnalities so I'll be able to show you exemple of very different game genres created with ODFAEG. (Because apparently this is what interest you)

It'll be useless to launch a realease which do the same things that existing library.

The framework is maybe a bit more complexe and I don't use 3 kind of matrix but 4. (base changement matrix, projection matrix, view matrix and transformation matrix.)

The base changement matrix is used to pass from one landmark to another. (Example : 2D to 2D isometric landmark.)

The projection matrix is used to pass from view coordinates to eyes coordinates. (Example : 3D view coordinates to perspective projection coordinates.)

The view matrix is used to pass from world coordinates to view coordinates.

And the transformation matrix is used to apply transformations to each objects.

But hopefully I've implemented some classes which already do all the job for you.
Actually I'm finishing to work out the 3D view class and my own pipeline. (To be able to render semi-transparent object with a depth test)

So It become very easy to display sem-transparent objects with the framework, you have just to put the faces of the objects into the pipeline when you update the current frame and draw everything which only one draw.

I'll finish this part so, I've not so many things to implement what's only remain is :

-The networking. (I've already a system which movement prediction but I've to rework the code a bit and put it to the framework)

-The particule system. (I'll re-use the thor classes which seems to be fine. :) )

And the rest is the 3D part, I just need to implement a terrain generator. (I'll certainly do an heightmap and a raytracing to select objects (I've already done one in another project.))

A shader to render shadows and lights.

A 3D objects loaders and normally that's all.

The last complicate thing that I've to do is bones animations. (Fof example when I move the hand of the caracter, the glove moves with it.)

But it should be and I'll be able to launch the final release in 2016 I hope because I'll resume classes soon.

I'll update the git-hub repository this evening because I've made some changement in the 3D part and I've added the own framework pipeline.

I've clean up the code a bit to get rid of the bad code. (By making the Entity class copiable, it's not a problem because this lass is not heavy.)











Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 08, 2014, 03:39:02 pm
Hi guys, I've updated the git-hub repository yesterday with the tilemap class and now I'm working on adapting the EntityManager to store 3D entities.

3D entity managers and bounding volumes'll have the advantages to allow to store and manage collisions with 3D and 2D entities. (For 2D entities, the depth of the gridMap'll cells and the bounding volumes'll be 0)

But unlikely the 2D entity managers, I can't store the z component of 3D objects in the stl container because the z component of all objects vertices is not the same.
Most of all, I need the opengl z interpolation of the pixels between the objects vertices.
So I need to do a test per pixel and not per entity like in 2D.

So ODFAEG'll provides two ways to manage the rasterisation.

-The first one is to activate the opengl depth test and alpha test if you have transparent objects. (But it'll not work with semi-transparent objects because if the alpha component of an object's pixel is less greater than an other object's opaque pixel wich is behind the semi-transparent pixel object's, the opaque pixel'll be hidden by the opengl depth test or we should see throw the semi-transparent pixel)
I had to find a solution so and this solution is to draw all visible objects on a framebuffer texture by applying a shader on this rendertexture which'll do the depthtest, the alpha test and the alpha blending.
Then I create a tile which the texture of the rendertexture and I draw it.

-The second method is to use the TileMap class of ODFAEG to render 3D visible objects.

Once I'll have finished that, I'll create a particule system, the network and then 3D terrain and 3D objects management and that'll be ok for the last release.




Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on March 08, 2014, 05:36:57 pm
will you make a 3D game to use all those features? =)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 08, 2014, 06:15:41 pm
Quote
will you make a 3D game to use all those features? =)

Yes exactly, I've pretty finished the 2D part so now I need 3D features and I'll make a 3D FPS to test the 3D features.

And then finish my 2D hack and slash in 3D iso, and  my full 2D small games of course. ^^



Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 11, 2014, 01:25:14 pm
Hi guys, actually I need to rewrite all the SFML classes of the graphic module to display also 3D Shapes, 3D Tiles, etc...

I'll probably add ellipsoïd and curves but it's not a priority.

For 3D text I don't know, I've to look into the 2D sfml Font and text classes to see if I can implement that functionnality. (It's one of the rare things that I've never tried but it'll be very interesting to learn. ^^)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 16, 2014, 04:36:30 pm
Hi, I'll update the git-hub soon, I've tested ODFAEG on linux and it seems to work. ;)

My tilemap system seems to also works, so, I'll add a new functionality which'll choose the most optimized way to render the current frame depending on which functionalities that the hardware support. (But most of all on  recent PC it'll be the ODFAEG Tilemap and 3D ODFAEG support classes which'll be used. ^^)

I need to have big f2p games on linux like it's the case for windows. (Because I prefer linux. ^^)

Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on March 16, 2014, 05:51:45 pm
I need to have big f2p games on linux..

What do you mean?
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 16, 2014, 06:18:49 pm
My graphical card driver on window is actually dead and it's quite annoying to do reinstallations because of a virus, pub spamming or a wrong driver. (And I don't have the installation cd because he's no more provided by the vendor, so I'll have to crack windows...)

In linux you know where find the right software directly (thanks to the apt repository), it's free so you haven't the license problems and you don't waste time to find a good website for an application or a driver.
And if the appli isn't in the apt repository, if you download bad sofware and pub integrated in the dowload you'll be sure that linux'll block it. (It's not the case with window so my window has become a real mess)

Windows is only good for gaming, because wine doesn't work very well with windows applications and windows applications aren't made to work on linux anyway. (Because they only want to avoid to loose their clients)

I'm quite disappointed of that so it's why I would like to create an f2p which works well on linux. (Because it's quite annoying to be forced to go on windows only to play at your favorite game)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: panithadrum on March 16, 2014, 07:29:49 pm
I think he means he wsnts to create f2p games that work in Linux
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 16, 2014, 09:03:25 pm
Is there a system restaure on linux ? (Like on window)
Title: AW: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: eXpl0it3r on March 16, 2014, 09:10:30 pm
Is there a system restaure on linux ? (Like on window)
Why don't you ask somewhere else? This forum is about SFML and not some general help forum. ;)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 16, 2014, 09:26:18 pm
Ok
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 17, 2014, 12:16:59 pm
Major improvements are coming!

Hi, for the 3D my entity manager is not sufficient so I've create a new one :

-The application class'll choose the render classes and the opengl options which'll be used for the 3D or the 2D rendering. (you'll just have to specify if it's a 3D or a 2D application)

For the 2D : if shader aren't avalaible this is the sf::RenderWindow class which'll be used, otherwise this'll be the odfaeg::RenderWindow class.
In case 1 : the entities'll be inserted by their layer's positions into the visible entity vector, otherwise they'll be inserted by their texture.

For the 3D it'll always be the odfaeg::RenderWindow which'll be used and the entities'll always be inserted by their texture, but if the shader aren't avalaible the deth and alpah test'll be activated.

I'll rename the class Tile to the class Face because sprite and tile aren't not the same, sprite are simply textured quads entities, faces are'll be able to use any king of primitive type and they are attached to an entity.

The odfaeg entity manager'll simply regroup every faces using the same texture into the same tilemap and'll return all these tilemaps.

the world class'll be modified and'll be used to do the abstraction between all the entity managers types and entity system types used and the developper. (So the developper'll only have access to the function of the classe world to create the maps.)

Each entity manager'll be able to have a different view.

So the developer'll not have to know which entity manager and which renderwindow he must use if the shader are avalaible or not.











Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on March 17, 2014, 12:22:45 pm
I'm pretty sure this is the most game specific library I've seen, it is NOT suited for most games as claimed :p

Why don't you learn first what a traditional 3D engine looks like and also a 2D one? Look at Unity and other good engines and try to do what they do, achieve a design that fits most games you can imagine.. I'm sure you would have better results..
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 17, 2014, 05:58:45 pm
I know what a traditional 2D or 3D engine looks like, it's why I want to combine the techniques of a 2D and a 3D engine to be able to create many different games genres.




Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on March 17, 2014, 09:08:03 pm
I'm hanging on to see one good sample  :D
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 18, 2014, 02:51:00 pm
Yeah I know but it'll take time because I have computers which support functionnalities than other doesn't support. (By example my oldest computer don't support FBO and shaders)

So I need to have very specific classes for each supported functionnalities. (It's not always the case with actual frameworks or libraries) :

-JOGL doesn't work on my PC if I use swing and some javaclass which lead to concurrent thread exceptions. (Same for each framework using JOGL)
-QtSockets doesn't work on my plateform.
-Unity, Irrlicht and other c++ framework doesn't use SFML, so, I'm forced to use their entity system and I don't really need them for simple 2D games. (I prefer don't use GLSL if my  Pc doesn't support shaders and fbo and use ASM shaders by example, but I'll not make that here because I very suck in ASM, but in case of someone want to do it...)

So I've a class called "World" which use different EntityManagers type depending on which functionnalities are supported. (So I can use shaders or not, if the PC support shaders, the effects'll just be more beautifull.)

Here is an example (I use the crtp pattern) :P
#ifndef WORLD_H
#define WORLD_H

#include <SFML/Graphics.hpp>
#include "../Graphics/3D/view.h"
#include "../Graphics/2D/entityManager.h"
#include "../Graphics/3D/entityManager.h"
namespace odfaeg {
class EntitiesUpdater;
class AnimUpdater;
class World {
    public :
        static void createEntityManager (sf::View &view, std::string name, int cellWidth, int cellHeight, int cellDepth);
        static void createEntityManager (g3d::View &view, std::string name, int cellWidth, int cellHeight, int cellDepth = 1);
        static void removeEntityManager(std::string mapName);
        static void setCurrentEntityManager(std::string name);
        static void update();
        static void checkVisibleEntities();
        template <typename E>
        static std::vector<E*> getVisibleEntities (std::string expression);
        template <typename E>
        static bool containsMovableVisibleEntity(E *ae) {
            if (!ae->isMovable())
                return false;
            if (currentEntityManager->isG2DEntity())
                static_cast<g2d::EntityManager*>(currentEntityManager)->containsMovableVisibleEntity(ae);
            else
                static_cast<g3d::EntityManager*>(currentEntityManager)->containsMovableVisibleEntity(ae);
        }
        template <typename E>
        static void removeVisibleEntity(E* entity);
        template <typename E>
        static void insertVisibleEntity(E* entity);
        virtual ~World();
    private :
        static std::vector<EntitiesUpdater*> eus;
        static std::vector<AnimUpdater*> aus;
        static std::vector<EntityManagerHolder*> ems;
        static EntityManagerHolder* currentEntityManager;
};
}
#endif
 

g3d::EntityManager use a shader but g2d::EntityManager doesn't use a shader.

I'll put some items into the class Application (the command system, the view, etc...) and the developper'll just have to inherits from this class, redefining some methods to render, build and update the world.

#ifndef APPLICATION
#define APPLICATION
#include <SFML/Graphics.hpp>
#include "resourceCache.h"
#include "../Graphics/3D/renderWindow.h"
#include "../Graphics/3D/renderStates.h"
#include "system.h"
#include "../Graphics/3D/tileMap.h"
namespace odfaeg {
class Application {
public :
    Application(sf::VideoMode vm, std::string title, bool g2dAppli, sf::Uint32 style = sf::Style::Default, sf::ContextSettings settings = sf::ContextSettings()) {
        if (g2dAppli) {
            if (sf::Shader::isAvailable()) {
                ODFAEGWindow = new g3d::RenderWindow(vm, title, style, settings);
                g3d::View& view = ODFAEGWindow->getView();
                view.setUpVector(Vec3f(0, -1, 0));
                view.scale(-1, 1, 1);
                view.move(-ODFAEGWindow->getSize().x * 0.5f, -ODFAEGWindow->getSize().y * 0.5f, 0);
            } else {
                SFMLWindow = new sf::RenderWindow(vm, title, style, settings);
            }
        } else {
            if (sf::Shader::isAvailable()) {
                ODFAEGWindow = new g3d::RenderWindow(vm, title, style, settings);
            } else {
                ODFAEGWindow = new g3d::RenderWindow(vm, title, style, settings, true);
            }
        }
        clearColor = sf::Color(0, 0, 0);
        app = this;
        running = false;
    }
    void move(float x, float y, float z = 0) {
        if (ODFAEGWindow != nullptr)
            ODFAEGWindow->getView().move(x, y, z);
        else
            SFMLWindow->getView().move(x, y);
    }
    int exec() {
        load();
        running = true;
        while (running) {
            render();
            update();
        }
        return EXIT_SUCCESS;
    }
    void stop() {
        running = false;
        if(SFMLWindow != nullptr)
            SFMLWindow->close();
        else
            ODFAEGWindow->close();
    }
    void load() {
        if (SFMLWindow != nullptr)
            g3d::TileMap::genBuffers(SFMLWindow->getSize().x, SFMLWindow->getSize().y);
        else
            g3d::TileMap::genBuffers(ODFAEGWindow->getSize().x, ODFAEGWindow->getSize().y);
        onLoad();
        onInit();
        running = true;
    }
    virtual void onInit() {}
    void render() {
        g3d::TileMap::clearBufferBits(sf::Color(0, 0, 0));
        g3d::TileMap::clearDepthBits();
        if (SFMLWindow != nullptr) {
            SFMLWindow->clear(clearColor);
        } else {
            ODFAEGWindow->clear(clearColor);
        }
        onRender();
        if (SFMLWindow != nullptr) {
            SFMLWindow->display();
        } else {
            ODFAEGWindow->display();
        }
    }
    void update() {
        sf::Event event;
        if (SFMLWindow != nullptr) {
            if (SFMLWindow->pollEvent(event)) {
                onUpdate(event);
            }
        } else {
            if (ODFAEGWindow->pollEvent(event)) {
                onUpdate(event);
            }
        }
        listener.pushEvent(event);

    }
    void draw(sf::Drawable& drawable, sf::RenderStates states = sf::RenderStates::Default) {
        if (SFMLWindow != nullptr)
            SFMLWindow->draw(drawable, states);
    }
    void draw(g3d::Drawable& drawable, g3d::RenderStates states = g3d::RenderStates::Default) {
        if (ODFAEGWindow != nullptr) {
            ODFAEGWindow->draw(drawable, states);
        }
    }
    virtual void onLoad (){}
    virtual void onRender (){}
    virtual void onUpdate (sf::Event &event) {}
    void addClock(sf::Clock clock, std::string name)  {
        //std::map<std::string, sf::Clock>::iterator it = clocks.find(name);
        /*if (it != clocks.end())
            throw Erreur (13, "This clock already exist!", 0);*/

        clocks.insert(std::pair<std::string, sf::Clock>(name, clock));
    }
    sf::Clock getClock(std::string name) {
        std::map<std::string, sf::Clock>::iterator it = clocks.find(name);
        if (it == clocks.end())
            throw Erreur (14, "Clock not found!", 0);
        return it->second;
    }

    ResourceCache& getCache() {
        return cache;
    }

    void setClearColor(sf::Color clearColor) {
        this->clearColor = clearColor;
    }
    static bool isG2dAppli() {
        return g2dAppli;
    }
    static Application* app;
private :

    sf::RenderWindow *SFMLWindow;
    g3d::RenderWindow *ODFAEGWindow;
    std::map<std::string, sf::Clock> clocks;
    Listener listener;
    ResourceCache cache;
    static bool g2dAppli;
    bool running;
    sf::Color clearColor;
};

}
#endif // APPLICATION
 

The sf::Event'll be passed at the derived application, the developper'll be able so to retrieve event's informations and the application'll pass each sf::Event to the listener which'll execute each actions.



Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on March 18, 2014, 05:35:24 pm
What kind of design is that? How does the entity manager know whats visible or not in the world? You really should try to encapsulate things better.

For example, you could have a renderer class which knows about the camera and the scene, and can therefore do culling by itself.. Just a suggestion
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 18, 2014, 08:52:23 pm
No because the world can have more than one entity manager so..., but the developper'll have to select the entity manager before working with it.

World::setCurrentEntityManager("entityManagerName");
 

The same things goes for the camera, I've more than one camera. (It depends of the game perspective)

So the framework have to create the right entitymanagers and the right camera depending on the hardware support..., and the game perspective... (The World class create the right entity manager and the Application class create the right camera and renderwindow)
And the entity systems have to update the current entity manager.
I've also to change the vertex position in perspective projection because I've coordinates between -1 and 1 with the perspective projection and between 0 and screenresolution with the pespective projection.

I would like to always have coordinate between 0 and screenresolution for the culling.

But the world knows about the camera and the scene so...





Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 19, 2014, 11:36:35 am
Hi!

I've passed the renderwindow to the entity manager in the world.

So the shadows and lights are rendered differently depending on the hardware support (By rendertexture or by printscreen)

I'll add a render function in the class world whitch'll render the current frame.





 

Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 19, 2014, 02:08:01 pm
Finally I think I'll only use my own classes to draw 3D or 2D objects with 3D vertices and get rid of SFML.

It'll be better.

It'll only use SFML for the sound and the network.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 23, 2014, 12:16:26 pm
Hi!

I've done some tests in these days and there are concluant.

The entity manager store now each 2D or 3D objects with the same primitive type and texture in a class before drawing it on an rendertexture. (It's faster. :P)
The map class'll also be able to create the shadow and the lightmap.

And the entity manager choose the best options to render the scene, depending on the hardware support.

If shader are supported, an alpha test is performed : (I had to change the shader a bit)

 "uniform sampler2D depthBuffer;" \
            "uniform sampler2D frameBuffer;" \
            "uniform sampler2D texture;" \
            "uniform vec2 resolution;" \
            "void main () {     " \
                "vec2 position = ( gl_FragCoord.xy / resolution.xy );" \
                "vec4 depth = texture2D(depthBuffer, position);" \
                "vec4 color = texture2D(frameBuffer, position);" \
                "vec4 pixel = texture2D(texture, gl_TexCoord[0].xy);" \
                "vec4 finalColor = pixel;" \
                "if (gl_FragCoord.z >= depth.z) {" \
                    "gl_FragColor = finalColor;" \
                "} else if (color.a < finalColor.a) {" \
                    "gl_FragColor = finalColor;" \
                "}" \
            "}";
 

Otherwhise the objects are sorted by their layer's position for 2D objects.

The same thing happens for 3D objects, excepts that if the shaders aren't support, an internal opengl depth test and alpha test is performed. (But it doesn't work with semi-transparent pixels of coursewith the 3D)

All entity managers and entities systems are now stored in the class World, and the developper'll be able to to store and access to 2D or full 3D entity managers and systems through the world static class everywhere in the source code, the world class have also some usefull functions, and the rendering loop have been simplified :

std::vector<Entity*> entities = World::getVisibleEntities<Entity>("E_TILE");// draw everything here...
            for (unsigned int i = 0; i < entities.size(); i++) {
                    getRenderWindow().draw(*entities[i]);
            }
            entities = World::getVisibleEntities<Entity>("E_WALL+E_DECOR+E_CARACTER+E_PONCTUAL_LIGHT");
            Entity& shadows = World::getShadowMap<Entity>();
            getRenderWindow().draw(shadows, BlendMultiply);
            // draw everything here...
            for (unsigned int i = 0; i < entities.size(); i++) {
                    getRenderWindow().draw(*entities[i]);
            }
            Entity& lights = World::getLightMap<Entity>();
            getRenderWindow().draw(lights, BlendMultiply);
 

The call of the window.clear and window.display functions aren't necessary anymore because it's done in the base application class.

I'll update the git hub when I've corrected all the remaining bugs, I need to have a simple way to generate and display entities before implementing the network and doing some tests on a remote server.

But I found this code more simplier than before and the developper'll not have to worry about which entity to use to render the scene correctly with the supported hardware and the game perspective.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on March 23, 2014, 01:25:17 pm
Is concluant a english word?
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lo-X on March 23, 2014, 01:44:42 pm
Is concluant a english word?

Event if it's the root of an english word, it's not english itself :) I think he meant "concluding"
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on March 23, 2014, 03:01:01 pm
I see.. So, is that also the 3D engine for any game? The snippets you've been showing?
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 24, 2014, 06:51:57 pm
Yes I meant concluding and not concluant.

I've sorted the graphic engine :

There are 3 engines for the graphics:

The 2D engine which'll be contained in the odaeg::g2d namespace.

The 3D engine which'll be contained in the odfaeg::g3d namespace. (Not finished yet)

And the global graphics engine which'll render all the objects of the two first engines.

-The global engine'll contains the render window, the view, the textures, the vertices and all objects used to render a 2D or a 3D scene at the screen (It's the SFML graphics internal classes that I've rewritten to draw 3D vertices)
-The 2D engine contains the 2D entity manager, and all the 2D entities of the framework.
-The 3D engine'll contains the 3D entity manager and all 3D entities of the framework.

This is currently how it'll works once I'll update the git-hub.

The SFML rendering classes'll not be used anymore. (Even 3D objects'll be rendered with 3D vertices, I need that to manage the tilemaps)





Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on March 24, 2014, 08:24:11 pm
Can you already make a simple FPS shooter with it? :)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 24, 2014, 09:10:46 pm
No, not for the moment but soon.
I've still to implement the 3D terrain generation and the 3D object loader, and after that normally you'll be able to create a simple fps.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 27, 2014, 11:59:51 am
I've improved some things and I'll update the git-hub repository this evening!

-Now, animations have children entities, animated entities can have another animated entities as children.

The interest is that you'll now be able to create bones animations, which each bone is a child of a parent animation. (And you can change children animated entity properties at each frame of the parent animation)

It's also usefull if an entity have several animations (a caracter for exemple which can attack, move, etc...)

-The entity manager can'll now choose the best way to render the scene, it depends if your PC support shader and render texture opengl functions or not.

So you don't have to care about the opengl functionnalities that your PC support.

But there is still a bug : the shadows aren't drawing but I'll correct that bug later, now, I would like to do network tests to implement the network module.

(Things become more complicate when I draw on a render texture and then on another render texture. (It's the case for the light and shadow maps, if rendertextures aren't supported the entity manager draw directly on the render window and do screen captures))

I would like to advance faster but I don't have so much time and I'm alone.

Ho, I've forgotten, I've also undefined references problem with my rectangle shapes classes.

Well, when I've finished to correct this last bugs and to put the networking and particule system in ODFAEG, I'll be able to begin to encode 3D features. (Terrain generation, 3D object loading, 3D shapes (sphere, etc...), and shadows and lighting in 3D, I think I'll use the opengl default lighting system if the PC doesn't support shaders otherwhise I'll made a pixel per pixel lighting, but i'm totally new with this but I would like to learn more about GLSL and opengl lighting)

A last things, the entities'll be able to have collision areas or volume now.

But I'm alone to do all of this so it'll take time, but one I'll have finished all of this, I'll be able to create awesome games of all genre. :)

I'm quite happy to have a functionnal 2D graphics engine.

I think I'll also integrate a SQL driver into the framework and the QT SQL modules classes, so, I'll not have to install QT if I want to use a database.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Laurent on March 27, 2014, 12:55:30 pm
Quote
I'm quite happy to have a functionnal 2D graphics engine.
Where are the demos? You have written 10 pages of technical posts, but I don't think people care about it, we just want to see what your framework is able to achieve. Show something ;)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 27, 2014, 02:49:47 pm
Yes your're right I need to make a demo but before I have to change my tilesets a bit. :P

I even started to encode an IA for the demo but I've to rework the source code a bit to adapt the source code of the framework with the source code with my other project and it takes a bit time.

Otherwise I know that many people doesn't care about the technical part, it's why I want to hide it a lot of possible in the frawemork use.

I've started to encode the network, and the server and client classes, for the moment it supports three packets : RSAEncryptedPacket, AESEncryptedPacket and sf::Packet with udp and tpc sockets.

But this is also technical things then, I'll not elaborate this anymore, it'll be explained in more details in the tutorials.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 27, 2014, 09:03:35 pm
Git-hub updated!


I've oprimised the rendering in the entity manager, and implementing the network module.
No tutorial for the moment because I've to rewrite it and to make a demo of with the 2.5D engine.
I don't use the graphic module of SFML anymore and I use 3D vertices to render everything. (It's more simple)

SFML'll just be used for the network, the window, the events and I'll also use it for the sound.

But actually I've a problem with code block for projects using ODFAEG, code blocks show me this message every time I want to aexecute the demo :
-It seems that this projet has not been build yet. Do you want to build it now ?
I clicked on the yes button and I have this warwing messages :

Code: [Select]
||Warning: resolving _glewInit by linking to _glewInit@0|
||Warning: resolving _glewGetErrorString by linking to _glewGetErrorString@4|
||=== Build finished: 0 errors, 2 warnings (0 minutes, 1 seconds) ===|

And then, nothing happens...., code::block don't want to build my .exe anymore.  >:(

I haven't changed anything, yesterday it was executing fine but today....

I really don't understand.

I've tried to recreate a code::block projet but it didn't solve the issue.


PS : I've found the problem, I had to declarate this variable to be static :
#ifndef ODFAEG_SINGLETON_HPP
#define ODFAEG_SINGLETON_HPP
#include <mutex>
namespace odfaeg {
    static std::recursive_mutex rec_mutex;
}
#endif
 

Another thing, if I don't declare a pointer to the render texture in the class Map, it crash, same thing in the class TileMap.

Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on March 27, 2014, 09:30:40 pm
So, is this a component based architecture or you inherit entities?
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 27, 2014, 09:43:10 pm
Quote
So, is this a component based architecture or you inherit entities?

No I inherit from entity, because I've a scene graph and each entities have children and parents, and I combine transformations.

It's not like in the SFML tutorial where the node have only one child (the sf::Sprite), it's more complicate than that but more powerfull, I can put all the information in the entity node, and do collision test in the node entities or in the root entity, and don't need to use OBB-Trees or something like that and for animations it's more simple too.

I've modified my shader in the tilemap class and it work event with full 3D semi-transparent objects : (The previous code was wrong)

 "void main () {"
                "gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;"
                "gl_TexCoord[0] = gl_TextureMatrix[0] * gl_MultiTexCoord0;"
                "gl_FrontColor = gl_Color;"
            "}";
            const std::string  depthGenFragShader =
            "uniform sampler2D depthBuffer;"
            "uniform sampler2D texture;"
            "uniform vec2 resolution;"
            "void main () {"
                  "vec2 position = ( gl_FragCoord.xy / resolution.xy );"
                  "vec4 color = texture2D(depthBuffer, position);"
                  "vec4 pixel = texture2D(texture, gl_TexCoord[0].xy);"
                  "if (gl_FragCoord.z > color.z && pixel.a >= color.a) {"
                     "gl_FragColor = vec4(0, 0,  gl_FragCoord.z, pixel.a);"
                  "} else {"
                     "gl_FragColor = color;"
                  "}"
            "}";
            const std::string frameBufferGenFragShader =
            "uniform sampler2D depthBuffer;"
            "uniform sampler2D frameBuffer;"
            "uniform sampler2D texture;"
            "uniform vec2 resolution;"
            "void main () {     "
                "vec2 position = ( gl_FragCoord.xy / resolution.xy );"
                "vec4 depth = texture2D(depthBuffer, position);"
                "vec4 color = texture2D(frameBuffer, position);"
                "vec4 pixel = texture2D(texture, gl_TexCoord[0].xy);"
                "if (gl_FragCoord.z >= depth.z) {"
                    "gl_FragColor = pixel;"
                "} else if (color.a < pixel.a) {"
                    "gl_FragColor = pixel;"
                "} else {"
                    "gl_FragColor = color;"
                "}"
            "}";
 

I don't undestrand why it's not integrated in the opengl pipeline...

But there is a limitation, the value of the zFar can't be greater than 253, because, I've to use a color component to store the z value on the depthtexture.

But I don't thing it's a real problem, I've read an article to do the perpective projection matrix (but I've change the matrix a bit because it wasn't very exact)  and it was said that if the zfar valu is too great it can cause depth test precision problems.

PS : I think this'll be the final version of the graphics engine node, the rest'll only be the add of new functionnalities then. (Drawing 2D/3D shapes, 3D terrain generation, etc...)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on March 28, 2014, 01:04:46 am
Wasn't everyone concluding component based architectures are more powerful and the way to go? Also, having a scene graph is usually really bad as a primary storage for your scene data. It will be a nightmare to iterate efficiently in most cases, from what I've seen all around the web.

Ogre makes something like you do, attaching multiple items in a single node, I believe.

Wasn't there a alpha test in OpenGL? I think so (Not sure if its deprecated in latest API's).

Limiting the zFar to such a small value is really a bad thing to do. That definitely doesn't suit the "all kinds of games model", MANY 3D games implement huge zFar values to render geometry very far away. Many times over 1.000 units away I believe. Even more in cases like Arma, I think.

One question, why are you using a depth texture over a depthbuffer? Also, why don't you use the depth texture as a special kind of texture, made specifically for depths, I think the type is GL_DEPTH_COMPONENT? It works quite the same as a depth buffer I think.

I really think you are underestimating to have a fully functional 3D engine, which also does well all sorts of 2D tasks. If you suddenly realized you are only at the 0.05% progress, would you have the will to carry on until the end?
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: lolz123 on March 28, 2014, 01:43:10 am
Some suggestions:

- Don't do the depth test manually.
- Try not to use if's in a shader, especially a fragment shader. It is very slow, especially when not branching on a uniform or constant.
- Use custom attributes.
- gl_ModelViewProjectionMatrix and the associated matrix stack are deprecated AFAIK.
- You probably don't need a texture matrix.
- You don't need gl_FrontColor.
- texture2D is deprecated.
- Use VBO's.
- Use deferred shading.
- glFlush is not needed.
- The way your engine is set up will make rendering shadow maps quite difficult, since it keeps swapping the shaders on you. Unless I understand it incorrectly.

I would recommend first reading up on modern OpenGL before making a 3D engine. Something like http://www.arcsynthesis.org/gltut/ (http://www.arcsynthesis.org/gltut/)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 28, 2014, 11:14:31 am
I think I wasn't clear anought sorry, I use bot, component and scene nodes.

The component is the entity manager.

And the world contains components (entity managers) and systems which updates the entities and components that I use to draw the scene.

I need to use shaders because otherwise if I render 3D vertices with semi-transparent texture (like glass or water per example), semi-transparent object pixels hides opaque pixels.

The first fragment shader solve the first part of the problem : if the z component of the pixel that I want to draw is greater or equal to the z component of the current framebuffer's pixel I perfom an alpha test, and I only draw the pixel on the depth texture if its alpha component is greater or equal than the alpha component of the current framebuffer's pixel.

GL_GREATER_OR_EQUAL is not avalaible for the opengl alpha test, you've to specify a precis value, this is why I can't use the opengl alpha test.

I can't use the GL_DEPTH_COMPONENT because I need to also have the alpha value of the depth texture. (And not only the z value)

The second fragment shader solve the second part of the problem if the z component of the pixel that I want to draw is less greater than the z component of the current framebuffer's pixel.
If the alpha component of the current framebuffer's pixel is less greater than the alpha component of the pixel that I want to draw, I draw nevertheless the pixel.

I don't really knows how vbo's work but I think I'll use them later. ^^ (I'm always confunding VBO and FBO. :@)

For the zfar I can solve the problem if I normalize the z coordinate in the shader. ^^

I thought that it was already done and that the z value was between 0 and 1 but it doesn't seems to be the case, so, I think I just need to do this in the projection matrix.

I have different proportions with perspective and orthographic projections (screen coordinates are between 0 and screewidth with orthographic projection and between -1 and 1 with perspective projection so, I think I have to normalize them in the projection matrix for orthographic projection to pass from viewport coordinates to normalized coordinates)

I thing that's it's what Laurent does it in his projection matrix. (Because I didn't have this problemwith SFML matrix)

Thanks for your answers, but some points are still obscure to me. (It also do this for lurning purpose)

I hope that I've answered to your questions, but I need to read a thrad about modern GLSL, the threads that I've read was made several years ago so I use deprecated functions.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on March 28, 2014, 11:59:31 am
I need to use shaders because otherwise if I render 3D vertices with semi-transparent texture (like glass or water per example), semi-transparent object pixels hides opaque pixels.

Why? Do you have blending enabled? Are you rendering the transparent objects last?

I think you are reinventing the wheel in some aspects, and inventing it squared..  There are well known tutorials, books and tips around the internet which tell you how to actually efficiently solve those issues. Try to read Game Engine Architecture for example. Not that it is a prime example, but it should help you structure your mind around 3D engines.. Also a good OpenGL book would be nice. If you still don't know what an VBO is / why is it so important, then you are clearly underestimating the task you re doing..

As far as I know (I might be wrong on this one), after multiplying your 3D vertex with the projection matrix, if its z component is not normalized, between -1 and 1 in case of opengl, I believe you need to divide all components of the vertex by its W. I say between -1 and 1 because I _think_ opengl clips geometry at -1 and 1 to all components of the vertex, after normalizing it(dividing by W internally if needed). http://www.opengl.org/archives/resources/faq/technical/transformations.htm  9.011
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 28, 2014, 12:33:31 pm
Quote
I need to use shaders because otherwise if I render 3D vertices with semi-transparent texture (like glass or water per example), semi-transparent object pixels hides opaque pixels.

Why? Do you have blending enabled? Are you rendering the transparent objects last?

But what if the alpha component of the texture's pixels of the objects is not the same (I've textures with semi-transparent and opaque pixels)

It'll not work and I can't sort the objects by they z component  if I have pixel's object which are before and other pixel objects with are after another object.

And opengl need all the vertices of my faces to do the interpolation.  (I can't do a sorting by vertices)

So I need to use a shader. :)

I'll read some books about vbo's.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 28, 2014, 01:46:39 pm
So the advantage of my shader is that I can draw objects without carrying on the drawing's order of objects using semi-transparent textures.

I can cross every semi-transparent textures of different objects between them. (And creating nice effects)

I only have to regroup vertices using the same texture and the same primitive type in a map, and then, draw everything.

But I use several component to render each entities, because, for light and shadows in 2.5D I don't need to use a shader but a simple render texture.


Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on March 28, 2014, 02:48:46 pm
Quite confusing :p I foresee a rewrite of your code  in 3..2..1 :p
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 28, 2014, 03:13:30 pm
I've found the bug with shadows it was not a bug of the framework, I've forgotten that I have to get visible entities out of the world before getting the shadow map because it's the getVisibleEntities function which draw the shadows on the render texture.

The application class is able to draw object directly on the framebuffer if it's not a tilemap, otherwise the object is drawn on a tilemap and use my shaders.

I know that it's quite confusing but I just want to do animated water by example or other animations by changing the z component of the vertices onwich the textures waters are mapped.

I'll use this same technique is used for the color computation of the pixel with lights. (The only difference is that the view matrix is different because we need to have the depth value relative to the light position and not to the camera's position.

Personnaly I prefer use this rather than cube maps, normal mapping and other older techniques. (I find it more simple)

Moreover, I can computing the pixel color in function of different parameters like refraction, light deviation, the alpha channel and so on.

PS : I have still to correct something because the position of the lights and shadows is not correct when I move the view, mmm...., it's quite difficult if we want to have a view which can point in any direction in a 2D or a 3D world.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: lolz123 on March 28, 2014, 04:54:45 pm
Quote
Personnaly I prefer use this rather than cube maps, normal mapping and other older techniques.

What exactly do you prefer? These techniques are not really old and don't have many replacements.

Quote
But what if the alpha component of the texture's pixels of the objects is not the same (I've textures with semi-transparent and opaque pixels)

It'll not work and I can't sort the objects by they z component  if I have pixel's object which are before and other pixel objects with are after another object.

Your shader will not solve these problems. Also, keep in mind that you cannot read from a framebuffer while you are writing to it.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 28, 2014, 08:59:46 pm
But my shader works, I have semi-transparent texture that I draw in any order and I have the same result that the sorting that I've made with the z position of my vertices.

I cannot read to a framebuffer while I'm writting on it, it's why I use FBO.

But I've a question, if I put negative size with the glViewport function, will it inverse the x and y vertex positions ???

I would like that the developper can choose the unity.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 28, 2014, 10:05:00 pm
I've tried this :

float* ViewMatrix::getGlMatrix () {
    float* matrix = new float[16];
    if (needToUpdate3D) {

        matrix4f.m11 = xAxis.x * s3d.x;
        matrix4f.m12 = yAxis.x * s3d.x;
        matrix4f.m13 = zAxis.x * s3d.x;
        matrix4f.m14 = 0;
        matrix4f.m21 = xAxis.y * s3d.y;
        matrix4f.m22 = yAxis.y * s3d.y;
        matrix4f.m23 = zAxis.y * s3d.y;
        matrix4f.m24 = 0;
        matrix4f.m31 = xAxis.z * s3d.z;
        matrix4f.m32 = yAxis.z * s3d.z;
        matrix4f.m33 = zAxis.z * s3d.z;
        matrix4f.m34 = 0;
        matrix4f.m41 = -xAxis.dot(o3d);
        matrix4f.m42 = -yAxis.dot(o3d);
        matrix4f.m43 = -zAxis.dot(o3d);
        matrix4f.m44 = 1;
        needToUpdate3D = false;
    }

    matrix[0] = matrix4f.m11;
    matrix[1] = matrix4f.m21;
    matrix[2] = matrix4f.m31;
    matrix[3] = matrix4f.m41;
    matrix[4] = matrix4f.m12;
    matrix[5] = matrix4f.m22;
    matrix[6] = matrix4f.m32;
    matrix[7] = matrix4f.m42;
    matrix[8] = matrix4f.m13;
    matrix[9] = matrix4f.m23;
    matrix[10] = matrix4f.m33;
    matrix[11] = matrix4f.m43;
    matrix[12] = matrix4f.m14;
    matrix[13] = matrix4f.m24;
    matrix[14] = matrix4f.m34;
    matrix[15] = matrix4f.m44;
    return matrix;
}
 

I've found this on this following link : http://stackoverflow.com/questions/349050/calculating-a-lookat-matrix (http://stackoverflow.com/questions/349050/calculating-a-lookat-matrix)


But it doens't work, I'm really wondering about how this guy is doing.

PS : this is only the translation with doesn't work.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on March 29, 2014, 12:41:10 am
You should really calm down and first understand what you are doing.. only then do a library with it..

Didn't look at it, but if you are copying the matrix right, you might need to transpose it or switch the multiplication order..
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 29, 2014, 08:32:27 am
No, it's ok, I'll keep my Heuler angle camera system, It can manage a lot of different cameras : FPS camera, tack bal camera, free fly camera, etc....

And not every game use a lookat matrix.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 29, 2014, 11:27:36 am
PBO are they faster than shaders ???

http://www.songho.ca/opengl/gl_pbo.html#pack (http://www.songho.ca/opengl/gl_pbo.html#pack)

If yes I can try to replace my shaders by a pbo but I don't know if I can make special effects with this, but maybe for my own depth and alpha test I can try to use them.

But it's not my priority to do that for the moment, I need to finish all framework functionnalities and to have a demo, I can optimisate this later. :)

I've changed the source code so many times yet so, it can wait. ^^
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Nexus on March 29, 2014, 12:10:48 pm
I've changed the source code so many times yet so, it can wait. ^^
Maybe it would pay off to think about the design before writing the code...

Especially for a project of this scale, a detailed structure of the code is absolutely mandatory. And instead of trying to implement all features at once (which leads to certain failure), you should rather make the existing functionality robust before you go on. Robust means: Provide a clean API, write documentation, fix bugs, optimize, ...

I doubt that you'll listen to this advice, but who knows. And maybe a future reader of this thread who isn't only here for entertainment can benefit from it ;)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 29, 2014, 01:45:46 pm
It's impossible to think about all the design before, there is always something new which can come.

Manytimes you've to change your code, even with a good design I could'nt predict by example that SFML2'll add the possibility to create scene nodes, and I event didn't know about VBO, I've always used classes provided by SFML because until now they where sufficient.
SFML, and vertex arrays because I haven't any problem of performance.
But the most paintfull is to make it work on all plateform, some graphical cards support opengl functionnalities than other graphical cards doesn't support.

But I think that my code design know is robust, even if a passing textures to a shader is maybe a bit slower but I gain performance by executing the code on the GPU and not on the CPU. (I've read before that shader and FBO are fastest anyway than PBO.)

But maybe it was not true in all the cases. If we want we can discuss a lot about performance...

But if it's playable I don't really see an emergency by modifying the source code, I've already done a lot of optimisations until now for the scene rendering.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on March 29, 2014, 02:02:39 pm
What Nexus means is that you are still a beginner using openGL, and you should go back to learning and thinking, making small prototypes, getting familiar with it and then come back..

What you are trying to do is simply above your programming level right now. Nothing you can change with some study and time. But if you keep rushing the task right now like you are, you will waste time and make your own life harder.. I think most developers have been there and learned just the same.. I've been there too (kind of)..
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 29, 2014, 02:18:37 pm
I'm not a beginner with opengl but maybe I should check how 3D engines does for rendering effects. (Because I've never do this in 3D)

But otherwise I know opengl quite well, it's just that sometimes I don't know about which is the best technique to render different things. (Water, lighting, etc...)

There are many different way to render things with opengl. (FBO and shaders, 3D textures, cubemaps, multitexturing, PBO, etc...)

opengl is a very wide api.

But I'm pretty sure that modern api use shaders. (Except if they only need to modify vertices component, the using of VBO is certainly more appropriate)

But I'm not totally sure so it's why I need to see how a recent 3D engine proceed.

Is there a good 3D engin which is opensource like SFML ???
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Nexus on March 29, 2014, 02:36:14 pm
Looking at existing 3D graphics engines is definitely a good idea.

There are several ones with an open-source philosophy:
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on March 29, 2014, 02:41:25 pm
From your last post, its clearly noticeable you are a beginner with graphics in general. You might know the OpenGL API but you aren't aware of how the graphics pipeline really works as far as I can tell..

I second Nexus's suggestion, take a look in those engines, browse the internet for information... I am sure you will get it right eventually, but right now I can assure you your lack of understanding is crippling your entire framework's design.

Investigate on the GPU pipeline to better understand the process. Then you will see how using FBO or not, its all the same if done correctly, VBO or client-side arrays, its also all the same shader-wise.. Understand the pipeline and it will all make sense :)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: G. on March 29, 2014, 02:49:39 pm
You're wrong Grimshaw, Lolilolight is one of the most experienced C++ developer in the world, it's safe to believe him when he says that he knows OpenGL quite well.

BTW Loli, did you say that your replacement for normal mapping was a displacement of vertices? If not, how does your engine do normal mapping?
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 29, 2014, 03:31:05 pm
It's just an idea that I had : displacing vertices to cross semi-transparent textures between them but I have'nt tested yet.

Using vbo to do this seems to be a good idea.

But first I want to have a look at the source code of an existing 3D engine, it's not a bad thing, but, as you've said, I'm quite experienced so, I'm now able to invent my own techniques.

This is what I've always done until now. (exepts for more complicated things like cryptography because I want to be sure to have a framework which is very  securised.)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on March 29, 2014, 03:33:50 pm
Oh G. You are right, I bow to his superior intellect :D Especially with his latest post :D
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 29, 2014, 03:39:08 pm
Lol I'm not so smart, if I use my own techniques it's because I don't understand many of existing 3D engine techniques. (So i found it smart to act like that)

Where I'm quite smart it's only in c++. (And to invent new and simpliest techniques also)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: lolz123 on March 29, 2014, 05:00:08 pm
Quote
But I'm pretty sure that modern api use shaders. (Except if they only need to modify vertices component, the using of VBO is certainly more appropriate)

VBO's and shaders are not replacements for one another. Like I said, I would first read a good modern OpenGL book it you really want to get into 3D engines.

Also, please turn down the arrogance a bit. Especially when so far the arrogance seems to be unfounded. Calling yourself "One of the most experienced C++ developers in the world" is pretty obnoxious. I myself have often been called arrogant, and rightfully so, but I hope that I have mended my ways.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Tuffywub on March 29, 2014, 05:22:40 pm
I don't really knows how vbo's work...

I'm not a beginner with opengl...

VBOs are an absolute MUST if you want to create a 3D engine with reasonable performance today...
Not knowing VBO's is to modern OpenGL what not knowing what objects are is to C++.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 29, 2014, 05:34:08 pm
Ok but anyway I work every day very hard to be the best. :)

Ok, ok, I'll check out about vbo, I've read a tutorial about vbo a long time ago but I wasn't expecting that they where so much important in a 3D engine.

All the tutorials that I've found until now was talking about shaders.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on March 29, 2014, 07:07:28 pm
VBO's aren't just important, they are the ONLY way to render in modern OpenGL. Either with client-side arrays or server-side arrays(VBO), its the same thing, as far as the shaders are concerned.

Also, I think you should forget that shaders vs non shaders thing. In modern OpenGL, you are forced to use shaders, its the ONLY way to do anything. That's the way to go. Plus, leaving the fixed pipeline behind will probably have no consequence for you. By the time you have a usable library, no computer or phone will not support shaders.. :)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 29, 2014, 07:22:57 pm
Mmm..., ok I see!

I've looked in the sources of Irrlicht, and, Irrlicht uses vbo. ^^

This source code'll help me to render water, pixel per pixel lighting and shadow rendering. ^^

It'll become quite interesting. (this is pretty the only things which I've still to do to have a complete engine, with terrain generation and .obj file loading.)

Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on March 29, 2014, 07:41:38 pm
Nope, it is not the only list of things still left to do, you really have no clue xD
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 29, 2014, 08:56:36 pm
Ok, if you think that. ^^

Anyway the next update'll be the final version of the ODFAEG rendering engine, which'll use vbo to update vertices object in the TileMap class, if vbo are not supported it's vertex array which'll be used.

The TileMap class'll be renamed as FrameRenderer. (Because it simply draw each faces of the current frame on the framebuffer and the depth texture)

The advantage with the odfaeg::framerenderer'll be that this rendering class'll be able to update or load each faces using the same primitive type and the same texture into a vector. (without carrying about the order on which entities'll be drawn if they have semi-alpha textures)

But your right transferring each vertices at every frame can be very heavy if I've a lot of vertices to draw, mmm..., but there is a last problem : I can't use the shader anymore because I can't draw VBO on a rendertexture!!!

No finally I think I can. ^^

So I'll combine vbo and shaders for more powerfullness. (It should optimize the trick) :)

Thank to you all, I'll try this.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 30, 2014, 12:02:25 pm
Ok, I've reviewed the design a bit.

-I'll add two classes :

Face (it'll contains information about vertices and textures)
Facegroup (it'll contains all vertices which use the same textures for a group of faces, because we can't bind the textures in vbo, I'll use one vbo per facegroup)
All shapes'll inherit from the face class.

FastRenderComponentManager : this class will contains usefull rendering informations like texture buffers and'll use pbo or shader to render efficiently semi-transparent objects by reading and writting on textures in a fast way.
it's also this class which'll draw all the render components.

RenderComponent : this class'll render all vertices of a facegroup object with vbo, render components can be a model, a 2D gui, a set of tiles using the same texture, etc....

EntityManager : entity manager'll know about  the render component manager and the main window, this si this class which'll regroup each faces in facegroups and which'll choose the best way to render everything on rendercomponents.

This is also this class which'll update the rendercomponents to get the current frame.

I think this design is good. :)

PS : I've added a function compute normals in the vertex array class.






Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 30, 2014, 01:53:19 pm
Re, I have add a filter in the class facegroup, It should be nice if I can filter faces by material, color, primitive type used or a combination of those three criteria, but I hope that'll not slow the performances, I have to filter the entities faces before creating the vbos.

But I'll only create vbo on the init function of my fastRenderComponentClass so I just hope it'll not be to long for init the scene.

And them I've just to save vertex adress position of the first vertex face to update vbo. (by passing faces of visible entities with are in the camera)

I have still to test but the idea seems to be good.

Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on March 30, 2014, 02:34:48 pm
I still think you have no idea what a PBO is :p
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 31, 2014, 05:16:21 pm
I've  a question, can I draw the vertices of a IBO if I pass not all the vertices indices, but only the indices of vertices which are in the view ?

By exemple if I pass this array : (0, 1, 2, 3,  8,  9, 10, 11) at getDrawElements.  (If the vbo contains 3 quads but I only want to draw 2 of them.

Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: lolz123 on March 31, 2014, 05:18:18 pm
You can. But, it is easier to just draw one quad multiple times rather than change and index buffer.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on March 31, 2014, 05:47:23 pm
Ok. :)
Title: New update in the evening.
Post by: Lolilolight on April 01, 2014, 04:29:42 pm
I've nearby finished the component based system, this is a preparation for the next update which'll introduce VBO.

I've just a problem of a position with the different view to correct and them... (The tiles position is not the same in the rendertexture and in the window, but they have the same view...)
It's quite annoying to do because the view can be in any sense. (it's not a lookat matrix but translation and rotations because I need a view adapted for every kind of games, so I need to calculate the good angles and translations vectors depending on the different cameras type parameters. (2D rotation, 3D rotation, up vector, free fly camera's angles, zoom, lookat vector, etc...)

The class tilemap'll disappear, It'll be a class FastRenderingComponentManager class which'll be used instead, this class'll be able to draw ODFAEG's components or simple drawable objects. (This class isn't drawable, it'll contains some rendering informations like the current frame buffer render texture, the depth buffer render texture, ..., to draw components whith the best optimized opengl functions supported by your hardware, this is an equivalent to sf::RenderTarget but that I've improved)

A new class'll be added : FastRenderComponent : this class'll be able to pre-load entities or drawable objects and to render them on the screen later.

This class'll also sort entities vertices, before drawing them on the window or on the frame buffer render texture and then on the window of the FastRenderComponentManager class. (It depends which opengl functions your pc'll support.

The EntityManager class'll load or update all visible entities on FastRenderComponents, and then'll return RenderComponent containing the entities which are visible on the screen, and then you can draw with a fastRenderComponentManager object.

And that's it!

This is a major design improvement that I've done, and it'll allow me to choose the way which I want to render things on component. (By example if I want to render lights on a 2D component before drawing them of if I ant to use a shader)

By example, it'll be possible to draw sphere's on a 2D component and them to draw this component over the  screen. instead of using a shader.












Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on April 01, 2014, 09:47:36 pm
Sorry but I've a problem with the git-hub files so, I'll post this update later, anyway, I've still some displaying bugs to wipe out.

And I'll add the update with vbo directly, so, the core of the engine'll be finished, the rest'll be the adding of new functionnalities. (3D terrain generation, 3D files loaders, new shapes, 2D guis, lighting, database connexion, etc...)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: therocode on April 02, 2014, 08:27:25 pm
Hi!

I have a crash in my code from my cool physics library that I am trying to make. The code is:

int* finaNummer = new int[50];

for(int i = 4; i < 100; i += 2)
{
    if(finaNummer[i] == 4)
        finaNummer[i] += 10;
}

Why does it crash?! I tried to google but there was nothing there.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: G. on April 02, 2014, 09:34:10 pm
I know this thread is weird, but WTF is this doing here?
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on April 02, 2014, 10:00:09 pm
I've found thoss positionnement problems, I had just had to put some - in the projection matrix.

So I just do a scale of 1, -1, 1 for the viewmatrix and I've an yaxis with point at the bottom like SFML. :)

I'll repair the git-hub repository tomorrow evening, tommorow morning I've something to do, and I've still to implement vbo on my component based design.

After this update with vbo and components, I'll test the network module on a remote machine, and then, the version II of the framework'll be finished!

So the second version is nearby finished.

The version III (which'll be the final version)'ll include a particule system and a 3D terrian generation.

therocode I think you have miss posted.


Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: zsbzsb on April 03, 2014, 03:20:33 am
Quote
therocode I think you have miss posted.

I think he seriously wants you to answer his question, he obviously can see how great of a coder you are. So maybe you should respond and answer his question  ;)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: StormWingDelta on April 03, 2014, 05:33:36 am
lol this is one ambitious project. :P
Title: Design improvement and new update this evening!
Post by: Lolilolight on April 03, 2014, 07:24:12 pm
Hi everyone. :)

I've reviewed the design as I said :

Textures'll not be contained in the class Entity anymore but in a class called Material, a material is a set of textures (int this case it'll do multi texturing), and'll also contains some informations about the colors.

A class called face'll contains the material and the vertex array of a single textured face. (A face'll always have one material so)

And the class entity'll contains a new attribute : a std::vector of faces!

A class facegroup'll be able to regroup all vertex using the same material and the same primitive type. (It'll be used in the render component class to render and sort vertices in the most optimizaed way depending on your hardware support.

And the class entity manager'll be able to draw each desired entities into a RenderComponent.

PS : RenderComponents'll be like billboards, but for every kind of entities and not only for particules.

Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on April 03, 2014, 09:40:02 pm
I've update the git-hub but I've still to correct some bugs... :

-The view size isn't good when I draw components with the RenderComponentManager class.
-I'll pre-transform vertices in the face class and update only their transform when it's necessary, the functions onMove, onScale and onRotate of the entity class'll call the update method of the class face when the transformation of the entity has changed. :)
-I've to update the z position correctly for animated entity, depending on the entities behind and before the current animated entity taht I insert in the vector of visible entities.
And I have to use a vbo in the FastRenderComponent class.

But I'm pretty proud of my design review, he's very must simplier and proper and fast. :)

When all the bugs'll be corrected I'll do some networking test and the second version'll be finished, in the last version I have just to fill the odfaeg/Graphics/3D folder and add some collision classes and a particule system to the physic module.

For the lighting in 3D a I still don't know about which technique I'll use, there are so many of them..., I've to have a look to all those technique and choose one.





Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Jesper Juhl on April 03, 2014, 09:50:57 pm
/me wonders if this thread will ever end.

Ship some example game already that shows how great this framework is. Or stop talking. This is getting silly.

From what I have seen so far, I stand by my earlier comment that a framework for every type of game is just not feasible. And even if it was, this one is not it - lack of RAII, lack of OpenGL understanding, just generally messy code, a developer who is "full of himself/overstating own abilities", lack of use of modern C++11, etc etc..
OK. Maybe I'm being an ass, but this thread needs to die, as humorous as it is, (IMHO).
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on April 03, 2014, 10:18:56 pm
Ha yeah I've forgotten, I'll post a small source code example soon : (but for the game it'll take more time, because I need to add a gampeplay)

I think I'll post less often.

Quote
And even if it was, this one is not it - lack of RAII, lack of OpenGL understanding, just generally messy code, a developer who is "full of himself/overstating own abilities", lack of use of modern C++11, etc etc..

Sorry but I use all this technique and it works, but maybe I need to review the source code a bit. :P

Sorry to disappoint you but I understand opengl very well, RAAI, I use it because the std::vector are using it and even if they don't I destroy them in the destructor.

And I use modern c++11 techniques also and a lot of modern techniques. (Entity scene nodes, pattern observer, based component pattern, type erasure, CRTP, etc..., etc...)

But you'll see it once I'll have finished the tests and the demo. :P

But I'm not in a hurry, all I want now, is to have a good design. :) (The demo'll come just after)

But now I think that the design is ok, so, I'll post less, otherwise this thread'll never end, and, I'll post again when the demo'll be finished.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: G. on April 03, 2014, 11:07:36 pm
I browse the SFML forums using the "Unread" feature, it shows every threads with new posts. I come here more than once a day and this thread always has "something" new. I don't want to hurt your feelings because I think you're a little bit retarded, but nobody takes this project seriously. It is almost 200 posts long and yet there is nothing to see.  :-\

Maybe you should post less here and more on your devblog. :P Come here to show big updates, not useless things that change every day.
And claiming that you're "one of the most experienced C++ dev in the world" doesn't help, especially when you have achieved nothing and have been unemployed for years. No you're not that awesome and it's not a shameful thing to be average.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Njifra on April 03, 2014, 11:36:28 pm
I browse the SFML forums using the "Unread" feature, it shows every threads with new posts. I come here more than once a day and this thread always has "something" new. I don't want to hurt your feelings because I think you're a little bit retarded, but nobody takes this project seriously. It is almost 200 posts long and yet there is nothing to see.  :-\

Maybe you should post less here and more on your devblog. :P Come here to show big updates, not useless things that change every day.
And claiming that you're "one of the most experienced C++ dev in the world" doesn't help, especially when you have achieved nothing and have been unemployed for years. No you're not that awesome and it's not a shameful thing to be average.

I agree, and ull never make that example...
You have finished 0.00009% of it...
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on April 03, 2014, 11:39:49 pm
As much as the other things may or may not be discussable, you do not understand OpenGL at all. You're exactly the definition of a beginner using it as you've proven all along this thread. Even the little you're getting done with OpenGL is all taken from tutorials around the web, as everyone can see :p

Be honest, you are mocking us or being serious?
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: StormWingDelta on April 04, 2014, 04:29:50 am
I say build for one game type at a time than find out what is common among all the types of games and build a framework around that rather than what makes them different.  If you build around what they all have in common than branch out from there you'll be able to pull this off.  It isn't impossible but I think the old saying, "Don't bite off more than you can chew.", comes to mind.  Also if you need help just ask, trying to do all this by yourself isn't going to end well as I found out the hard way.  At the very least we can help by finding more useful tutorials.  I'd recommend ignoring anything more than 3 years old unless it is really good or the codes for it haven't changed much. :P


If you need a few helpers there are bored people like me that might help if able. :)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on April 04, 2014, 11:01:49 am
Hi, yes it's right I'm unemployed since several years, this is why I want to make this kind of framework, because, over one year, I'll loose the insertion allocations, and I don't want to do something other than computer sciences. (And to have made studies for nothing)
I'm intending  to  create my game developpement own studio so if I'm still unemployed in one year (I hope this'll work), if not, I'll continue this as a passion.

The tutorials what I've found on the internet are sufficient for the moment and I don't have time to read many books or articles with explain a lot of tehcniques.
But, if someone have done it and if he really think that he really have better knowledge than me, he can help, or he can shut up.

I've the intention of creating a game soon for the demo but only a 2.5D game because it's easier to start to do tests and after, I'm intending to create a full 3D game. (A simple FPS)

This thread becomes to be..., a mess, so I think I'll recreate another one once when I'll have finish to encode the demo and correcting all the remaining issues.

I don't know if people are passing on the devblog, I've more answers on a forum most of time.

But for the advanced techniques I must admit that I need help.

PS : ok, as you think that I'm not serious I'll post less, and starting to encode the demo.

It's just that many people make me wasting a lot of time by mocking me, last years I had a proposition but never answers for a stage, they promise to create job, they force us the search for a jobs, but, there's one job for 50 people and we have to past tests, so, there's no chance.

And a few years ago, a people was telling me that he have a stand at the japan expo to present the project but it as a lie.

I think this domain is simply satured.

But i'm not here to talk about that, but please don't make links between thing which they haven't any rapport.

It's not because I'm unemployed since several years that I'm bad.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Nexus on April 04, 2014, 12:14:20 pm
You're not bad, but you want to do too much at once, which is simply not realistic. Have a look at existing 3D frameworks like Ogre, Irrlicht, CrystalSpace (or even all-in-one engines like Unity), but also 2D ones like Allegro, SDL, SFML. They have existed for years if not decades, and the people developing them are often very experienced, as they have worked years in game development industry before. This experience is something you don't have, and even with that experience it would be almost impossible to create a framework of such a scale and quality in less than a year. You must acknowledge that fact.

You talk about saturated market, yet you want to develop something that other products already do much better. If you want to be successful, you should rather find a niche, where your framework has potential. If you start small, it's not only more likely that you will ever finish, but you also gain experience that you can use later for bigger projects. And you have something to show that you achieved -- people won't question what you did the whole time, if there is a result. My suggestion is that you cease the development of ODFAEG and find a more specific problem domain where your work is recognized by the community.

The reason why you are not taken seriously is because you never consider our advice and because you have imaginations of your framework that are beyond reality -- not only your future visions; you also completely overestimate what you have already done. In this forum there is a great exchange of knowledge, but if you want to benefit from it, you should dismiss your attitude of knowing already everything (which you obviously don't) and be open for suggestions from others. Every single person responding here has already said that (in fact, I alone am saying it for the fifth time or so), so please consider the possibility of it being true. And before, the exact same story has happened in the French forum.

Lolilolight, it is really really time that you realize the whole situation and take care of what you post. This can't go on like that.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on April 05, 2014, 09:59:43 pm
Hi!

I've implemented the vbo in the vertex array and render target classes.

Now, I've still to correct some positionning problems in the FastRenderComponentManager class for multi pass rendering with the camera, and the core of the framework'll be almost finished.

Before beginning to encode the last version, I'll write a demo, I end the discution on this topic here, and I'll start a new one, if anyone can help me to correct the remaining bugs, he's welcome.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on April 05, 2014, 10:43:58 pm
I don't think encode means what you think it means :p
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on April 06, 2014, 06:55:59 pm
Yeah probably. :P

I've a little example of source code which runs, I'll add a tutorial and a source code example soon. :P

And later the same but with the network.

But I've still a problem when I draw component in the fastRenderComponentManager class, when combining the view transform, I've a part of the screen which is black. :/

So I draw directly entities on the windows and component directly on the window, without applying my shaders.
I think I need to find a tutorial about billboard or something like for multi-pass shader rendering but if anyone can help me he's welcome. :)

Once I'll have find a way to do multi-pass rendering, it'll become more funny. :P (Because I'll be able to start to make the first game with these framework.)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on April 06, 2014, 09:17:25 pm
If a part of the screen is not being rendered to (is black), you probably need to call glViewport() to the whole window, to make sure its used. Also make sure the scissor test is disabled. That should help.

What do you need multi pass rendering for?
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on April 06, 2014, 10:58:15 pm
I've done this but it doesn't work, I think I'll try with the source code of of 3DEE. (I hope it'll word)

I need the multi pass rendering to render 3D semi transparent objects correctly.

Especially for semi-transparent objects which are in collision with others (like water textures), I can't display them in a certain order because some semi-tranparent fragment of a texture can be behind or before the fragments of the second semi-transparent texture, and as the default opengl depth test don't consider semi-transparent fragments, I need a shader with test also the alpha component of the pixel before drawing it, like this :
 const std::string vertexShader =
            "void main () {"
                "gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;"
                "gl_TexCoord[0] = gl_TextureMatrix[0] * gl_MultiTexCoord0;"
                "gl_FrontColor = gl_Color;"
            "}";
            const std::string  depthGenFragShader =
            "uniform sampler2D depthBuffer;"
            "uniform sampler2D texture;"
            "uniform vec2 resolution;"
            "void main () {"
                  "vec2 position = ( gl_FragCoord.xy / resolution.xy );"
                  "vec4 color = texture2D(depthBuffer, position);"
                  "vec4 pixel = texture2D(texture, gl_TexCoord[0].xy);"
                  "if (gl_FragCoord.z > color.z && pixel.a >= color.a) {"
                     "gl_FragColor = vec4(0, 0,  gl_FragCoord.z, pixel.a);"
                  "} else {"
                     "gl_FragColor = color;"
                  "}"
            "}";
            const std::string frameBufferGenFragShader =
            "uniform sampler2D depthBuffer;"
            "uniform sampler2D frameBuffer;"
            "uniform sampler2D texture;"
            "uniform vec2 resolution;"
            "void main () {     "
                "vec2 position = ( gl_FragCoord.xy / resolution.xy );"
                "vec4 depth = texture2D(depthBuffer, position);"
                "vec4 color = texture2D(frameBuffer, position);"
                "vec4 pixel = texture2D(texture, gl_TexCoord[0].xy);"
                "if (gl_FragCoord.z >= depth.z) {"
                    "gl_FragColor = pixel;"
                "} else if (color.a < pixel.a) {"
                    "gl_FragColor = pixel;"
                "} else {"
                    "gl_FragColor = color;"
                "}"
            "}";
 


So more transparent pixels doesn't hide more opaque pixel when their z position is greater. (And I can draw textures in any order that I want.)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on April 07, 2014, 12:21:21 pm
I've found the bug. :P

So, only some network tests are remaining, some source code is to clean up and to put in .impl and .cpp files and it should be ok for the version II and the demo.

Everyone who thinks he can improve the source code design and to add some idioms is welcome. :)

Title: The release of the second version'll be lauch in may! (or june!)
Post by: Lolilolight on April 11, 2014, 02:22:55 pm
Hi!

The second version is nearby finished, I've still to clean the code a bit, add some idioms (RAII, etc...) and then, finishing the documentation and the demo!

I'll put the listener into a class called InputSystem, and the cache into a class called ResourceSystem and use the monostate pattern like I do in the network class. (I've to avoid the use of the singleton pattern in a multi-threaded context, and I want to make each functionnalities independant of the framework, by example, the developper can use another framework for his application and also using the input system of odfaeg)
I've also corrected the source code of the network module. (And the developper'll be able to choose if he wants to make a secure connexion or not, in a further version I'll add an https class to add the https protocol)

The best code design

The framework'll use this following patterns or idioms so :

-RAAI for resources acquisition and liberation.
-CRTP (curiously recursive template pattern) for calling 2D or 3D entity manager's function. (it depends if the entity manager which is stored in the world
-Type erasure. (For signals and slot management and also for storing resources of different type into the cache)
-Based Component Design pattern : (The 2D or 3D entities'll be able to be dawn on components, very usefull if we need to do multi-pass rendering with differents views or with different layouts, the component manager class'll be able to use advanced rendering functions (new blend modes, advanced alpha test, etc...) but only if your pc support shaders)
In the same optic, the view class'll combine a lookat matrix with a transformation matrix, so, no need to use billboards)
I don't want to make this framework very big like Irrlicht, Ogre, etc..., but I want to combine all the techniques of existant framework or libraries to make the source code simplier to use and most powerfull. (And also to make my life easier)
-Entity scene nodes : the transformations between the entities of the scene graph'll be able to be combined if each graphic entities have children or parent node. (But you can redefines transformation functions if you need to update other's informations like collision areas or collision volumes of the entities)
The framework pre-transform the vertices of a root entity and each childs. (The framework also pre-transform vertices if your pc support vbo to have a very fast rendering time)


Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: StormWingDelta on April 11, 2014, 05:38:01 pm
Keep in mind when making this that it should be as unrestricted as it can be like SFML is if you are intending people to be able to use for any game. :)  Also you could have a list of game types and than one of those could be a fully unrestricted type where they can use all the tools rather than limiting based on the game.  This will help quite a bit.  :D
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on April 11, 2014, 07:03:49 pm
Yes I don't know about every kind of games that are existing so I need to check and make a list. (I only know about fps, hack and slash, rts and mmorpg and rpg's likes)

I've forgotten to mention that two new chapter'll see the day :

-The first'll talking about collisions.
-The second'll be talking about the network.

I don't know if I'll implement the thor's particule system un this version or not, but I'll try to make it in this version so, the only think with'll remains'll be full 3D features. (It'll not take too much time because the source code is very modular and I've already prepared all to integrate full 3D easily, I only hope that it won't be too slow and that the result'll be acceptable.)

PS: Ha yes, I've forgotten the sound and the 2D guis but, I don't think it'll be very difficult with SFML and sf::gui. :)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: StormWingDelta on April 11, 2014, 08:17:02 pm
yep there are a lot of game types out there.  You've got puzzle, shooter, space, rts, rpg, mmo, action, strategy, etc.

The general idea would be to start with the common things between them and than work down one branch of games in a particular area at a time so you don't get overwhelmed. :)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on April 12, 2014, 07:51:59 am
Ho god, since a long time ago I was checking a way to find the z position for 2D iso or 2D tiles, and it's very simple. :/

The z value is the same that the y value of the center of the tile. (Because more the tile is bot., more its z component is greater in 2D or 2D iso.)

So I think I'll compute the z of 2D entities in the entity class rather than pass it to the 2D entity constructor, so I've just to do a depth and an alpha test later, and it'll be very more simple for animated entities.

Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on April 12, 2014, 10:41:11 am
I think I'll change the gridmap and the map class, and make only one entity manager for 2D and 3D objects, it'll be more simple.

I'll also make only 3D collision volumes but they'll also can be used for the 2D.


Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on April 12, 2014, 06:27:58 pm
If your designs are really good and work very well why are you consistently refactoring your classes? :p
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: StormWingDelta on April 12, 2014, 10:32:43 pm
If your designs are really good and work very well why are you consistently refactoring your classes? :p

Yep would be a good idea to pick easy to remember and common names that don't need changing. XD
Title: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: The Terminator on April 13, 2014, 02:24:58 am


Yep would be a good idea to pick easy to remember and common names that don't need changing. XD

....?
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on April 13, 2014, 10:46:12 am
Yeah sometimes I need to change the classes a bit but it doesn't take a lot of time, so I have more time to debug. (It's the advantage to have a good design)

But even with a good design I need to change them a bit to add functionnaities like full 3D here.

There's some misstakes in the class matrix4f and matix3f, I'll update the git-hub this evening.

I've changed the bounding areas to bounding volumes so the new classes becomes :

-BoundingSphere, BoundingEllipsoid, BoundingBox, OrientedBoundingBox and BoundingPolyhedron.

Title: Great news!!!
Post by: Lolilolight on April 16, 2014, 09:31:09 pm
I've found the bugs with my render components and now I use a framebuffer and a depthbuffer texture by component (and not for all components anymore) I've adapted the gridMap class to store 3D entities for the final version of ODFAEG!!!

Now, 2D and 3D entities can be drawn on components correctly, the advantage of odfaeg's render components is that they have a dephtest which manage semi-tranparent pixels. (if your pc support the GLSL)

You can so cross semi-transparent textures on the z axis and create special effects. (pixel water which overlap the ground by exemple)
(But it only work for PC which support shader, otherwise rendercomponent'll use the default opengl depth test or the zsorting for flat textures)

The world class can so directly draw entities on component, and components'll be drawn directly on the window by the application, so in the onRender function you have just to specify which entity you want to draw on which component, here I draw the ground on a first render component and the other entities in a second render component, so, event if the z of the ground textures is greater than the z of the texture's caracter, the ground texture doesn't overlap the caracter because the ground is drawn on another component.
 void onRender() {
            World::drawOnComponents("E_TILE", 0);// draw the ground on the background component.
            World::drawOnComponents("E_WALL+E_DECOR+E_ANIMATION+E_CARACTER+E_PONCTUAL_LIGHT", 1);        
//Draw all other entities to the foreground component.  
 }
 

Component'll also be used to generate light map and shadow easy in 3D in the last version of ODFAEG.

The node of the framework is nearby finished so I'll wait to have a better source code before updating the git-hub with a source code example!

But maybe I'll need some help fore optimisation so I'll browse some other forums before, because drawing everything on rendertextures and passing params to shader is a bit slow. :/  (even with vbos)

#include "../../../../include/odfaeg/Graphics/2D/fastRenderComponent.h"
namespace odfaeg {
namespace g2d {
FastRenderComponent::FastRenderComponent (RenderWindow& window, int layer) :
    Transformable(Vec3f(window.getView().getPosition().x, window.getView().getPosition().y, layer),
                  Vec3f(window.getView().getSize().x, window.getView().getSize().y, 0),
                  Vec3f(window.getView().getSize().x + window.getView().getSize().x * 0.5f, window.getView().getPosition().y + window.getView().getSize().y * 0.5f, layer)),
    view(window.getView()) {
    sf::Vector3i resolution ((int) window.getSize().x, (int) window.getSize().y, window.getView().getSize().z);
    depthBuffer = new RenderTexture();
    frameBuffer = new RenderTexture();
    depthBuffer->create(resolution.x, resolution.y);
    frameBuffer->create(resolution.x, resolution.y);
    frameBuffer->setView(window.getView());
    depthBuffer->setView(window.getView());

    if (Shader::isAvailable()) {
        frameBufferGenerator = new Shader();
        depthBufferGenerator = new Shader();
        const std::string vertexShader =
        "void main () {"
            "gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;"
            "gl_TexCoord[0] = gl_TextureMatrix[0] * gl_MultiTexCoord0;"
            "gl_FrontColor = gl_Color;"
        "}";
        const std::string  depthGenFragShader =
        "uniform sampler2D depthBuffer;"
        "uniform sampler2D texture;"
        "uniform vec3 resolution;"
        "void main () {"
              "vec2 position = ( gl_FragCoord.xy / resolution.xy );"
              "vec4 color = texture2D(depthBuffer, position);"
              "vec4 pixel = texture2D(texture, gl_TexCoord[0].xy);"
              "if (gl_FragCoord.z >= color.z && pixel.a >= color.a) {"
                 "gl_FragColor = vec4(0, 0,gl_FragCoord.z, pixel.a);"
              "} else {"
                 "gl_FragColor = color;"
              "}"
        "}";
        const std::string frameBufferGenFragShader =
        "uniform sampler2D depthBuffer;"
        "uniform sampler2D frameBuffer;"
        "uniform sampler2D texture;"
        "uniform vec3 resolution;"
        "void main () { "
            "vec2 position = ( gl_FragCoord.xy / resolution.xy );"
            "vec4 depth = texture2D(depthBuffer, position);"
            "vec4 color = texture2D(frameBuffer, position);"
            "vec4 pixel = texture2D(texture, gl_TexCoord[0].xy);"
            "if (gl_FragCoord.z >= depth.z) {"
                "gl_FragColor = pixel;"
            "} else if (color.a < pixel.a) {"
                "gl_FragColor = pixel;"
            "} else {"
                "gl_FragColor = color;"
            "}"
        "}";
        if (!depthBufferGenerator->loadFromMemory(vertexShader, depthGenFragShader))
            throw Erreur(50, "Failed to load depth buffer generator shader", 0);
        if (!frameBufferGenerator->loadFromMemory(vertexShader, frameBufferGenFragShader))
            throw Erreur(51, "Failed to load frame buffer generator shader", 0);
         depthBufferGenerator->setParameter("resolution",resolution.x, resolution.y, resolution.z);
         frameBufferGenerator->setParameter("resolution",resolution.x, resolution.y, resolution.z);
         backgroundColor = sf::Color::Transparent;
    }
}
void FastRenderComponent::setBackgroundColor(sf::Color color) {
    this->backgroundColor = color;
}
void FastRenderComponent::clearBufferBits() {
    frameBuffer->clear(backgroundColor);
}
void FastRenderComponent::clearDepthBits() {
    depthBuffer->clear(sf::Color::Transparent);
}
g2d::Tile FastRenderComponent::getFrameBufferTile () const {
    sf::IntRect subRect(0, 0, frameBuffer->getView().getSize().x, frameBuffer->getView().getSize().y);
    g2d::Tile tile (&frameBuffer->getTexture(), Vec2f(0, 0), Vec2f(frameBuffer->getView().getSize().x, frameBuffer->getView().getSize().y), subRect);
    return tile;
}
g2d::Tile FastRenderComponent::getDepthBufferTile() const {
    sf::IntRect subRect(0, 0, depthBuffer->getView().getSize().x, depthBuffer->getView().getSize().y);
    g2d::Tile tile (&depthBuffer->getTexture(), Vec2f(0, 0), Vec2f(depthBuffer->getView().getSize().x, depthBuffer->getView().getSize().y), subRect);
    return tile;
}
bool FastRenderComponent::load(std::vector<Entity*> visibleEntities)
{

    if (Shader::isAvailable()) {
        fg.clear();
        for (unsigned int i = 0; i < visibleEntities.size(); i++) {

            if (visibleEntities[i]->isLeaf()) {
                for (unsigned int j = 0; j < visibleEntities[i]->getFaces().size(); j++) {

                    visibleEntities[i]->getFaces()[j]->transform(visibleEntities[i]->getTransform());

                    fg.addFace(visibleEntities[i]->getFaces()[j]);
                }
            }
        }
        m_vertices = fg.getFaces();
    }
    this->visibleEntities = visibleEntities;
}

void FastRenderComponent::draw(RenderTarget& target, RenderStates states) const {
    const Shader* devShader = states.shader;
    states.transform = getTransform();
    if (Shader::isAvailable()) {
        frameBuffer->setView(target.getView());
        depthBuffer->setView(target.getView());
        for (unsigned int i = 0; i < m_vertices.size(); i++) {
            states.texture = const_cast<FastRenderComponent*>(this)->m_vertices[i].first.getMaterial().getTexture();
            for (unsigned int j = 0; j < m_vertices[i].second.size(); j++) {
                states.shader = frameBufferGenerator;
                frameBufferGenerator->setParameter("depthBuffer", depthBuffer->getTexture());
                frameBufferGenerator->setParameter("frameBuffer", frameBuffer->getTexture());
                frameBufferGenerator->setParameter("texture", Shader::CurrentTexture);
                frameBuffer->draw(*m_vertices[i].second[j], states);
                frameBuffer->display();
                depthBufferGenerator->setParameter("depthBuffer", depthBuffer->getTexture());
                depthBufferGenerator->setParameter("texture", Shader::CurrentTexture);
                states.shader = depthBufferGenerator;
                depthBuffer->draw(*m_vertices[i].second[j], states);
                depthBuffer->display();
            }
        }
        g2d::Tile tile = getFrameBufferTile();
        tile.setCenter(frameBuffer->getView().getPosition());
        states.shader = devShader;
        target.draw(tile, states);
    } else {
        for (unsigned int i = 0; i < visibleEntities.size(); i++) {
            for (unsigned int j = 0; j < visibleEntities[i]->getFaces().size(); j++) {
                states.texture = visibleEntities[i]->getFaces()[j]->getMaterial().getTexture();
                states.transform = visibleEntities[i]->getTransform();
                target.draw(visibleEntities[i]->getFaces()[j]->getVertexArray(), states);
            }
        }
    }
}
void FastRenderComponent::init() {
}
FastRenderComponent::~FastRenderComponent() {

}
View& FastRenderComponent::getView() {
    return view;
}
int FastRenderComponent::getLayer() {
    return getPosition().z;
}
}
}
 

I don't thing that's it's necessary to pass the transformation matrix if I update vertices in the vbo, in any case I'll have to browse other forums to get some optimisation advices, the source code of SFML is not sufficient anymore.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on April 17, 2014, 08:08:26 pm
I've  neverless updated the git-hub because there was important bug corrections.

The next updates'll be the remaining tests for bug corrections and rendering optimisations that I don't have found yet and almost documentation and source code examples.

And then, the release of the second version of ODFAEG'll see the day!

But I've set the implementation of lighting and shadow in pause because, as nexus as pointed out, I can't implement all features at once alone. (Or it'll take too much time to test everything and to debug/optimisate everything.)

But the main root of the framework is nearby finish, a have basic secure networking, graphics and physics classes which seems to work pretty well exepts for pixel per pixel rendering where it's a bit more difficult to have optimized result.
And I never had the occasion to program games with very evoluated graphism and I've hard to find help in this domain.
Title: ODFAEG is now working on linux.
Post by: Lolilolight on April 21, 2014, 11:02:18 am
I've switched to linux (distrib ubuntu 13.04 64 bits) to make it works, and corrected the last bugs.

I've get rid on my polluated windows 7 64 bits and it's now faster so I'll stay on ubuntu. ;)

I'll update the git-hub this evening so, just the time to install git-shell on linux.  :)

In the next update it'll be most of all code purification and new functionnalities implementation. (putting the templates in a .inl file like SFML, makes the library works in shared mode and configure the package files for linux, implementing the particule system of the thor library, implementing the SFML fonts and shapes to make it work with odfaeg, etc...)

I'll make a full 3D isometric game to test everything before making the final release which'll include more 3D functionnalities (3D terrain generation, 3D object loader, 3D object selection, animated entities interpolation, lighting and shadowing.) and the sound module.

I can't implement all functionnalities at once, because I'm alone to make this project and it'll be very unstable if I do that anyway, for full 3D games you'll have to be patient. :)
For those who don't still know me :
I'm a fullstack developper (it means that I can make a bit of everything (networking, database management, web and application developpment, os management and software usage)) but I'm not specialized in something.
But it doens't means that I can make everything at once. (I hope it's clear for you)



Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: StormWingDelta on April 21, 2014, 05:57:22 pm
Luckily with github we can help out if needed so if you need help just ask since I'm sure those of us that specialize in specific areas could clean up and better some of the code or even add to it. :)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on April 21, 2014, 09:59:12 pm
Yep.  :D

The update'll be set tomorrow because, I've still improved the command system. (which was too slow)

Now the scene updates and renders even faster.  :)

I think I'll ad the possibility to do assynchrone or synchrone command execution like in opengl. (In assynchrone mode, one sf::event'll be send to the thread and then the thread'll process this event, in synchrone mode, all event'll be send to the thread and the thread'll process all the events.


Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Deathbeam on April 22, 2014, 10:56:23 am
I like opening this thread always when you post something new @Lolilolight and then reading your posts and trying to understand all that things you are writing :) Take this as compliment, becouse I am totally unskilled in this core things what you are doing :D
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on April 22, 2014, 07:29:34 pm
Ok, so, I'll update the git-hub this evening, including a tutorial and a source code example which'll show what we can actually do with the framework.

And it's only the beginning because I'm not very far compared to some projects that I've seen on other threads. (Like d3d by example)

It's not that I'm not able to to domething similar compared to these other projects but it's only because I don't want to put all the fonctionnalistes at once in my framework.

I hope that in a few years it'll looks like even better. (When I'll have finished to implement the 3D functionnalities)

And I hope that I'll have a more acceptable result than in the past with the 3D when displaying full 3D models. (I hope that my skills for the 2.5D'll help, but I think that it can help me a lot)

So..., there are always some points where I'm still unskilled, even if I spend a lot of energy for this framework and it's not very benefit.

So I'll create a less ambitious project first with this version and then create a more ambitious project with the final version of odfaeg.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on May 04, 2014, 07:52:04 pm
Hi!

I haven't bring some news since a little time ago, it's because I've a little stage until next week.

But I've found a bug which my vbos (my source code was wrong), so, I've corrected it and I'll update the git-hub this evening or tomorrow.

Next I'll perform networking test on remote machines (movement predictions, IA, etc...) and if the result is acceptable I'll be able to show a little game.



Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on May 04, 2014, 08:08:04 pm
Git hub updated!!!

I don't want to use modern opengl with glVertexAttribPointer function because I want to keep a compatibility with older opengl versions.

VBO's are now displaying and updating correctly. (In the source code before it was still VBA which were used)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on May 12, 2014, 12:12:50 pm
I've corrected a bug in the symEncPacket file. (the size was wrong)

Now sending and receiving TCP and UDP encrypted packet work correctly. (I've transfered the map from the server program to the client program and caracter's position)

I've performed local networking test and I'll perform remote networking test soon.

Then I'll create a multiplayer game as a demo, but before that I need to finish the IA and to implement a particule system and the guis.

PS : I've also tried to implement modern opengl but it doesn't seems to work. :/ (It works only when I draw in the main but not in the RenderTarget class)

Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on May 17, 2014, 01:02:37 pm
Hi!
It's now possible get the position on the path from the loop time to perform mouse movements.

float t = (float) getClock("LoopTime").getElapsedTime().asMicroseconds() * caracter->getSpeed();
        if (caracter->isMoving()) {
            if (caracter->isMovingFromKeyboard()) {
                World::moveEntity(caracter, caracter->getDir().x * t, caracter->getDir().y * t);
                if (World::collide(caracter)) {
                    World::moveEntity(caracter, -caracter->getDir().x * t, -caracter->getDir().y * t);
                }
                Vec3f d = caracter->getCenter() - getView().getPosition();
                getView().move(d.x, d.y, 0);
                World::update();
            } else {

                Vec3f pos = Computer::getPosOnPathFromTime(caracter->getCenter(), caracter->getPath(),1,1);
                Vec3f d = pos - caracter->getCenter();
                //std::cout<<"actual pos : "<<caracter->getCenter()<<"pos : "<<pos<<"d : "<<d<<"final pos : "<<caracter->getPath()[caracter->getPath().size() - 1]<<std::endl;
                Vec3f dir = d.normalize();
                World::moveEntity(caracter, d.x, d.y);
                if (Vec2f(dir.x, dir.y) != caracter->getDir())
                    caracter->setDir(Vec2f(dir.x, dir.y));
                getView().move(d.x, d.y, 0);
                if (pos.computeDist(caracter->getPath()[caracter->getPath().size() - 1]) < 2) {
                    //std::cout<<"stop"<<std::endl;
                    caracter->setMoving(false);
                }
                World::update();
            }
        }
    }
 

It'll come in the next tutorial when I'll discuss about movement prediction with networking correction, and IA.
Title: Re: Version 2 and new topic are arriving but there is still a little work to do.
Post by: Lolilolight on May 23, 2014, 03:13:46 pm
I'll not be able to perform remote networking test because It doesn't want to run on a raspberry pi. (But local networking tests are running without any problem excepts sometimes I have to launch the serveur more than once because of a bug with openssl :/)

But it isn't a real problem for me, I'll fix the remainings bugs of the library on my own computer and add the last functionnalities that I need for the demo game. (fonts, particule system and the sound.)

I'll also purge the source code, put some functions inline and putting everything on the rights files (headers, source code, template), finish to make the documentation and making a website. :P

So there's still a little work to do.

Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on May 26, 2014, 11:49:47 am
I've adapted the particule system of the thor::library and all classes of the SFML graphics module in odfaeg, I'll update the git-hub this evening.

So only the sound module is remaining and then I'll be able to write a demo to test everything.

But before I need to finish the demo and to put some code in the right files.
Title: Some changements.
Post by: Lolilolight on May 26, 2014, 04:47:30 pm
Hi, the demo'll change a bit because I've rewritten the command system a bit, now there is just an std::map for all command (a coman can take an action and a slot, a triggerer function and a slot or an action, a trigger function and a slot)

The class ActionMap have been renamed to Command, and you have to always connect a command to the listener. (You cannot connect a trigger and a slot function directly.

The class FastDelegate is now able to take any kind of function, and thus, also std::function!!! (Or even your own function type)

In c/c++ there is a lot of functions with a different type, and with c++11 there are even more, so, this is why I've created a class to store them temporatly and to call the function pointers correctly with the inheritance.

Now, you can pass a shader when drawing entities on components and perform per pixel lighting for exemple. (This is what I'll do in the last version)
Title: Git hub repository updated!
Post by: Lolilolight on May 26, 2014, 05:29:44 pm
See title. :)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on May 26, 2014, 08:08:38 pm
So, how many people are using this library already? Around 100 I guess?
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on May 26, 2014, 08:14:03 pm
Quote
So, how many people are using this library already? Around 100 I guess?

idk, maybe just me at the moment, but idc, if it feeds my needs.

And if it helps but I think I can remove it from the git-hub repositories, if nobody use it but it's always a line on my cv until I've made a more ambitious project and until I can show somethings else than source code.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on May 26, 2014, 08:35:34 pm
Keep it there, maybe someone will find it useful :)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: StormWingDelta on May 27, 2014, 01:12:02 am
Yep someone might.  :)

Meantime did you ever add support for sprites with sub sprites yet?  Could be useful for things like turrets and such. :)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on May 27, 2014, 08:14:26 am
Quote
Meantime did you ever add support for sprites with sub sprites yet?

What do you mean ?

tilesets ?

Or a big sprite class like in the thor library ?

At the moment I do everything with tilesets and subrects.

Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: StormWingDelta on May 28, 2014, 02:32:49 am
Sort of like where a bunch of smaller sprites can make up a larger one or having smaller ones attached to the bigger one.  Like for example turrets on a ship or something that happens in a game like Bubble Tanks.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on May 28, 2014, 08:07:25 am
Ha ok. :)

I have made a thing like that in the past but for the ground, a big entity which contained a bunch of tiles.

But I've removed this class and added the tiles directly, but, I think I'll remake this class later. :)

Because I have to find a way to don't check in every grid cells where the big sprite is at the rendering time otherwhise it slow the performances.

To generate 3D terrain this class'll be helpfull, and, not only for sprites. (By example if I want to generate a bunch of triangles which random texture)

Title: New features added!
Post by: Lolilolight on May 28, 2014, 12:57:33 pm
Hi!

I've added a class to attach tiles together, (the class  BigTile.)

I've also added the sound module.

Mmmm..., I have to rework the lighting/shadow system and normally all is finished for the 2D and the 2.5D.

So the next functionnalities'll only concern the 3D.



Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on May 28, 2014, 01:06:33 pm
Will you keep saying every post that its just a little thing then its finished and then you never are? :p
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on May 28, 2014, 09:54:36 pm
There is a tutorial and a demo but I certainly need to make other things like : class documentation, a website, etc...

I'll not say a delay anymore because I really don't know about the time it'll take, I didn't expected that make the documentation'll take so long.

PS : I must also thing about a video which'll encourage anyone to keep an eye on my framework.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on May 29, 2014, 01:49:15 am
stop thinking and do.. why don't you implement something new every day and show us the screenshot of what you have? it would certainly keep everyone more interested and would be more fun than reading "I found a new bug, I had to rewrite everything"..

Trust me, your classes are poorly designed so far and you will need to refactor most things many times until you have something you love, let alone impressing other people.. That's why making an engine for all games takes years, and you want to do it in months with no experience..
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on May 29, 2014, 10:00:28 am
Yeah good idea.

I'm actually reworking tilesets to do this.


Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on May 29, 2014, 05:33:43 pm
It's quite annoying to put all images on a tileset so, I think I'll begin to make the final version, the second version is pretty finished anyway.
And most of all, there are some shaders that I want to test!

So, the next news'll not be given until. (I don't know when)

I don't want to bring news that'll not encourage people.



Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on May 29, 2014, 09:21:27 pm
Ok, I'll try to make that..., I have just to make hero and monsters tilesets......
But it can already does a lot of things so it'll take time to make a video of everything...
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on May 29, 2014, 10:28:38 pm
There are lots of tilesets in the web.. Use some to get going.. To pack png's into a tileset I recommend texture packer..
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on May 29, 2014, 10:41:57 pm
Yeah I use them but I have to retouch them, because, the background is not transparent and they are not on a big image.

And sometimes the shadow is rendered. (I don't need it, I can generate light and shadow myself with a shader)

I have begin to write a small  shader for this :

perPixelLighting = new Shader();
    const std::string   vertexShader =
    "void main () {"
        "gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;"
        "gl_TexCoord[0] = gl_TextureMatrix[0] * gl_MultiTexCoord0;"
        "gl_FrontColor = gl_Color;"
    "}";
    const std::string fragmentShader =
    "uniform sampler2D depthBuffer;"
    "uniform vec3 resolution;"
    "uniform vec4 lightPos;"
    "uniform vec4 lightColor;"
    "const vec2 size = vec2(2.0,0.0);"
    "const ivec3 off = ivec3(-1,0,1);"
    "void main () {     "
        "vec2 position = ( gl_FragCoord.xy / resolution.xy );"
        "vec4 depth = texture2D(depthBuffer, position);"
        "float s01 = textureOffset(depthBuffer, position, off.xy).z;"
        "float s21 = textureOffset(depthBuffer, position, off.zy).z;"
        "float s10 = textureOffset(depthBuffer, position, off.yx).z;"
        "float s12 = textureOffset(depthBuffer, position, off.yz).z;"
        "vec3 va = normalize (vec3(size.xy, s21 - s01));"
        "vec3 vb = normalize (vec3(size.yx, s12 - s10));"
        "vec3 bump = normalize(vec3 (cross(va, vb)));"
        "vec4 pixPos = vec3 (position.x, position.y, depth.z, 0);"
        "vec4 vertexToLight = lightPos - pixPos;"
        "float attenuation = 1.0f - (length(vertexToLight) / lightPos.a);"
        "vec3 dirToLight = normalize(vertexToLight.xyz);"
        "float nDotl = dot (dirToLight, bump);"
        "float attenuation *= nDotl;"
        "gl_FragColor = lightColor * max(0.0f, attenuation);"
    "}";
 

But it's for the 3D, and, I havent' tested yet.
The idea is to generate the normal map with the depth buffer.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on May 29, 2014, 10:55:58 pm
You want to have everything working from the start, you have absolutely nothing to show and yet you re trying to make lighting right away? Even worse that you are clearly not comfortable with what you're doing, that shader code is probably copied from somewhere they way you speak about it...
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: lezebulon on May 29, 2014, 11:00:55 pm
17 pages and not even anything to show.... I don't get it
who do you think will use this ? I can't even tell what are the key feature that are not utility stuff
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: StormWingDelta on May 30, 2014, 02:45:03 am
Why not try getting a working mini-game up and running with what you have currently since it would help in building the Engine.  I'd build the engine as I was building a game or two that would be using it rather than trying to build the engine without any game to use it.  Also you could have a large number of demos that show what the different functionality does as well if a full game is too complicated. :)


Try to keep in mind people are going to keep nagging at you until they see something worth getting interested in or until you can prove you aren't getting in over your head.  Github allows us to help you so if you want help with something just ask and we'll help.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on May 30, 2014, 07:56:46 am
Yeah maybe I shouldn't do the 3D yet, and make a 2D game as a demo.

My shaders are not copied from anywhere I simply do them by myself with my own knowledge of opengl and by reading some tutorials :

http://mdeverdelhan.developpez.com/tutoriel/dynamiclight/tutoriel1/ (http://mdeverdelhan.developpez.com/tutoriel/dynamiclight/tutoriel1/)

I've also to search how retrieve neightbours pixels in a texture. (So I've found the offset function)

Do you think that I copy paste source code like some of you ? It never gives the results that you hope to have anyway, so, I've no interest of doing this.

My shader is totally different than the shader presented in his tutorial and it doens't manage diffuse component yet, and most of all, he doesn't use FBO and I do, this tutorial seems to be pretty old,

But I have to test my shader later.

It's nice to present screenshot of copied projects and one of them was created and has the same name than the old name of my framework (so funny) but please don't compare me to you.
Thanks.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on May 30, 2014, 12:44:05 pm
The best response I can make to that last post is: AAHAHAHAHAHAHHAAHHAHAHAHA
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: select_this on May 30, 2014, 01:21:47 pm
...

Do you think that I copy paste source code like some of you ?

...

It's nice to present screenshot of copied projects and one of them was created and has the same name than the old name of my framework (so funny) but please don't compare me to you.

You haven't got 10+ members of the community all saying the same thing to you for no reason at all - you're not normally as abrasive as this so perhaps we can let that slide, but you just don't seem to want to listen to criticism, constructive or otherwise - this is probably why replies to your posts are getting shorter and more curt than they would be otherwise. Sometimes it seems like your responses indicate that you're getting the message, per se, but then your subsequent posts seem to revert back, which I imagine is increasing the frustration.

I, for one, would love to see all your hard work come to fruition. As far as I can tell no one wants you to fail, they're just advising that you're likely to in your current course of action, based on the experience of thousands upon thousands of developers and programmers. We're saying all this to help you succeed.

You obviously have a lot of determination, which is fantastic - I hope that never leaves you. But you also seem to have excess pride - if you can curtail that and listen to all the advice given, without judgement of character or intention on either side, you'll get where you wanna go a lot quicker and a lot less painfully.  :)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on May 30, 2014, 01:29:47 pm
I've rewritten the abstract classes world and EntityManagerBase correctly, now, the world call the right function with the templates. (The function of the base class of all entity managers)

The developper can create entity managers as any type as he want, so if he want to have a more complexe entity manager, he can, but he have to redefines different functions (it depends if it is a 2D or a 3D entity manager)
Personaly I hesitate, which is the best, passing the entity manager type directly as a template argument of the world like the entity, or, don't pass it and force the developper to redefines some functions for 2 types of entity manager bases. (2D and 3D)

I prefer the second solution but I doubt a bit about it.

Anyway I have to ovewritte the functions of the class odfaeg::transform in the g2d::Entity class to pass 2D vectors instead of 3D vector, it'll be more practice, and finishing the tilesets and then, I'll be able to make a video.





Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: select_this on May 30, 2014, 01:45:49 pm
Personaly I hesitate, which is the best, passing the entity manager type directly as a template argument of the world like the entity, or, don't pass it and force the developper to redefines some functions for 2 types of entity manager bases. (2D and 3D)

I don't know much about what you're trying to do, but from the sound of it the second mechanism could get very unwieldy very quickly, especially if it doesn't cater for use cases you've not yet thought of. I suppose it depends on how much genericism you anticipate would be useful, and how many functions the user would be forced to override.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on May 30, 2014, 02:52:55 pm
The second solution is quite heavy but the genericism is also important, because, I can't manage 2D and 3D entities by the same way, 3D entities are stored in a 3D grid and 2D entitites in a 2D grid and the culling methods also differs. (I don't need a z culling for 2D entities)
The shadows and the light map generation also differs for 2D and 3D entitites.
I need to have a generic entity manager for 2D entitites and another one for 3D entities and defines some functions for all of them.

-The number of function to overload : I can decide it by myself. But to have a good entity manager, it's generally usefull to have something like 10 functions. (I use one for the frustum culling, another for loading 2D or 3D entities on components. (They decides how to render entitites), another to update the entities in the grid when they are transformed, another to find the path between two grid cells, etc...)

I don't use a BSP tree because of the path finding, I don't know how to do this with a BSP-tree and I want to let the possibility to the user to create one for 2D and 3D entities if he needs to make something more complex.
But excepted that difference, the mecanism is the same for 2D and 3D entities. (They use the same classes to render they vertices, it's just that the z of 2D entities is hidden, I use it only for the z-sorting and also in my shaders)
And the components make the links between 2D and 3D entities and the windows to render them in an more optimal way, later I think I'll make instanced rendering in components but actually I don't know how I can do that, it seems that this new features are not supported by a lot of PC's yet, I don't know if it's possible to do that with GLSL 130. (Which is the last version supported by my ati driver in ubuntu)
And moddern opengl (with glVertexAttribPointer) don't seems to render anything with my components but it works without any problems with older opengl function.  (with glVertexColorPointer)
But when I do moddern opengl directly in a main it render something. (I figure out that there is certainly a problem in the class RenderTarget with the gl context)

For the components there is only one type of component at the moment (RenderComponent) which render the entities of the framework but later I think it'll be usefull to add a second type (guicomponent) to render guis like buttons, checkbox, etc... with sf-gui.





Title: Shadows and lights are there again!!!
Post by: Lolilolight on June 02, 2014, 04:25:20 pm
Shadows and lights are there again!!! (With the shadow map and the lightmap generation)

I've pretty finished to improve and clean the graphic's engine bugs, so now, I'll do the same with the physic's engine.

And then I'll make a video!!!

And after that, I have to test the sound module, I never tested the one of SFML until now.


Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: lezebulon on June 02, 2014, 08:58:25 pm
how does the "shadow map" work for 2D stuff ? what does it actually draw?
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on June 02, 2014, 11:18:10 pm
Its so confusing to use the shadow map term like that.. The shadow map is a well defined popular technique but I sense its been re-invented for some reason in this library..
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on June 02, 2014, 11:37:09 pm
Hi!

I project the sprites and the walls on the ground and I draw them all on a rendertexture to get the shadowmap and then I draw the shadow on the ground.
It's why I called this technique "shadow map.", I just know there exists a similar technique for the 3D, this is why I called it shadow map. (In 3D this technique projet the shadow with a shader where a fragment is projected onto another fragment)

I use the same technique to draw lights with the lightmapping technik, for the 2D. (For the 3D I'll use normal mapping instead, or, vertex linghting with old graphics cards)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: lezebulon on June 03, 2014, 12:26:37 am
I'm not really sure I understand... do you have a picture of how it actually project 2D sprites on the "ground"?
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: StormWingDelta on June 03, 2014, 03:25:57 am
Hi!

I project the sprites and the walls on the ground and I draw them all on a rendertexture to get the shadowmap and then I draw the shadow on the ground.
It's why I called this technique "shadow map.", I just know there exists a similar technique for the 3D, this is why I called it shadow map. (In 3D this technique projet the shadow with a shader where a fragment is projected onto another fragment)

I use the same technique to draw lights with the lightmapping technik, for the 2D. (For the 3D I'll use normal mapping instead, or, vertex linghting with old graphics cards)
I don't recommend Reinventing the Wheel if you don't have too or aren't trying to avoid relying on other libraries.  If it has been thought of chances are someone made a library for it.  Don't feel to bothered by using smaller libraries to save on time if you have too.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on June 03, 2014, 03:51:41 pm
I think that in one week (or two max) I'll be able to put a screen, I just want to be sure that all is ok.

Now I've just implemented this :

http://www.codezealot.org/archives/55 (http://www.codezealot.org/archives/55)

But I'll have to find a library for physics and especially for collisions ray/shapes.



Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on June 03, 2014, 07:05:35 pm
Can you explain why did you implement SAT if you are about to pick a physics library? You're making something really hard to make and yet, apparently, your biggest enemy is yourself :)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Jesper Juhl on June 03, 2014, 07:14:38 pm
I'm honestly suspecting that we are seeing a case of the Dunning–Kruger effect (http://en.m.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect) in action.
Not saying that to be demeaning or anything; we've probably all been there to some degree - it's just the most likely explanation as I see it.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on June 03, 2014, 07:34:11 pm
Quote
Can you explain why did you implement SAT if you are about to pick a physics library? You're making something really hard to make
.
It's not so hard to make after all, but it's not to use for bounding boxes because it's too slow, it's only for polygons.

Here is a screen shot with my shadow projections :

http://www.hostingpics.net/viewer.php?id=586783Capturedu20140603192908.png (http://www.hostingpics.net/viewer.php?id=586783Capturedu20140603192908.png)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Jesper Juhl on June 03, 2014, 07:39:05 pm
The shadow of the wall near the bonfire looks a bit "odd". But generally that looks nice - well done.
Perhaps the shadows would look better if they got slightly transparent near the edges and with a bit of antialiasing. But that's just a guess :)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on June 03, 2014, 07:54:52 pm
Yeah I know it isn't very accurate (for the shadow near the bonfire), it's because I've just projected the bottom points of the wall and build a convex shapes. (For the shadows of the walls)

This is why the shadow looks a bit odd.

I don't have another solution for the 2D. (because I haven't the z position of each pixels like in 3D)

Maybe add an antialiasing and transparency near the shadow edges like you said.





Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: G. on June 03, 2014, 08:01:47 pm
The shadow of the wall near the bonfire looks a bit "odd".
Odd? Shitty as hell yes.
http://www.hostingpics.net/viewer.php?id=586783Capturedu20140603192908.png (http://www.hostingpics.net/viewer.php?id=586783Capturedu20140603192908.png)
Looks very different from this 4 year old screenshot http://i.imgur.com/R9irYgo.jpg
Glad to see you're still using those walls you stole from another project. :D
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on June 03, 2014, 08:42:39 pm
Lol my old map editor, but, this time I think I'll make it with sf-gui.

There are too much dependencies with Qt and I think the macros and moc files used by Qt are a bit deprecated.

At least now you know that I don't do it with no experience, but since 4 years ago. :P

So it's time that I implement the game play now. (Lol)

But I wanted to put everything in a lib before, it'll be more practice for all myprojects. :P (My editor, the server and the client, so, there are 3 projects)
If I modify source code it's modified in my 3 projects directly.
Then I decided to make it opensource but...., in case of someone else needs it.



Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: lezebulon on June 03, 2014, 09:24:44 pm
thanks for the image! but it's exactly what I thought, it doesn't look very convincing, here all I can see is that the objects are floating above the grass and that we see their reflection in the grass (and not their shadow)

Unfortunately I don't think there's any solution to do convincing 2D shadows for just the sprite data
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on June 04, 2014, 01:03:07 am
Those shadows beside not looking good they are also incorrect :/ And this is the same scene you've shown months ago, there is nothing new..

You can't even get a good isometric game yet with the library, how do you expect to nail ALL other game genres perspectives and so on?

Also, it would rock if you could pay more attention to your english. I am totally fine with reading the broken english in every post but seeing you write the same way in your editors / source code is heartbreaking and sounds plain sloppy.. :(
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Excellium on June 04, 2014, 10:19:03 am
Lolilolight, have you ever heard of deferred shading ?
I worked with Gregouar in the past, on his 2.5D light engine (http://fr.openclassrooms.com/forum/sujet/csfmlopengl-moteur-d-eclairage-2-5d-63262#.U47YJ_l_s4M), and it had a pretty nice rendering.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on June 04, 2014, 01:57:16 pm
I don't know what deffered shading is, maybe I should search later but I don't plan to have a very nice rendering now, but, just a 2D isometric RPG. (If I can create one I'll be very happy)

As you said, i didn't advanced, because I had to put every source code in a library and rewrite all the source code of Gregouar for all my projects. (And adding some functionnality like the networking, etc...)
His code was not maintenable and, I hate copy/paste source code because I don't learn and I don't understand anything.

My shadows are not very different than the ones of Gregouar, it's him which have initialized me to the game creation univers in 2D iso.

Maybe he have improved them a bit after but I don't see something different.

I've added a transparent outline around the shadows, it seems to be better but I need to have rounded corners for the ani-aliasing, but, SFML don't provide a way to create shapes with rounded corners and I have to implement it myself later.

But please, don't bring some displaced behaviour from this website here.
I really hope this website'll not become like this website and I don't want to wasting time with some members of this website again.
So I say, say ya.

PS : And I can create orthographic and perspective projection with odfaeg, and loading 3D animated models soon (but I want to finish my 2D isometric game first), so, don't say wrong things here please.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on June 04, 2014, 04:19:07 pm
Where are you from if I might ask? And how old are you? :)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on June 04, 2014, 05:12:53 pm
In Belgium and I'm 25 years old. :)

All the framework versions should be finished for my 30 years old. :D (Only the last version remains)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on June 04, 2014, 07:42:42 pm
How would the games your framework could do in 5 years look like? : )
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on June 04, 2014, 07:58:57 pm
Probably like holy spirit but in pure 3D.
Title: Re: [ODFAEG] A major change!!!
Post by: Lolilolight on June 05, 2014, 01:36:19 pm
It seems that SDL support more plateforms and drivers than SFML.

So I think I'll change and choose SDL for the windowing rather than SFML, but I'll keep SFML for the networking and the sounds module I think. :)

It depends how it'll works.




Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on June 05, 2014, 02:46:56 pm
Yay now you can share the pain with the SDL forum people too :)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on June 05, 2014, 03:03:43 pm
Yeah but I'll just rewrite the sf::Window class and the glContext classes for the different plateform also.

I'll not use sf::VideoMode anymore with seems to leads to some compatibility problems.

I hope that It'll not be too complicated. (The functions of SDL are very similar to the ones of SFML)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on June 05, 2014, 03:19:45 pm
Maybe your awesome library will run even more awesome when fully ported to SDL, I bet everyone in the SDL forum is anxious to have you in the community : )
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on June 05, 2014, 04:08:46 pm
I think I'll try to improve the sfml window and porting the window module to SDL to get rid of the WindowImpl classes for the different plateforms.

But there is a different opengl context for each plateform so, it'll take a little time.

Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on June 05, 2014, 06:43:17 pm
SDL 2 seems to be very nice, I think I'll be able to use GLSL 3 and correct my previous problems.

There is also a class called SDL_GLContext, that's exactly what I needed!
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on June 05, 2014, 06:47:31 pm
Why are you discussing SDL topics in the SFML forum?
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: FRex on June 05, 2014, 07:00:36 pm
He is trying to port sf::Window to use SDL internally so it works even on semi exotic systems that SDL 2 supports but SFML 2.2 doesn't.
That's quite interesting (and semi-realistic...) idea actually. If this was done right it could be binary compatible even, just the WindowImpl pointer would have to be changed to be another type of pointer (SDL_Window pointer).
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on June 05, 2014, 09:53:47 pm
Yeah that's it! :)


Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Laurent on June 05, 2014, 10:16:48 pm
What's the point? Just use SDL directly, its API is simple and well abstracted too, it even has more features.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Excellium on June 05, 2014, 11:37:25 pm
And go spamming the SDL forum ! haha sorry, too easy joke xD
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on June 06, 2014, 03:42:18 pm
Hi.
I have changed the WindowImpl pointer to a SDL_Window pointer, I have also added an SDL_GLContext class and modified the sf::GlContext class.

changed all sf::Event to SDL_Event but now I have an ambiguity problem in the headers files of SDL, between the Uint64 type of SDL and sf::Uint64.

I'm surprised that they didn't named they variables as SDL_Uint64, because in C there are no namespace to correct the ambiguity, I think I'll have to spam their forum a bit to tell them to change. :P

But meanwhile I think I'll get rid of the SFML System module and using only SDL functions and std::thread, it should solve the issue.



Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Nexus on June 06, 2014, 03:43:38 pm
I'm surprised that they didn't named they variables as SDL_Uint64, because in C there are no namespace to correct the ambiguity, I think I'll have to spam their forum a bit to tell them to change. :P
But SFML has a namespace, why is that not enough!?
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on June 06, 2014, 03:48:06 pm
I think this is not enought because gcc seach in the sf::namespace and also in anonymous namespace (and not  in the current namespace)
And there are the same types in the two libs so...
Code: [Select]

-------------- Build: Debug in ODFAEG-DEMO (compiler: GNU GCC Compiler)---------------

In file included from /usr/include/SDL2/SDL_main.h:25:0,
                 from /usr/include/SDL2/SDL.h:67,
                 from /usr/local/include/odfaeg/Graphics/videoMode.h:3,
                 from /usr/local/include/odfaeg/Graphics/window.h:5,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/SDL2/SDL_stdinc.h:169:1: error: reference to ‘Uint64’ is ambiguous
 SDL_COMPILE_TIME_ASSERT(uint64, sizeof(Uint64) == 8);
 ^
/usr/include/SDL2/SDL_stdinc.h:154:18: note: candidates are: typedef uint64_t Uint64
 typedef uint64_t Uint64;
                  ^
In file included from /usr/local/include/SFML/Graphics/Export.hpp:31:0,
                 from /usr/local/include/odfaeg/Graphics/renderWindow.h:7,
                 from /usr/local/include/odfaeg/Core/application.h:4,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/myApplication.h:8,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:2:
/usr/local/include/SFML/Config.hpp:153:36: note:                 typedef long long unsigned int sf::Uint64
         typedef unsigned long long Uint64;
                                    ^
In file included from /usr/include/SDL2/SDL_main.h:25:0,
                 from /usr/include/SDL2/SDL.h:67,
                 from /usr/local/include/odfaeg/Graphics/videoMode.h:3,
                 from /usr/local/include/odfaeg/Graphics/window.h:5,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/SDL2/SDL_stdinc.h:318:42: error: reference to ‘Uint64’ is ambiguous
 extern DECLSPEC char *SDLCALL SDL_ulltoa(Uint64 value, char *str, int radix);
                                          ^
In file included from /usr/include/SDL2/SDL_main.h:25:0,
                 from /usr/include/SDL2/SDL.h:67,
                 from /usr/local/include/odfaeg/Graphics/videoMode.h:3,
                 from /usr/local/include/odfaeg/Graphics/window.h:5,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/SDL2/SDL_stdinc.h:154:18: note: candidates are: typedef uint64_t Uint64
 typedef uint64_t Uint64;
                  ^
In file included from /usr/local/include/SFML/Graphics/Export.hpp:31:0,
                 from /usr/local/include/odfaeg/Graphics/renderWindow.h:7,
                 from /usr/local/include/odfaeg/Core/application.h:4,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/myApplication.h:8,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:2:
/usr/local/include/SFML/Config.hpp:153:36: note:                 typedef long long unsigned int sf::Uint64
         typedef unsigned long long Uint64;
                                    ^
In file included from /usr/include/SDL2/SDL_main.h:25:0,
                 from /usr/include/SDL2/SDL.h:67,
                 from /usr/local/include/odfaeg/Graphics/videoMode.h:3,
                 from /usr/local/include/odfaeg/Graphics/window.h:5,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/SDL2/SDL_stdinc.h:318:56: error: expected primary-expression before ‘char’
 extern DECLSPEC char *SDLCALL SDL_ulltoa(Uint64 value, char *str, int radix);
                                                        ^
/usr/include/SDL2/SDL_stdinc.h:318:67: error: expected primary-expression before ‘int’
 extern DECLSPEC char *SDLCALL SDL_ulltoa(Uint64 value, char *str, int radix);
                                                                   ^
/usr/include/SDL2/SDL_stdinc.h:318:76: error: expression list treated as compound expression in initializer [-fpermissive]
 extern DECLSPEC char *SDLCALL SDL_ulltoa(Uint64 value, char *str, int radix);
                                                                            ^
/usr/include/SDL2/SDL_stdinc.h:325:17: error: reference to ‘Uint64’ is ambiguous
 extern DECLSPEC Uint64 SDLCALL SDL_strtoull(const char *str, char **endp, int base);
                 ^
In file included from /usr/include/SDL2/SDL_main.h:25:0,
                 from /usr/include/SDL2/SDL.h:67,
                 from /usr/local/include/odfaeg/Graphics/videoMode.h:3,
                 from /usr/local/include/odfaeg/Graphics/window.h:5,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/SDL2/SDL_stdinc.h:154:18: note: candidates are: typedef uint64_t Uint64
 typedef uint64_t Uint64;
                  ^
In file included from /usr/local/include/SFML/Graphics/Export.hpp:31:0,
                 from /usr/local/include/odfaeg/Graphics/renderWindow.h:7,
                 from /usr/local/include/odfaeg/Core/application.h:4,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/myApplication.h:8,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:2:
/usr/local/include/SFML/Config.hpp:153:36: note:                 typedef long long unsigned int sf::Uint64
         typedef unsigned long long Uint64;
                                    ^
In file included from /usr/include/SDL2/SDL_main.h:25:0,
                 from /usr/include/SDL2/SDL.h:67,
                 from /usr/local/include/odfaeg/Graphics/videoMode.h:3,
                 from /usr/local/include/odfaeg/Graphics/window.h:5,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/SDL2/SDL_stdinc.h:325:17: error: ‘Uint64’ does not name a type
 extern DECLSPEC Uint64 SDLCALL SDL_strtoull(const char *str, char **endp, int base);
                 ^
In file included from /usr/include/SDL2/SDL_audio.h:33:0,
                 from /usr/include/SDL2/SDL.h:71,
                 from /usr/local/include/odfaeg/Graphics/videoMode.h:3,
                 from /usr/local/include/odfaeg/Graphics/window.h:5,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/SDL2/SDL_endian.h:167:18: error: reference to ‘Uint64’ is ambiguous
 SDL_FORCE_INLINE Uint64
                  ^
In file included from /usr/include/SDL2/SDL_main.h:25:0,
                 from /usr/include/SDL2/SDL.h:67,
                 from /usr/local/include/odfaeg/Graphics/videoMode.h:3,
                 from /usr/local/include/odfaeg/Graphics/window.h:5,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/SDL2/SDL_stdinc.h:154:18: note: candidates are: typedef uint64_t Uint64
 typedef uint64_t Uint64;
                  ^
In file included from /usr/local/include/SFML/Graphics/Export.hpp:31:0,
                 from /usr/local/include/odfaeg/Graphics/renderWindow.h:7,
                 from /usr/local/include/odfaeg/Core/application.h:4,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/myApplication.h:8,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:2:
/usr/local/include/SFML/Config.hpp:153:36: note:                 typedef long long unsigned int sf::Uint64
         typedef unsigned long long Uint64;
                                    ^
In file included from /usr/include/SDL2/SDL_audio.h:33:0,
                 from /usr/include/SDL2/SDL.h:71,
                 from /usr/local/include/odfaeg/Graphics/videoMode.h:3,
                 from /usr/local/include/odfaeg/Graphics/window.h:5,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/SDL2/SDL_endian.h:167:18: error: ‘Uint64’ does not name a type
 SDL_FORCE_INLINE Uint64
                  ^
In file included from /usr/include/SDL2/SDL_audio.h:36:0,
                 from /usr/include/SDL2/SDL.h:71,
                 from /usr/local/include/odfaeg/Graphics/videoMode.h:3,
                 from /usr/local/include/odfaeg/Graphics/window.h:5,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/SDL2/SDL_rwops.h:204:17: error: reference to ‘Uint64’ is ambiguous
 extern DECLSPEC Uint64 SDLCALL SDL_ReadLE64(SDL_RWops * src);
                 ^
In file included from /usr/include/SDL2/SDL_main.h:25:0,
                 from /usr/include/SDL2/SDL.h:67,
                 from /usr/local/include/odfaeg/Graphics/videoMode.h:3,
                 from /usr/local/include/odfaeg/Graphics/window.h:5,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/SDL2/SDL_stdinc.h:154:18: note: candidates are: typedef uint64_t Uint64
 typedef uint64_t Uint64;
                  ^
In file included from /usr/local/include/SFML/Graphics/Export.hpp:31:0,
                 from /usr/local/include/odfaeg/Graphics/renderWindow.h:7,
                 from /usr/local/include/odfaeg/Core/application.h:4,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/myApplication.h:8,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:2:
/usr/local/include/SFML/Config.hpp:153:36: note:                 typedef long long unsigned int sf::Uint64
         typedef unsigned long long Uint64;
                                    ^
In file included from /usr/include/SDL2/SDL_audio.h:36:0,
                 from /usr/include/SDL2/SDL.h:71,
                 from /usr/local/include/odfaeg/Graphics/videoMode.h:3,
                 from /usr/local/include/odfaeg/Graphics/window.h:5,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/SDL2/SDL_rwops.h:204:17: error: ‘Uint64’ does not name a type
 extern DECLSPEC Uint64 SDLCALL SDL_ReadLE64(SDL_RWops * src);
                 ^
/usr/include/SDL2/SDL_rwops.h:205:17: error: reference to ‘Uint64’ is ambiguous
 extern DECLSPEC Uint64 SDLCALL SDL_ReadBE64(SDL_RWops * src);
                 ^
In file included from /usr/include/SDL2/SDL_main.h:25:0,
                 from /usr/include/SDL2/SDL.h:67,
                 from /usr/local/include/odfaeg/Graphics/videoMode.h:3,
                 from /usr/local/include/odfaeg/Graphics/window.h:5,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/SDL2/SDL_stdinc.h:154:18: note: candidates are: typedef uint64_t Uint64
 typedef uint64_t Uint64;
                  ^
In file included from /usr/local/include/SFML/Graphics/Export.hpp:31:0,
                 from /usr/local/include/odfaeg/Graphics/renderWindow.h:7,
                 from /usr/local/include/odfaeg/Core/application.h:4,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/myApplication.h:8,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:2:
/usr/local/include/SFML/Config.hpp:153:36: note:                 typedef long long unsigned int sf::Uint64
         typedef unsigned long long Uint64;
                                    ^
In file included from /usr/include/SDL2/SDL_audio.h:36:0,
                 from /usr/include/SDL2/SDL.h:71,
                 from /usr/local/include/odfaeg/Graphics/videoMode.h:3,
                 from /usr/local/include/odfaeg/Graphics/window.h:5,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/SDL2/SDL_rwops.h:205:17: error: ‘Uint64’ does not name a type
 extern DECLSPEC Uint64 SDLCALL SDL_ReadBE64(SDL_RWops * src);
                 ^
/usr/include/SDL2/SDL_rwops.h:219:63: error: reference to ‘Uint64’ is ambiguous
 extern DECLSPEC size_t SDLCALL SDL_WriteLE64(SDL_RWops * dst, Uint64 value);
                                                               ^
In file included from /usr/include/SDL2/SDL_main.h:25:0,
                 from /usr/include/SDL2/SDL.h:67,
                 from /usr/local/include/odfaeg/Graphics/videoMode.h:3,
                 from /usr/local/include/odfaeg/Graphics/window.h:5,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/SDL2/SDL_stdinc.h:154:18: note: candidates are: typedef uint64_t Uint64
 typedef uint64_t Uint64;
                  ^
In file included from /usr/local/include/SFML/Graphics/Export.hpp:31:0,
                 from /usr/local/include/odfaeg/Graphics/renderWindow.h:7,
                 from /usr/local/include/odfaeg/Core/application.h:4,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/myApplication.h:8,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:2:
/usr/local/include/SFML/Config.hpp:153:36: note:                 typedef long long unsigned int sf::Uint64
         typedef unsigned long long Uint64;
                                    ^
In file included from /usr/include/SDL2/SDL_audio.h:36:0,
                 from /usr/include/SDL2/SDL.h:71,
                 from /usr/local/include/odfaeg/Graphics/videoMode.h:3,
                 from /usr/local/include/odfaeg/Graphics/window.h:5,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/SDL2/SDL_rwops.h:219:63: error: ‘Uint64’ has not been declared
 extern DECLSPEC size_t SDLCALL SDL_WriteLE64(SDL_RWops * dst, Uint64 value);
                                                               ^
/usr/include/SDL2/SDL_rwops.h:220:63: error: reference to ‘Uint64’ is ambiguous
 extern DECLSPEC size_t SDLCALL SDL_WriteBE64(SDL_RWops * dst, Uint64 value);
                                                               ^
In file included from /usr/include/SDL2/SDL_main.h:25:0,
                 from /usr/include/SDL2/SDL.h:67,
                 from /usr/local/include/odfaeg/Graphics/videoMode.h:3,
                 from /usr/local/include/odfaeg/Graphics/window.h:5,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/SDL2/SDL_stdinc.h:154:18: note: candidates are: typedef uint64_t Uint64
 typedef uint64_t Uint64;
                  ^
In file included from /usr/local/include/SFML/Graphics/Export.hpp:31:0,
                 from /usr/local/include/odfaeg/Graphics/renderWindow.h:7,
                 from /usr/local/include/odfaeg/Core/application.h:4,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/myApplication.h:8,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:2:
/usr/local/include/SFML/Config.hpp:153:36: note:                 typedef long long unsigned int sf::Uint64
         typedef unsigned long long Uint64;
                                    ^
In file included from /usr/include/SDL2/SDL_audio.h:36:0,
                 from /usr/include/SDL2/SDL.h:71,
                 from /usr/local/include/odfaeg/Graphics/videoMode.h:3,
                 from /usr/local/include/odfaeg/Graphics/window.h:5,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/SDL2/SDL_rwops.h:220:63: error: ‘Uint64’ has not been declared
 extern DECLSPEC size_t SDLCALL SDL_WriteBE64(SDL_RWops * dst, Uint64 value);
                                                               ^
In file included from /usr/include/SDL2/SDL.h:91:0,
                 from /usr/local/include/odfaeg/Graphics/videoMode.h:3,
                 from /usr/local/include/odfaeg/Graphics/window.h:5,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/SDL2/SDL_timer.h:61:17: error: reference to ‘Uint64’ is ambiguous
 extern DECLSPEC Uint64 SDLCALL SDL_GetPerformanceCounter(void);
                 ^
In file included from /usr/include/SDL2/SDL_main.h:25:0,
                 from /usr/include/SDL2/SDL.h:67,
                 from /usr/local/include/odfaeg/Graphics/videoMode.h:3,
                 from /usr/local/include/odfaeg/Graphics/window.h:5,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/SDL2/SDL_stdinc.h:154:18: note: candidates are: typedef uint64_t Uint64
 typedef uint64_t Uint64;
                  ^
In file included from /usr/local/include/SFML/Graphics/Export.hpp:31:0,
                 from /usr/local/include/odfaeg/Graphics/renderWindow.h:7,
                 from /usr/local/include/odfaeg/Core/application.h:4,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/myApplication.h:8,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:2:
/usr/local/include/SFML/Config.hpp:153:36: note:                 typedef long long unsigned int sf::Uint64
         typedef unsigned long long Uint64;
                                    ^
In file included from /usr/include/SDL2/SDL.h:91:0,
                 from /usr/local/include/odfaeg/Graphics/videoMode.h:3,
                 from /usr/local/include/odfaeg/Graphics/window.h:5,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/SDL2/SDL_timer.h:61:17: error: ‘Uint64’ does not name a type
 extern DECLSPEC Uint64 SDLCALL SDL_GetPerformanceCounter(void);
                 ^
/usr/include/SDL2/SDL_timer.h:66:17: error: reference to ‘Uint64’ is ambiguous
 extern DECLSPEC Uint64 SDLCALL SDL_GetPerformanceFrequency(void);
                 ^
In file included from /usr/include/SDL2/SDL_main.h:25:0,
                 from /usr/include/SDL2/SDL.h:67,
                 from /usr/local/include/odfaeg/Graphics/videoMode.h:3,
                 from /usr/local/include/odfaeg/Graphics/window.h:5,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/SDL2/SDL_stdinc.h:154:18: note: candidates are: typedef uint64_t Uint64
 typedef uint64_t Uint64;
                  ^
In file included from /usr/local/include/SFML/Graphics/Export.hpp:31:0,
                 from /usr/local/include/odfaeg/Graphics/renderWindow.h:7,
                 from /usr/local/include/odfaeg/Core/application.h:4,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/myApplication.h:8,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:2:
/usr/local/include/SFML/Config.hpp:153:36: note:                 typedef long long unsigned int sf::Uint64
         typedef unsigned long long Uint64;
                                    ^
In file included from /usr/include/SDL2/SDL.h:91:0,
                 from /usr/local/include/odfaeg/Graphics/videoMode.h:3,
                 from /usr/local/include/odfaeg/Graphics/window.h:5,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/SDL2/SDL_timer.h:66:17: error: ‘Uint64’ does not name a type
 extern DECLSPEC Uint64 SDLCALL SDL_GetPerformanceFrequency(void);
                 ^
In file included from /usr/include/SDL2/SDL_syswm.h:66:0,
                 from /usr/local/include/odfaeg/Graphics/window.h:15,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/X11/Xlib.h:211:9: error: reference to ‘Font’ is ambiguous
         Font font;         /* default text font for text operations */
         ^
In file included from /usr/include/X11/Xlib.h:44:0,
                 from /usr/include/SDL2/SDL_syswm.h:66,
                 from /usr/local/include/odfaeg/Graphics/window.h:15,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/X11/X.h:100:13: note: candidates are: typedef XID Font
 typedef XID Font;
             ^
In file included from /usr/local/include/SFML/Graphics.hpp:35:0,
                 from /usr/local/include/odfaeg/Graphics/transformMatrix.h:10,
                 from /usr/local/include/odfaeg/Graphics/renderTarget.h:5,
                 from /usr/local/include/odfaeg/Graphics/renderWindow.h:8,
                 from /usr/local/include/odfaeg/Core/application.h:4,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/myApplication.h:8,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:2:
/usr/local/include/SFML/Graphics/Font.hpp:50:25: note:                 class sf::Font
 class SFML_GRAPHICS_API Font
                         ^
In file included from /usr/include/SDL2/SDL_syswm.h:66:0,
                 from /usr/local/include/odfaeg/Graphics/window.h:15,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/X11/Xlib.h:211:9: error: ‘Font’ does not name a type
         Font font;         /* default text font for text operations */
         ^
/usr/include/X11/Xlib.h:272:2: error: reference to ‘Window’ is ambiguous
  Window root;  /* Root window id. */
  ^
In file included from /usr/include/X11/Xlib.h:44:0,
                 from /usr/include/SDL2/SDL_syswm.h:66,
                 from /usr/local/include/odfaeg/Graphics/window.h:15,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/X11/X.h:96:13: note: candidates are: typedef XID Window
 typedef XID Window;
             ^
In file included from /usr/local/include/SFML/Window.hpp:40:0,
                 from /usr/local/include/SFML/Graphics.hpp:32,
                 from /usr/local/include/odfaeg/Graphics/transformMatrix.h:10,
                 from /usr/local/include/odfaeg/Graphics/renderTarget.h:5,
                 from /usr/local/include/odfaeg/Graphics/renderWindow.h:8,
                 from /usr/local/include/odfaeg/Core/application.h:4,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/myApplication.h:8,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:2:
/usr/local/include/SFML/Window/Window.hpp:57:23: note:                 class sf::Window
 class SFML_WINDOW_API Window : GlResource, NonCopyable
                       ^
In file included from /usr/include/SDL2/SDL_syswm.h:66:0,
                 from /usr/local/include/odfaeg/Graphics/window.h:15,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/X11/Xlib.h:272:2: error: ‘Window’ does not name a type
  Window root;  /* Root window id. */
  ^
/usr/include/X11/Xlib.h:326:5: error: reference to ‘Window’ is ambiguous
     Window root;         /* root of screen containing window */
     ^
In file included from /usr/include/X11/Xlib.h:44:0,
                 from /usr/include/SDL2/SDL_syswm.h:66,
                 from /usr/local/include/odfaeg/Graphics/window.h:15,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/X11/X.h:96:13: note: candidates are: typedef XID Window
 typedef XID Window;
             ^
In file included from /usr/local/include/SFML/Window.hpp:40:0,
                 from /usr/local/include/SFML/Graphics.hpp:32,
                 from /usr/local/include/odfaeg/Graphics/transformMatrix.h:10,
                 from /usr/local/include/odfaeg/Graphics/renderTarget.h:5,
                 from /usr/local/include/odfaeg/Graphics/renderWindow.h:8,
                 from /usr/local/include/odfaeg/Core/application.h:4,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/myApplication.h:8,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:2:
/usr/local/include/SFML/Window/Window.hpp:57:23: note:                 class sf::Window
 class SFML_WINDOW_API Window : GlResource, NonCopyable
                       ^
In file included from /usr/include/SDL2/SDL_syswm.h:66:0,
                 from /usr/local/include/odfaeg/Graphics/window.h:15,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/X11/Xlib.h:326:5: error: ‘Window’ does not name a type
     Window root;         /* root of screen containing window */
     ^
/usr/include/X11/Xlib.h:415:5: error: reference to ‘Window’ is ambiguous
     Window sibling;
     ^
In file included from /usr/include/X11/Xlib.h:44:0,
                 from /usr/include/SDL2/SDL_syswm.h:66,
                 from /usr/local/include/odfaeg/Graphics/window.h:15,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/X11/X.h:96:13: note: candidates are: typedef XID Window
 typedef XID Window;
             ^
In file included from /usr/local/include/SFML/Window.hpp:40:0,
                 from /usr/local/include/SFML/Graphics.hpp:32,
                 from /usr/local/include/odfaeg/Graphics/transformMatrix.h:10,
                 from /usr/local/include/odfaeg/Graphics/renderTarget.h:5,
                 from /usr/local/include/odfaeg/Graphics/renderWindow.h:8,
                 from /usr/local/include/odfaeg/Core/application.h:4,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/myApplication.h:8,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:2:
/usr/local/include/SFML/Window/Window.hpp:57:23: note:                 class sf::Window
 class SFML_WINDOW_API Window : GlResource, NonCopyable
                       ^
In file included from /usr/include/SDL2/SDL_syswm.h:66:0,
                 from /usr/local/include/odfaeg/Graphics/window.h:15,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/X11/Xlib.h:415:5: error: ‘Window’ does not name a type
     Window sibling;
     ^
/usr/include/X11/Xlib.h:481:9: error: reference to ‘Time’ is ambiguous
         Time time;
         ^
In file included from /usr/include/X11/Xlib.h:44:0,
                 from /usr/include/SDL2/SDL_syswm.h:66,
                 from /usr/local/include/odfaeg/Graphics/window.h:15,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/X11/X.h:77:23: note: candidates are: typedef long unsigned int Time
 typedef unsigned long Time;
                       ^
In file included from /usr/local/include/SFML/System/Clock.hpp:32:0,
                 from /usr/local/include/SFML/System.hpp:33,
                 from /usr/local/include/odfaeg/Math/vec4.h:6,
                 from /usr/local/include/odfaeg/Graphics/view.h:4,
                 from /usr/local/include/odfaeg/Graphics/renderTarget.h:3,
                 from /usr/local/include/odfaeg/Graphics/renderWindow.h:8,
                 from /usr/local/include/odfaeg/Core/application.h:4,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/myApplication.h:8,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:2:
/usr/local/include/SFML/System/Time.hpp:40:23: note:                 class sf::Time
 class SFML_SYSTEM_API Time
                       ^
In file included from /usr/include/SDL2/SDL_syswm.h:66:0,
                 from /usr/local/include/odfaeg/Graphics/window.h:15,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/X11/Xlib.h:481:9: error: ‘Time’ does not name a type
         Time time;
         ^
/usr/include/X11/Xlib.h:574:2: error: reference to ‘Window’ is ambiguous
  Window window;         /* "event" window it is reported relative to */
  ^
In file included from /usr/include/X11/Xlib.h:44:0,
                 from /usr/include/SDL2/SDL_syswm.h:66,
                 from /usr/local/include/odfaeg/Graphics/window.h:15,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/X11/X.h:96:13: note: candidates are: typedef XID Window
 typedef XID Window;
             ^
In file included from /usr/local/include/SFML/Window.hpp:40:0,
                 from /usr/local/include/SFML/Graphics.hpp:32,
                 from /usr/local/include/odfaeg/Graphics/transformMatrix.h:10,
                 from /usr/local/include/odfaeg/Graphics/renderTarget.h:5,
                 from /usr/local/include/odfaeg/Graphics/renderWindow.h:8,
                 from /usr/local/include/odfaeg/Core/application.h:4,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/myApplication.h:8,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:2:
/usr/local/include/SFML/Window/Window.hpp:57:23: note:                 class sf::Window
 class SFML_WINDOW_API Window : GlResource, NonCopyable
                       ^
In file included from /usr/include/SDL2/SDL_syswm.h:66:0,
                 from /usr/local/include/odfaeg/Graphics/window.h:15,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/X11/Xlib.h:574:2: error: ‘Window’ does not name a type
  Window window;         /* "event" window it is reported relative to */
  ^
/usr/include/X11/Xlib.h:575:2: error: reference to ‘Window’ is ambiguous
  Window root;         /* root window that the event occurred on */
  ^
In file included from /usr/include/X11/Xlib.h:44:0,
                 from /usr/include/SDL2/SDL_syswm.h:66,
                 from /usr/local/include/odfaeg/Graphics/window.h:15,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/X11/X.h:96:13: note: candidates are: typedef XID Window
 typedef XID Window;
             ^
In file included from /usr/local/include/SFML/Window.hpp:40:0,
                 from /usr/local/include/SFML/Graphics.hpp:32,
                 from /usr/local/include/odfaeg/Graphics/transformMatrix.h:10,
                 from /usr/local/include/odfaeg/Graphics/renderTarget.h:5,
                 from /usr/local/include/odfaeg/Graphics/renderWindow.h:8,
                 from /usr/local/include/odfaeg/Core/application.h:4,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/myApplication.h:8,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:2:
/usr/local/include/SFML/Window/Window.hpp:57:23: note:                 class sf::Window
 class SFML_WINDOW_API Window : GlResource, NonCopyable
                       ^
In file included from /usr/include/SDL2/SDL_syswm.h:66:0,
                 from /usr/local/include/odfaeg/Graphics/window.h:15,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/X11/Xlib.h:575:2: error: ‘Window’ does not name a type
  Window root;         /* root window that the event occurred on */
  ^
/usr/include/X11/Xlib.h:576:2: error: reference to ‘Window’ is ambiguous
  Window subwindow; /* child window */
  ^
In file included from /usr/include/X11/Xlib.h:44:0,
                 from /usr/include/SDL2/SDL_syswm.h:66,
                 from /usr/local/include/odfaeg/Graphics/window.h:15,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/X11/X.h:96:13: note: candidates are: typedef XID Window
 typedef XID Window;
             ^
In file included from /usr/local/include/SFML/Window.hpp:40:0,
                 from /usr/local/include/SFML/Graphics.hpp:32,
                 from /usr/local/include/odfaeg/Graphics/transformMatrix.h:10,
                 from /usr/local/include/odfaeg/Graphics/renderTarget.h:5,
                 from /usr/local/include/odfaeg/Graphics/renderWindow.h:8,
                 from /usr/local/include/odfaeg/Core/application.h:4,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/myApplication.h:8,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:2:
/usr/local/include/SFML/Window/Window.hpp:57:23: note:                 class sf::Window
 class SFML_WINDOW_API Window : GlResource, NonCopyable
                       ^
In file included from /usr/include/SDL2/SDL_syswm.h:66:0,
                 from /usr/local/include/odfaeg/Graphics/window.h:15,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/X11/Xlib.h:576:2: error: ‘Window’ does not name a type
  Window subwindow; /* child window */
  ^
/usr/include/X11/Xlib.h:577:2: error: reference to ‘Time’ is ambiguous
  Time time;  /* milliseconds */
  ^
In file included from /usr/include/X11/Xlib.h:44:0,
                 from /usr/include/SDL2/SDL_syswm.h:66,
                 from /usr/local/include/odfaeg/Graphics/window.h:15,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/X11/X.h:77:23: note: candidates are: typedef long unsigned int Time
 typedef unsigned long Time;
                       ^
In file included from /usr/local/include/SFML/System/Clock.hpp:32:0,
                 from /usr/local/include/SFML/System.hpp:33,
                 from /usr/local/include/odfaeg/Math/vec4.h:6,
                 from /usr/local/include/odfaeg/Graphics/view.h:4,
                 from /usr/local/include/odfaeg/Graphics/renderTarget.h:3,
                 from /usr/local/include/odfaeg/Graphics/renderWindow.h:8,
                 from /usr/local/include/odfaeg/Core/application.h:4,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/myApplication.h:8,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:2:
/usr/local/include/SFML/System/Time.hpp:40:23: note:                 class sf::Time
 class SFML_SYSTEM_API Time
                       ^
In file included from /usr/include/SDL2/SDL_syswm.h:66:0,
                 from /usr/local/include/odfaeg/Graphics/window.h:15,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/X11/Xlib.h:577:2: error: ‘Time’ does not name a type
  Time time;  /* milliseconds */
  ^
/usr/include/X11/Xlib.h:592:2: error: reference to ‘Window’ is ambiguous
  Window window;         /* "event" window it is reported relative to */
  ^
In file included from /usr/include/X11/Xlib.h:44:0,
                 from /usr/include/SDL2/SDL_syswm.h:66,
                 from /usr/local/include/odfaeg/Graphics/window.h:15,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/X11/X.h:96:13: note: candidates are: typedef XID Window
 typedef XID Window;
             ^
In file included from /usr/local/include/SFML/Window.hpp:40:0,
                 from /usr/local/include/SFML/Graphics.hpp:32,
                 from /usr/local/include/odfaeg/Graphics/transformMatrix.h:10,
                 from /usr/local/include/odfaeg/Graphics/renderTarget.h:5,
                 from /usr/local/include/odfaeg/Graphics/renderWindow.h:8,
                 from /usr/local/include/odfaeg/Core/application.h:4,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/myApplication.h:8,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:2:
/usr/local/include/SFML/Window/Window.hpp:57:23: note:                 class sf::Window
 class SFML_WINDOW_API Window : GlResource, NonCopyable
                       ^
In file included from /usr/include/SDL2/SDL_syswm.h:66:0,
                 from /usr/local/include/odfaeg/Graphics/window.h:15,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/X11/Xlib.h:592:2: error: ‘Window’ does not name a type
  Window window;         /* "event" window it is reported relative to */
  ^
/usr/include/X11/Xlib.h:593:2: error: reference to ‘Window’ is ambiguous
  Window root;         /* root window that the event occurred on */
  ^
In file included from /usr/include/X11/Xlib.h:44:0,
                 from /usr/include/SDL2/SDL_syswm.h:66,
                 from /usr/local/include/odfaeg/Graphics/window.h:15,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/X11/X.h:96:13: note: candidates are: typedef XID Window
 typedef XID Window;
             ^
In file included from /usr/local/include/SFML/Window.hpp:40:0,
                 from /usr/local/include/SFML/Graphics.hpp:32,
                 from /usr/local/include/odfaeg/Graphics/transformMatrix.h:10,
                 from /usr/local/include/odfaeg/Graphics/renderTarget.h:5,
                 from /usr/local/include/odfaeg/Graphics/renderWindow.h:8,
                 from /usr/local/include/odfaeg/Core/application.h:4,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/myApplication.h:8,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:2:
/usr/local/include/SFML/Window/Window.hpp:57:23: note:                 class sf::Window
 class SFML_WINDOW_API Window : GlResource, NonCopyable
                       ^
In file included from /usr/include/SDL2/SDL_syswm.h:66:0,
                 from /usr/local/include/odfaeg/Graphics/window.h:15,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/X11/Xlib.h:593:2: error: ‘Window’ does not name a type
  Window root;         /* root window that the event occurred on */
  ^
/usr/include/X11/Xlib.h:594:2: error: reference to ‘Window’ is ambiguous
  Window subwindow; /* child window */
  ^
In file included from /usr/include/X11/Xlib.h:44:0,
                 from /usr/include/SDL2/SDL_syswm.h:66,
                 from /usr/local/include/odfaeg/Graphics/window.h:15,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/X11/X.h:96:13: note: candidates are: typedef XID Window
 typedef XID Window;
             ^
In file included from /usr/local/include/SFML/Window.hpp:40:0,
                 from /usr/local/include/SFML/Graphics.hpp:32,
                 from /usr/local/include/odfaeg/Graphics/transformMatrix.h:10,
                 from /usr/local/include/odfaeg/Graphics/renderTarget.h:5,
                 from /usr/local/include/odfaeg/Graphics/renderWindow.h:8,
                 from /usr/local/include/odfaeg/Core/application.h:4,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/myApplication.h:8,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:2:
/usr/local/include/SFML/Window/Window.hpp:57:23: note:                 class sf::Window
 class SFML_WINDOW_API Window : GlResource, NonCopyable
                       ^
In file included from /usr/include/SDL2/SDL_syswm.h:66:0,
                 from /usr/local/include/odfaeg/Graphics/window.h:15,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/X11/Xlib.h:594:2: error: ‘Window’ does not name a type
  Window subwindow; /* child window */
  ^
/usr/include/X11/Xlib.h:595:2: error: reference to ‘Time’ is ambiguous
  Time time;  /* milliseconds */
  ^
In file included from /usr/include/X11/Xlib.h:44:0,
                 from /usr/include/SDL2/SDL_syswm.h:66,
                 from /usr/local/include/odfaeg/Graphics/window.h:15,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/X11/X.h:77:23: note: candidates are: typedef long unsigned int Time
 typedef unsigned long Time;
                       ^
In file included from /usr/local/include/SFML/System/Clock.hpp:32:0,
                 from /usr/local/include/SFML/System.hpp:33,
                 from /usr/local/include/odfaeg/Math/vec4.h:6,
                 from /usr/local/include/odfaeg/Graphics/view.h:4,
                 from /usr/local/include/odfaeg/Graphics/renderTarget.h:3,
                 from /usr/local/include/odfaeg/Graphics/renderWindow.h:8,
                 from /usr/local/include/odfaeg/Core/application.h:4,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/myApplication.h:8,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:2:
/usr/local/include/SFML/System/Time.hpp:40:23: note:                 class sf::Time
 class SFML_SYSTEM_API Time
                       ^
In file included from /usr/include/SDL2/SDL_syswm.h:66:0,
                 from /usr/local/include/odfaeg/Graphics/window.h:15,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/X11/Xlib.h:595:2: error: ‘Time’ does not name a type
  Time time;  /* milliseconds */
  ^
/usr/include/X11/Xlib.h:610:2: error: reference to ‘Window’ is ambiguous
  Window window;         /* "event" window reported relative to */
  ^
In file included from /usr/include/X11/Xlib.h:44:0,
                 from /usr/include/SDL2/SDL_syswm.h:66,
                 from /usr/local/include/odfaeg/Graphics/window.h:15,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/X11/X.h:96:13: note: candidates are: typedef XID Window
 typedef XID Window;
             ^
In file included from /usr/local/include/SFML/Window.hpp:40:0,
                 from /usr/local/include/SFML/Graphics.hpp:32,
                 from /usr/local/include/odfaeg/Graphics/transformMatrix.h:10,
                 from /usr/local/include/odfaeg/Graphics/renderTarget.h:5,
                 from /usr/local/include/odfaeg/Graphics/renderWindow.h:8,
                 from /usr/local/include/odfaeg/Core/application.h:4,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/myApplication.h:8,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:2:
/usr/local/include/SFML/Window/Window.hpp:57:23: note:                 class sf::Window
 class SFML_WINDOW_API Window : GlResource, NonCopyable
                       ^
In file included from /usr/include/SDL2/SDL_syswm.h:66:0,
                 from /usr/local/include/odfaeg/Graphics/window.h:15,
                 from /home/laurent/Développement/Projets-c++/ODFAEG-DEMO/main.cpp:10:
/usr/include/X11/Xlib.h:610:2: error: ‘Window’ does not name a type
  Window window;         /* "event" window reported relative to */
  ^
/usr/include/X11/Xlib.h:611:2: error: reference to ‘Window’ is ambiguous

So I think that they are conflicts between SDL and SFML :/
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Nexus on June 06, 2014, 03:57:22 pm
What do you think is the purpose of namespaces if they can't avoid the simplest name conflicts?

When you write using namespace, do you really wonder why it leads to problems? ::)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on June 06, 2014, 04:23:01 pm
If you really want to use using namespace, you can also choose which type is known by default with using..

using sf::Integer; or
using sdl::Integer;
(change to proper type names)

If I am not mistaken that works well to choose which type will then belong to the global namespace.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on June 06, 2014, 04:50:19 pm
I'm using namespace in the .cpp files only but maybe it's not enought.

SDL have no namespace because it's written in C so, I don't now if the compiler do a distinction between sf::Uint32 and Uint32.

But it's not for nothing that all opengl functions are prefixed by the GL prefix.

SDL functions too but I'm just suprised that it isn't the case for the basic SDL integers types.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Nexus on June 06, 2014, 04:55:25 pm
I'm using namespace in the .cpp files only but maybe it's not enought.
It is more than enough, don't do it at all!

Qualify sf always, or at least make sure you don't include SFML and SDL headers at the same time.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: select_this on June 06, 2014, 04:55:50 pm
I don't now if the compiler do a distinction between sf::Uint32 and Uint32.

If you import the sf namespace, then no, it won't, regardless of whether it's in a source or header file. How can it? Imagine this scenario:

using namespace derp; // I made this up - imagine it has an int typedef called 'Uint32'
using namespace sf; // This also has the Uint32 typedef

...

Uint32 anInteger = 4; // Which Uint32 is this supposed to be? derp's version? sf's version?
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Jesper Juhl on June 06, 2014, 05:02:52 pm
Just stop with the "using namespace sf;" bit. When you do that you pull everything from the "sf" namespace into the global namespace and of course you then have problems. Just ditch that bad habit and get used to writing sf:: and std:: and there will be no problems. It's quite simple really.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on June 06, 2014, 05:15:47 pm
Ok I've removed the using and it works. thx. :)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on June 06, 2014, 09:40:31 pm
SDL is working fine now but I had to retract all the encapsulation over the gl context provided by SFML, it seems that it failed to create a context with a thread.
But it's often the source of many problems.


Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: zsbzsb on June 06, 2014, 09:44:59 pm
Do we really still need updates if you are now using SDL2?
Title: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: The Terminator on June 07, 2014, 12:07:43 am
^
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on June 07, 2014, 10:22:26 am
No, no updates here for the moment, I'll wate until i have finished the IA and the gameplay for the demo.

And I have some things to ask to the SDL forum, because SDL doesn't seems to like when I don't create the opengl context in the main.
Title: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: The Terminator on June 07, 2014, 04:18:00 pm
If you don't have any updates, why bother posting? This thread has over 300 posts already, many of which are your pointless "I still have to fix" posts that just annoy people. Plus, you don't need to tell us that you're going to spam the SDL forums regarding things that don't even have to do with SFML.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on June 07, 2014, 05:08:35 pm
Ok ok let's settle this.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on June 08, 2014, 03:56:04 pm
I've finished to port the source code soon, I've just to change the sf::Event to SDL_Event because SDL events structures are different.

The framework'll work on more exotic plateform and'll be able to manage multi-screen!

I'm just wondering why I don't  used it before.

But, maybe it's because SDL 2 wasn't released yet when I discovered SFML which was better at this time but it's not more the case now.

Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: zsbzsb on June 08, 2014, 03:59:33 pm
So you are now using SDL2.... then why are you still posting here? ???
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Jesper Juhl on June 08, 2014, 03:59:45 pm
Since you are now free of SFML and using SDL instead, could these pointless updates stop now? Please.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on June 08, 2014, 04:03:54 pm
Ok, ok, now, I'll stop to post here and create a thread on the SDL forum. :)

I think this is time for me to change.  :)

I dont think that SFML'll die because there are still some interessant modules than the window and graphics modules, I don't know the sound and the network modules of SDL but it seems there are not so good than the SFML ones which implements selectors.

I just hope that all of this'll be compatible. :)

So the thread here'll die.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: lezebulon on June 08, 2014, 04:27:45 pm
...and no demo was ever posted =)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on June 08, 2014, 05:34:55 pm
Yes right I'll post one demo on this forum and on the SDL forum (because I still use SFML for the network and the sound) but, this'll be for later, I still have to do all the game play. (And rewrite my IA)

And finishing to adapt the graphic module with SDL.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on June 08, 2014, 05:39:26 pm
This has been going for months and he still has absolutely nothing done..

I think I never met anyone to whom this article(http://scientificninja.com/blog/write-games-not-engines) applies more...
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: G. on June 08, 2014, 05:54:05 pm
This has been going for months and he still has absolutely nothing done..
Years (4 or 5) actually. :p
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Jesper Juhl on June 08, 2014, 10:35:35 pm
Lolilolight, seriously; stop it.

I have to say this (and I probably couldn't sugar-coat it even if I tried, so I'm just going to say it) but it's really nothing you haven't been told multiple times already by multiple people, so it shouldn't come as a surprise.

Yes right I'll post one demo on this forum and on the SDL forum (because I still use SFML for the network and the sound) but, this'll be for later
I'll believe this when I see it.

... I still have to do all the game play. (And rewrite my IA)
Sure you do, just like you've just finished subsystem "foo" and just need to implement "bar" - then a few days later you've finished "bar" but needed to rewrite "foo"  yadayada...
And btw, if you mean "Artificial Intelligence", then it's "AI", not "IA" - and seriously, that's not something you just write and it's not something that can be generalized and put into a "framework".

And finishing to adapt the graphic module with SDL.
Have fun. I for one am looking forward to seeing the SDL peoples reactions when you start spamming their forum (I've got popcorn ready).
At this point I personally don't think it makes any difference if you use SDL, SFML, raw OpenGL or whatever else - you'll end up with the same broken mess either way.

If you want to write games, then write a game rather than writing an engine (http://scientificninja.com/blog/write-games-not-engines) (as Grimshaw already said).
You are just wasting your time - time that you could spend writing an actual game.
I'll bet real money that whatever you end up with for this framework of yours will be something that you won't even use yourself (once you try to build an actual game) and I'm 100% positive that noone else will use it either if you keep at it like you have been for the past many months (years?).

You should really start reading what people have been writing in this thread over and over and realize that maybe you are not the programming god you think you are and start doing some real work towards learning C++ well before trying to do something more ambitious.
Just the fact that you recently had to be told what the effect of using "using namespace foo;" actually does (which is in chapter 1 of any decent C++ book) tells me that you are a beginner with too much self confidence and you really need to acknowledge the fact that maybe you really do have a lot to learn.
There's a reason I linked to the Dunning–Kruger effect (http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect) earlier - I honestly believe that you are suffering from this; to quote "If you’re incompetent, you can’t know you’re incompetent. […] the skills you need to produce a right answer are exactly the skills you need to recognize what a right answer is.".

And speaking about updates to this thread. Noone cares that you've just updated whatever odd corner of your code, so don't post that here. If you have a personal dev blog then post it there - at least there it would be somewhat at home.

I've seen you write that you are 25 years of age (so was I at some point lost in history). Take it from someone who's been writing code for longer than you have been alive: I've made many of the same mistakes you have. I've been overconfident with my own skill. I've believed that everyone else were idiots and I was the only genious who could write something good. etc.  I've also been proven wrong!
It took me years to learn that I wrote crap code and that I had basically no ide what I was doing. I finally got it and started to listen to people better than me and to seriously study the things I work with and I believe (hope) that I've improved. So can you. But you need to start!

And this thread needs to end!
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Lolilolight on June 08, 2014, 10:38:39 pm
I've finished the engine, now I'm testing it. (I don't care about the time because unlikely some of my old comerades like Gregouar I can encode a games with 100 lines instead of 1000 if I didn't had an engine.)

The only things which remains to do is more optimized rendering. (by example pixel by pixel rendering, 3D terrain generation and 3D obj model loading)

And I don't need the whole documentation and the whole functionnalities of a framework to do that.

My framework makes only 200 mo.

I'm not an amator like Greg, I'm a professionnal, I've already done stages, high level studies and many other things at home. (Not only games so)

Then, please, stop trolling.

PS : The AI is for the demo and will not be a part of the framework.

PS 2 : I'll stop to answer here know, otherwise it'll become..., a war.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Nexus on June 08, 2014, 11:04:09 pm
PS 2 : I'll stop to answer here know, otherwise it'll become..., a war.
I actually wanted to write something, but you're probably right. Everything important has been said meanwhile. So let's see...

To the other users, it would be nice if you didn't post here just to repeat the things that have been said, or for your personal entertainment... Otherwise this will never end.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Jesper Juhl on June 08, 2014, 11:10:54 pm
...
I'm not an amator like Greg, I'm a professionnal, I've already done stages, high level studies and many other things at home. (Not only games so)

Then, please, stop trolling.

I'm not trolling.
Whatever you may think, I'm actually trying to help you.

And as far as being an amateur goes, I fail to see how you could be much else.
Personally I started writing code when I was 12 (that's 26 years ago by now) (C64 basic, then moved to m68000 asm on the amiga, x386 asm on i386 and then onto C, C++ and other languages). When I was 25 I was still fairly green and my current self would consider my 25year old self an amateur.

What moves you from amateur to professional is what you've done and the experience you've gained.
Personally (just to give a little example) I've been involved with the Linux kernel for ~20 years by now (and the git history proves it (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/?id=refs%2Ftags%2Fv3.15-rc7&qt=author&q=Jesper+Juhl) (at least as far back as it goes)), doing mostly minor stuff, but hey it's been good. I was one of the original architects (and main developers) behind the Keepit (http://www.keepit.com/) backup software for close to 5 years. I worked on the Sysorb (http://www.evalesco.com/) monitoring software for years (including writing a defragmentation tool for their custom database).
I've done video streaming software, software to cryptographically secure http connections, software to maintain/manage hundreds of webservers at hosting companies, credit card clearing software and much much more. I'm currently employed doing work on a medical image viewer - amongst other things optimizing its streaming capabilities. I've also worked as a software tester and Systems Administrator amongst other things.
Not to boast, but that in my book qualifies me as a professional. Merely having a degree in computer science and a few hobby projects does not (in my book). And I'll take the liberty to say that at this point in time I believe I have a fairly good idea of what makes a competent developer and what doesn't.
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Ixrec on June 08, 2014, 11:12:53 pm
To the other users, it would be nice if you didn't post here just to repeat the things that have been said, or for your personal entertainment... Otherwise this will never end.

^
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Grimshaw on June 09, 2014, 02:44:57 am
Jesper and the others make pretty fair observations indeed.. I'd just say that worse than a lacking C++ knowledge,(I think Lolilolight has enough c++ knowledge to get something decent done) is the complete cluelessness about engine architectures..

He doesn't seem to have any idea how old engines used to be built and much less how modern engines are being built (They are successful and thriving for a reason, but you seem to think your design is simply better than theirs). Yet, you seem to think you can make an awesome engine on the first try, with the first weird clueless design you could came up with.. Not only your end to this task is poorly defined, you are taking the wrong path in the wrong way...

But well, no one better than a future you to proove to yourself the things people have been saying around here.. I think some day you will understand that "those little things that you just need to finish to be done with it" are actually tasks so complex that you can't even do yet.. Even if you don't get to that, I truly wish you the best of luck and success in what you're doing :)
Title: Re: [ODFAEG] (Open Source Development Framework Adapted for Every Game)
Post by: Laurent on June 09, 2014, 11:47:00 am
This thread ends right now.

Lolilolight: feel free to ask me to unlock this thread as soon as you have something relevant to show. I'll be happy to do it.

Others: I know, but... this has to stop, really.