Moteur de jeux (ODFAEG) et jeux.

Version imprimable

Voir 40 message(s) de cette discussion en une page

05/02/2015, 21h13
Cirrus Minor

1 pièce(s) jointe(s)

Citation:

Envoyé par Lolilolight

Tout aide pour la personnalisation du forum est la bienvenue. :)

Je commence :)

T'as oublié quelques corrections (voir capture d'écran plus bas) dans ton copier coller du forum SFML :aie:

Et il y aura *vraiment* un ODFAEG game jam ou s'est aussi un oubli ?

Pièce jointe 168215
05/02/2015, 21h39
Invité

Merci je vais corriger cela sur le forum.
Non il y aura un game jam! :D (Car J'ai envie de voir ce que peut faire le framework!)

Là je fais un pong en réseau, et ça va, j'avance bien. :)
07/02/2015, 15h01
Invité

Tutoriels vidéos :

Sur ma chaîne youtube vous pouvez trouver plusieurs vidéos, sur la réalisation d'un pong en réseau avec le moteur!

Mais je ne l'ai pas encore terminé..., là je suis entrain de finir la partie serveur. (Qui effectuera tout les calculs en fonction du temps de latence et des collisions, chose pas si simple que ça à faire.)

J'en ai profiter pour améliorer un peu le moteur pour la version 1.2 à venir.
Par principe je ne garde pas les versions antérieures, comme le fait SFML, car il n'y a pas de différences majeures entre les versions comme avec SFML, juste de l'ajout de fonctionnalités et de l'optimisation.

-Désormais chaque utilisateur (côté serveur) possède une horloge synchronisée avec le client! (J'ai intégré ça dans le framework pour ne pas devoir faire la synchronisation avec les horloges des clients pour chaque jeux)
Ce qui permettra de gérer les collisions à travers le réseau de manière simple en récupérant une position dans le passé par exemple. (Lorsque le client à envoyé le message et non pas lorsque le serveur à reçu le message)
-Possibilité d'ajouter des guis (boutons, zone d'édition de texte, etc...) avec gestion des événements propre à la gui en question et de décider pour quel(s) interface(s) on souhaite traiter les événements, par exemple, si on affiche un menu seul les événements du menu peuvent être traité.
Pour cela il suffit d'activer et désactiver le context de gestion des événements pour la gui (ou bien pour la fenêtre principale de l'application)

L'origine des guis par défaut est le coin supérieur gauche de l'écran et on ne peut pas changé la vue contrairement aux composants de rendu.

Les guis s'affichent tout à la fin c'est à dire après l'appel de la méthode onDisplay() (donc après l'affichage de la "shadowMap" et de la "lightMap" si on reprend la démo)
09/02/2015, 11h26
Invité

Amélioration du module physique à venir.

Salut!

Le module graphique étant pratiquement terminé (pour la 2D), je me penche donc du côté du module physique et de la recherche d'algorithme générique pour détecter les collisions entre volumes 2D et 3D.

J'ai une structure de base avec des interfaces mais je n'ai pas encore pu tout tester car il y a, pas mal de volumes englobants.

J'ai pu améliorer cependant ce module suite à la réalisation du pong :

-Désormais la classe boundingvolume possède une méthode pour détecter l'intersection entre un volume englobant et un rayon!
-La méthode d'intersection permet maintenant de choisir de rechercher la collision soit entre 2 points (segment) ou bien soit entre un point et l'infini. (demi-droite)
-Possibilité de récupérer le MTU si 2 volumes englobants sont en collision, pour information, le MTU (minimal translation vector) est le vecteur que doit parcourir une entité pour qu'elle ne soit plus en collision avec l'autre entité.

Plus tard je tâcherai de gérer les corps souple (non rigide) mais ce n'est pas pour tout de suite. :/
11/02/2015, 00h12
maeiky

J'aime bien tes vidéos, surtout tes derniers tutoriels, ça vaut la peine d'aller voir :ptdr:

Tu n'as pas mis de lien? Bref le voici :

https://www.youtube.com/channel/UCaoPAXXJI8nWNhpSMz6PQfw/videos

En tout cas, je ne me tanne pas, c'est super. Je sais pas si tu vas arriver à réaliser tout ce que tu souhaite, j'ai hâte de voir le résultat.
11/02/2015, 17h03
Invité

