Discussion :

[Invité]

Re, trois bonne nouvelles;

-J'ai pu retiré le singleton, (pour le gestionnaire de ressource) les ressources ne sont accessible que là ou leur contexte a été déclaré, il y a deux classes : ResourceManager pour un contexte pour des ressources d'un seul type et ResourceCache pour un contexte pour des ressources de plusieurs types et les ressources sont détruite en même temps que leur contexte, il y a aussi possibilité de charger les ressources avec un contexte (d'une classe dérivée) et les passer à un contexte plus générique. (En passant par le cache)
-J'ai retiré mon propre système de pointeurs intelligents, il ne fonctionnait pas bien, j'utilise donc ceux de la STL.
-Je viens d'avoir un mp intéressant, le framework pourra peut être intégrer d'autres librairies comme par exemple la SDL.

[Invité]

Salut,

Alors ici je vais essayer de vous expliquer un peu plus en détails les nouveautés qui auront lieu lors de la fusion des deux moteurs de jeux :

D'après ce que j'ai compris, il y aura un nouveau système permettant de charger des modules (des fichiers .dll ou bien .so pour linux) et de sélectionner un module au choix et l'utiliser à travers une interface, ceci permettra par exemple, de pouvoir charger une autre bibliothèque si un jour SFML n'est plus maintenue et que l'on passe à SDL 3.x.

Cela laisserait libre à chacun d'utiliser un module présent dans le moteur, d'améliorer un module existant ou bien même d'intégrer sa propre librairie au moteur. (en redéfinissant quelque fonctions d'une l'interface commune qui elle sera utilisée par le moteur.)

Personnellement je trouve que c'est une superbe idée, qu'en pensez vous ?

[Invité]

-J'ai presque terminé pour la génération de la doc, il ne me reste plus qu'un module. (Ensuite je met des std::unique_ptr partout et j'essaye de mieux séparer et aérer le code et se sera bon)

-Le site web est en cours, et j'y ai déjà insérer un peu de contenu, par contre, j'aurai besoin d'un webdesigner pour le css surtout. (Possibilité de changer aussi la structure du site selon l'avis du webdesigner.)

PS : ha oui et j'allais oublié, on a un chat IRC. (Réservé au personnes désirant faire partie de l'équipe, il est conseillé de rester sur l'irc, afin que, je puisse faire appel à vous dès que j'en ai le besoin, étant conscient que ceci est juste du travail de bénévolat (d'ailleurs moi aussi je fais ça juste pour le plaisir dans l'espoir de devenir un vrai professionnel du développement de jeux vidéos et de moteur un jour) je n'imposerais pas de deathline par contre, il faudra essayer de se fixer un planning et savoir qui fait quoi.)

[skeud]

Juste une petite remarque rapidement ^^. N'utilise pas dvp.com pour faire ton devlog, ça risque d’être mal vu ^^. A la limite, vient donné l'état d’avancement toute les semaine (et encore) et utilise ton wiki ou un forum concernant ton projet pour faire ton devlog .

Explication:
Je suis (suivre, pas être hein ) ton thread depuis un moment et ce n'est pas très agréable de recevoir des notifs tout les 2-3 jours pour s’apercevoir que c'est juste une petite mise à jour de ton boulot (je ne critique pas le boulot, qui est plutôt bien d’ailleurs) ^^. Avec un post par semaine, tu tiendras au courant tout le monde de tes avancées et tu pourras plus facilement résumé ce que tu fais et ce que tu vas faire .

[Neckara]

Bonjour,

ce n'est pas très agréable de recevoir des notifs tout les 2-3 jours pour s’apercevoir que c'est juste une petite mise à jour de ton boulot

Je trouve que c'est un peu exagéré vu qu'il n'y a pas tant de posts à la suite que cela surtout qu'il y a d'autres sujets qui ont des notifications plus régulières.

Personnellement cela ne me dérange pas plus que cela.

Un wiki ou un forum "personnel" a une visibilité bien réduite qu'un post sur ce forum.
Autant dire que personne (ou presque) ne viendra voir un tel devlog, sans compter qu'il sera bien moins aisé d'être notifié d'avancement sur le devlog.
En effet, je doute que beaucoup d'entre vous seriez prêt à vous inscrire à 4 forums, suivre 3 comptes Twitter et visiter régulièrement 1 wiki.

Cela n'engage que moi, mais en tant que développeur, le "devlog", m'intéresse aussi.
Les questions qu'il se pose, les modifications sur son projet, les erreurs qu'il commet, tout cela me permet de "vivre son projet" et aussi peut-être d'intervenir sur un point particulier.
J'ai donc moins une vision d'utilisateur que de collègue développeur. Ce sont donc plus son projet qui m'intéresse que le produit qu'il créé.

Après, j'aurais peut-être une solution à proposer à Lolilolight : créer deux sujets, un pour le devlog et un autre pour le moteur en lui-même, ceci ayant déjà été fait par d'autres projets si je ne m'abuse.
Au pire, si les notifications gênent vraiment, il est possible de se désabonner de la discutions et de la visiter chaque samedi par exemple.
Ou alors demander à LW d'avoir un forum devlog ?


Ensuite, pour avoir tenu moi aussi un tel sujet, ce n'est pas facile non plus.
Il y a déjà une forte volonté de partagé avec les autres membres du forums, de faire connaître et "reconnaître" notre travail, c'est une source de motivation non négligeable.
Motivation essentielle à la vie d'un projet.
Il faut aussi savoir que lorsqu'on s'investit autant dans un tel projet, on a une notion du temps très différente, une semaine devient une éternité. Ce qu'on a fait la semaine dernière, c'est très "ancien".
Difficile donc de parler ensuite d'une chose qu'on a fait la semaine dernière alors qu'on est déjà passé à autre chose.

[Invité]

Salut,
Je pense que (comme l'a dit neckara) je vais créer deux sujets différents, après tout, ce n'est pas une mauvaise idée, le second parlera plutôt du deveblog, ou je partagerai le travail qui a été effectué, il y aura bien sûr des notifications plus régulières, car en effet pour moi, une semaine ça représente une éternité pour un tel projet. (Si les notifications vous gêne, vous n'êtes pas obligé de suivre ce sujet.)

Et se sujet-ci comportera beaucoup moins de notifications, juste les notifications plus importantes comme le lancement des bêtas ou bien des releases du moteur par exemple.
Voili voilou. (Le but du jeux sera plutôt pour tester le moteur utilisé pour d'autres projets. (commerciaux ou non)

[Invité]

Quelques changements importants :

-Désormais on peut utiliser des signaux et des slots avec des paramètres de type différents.

Un exemple d'utilisation dans une gui par exemple :

Code cpp :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
class Button {
 
bool isMouseInButton(sf::Vector2f mousePos) {
 
//On test si la position de la souris est dans le rectangle du bouton.
 
}
 
void setActionListener(ActionListener &al) {
 
Action a (odfaeg::Action::EVENT_TYPE::MOUSE_BUTTON_PRESSED_ONCE, sf::Mouse::Left);
 
Command cmd(a, FastDelegate<bool>(&Button::isMouseInbutton, this, sf::Vector2f(-1, -1)),    FastDelegate<void> (&ActionListener::actionPerformed, &al, buttonID);
 
listener.connect(buttonID,  command);
 
}
 
Listener listener;
 
}

Il y a deux fonctions différente donc maintenant pour changer les paramètres du signal et du slot.

Désormais se sera l'axe z qui sera employé pour la hauteur et non plus l'axe y, cela est beaucoup plus simple, car au lieu de permuter les coordonnées en y et z des tiles ce qui m'oblige à faire deux fonctions différents pour la génération de terrain, je peux tout faire dans la même fonction en définissant juste un z différent de 0 pour la 3D.

La seule chose que j'ai à faire est de définir un up vector différent pour avoir une vue du dessus pour la 3D (en faisant pointer la caméra en (0, 0, 1) et pour la 3D en faisant pointer la caméra en (0, 1, 0))

Voila, je vais faire les dernière petite chose à faire avant le lancement de la version bêta du moteur et puis de la release.

La 3D arrive bientôt, j'ai réussi à ajouter des objets en 3D dans l'entity manager donc il n'y a plus qu'à faire les algorithmes pour générer un terrain et pour charger des modèles en 3D, tout le reste est fais. ^^ (Mais je n'ai pas encore pu tout testé d'où la nécessité de la version bêta qui aura pour but de corriger les bugs mais surtout de valider les algorithmes.)

[Invité]

Salut!

Je n'ai plus qu'à corriger les derniers tutoriels, rajouter les démos sur le git-hub et trifouiller 2-3 bidouille dans le code source et la 1ère release sera terminée, elle sortira normalement en janvier, cet release aura pour but d'optimiser le moteur ainsi que de corriger les bugs avant de commencer la release 2.

Par contre n'ayant pas windows je n'ai pas pu testé la compilation dynamique avec les .dll donc mais je laisse le soin à ceux qui ont windows de s'en charger au besoin. (Ca ne doit pas être bien compliqué)

Pour la release suivante qui sera une fusion de deux moteurs, il y aura en plus le chargement de modèle 3D pour mon propre module, ainsi que la possibilité de pouvoir utiliser d'autre moteurs voir même de coder ses propres modules!

Le développeur pourra donc soit utiliser les modules existant, utiliser une librairies externe à travers une interface ou bien, coder ses propres modules.

[Invité]

Salut!

J'ai attaché 4 runs sur le dépôt, voici en quoi elles consiste :

-ODFAEG-DEMO : Juste une démo de test qui déplace une entité sur une map, gère les collisions, affiche des lumières/ombres.

-ODFAEG-SERVER et ODFAEG-CLIENT : Même chose mais le réseau est ajouté, afin de tester la synchronisation de mouvement en réseau.

-ODFAEG-3DDEMO : Affiche juste une heightmap générée aléatoirement, la 3D n'est pas une priorité donc je ne m'étendrai pas sur cette démo, elle est juste là pour montrer que l'on peut afficher de la 3D avec ODFAEG.

Pour le réseau il se peut que se message d'erreur apparaissent :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Error encrypting message: error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt

C'est un bug Openssl on dirait bien..., car même si les octets sont bons, ça crash.

Il suffit de relancer le serveur et le client jusqu'à que ça marche.

PS : par contre, je rajouterai bien un générateur de labyrynthe pour la version suivante car j'ai oublié de le faire pour cette version ici, tant pis.

[Invité]

J'ai trouvé pour le bug openSSL, j'avais juste oublié de commenté une ligne dans le fichier aes.h.
J'ai donc corrigé ça sur le dépôt.

Maintenant tout devrait marché sans soucis. (En tout cas chez moi les runs fonctionnent bien )

Je pense que je vais faire un jeux du genre diablo like en 3D iso comme celui qu'avait fait Grégoire et un FPS pour vraiment bien tester le moteur à fond et être sur qu'il n'y a plus de bugs (ces codes seront opensource également et repris dans les tutos) mais le code source des jeux suivant sera bien entendu propriétaire. (Et oui il va bien falloir que je pense à gagner ma croûtes, sans devoir dépendre d'organismes de payement, de subventions, etc..., et puis, c'est parfois loin d'être suffisant.)

[Invité]

Re!

J'ai essayé de faire de la fumée dans ODFAEG-DEMO avec mon système de particules, mais je galère pour faire quelque chose de vraiment réaliste. :/

Je n'avais pas rajouté d'exemple d'utilisation pour le moteur de particules, en voilà donc un.

J'ai également corrigé un bug dans la classe vertex array!

[Invité]

Salut!

Tout d'abord bonne année, et une excellente nouvelle à la clés!

La 1ère vraie release (la version 1.0) de mon moteur de jeux va enfin pouvoir voir le jour. (Et oui!)
La semaine prochaine, juste le temps de faire les 2-3 petites choses manquantes!

Le but de cette release est de faire un jeux complet en 3D isométrique avec le moteur afin d'être sûr qu'il n'y ai plus de bugs, il y aura donc des release intermédiaires avant la version suivante. (La 2.0 qui incluera des fonctionnalités en 3D supplémentaire ainsi que un système de modules qui permettra l'utilisation de modules de librairie externe, voir même de créer ses propre modules)

Les tutoriels en français sont déjà disponible sur cette page : Ici!

Bonne amusement.

PS : à suivre, quelques vidéos.

[guitz]

Bonjour,

Et Bravo je te trouve très courageux de développer ton moteur de jeu, c'est vraiment un travail titanesque, mais j'ai une question qui me brûle les mains quelque peu.
Comment te positionnes-tu sur le marché des moteurs actuels ? J'ose espérer que tu ne comptes pas rivaliser avec des moteurs aussi poussés que Unreal engine ou dans une moindre mesure Unity ? Je suis sûr que tu en es conscient car je sais que tu n'es pas bête, alors je suppose donc que tu es entrain de développer un moteur bien moins poussé mais pro et que tu comptes vendre 10 fois moins cher que celui de Unity par exemple ? Donc si on essaie de quantifier ça, comme sa licence coute 1500 euros , tu comptes vendre la tienne 150 euros ?

Mon intention n'est pas de te rabaisser et encore une fois je suis admiratif que tu t'accroches à ce projet hyper compliqué (j'avais essayé de faire un moteur en binôme en c++ avec DirectX que je trouve impinable ! La leçon que j'en ai tiré c'est plus jamais ça !)

[Invité]

Bonjour,

Et Bravo je te trouve très courageux de développer ton moteur de jeu, c'est vraiment un travail titanesque, mais j'ai une question qui me brûle les mains quelque peu.
Comment te positionnes-tu sur le marché des moteurs actuels ? J'ose espérer que tu ne comptes pas rivaliser avec des moteurs aussi poussés que Unreal engine ou dans une moindre mesure Unity ? Je suis sûr que tu en es conscient car je sais que tu n'es pas bête, alors je suppose donc que tu es entrain de développer un moteur bien moins poussé mais pro et que tu comptes vendre 10 fois moins cher que celui de Unity par exemple ? Donc si on essaie de quantifier ça, comme sa licence coute 1500 euros , tu comptes vendre la tienne 150 euros ?

Sur le marché je positionne mon moteur sur un moteur de jeux pour développeur indépendant qui souhaiterais se lancé sur le marché, ou bien juste faire ça en tant que passionné, avec un moteur simple et minimaliste. Le but est que celui qui débute ne se perde pas avec de nombreuses fonctionnalités dont il n'aurait pas besoin, mais il pourra rajouté des fonctionnalités et innové sans dépendre d'une interface graphique ni d'un langage de script en se basant sur la version opensource.

Mais je ne le positionnerai pas sur le marché des industriels comme ubisoft par exemple. (D'ailleurs, je suis sûr que de telle boîtes n'achèteront jamais mon moteur)
D'ailleurs il n'y aura pas d'interface graphique ni de langage de scripts d'intégrés comme dans unity ou bien unreal engine ou autre.

A vrai dire, je ne sais pas si je vais le vendre, ou bien si je vais juste vendre les jeux fais avec le moteur, si les jeux ne suffisent pas alors je ferai une version pro du moteur et une version opensource (exactement comme l'a fait unity) et je la vendrai, se sera la version 2! (Il faut avouer aussi que je préfère développer des moteurs que des jeux)
Ce ne sera bien sûr pas aussi cher que des moteurs comme unity ou encore unreal engine, vouloir concurrencer de tels moteurs à moi tout seul serait fou de ma part, surtout qu'ils ont leurs interfaces graphique et leur langage de scripts.

Dans ce cas là la licence devrait tourner autour de 150 euros comme tu dis.

L'opensource m'a toujours permis d'avoir de bonnes idées, pour réalisé ce moteur, je n'ai pas envie donc de rendre le moteur totalement propriétaire. :/

Mon intention n'est pas de te rabaisser et encore une fois je suis admiratif que tu t'accroches à ce projet hyper compliqué (j'avais essayé de faire un moteur en binôme en c++ avec DirectX que je trouve impinable ! La leçon que j'en ai tiré c'est plus jamais ça !)

Merci, ça fait du bien de savoir que il y a encore quelque personnes qui ne sont pas là que pour te lyncher.

[Cirrus Minor]

As-tu pensé à développer et publier quelques jeux très simples avec ton moteur ?
Je pense que, si tu t'adresses à des débutants, ou en tout cas à des développeurs qui cherchent un moteur très simple, tu devrais avoir quelques jeux qui servent à la fois de démos des capacités du moteur, mais aussi de tutoriels de son utilisation.

Je pense à des jeux comme un memory (très bien pour le temps réel, les événements souris), le pong (pour une physique très simple avec des collisions), un Asteroids... assez minimalistes (en termes de graphismes / fonctionnalités) mais développés de 'A à Z' (écran d'accueil, jeu, game over).

[Invité]

Ok, oui, je vais visé des jeux de ce genre là, pour les démos.

Je ne compte pas faire des jeux très important pour des démos.

Par contre je n'ai pas encore fait un jeux de A à Z, mais dès la sortie de la 1ère release je vais m'y mettre.

Pour l'instant les démos sont juste des runs intermédiaires que j'ai faîtes pour tester les différents modules mais pas des jeux.

Les débutants pourront se baser sur les démos pour créer le jeux qu'ils veulent.

En tout cas dans les jeux il y aura le minimum de ce qu'on attend des jeux débutant :

-Des particules.
-Multijoueur.
-Les menus.
-Des animations. (Avec système de scene node)
-Une caméra.
-Des effets. (Lumière, ombres, etc...) (Ce dernier point est peut être pas indispensable pour un débutant mais il y en a qui le font)
-Une gestion d'événements avancée.
-Des sons.

[guitz]

Ah au fait je voulais te demandez lolilol, sur ton avatar c'est ton frère, ton petit ami ou ton meilleur ami ?

[Invité]

C'est mon acteur fétiche d'une web-série, la web-série noob.

OmégaZell

[guitz]

Ah ok, je vais regarder cette série Noob sur youtube, vu le nombre de visionnages ça a l'air pas mal !
Fin du HS

[Invité]

Par contre, je ne sais pas si les moteurs existant comme par exemple, Irrlicht, intègre des démos de jeux complet..., ce sont plutôt des runs.

Donc, je ne sais pas si je devrais en intégrer, m'enfin bon un pong en réseau, un memory et ce genre de jeux ce n'est pas très difficile à faire, donc, je pense que je vais en faire juste pour le fun.