Ha, merci pour le lien, je le cherchais! :D

Ici là maintenant je viens juste de finir le serveur du pong, donc, il me faut encore faire le client et j'espère que j'aurai le résultat que je souhaite. :)

Là ça upload la dernière vidéo pour le pong côté serveur ou j'ai effectué quelques corrections au niveau du code.

Normalement d'ici 5-10 minutes maxi elle devrait y être.
19/02/2015, 18h27
Invité

Version 1.3 sortie!

Sortie de la version 1.3, celle-ci intègre quelques guis!

Les différentes guis :

-odfaeg::graphic::gui::Button (gère un bouton avec une gestion des événements fort similaire à celle du framework Swing de java.
-odfaeg::graphic::gui::OptionPane (gère une sous fenêtre de dialogue (deux type pour le moment, boîte de confirmation, ou boîte de message)
-odfaeg::graphic::gui::TextArea (gère une zone de saisie de texte)

Bon ok ce n'est pas encore très personnalisable et beau pour l'instant mais, ce n'est pas le but visé pour le moment.

Du coup j'ai fais deux interfaces pour pouvoir réaliser ses propres type de guis ou bien composants de rendus plus complexe :

LightComponent : interface pour tout les composants graphique de rendu légés. (Les guis par exemple)
HeavyComponent : interface pour tout les composants graphique de rendu lourd. (Le rendu multi-passe par exemple, ces composants possèdes leur propre buffer)

On peut ainsi hériter des interfaces HeavyComponent et EntityManager si l'on souhaite utiliser d'autres shader pour générer la lightmap, ainsi que la shadow map et les buffers, ça évite ainsi de devoir faire trop de if dans les shaders ce qui n'est pas très bon côté performance.

Si l'on souhaite créer une gui on peut hériter de la classe LightComponent et comme chaque composant possède son propre contexte pour la gestion d'événement, on peut créer des événements personnalisés pour les composants graphiques avec des interfaces pour la gestion d'événements comme avec Awt/Swing.
21/02/2015, 20h42
Invité

Bon..., je ne sais pas si il y a moyen de changer le tag d'un sujet sans devoir en recréer un.

Donc il y a toujours le tag recrutement.

Je voudrais le changer en [Projet en cours] voir même projet terminé car à part des ajouts de fonctionnalités, le moteur ne comportera rien d'autre, je vais peut être ajouter des interfaces pour les autres librairies (bien que j'hésite à le faire car le linkage dynamique me pose quelques soucis et je ne m'y connais pas du tout au niveau des compilateurs et encore moins au niveau de l'OS et de la programmation de bas niveau mais j'espère quand même pouvoir un jour apprendre les bases, car je pense que ça pourrait être un plus surtout pour les administrateurs système.)

Je ne compte plus recruter.

Je ne sais pas si des personnes utiliseront mon moteur ou encore me proposeront des ajouts de fonctionnalités (je n'en connais pas) mais si c'est le cas j'en serai ravi.

Donc je clôture ce sujet. ^^
25/02/2015, 14h48
Invité

Révision du moteur réseau.

Salut!

Aujourd'hui je viens de corriger un bug avec le moteur réseau.

Auparavant je comparais les adresses IP pour retrouver l'utilisateur qui a envoyé le messages, mais le soucis est que dans le cas d'un réseau local ou tout les utilisateurs ont l'adresse IP 127.0.0.1 par exemple, alors cela posait problème.

J'ai donc fait comme ceci :

Pour le protocole TCP : c'est facile à chaque connexion d'un utilisateur, un nouveau socket est créer, je passe donc l'adresse mémoire de cette socket à l'utilisateur et ensuite à chaque fois qu'un socket à reçu un message TCP je n'ai plus qu'à rechercher à quel utilisateur appartient cette socket en comparant les adresses mémoires.

Pour le protocole UDP ça a été un peu plus compliqué car, le serveur utilise la même socket pour réceptionné les messages de tout les utilisateurs.
Cependant si les utilisateurs sont sur la même machine, il sont obligés d'utiliser un port différent pour envoyer les messages. (Si je ne me trompe pas)
Je fait donc désormais une comparaison sur l'adresse IP et le port distant utilisé par l'utilisateur pour envoyer les messages.

PS : j'aurai pu utiliser la même technique pour le protocole TCP et UDP vu que en TCP aussi le problème se pose je pense lorsque les clients sont sur la même machine, il doit choisir un port différent pour chaque client pour envoyer les messages au serveur.

M'enfin bref...
26/02/2015, 14h54
skeud

ça sera pas plus simple qu'au moment de la connection, le serveur attribue un identifiant unique à ton client, lui envois?

Ensuite pour toute les demandes, ton client envois cet identifiant au serveur en meme temps que la demande?

en général, en reseau c'est toujours ce qu'on fait, pour pallier aussi les problème de desynchronisation qui entraine une perte de connection TCP.
26/02/2015, 15h23
Invité

Citation:

ça sera pas plus simple qu'au moment de la connection, le serveur attribue un identifiant unique à ton client, lui envois?

Oui, j'aurai pu faire ça aussi.

De quel problèmes de désynchronisation parles tu ?

L'adresse mémoire de la socket côté serveur ne changera pas durant toute la durée de la connexion, et puis comme le client ne connais pas l'adresse mémoire de la socket côté serveur, je trouve que c'est bien pour éviter la triche. (Car un identifiant, on peut toujours le changer avec des logiciels pour tricher)

Je compte faire pareil pour les autres entités qui ne sont pas des clients mais des ennemis par exemple. (des monstres)
26/02/2015, 15h53
skeud

Il suffit qu'une desynchornisation se passe sur le DSLAM entre ton serveur et ton client pour que la socket se ferme, et ton adresse de socket sera donc invalide.

Il n'y a alors aucun moyen de retrouver les informations du client se reconnectant.

Si c'est ton serveur qui génère l'identifiant de connection, il n'y a aucun risque de triche :).
26/02/2015, 18h00
Invité

Ha, ok bah je vais faire ça alors. :D

Correction d'un problème avec la fonction bind.

Désormais, ont peut appeler bind plusieurs fois, ceci changera bien le paramètre.

En fait j'ai dû faire un tuple temporaire pour que à chaque appel à bind ça remettent les types du tuple à ph<i, type> pour "rebind" une nouvelle valeur.

Code:

1
2
3
4
5
6
7
8
9
10
11
 
int func (int arg) {
    std::cout<<" arg : "<<arg<<std::endl;
}
int main() {
     FastDelegate<void> fd(&func, ph<0, int>);
     fd.bind(2);
     fd();
     fd.bind(4);
     fd();
}

Auparavant cela m'affichait toujours deux, ici ça m'affiche bien deux et quatre.

Désormais, on peut créer ses propres types de gui de manière vraiment simple, par exemple, cette classe défini une zone de texte.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
 
#include "../../../../include/odfaeg/Graphics/GUI/textArea.hpp"
namespace odfaeg {
    namespace graphic {
        namespace gui {
            TextArea::TextArea(math::Vec3f position, math::Vec3f size, const Font* font, sf::String t, RenderWindow& rw) :
                rw(rw),
                LightComponent(position, size, size * 0.5f, false) {
                background = sf::Color::White;
                text.setFont(*font);
                text.setString(t);
                text.setColor(sf::Color::Black);
                text.setPosition(position);
                text.setSize(size);
                rect = RectangleShape(size);
                rect.setOutlineThickness(5.f);
                rect.setOutlineColor(sf::Color::Black);
                core::FastDelegate<void> slot(&TextArea::onTextEntered, this, core::ph<0, char>());
                core::Action a (core::Action::TEXT_ENTERED);
                core::Command cmd(a, slot);
                getListener().connect("CTEXTENTERED", cmd);
            }
            void TextArea::clear() {
                rect.setFillColor(background);
            }
            void TextArea::setTextSize(unsigned int size) {
                text.setCharacterSize(size);
            }
            void TextArea::setTextColor(sf::Color color) {
                text.setColor(color);
            }
            std::string TextArea::getText() {
                return tmp_text;
            }
            void TextArea::draw(RenderTarget& target, RenderStates states) {
                rect.setPosition(getPosition());
                target.draw(rect, states);
                target.draw(text, states);
            }
            bool TextArea::isMouseInTextArea() {
                physic::BoundingBox bb = getGlobalBounds();
                math::Vec2f mousePos = math::Vec2f(sf::Mouse::getPosition(rw).x, sf::Mouse::getPosition(rw).y);
                if (bb.isPointInside(mousePos)) {
                    return true;
                }
                return false;
            }
            void TextArea::addFocusListener(FocusListener* fl) {
                core::FastDelegate<bool> trigger(&TextArea::isMouseInTextArea, this);
                core::FastDelegate<void> slot(&FocusListener::gaignedFocus,fl, this);
                core::Action a (core::Action::EVENT_TYPE::MOUSE_BUTTON_PRESSED_ONCE, sf::Mouse::Left);
                core::Command cmd(a, trigger, slot);
                getListener().connect("CTEXTAREACLICKED", cmd);
            }
            void TextArea::onUpdate(sf::Event& event) {
                if (event.type == sf::Event::TextEntered) {
                    getListener().bindCommandSlotParams("CTEXTENTERED", static_cast<char>(event.text.unicode));
                }
            }
            void TextArea::onTextEntered(char caracter) {
                if (tmp_text.length() > 0 && caracter == 8)
                    tmp_text.erase(tmp_text.length() - 1, 1);
                else if (caracter != 8)
                    tmp_text.append(1, caracter);
                text.setString(sf::String(tmp_text.c_str()));
            }
        }
    }
}

Désormais, le placeholder permet de pouvoir juste spécifier le type de l'argument de la fonction de callback, plus obligé donc de mettre une valeur quelconque et impossible comme par exemple le '\0'.

28/04/2015, 15h06
Invité

Mon départ des réseaux sociaux.

Suite à de l'espionnage j'ai décidé de m'écarter des réseaux sociaux. (Forums, chats, etc...)

Donc plutôt que de rechercher un développement commun qui n'intéresse personne, j'ai décidé de développer dans mon coin toujours par simple passion plutôt que de rechercher une collaboration qui ne fait que de m’entraîner des ennuis et beaucoup d'humiliation.

En effet, beaucoup de gens sont ici pour du développement amateur et non pas pour créer un studio de développement.

Les sources du moteur seront toujours accessible, par contre les sources des jeux créés avec le moteur non.

Le moteur est bientôt terminé, le reste ne dépendra donc que de l'amélioration des pilotes opengl linux et la sortie de vulkan pour des jeux plus gourmand en matière de graphisme.
28/04/2015, 15h55
skeud

Citation:

Envoyé par Lolilolight

Suite à de l'espionnage j'ai décidé de m'écarter des réseaux sociaux. (Forums, chats, etc...)

Donc plutôt que de rechercher un développement commun qui n'intéresse personne, j'ai décidé de développer dans mon coin toujours par simple passion plutôt que de rechercher une collaboration qui ne fait que de m’entraîner des ennuis et beaucoup d'humiliation.

En effet, beaucoup de gens sont ici pour du développement amateur et non pas pour créer un studio de développement.

De l'espionnage? 8O T'en es sur?

Ton développement est super intéressant je te rassure, c'est plus la manière de communiquer qui l'est moins.

Pour la création d'un studio de développement, on aimerait tous en faire un, mais on sait très bien que c'est très peu probable rapport à la pléthore de petit studio qui ont 1000 fois plus de moyen que nous ^^.

Tu comptes quand même continuer dans cette direction et ne pas continuer ta recherche d'emploi? T'as réussi à trouver d'ailleurs? Car je te conseillerais plutôt de garder ton dev en weekend, trouver un boulot, construire des fonds, puis ensuite investir en ouvrant ton studio, tu auras plus de chance de réussite de cette manière :).

Bon courage ;).
28/04/2015, 18h20
Invité

Citation:

De l'espionnage? T'en es sur?

Oui, hier matin je me suis retrouvé avec des fichiers supprimés sur mon bureau et un fichier ouvert hier soir sans que je ne fasse rien.

Citation:

Ton développement est super intéressant je te rassure, c'est plus la manière de communiquer qui l'est moins.

La manière de communiquer n'a jamais été mon point fort d'ailleurs j'essaye de trouver des petits boulots pour m'améliorer à ce niveau là.

Citation:

Pour la création d'un studio de développement, on aimerait tous en faire un, mais on sait très bien que c'est très peu probable rapport à la pléthore de petit studio qui ont 1000 fois plus de moyen que nous ^^.

Oui c'est vrai, je ne sais pas si un jour j'aurai assez de fond pour cela, la concurrence est grande en tout cas c'est pour cela que j'ai toujours préféré faire des petits boulots et continuer le développement de jeux vidéos le week-end uniquement.

Citation:

Tu comptes quand même continuer dans cette direction et ne pas continuer ta recherche d'emploi? T'as réussi à trouver d'ailleurs? Car je te conseillerais plutôt de garder ton dev en weekend, trouver un boulot, construire des fonds, puis ensuite investir en ouvrant ton studio, tu auras plus de chance de réussite de cette manière .

Non je ne trouve pas d'appart ni de boulot dans l'informatique après 3 ans de recherche alors j'ai décidé de suivre une autre voie et de faire des petits boulot, je rend pleins de petits services, je suis payé en retour hein sinon je ne le ferai pas. :)

Il n'y a pas beaucoup de grandes sociétés par ici et donc peu d'offre d'emplois pour beaucoup de demandeurs d'emplois, on est plutôt une terre de services spécialisé dans la médecine et la sécurité sociale subventionné par l'état. (On est donc bien plus avancé à ce niveau là)

Bref, ceci n'est pas le sujet donc, je ne vais pas trop m'étendre là dessus.
28/04/2015, 21h28
yahiko

Je pense que ton projet est loin d'être inintéressant.
Le problème c'est que l'offre en terme de moteur graphique est déjà pléthorique.

Maintenant, pour acquérir des compétences, mener un tel projet est sans doute très enrichissant et très formateur.

A ta place, j'essaierai peut-être de laisser le moteur en l'état pour travailler d'une part sur des démos techniques afin de montrer les capacités de ton moteur, et d'autre part sur la publication de la documentation afin de montrer de quelle façon s'utilise ton moteur.

Quant au studio, tant qu'il y a de la vie, il y a de l'espoir, mais sans doute que le plus simple est de postuler dans des studios déjà existants histoire d'acquérir une expérience.

Bon courage !
29/04/2015, 07h54
Invité

Citation:

Maintenant, pour acquérir des compétences, mener un tel projet est sans doute très enrichissant et très formateur.

Oui, la seule chose que je trouve dommage au niveau de mes études c'est qu'on apprend rien au niveau de la programmation de l'os et des drivers, c'est peut être moins à la mode mais au moins ça nous laisserait plus de possibilité si au niveau des performances on est trop limité mais je ne le ferai que si un jour j'ai un studio car, juste le reste ça me donne déjà des masses de travail.

Citation:

A ta place, j'essaierai peut-être de laisser le moteur en l'état pour travailler d'une part sur des démos techniques afin de montrer les capacités de ton moteur, et d'autre part sur la publication de la documentation afin de montrer de quelle façon s'utilise ton moteur.

Ha oui j'ai oublié de mettre le lien vers la documentation :

http://lolilolight.github.io/en/autres/odfaeg/

J'ai aussi fait une chaîne youtube ou j'explique comment créer un pong avec le moteur :

https://www.youtube.com/channel/UCao...8nWNhpSMz6PQfw

Citation:

Quant au studio, tant qu'il y a de la vie, il y a de l'espoir, mais sans doute que le plus simple est de postuler dans des studios déjà existants histoire d'acquérir une expérience.

Oui peut être, à moins d'acquérir la vie éternelle. :D

Mais je ne pense pas que c'est possible.
02/05/2015, 14h02
Invité

L'avenir du moteur avec l'arrivée des nouvelles cartes graphiques et apis.

Opengl commence vraiment à souffrir de son ancienneté et c'est vraiment pénible surtout pour du rendu plus complexe. (Par contre il va me falloir une nouvelle carte graphique qui supporte ses nouvelles apis!)

C'est alors que j'ai décidé de mettre au point un algorithme qui effectuera lui même tout les calculs au niveau du GPU.

Je vais aussi créer un nouveau buffer pour l'order independant transparency : l'alpha buffer. (Celui-ci contiendra la valeur alpha du pixel le plus proche de l'observateur)

Pour faire simple et ne pas encombrer trop le code je n'ai géré que un seul type de primitive. (trianglesfan)
Mais il me sera aisé de gérer les autres type de primitive et ensuite d'implémenter cela avec OpenCL voir Vulkan à l'avenir.

Tout ceci est expliqué en détail sur mon blog :

https://lolilolightdevblog.wordpress...propre-driver/

Voir 40 message(s) de cette discussion en une page