Jeux Libres
       
           

» Les Forums » Présentation de projets » [Moteur de jeu] ODFAEG


Aller à la page : 1, 2, 3, 4.

[Moteur de jeu] ODFAEG
Lo



Grade : Maître
Inscrit le: 26 Dec 2007, 17:33
Ecrit le: 07 Fev 2019, 17:47             Message non corrigé

J'essaie d'avancer malgré mon manque d'expérience, les bogues (c'est mon tout premier jeux en ligne) et malgré le fait que je ne peux pas tout faire en même temps tout seul. (Je ne suis pas une équipe)

Editeur de niveaux, site web et le jeux en lui même.

Et malgré le fait que par moment je perd la motivation. (je n'ai plus la même motivation que j'avais lorsque j'avais 20 ans)

J'espère quand même avoir fini avant la fin de ma vie.

Je n'ai plus de nouvelles de personne, le serveur de chat est indisponible, si j'avais le temps j'aurai bien repris l'affaire mais j'ai déjà suffisamment à faire avec le projet Sorrok.





________
Parce qu'on ne peut s'exprimer que par nos créations. ^^
  Profil
Brouilles



Grade : Habitué
Inscrit le: 04 Fev 2012, 17:40
Ecrit le: 08 Fev 2019, 08:46             Message non corrigé

Bonjour,
Oui malheureusement le serveur de chat est indisponible depuis un moment. Le site n'est même pas en SSL (https) ...
Il est légèrement mort. J'ai bien l'impression que, en dehors de toi et moi. Plus personne des actifs ne vient encore.
Et de toute façon, les tutoriels ne sont absolument plus à jour, donc pas de nouvel arrivant ....

Cordialement.

________
Site personnel et Portfolio.
  Profil
Lo



Grade : Maître
Inscrit le: 26 Dec 2007, 17:33
Ecrit le: 14 Fev 2019, 13:13             Message non corrigé

Tu ne continues pas le site toi ?

A moins que tu n'aies pas les accès pour le modifier sur la raspberry. (Qui est malheureusement trop lente pour faire tourner mon serveur)
A un moment David m'avait donné les accès pour la rapsberry, mais, je ne les ai plus, j'avais laissé tombé parce que mon serveur ne tournait pas dessus.

Cependant lui ne fait pas de SSL donc forcément ça va plus vite.

J'ai essayé de porter mon moteur de jeux en openGL 3.3 mais ça ne fonctionne pas avec mesa sous linux, il me dit que c'est supporté mais ça ne fonctionne pas. (Seul les versions OpenGL 3.0 et GLSL 1.3 fonctionnent)

J'ai aussi du recoder le module fenêtre de SFML qui ne fonctionnait pas bien, librairie que je vais carrément laissé tombé car le développeur de la SFML ne prend pas ces bugs au sérieux il préfère fermer mon compte et supprimer mes reports de bugs.

Je ne venais plus tellement sur ce site à un moment donné non plus, ici j'ai reposté quelques messages pour donner des nouvelles mais je vois qu'il n'y a plus que deux membres qui fréquentent ce site.

Je dois encore recoder le module fenêtre de SFML pour le portage sous windows mais je ferai ça quand j'aurai fini le jeux. (Là peut être que les shaders m'afficheront quelque chose sous windows)

Et ses tutoriels en plus de ne pas être à jour ne sont pas si simple que ça a comprendre, c'est plus simple d'utiliser un moteur de jeux existant plutôt que de devoir gérer les collisions soit même, voilà pourquoi plus personne ne vient.

Malheureusement moi j'ai du coder mon propre moteur car unity ne tourne pas bien sur ma machine.

Par contre, je ne fais pas de glissements.

________
Parce qu'on ne peut s'exprimer que par nos créations. ^^
  Profil
Brouilles



Grade : Habitué
Inscrit le: 04 Fev 2012, 17:40
Ecrit le: 14 Fev 2019, 17:40             Message non corrigé

Bonjour,
Non, je n'ai pas accès au Raspberry Pi ni au code PHP du site.
Je suis comme toi ! Un simple visiteur, je ne peux pas faire grand chose de plus malheureusement.
Sinon effectivement, j'aurai au moins fait le passage du site en Https avec un SSL et fais quelques modifications sur le site !

Cordialement.

________
Site personnel et Portfolio.
  Profil
Lo



Grade : Maître
Inscrit le: 26 Dec 2007, 17:33
Ecrit le: 16 Fev 2019, 22:08             Message non corrigé

Arf il aurait pu, relayer le développement du site à quelqu'un d'autre, avant de partir..., il nous a mit le grade admin mais c'est somme si on était de simple visiteurs.

________
Parce qu'on ne peut s'exprimer que par nos créations. ^^
  Profil
Lo



Grade : Maître
Inscrit le: 26 Dec 2007, 17:33
Ecrit le: 19 Fev 2019, 14:08             Message non corrigé

Salut, j'ai mis le dépôt git du moteur en privé, mais je pense que je vais devoir créer plusieurs dépôts :

-Un dépôt publique pour le moteur de jeux qui sera opensource. (Comme celui-ci ne me rapporte pas d'argent sûrement parce qu'il existe des moteurs de jeux gratuit et mieux je vais devoir passer à autre chose)
-Un dépôt privé pour le jeux qui sera non opensource et ou seul les contributeurs. (3 contributeurs max sur git en ayant un dépôt privé mais ça suffira pour commencer) auront accès. (Je compte en faire mon gagne pain futur et fonder mon propre studio)
Je ferai néanmoins quelque tutoriels surtout sur la synchronisation réseau et un système PVE de base car je trouve que ça manque sur internet. (Pour le reste, pas besoin, tout y est, il suffira de lire les tutoriels du moteur)

Le site web du moteur n'est plus accessible pour le moment car avec un dépôt git privé, on ne peut pas avoir de site web, je vais devoir scinder le dépôt git en deux partie.

Pour la synchronisation réseau David m'avait expliqué comment il avait fait pour les positions mais pour la vie des personnages ce n'est pas pareil, en effet, il est difficile de prédire quel sera la vie du personnage après un temps de transfert de x millisecondes car contrairement à la position des personnage qui évolue de manière constante en fonction du temps, la vie des personnages dépend de la vitesse de régénération de la vie du personnage, de la vitesse d'attaque du personnage ennemi.

La prédiction de la valeur de la vie des personnages dans ce cas là devient un vrai casse tête, alors j'ai trouvé une solution plus simple, sans saturer la bande passante.

La solution est simple : côté serveur, créer une liste de x valeurs d'attaques et un autre vecteur de x valeurs de régénération de vie (x dépendant de la vitesse de régénération et de la vitesse d'attaque) pour chaque personnage et l'envoyer au client. Ceci permet de ne pas saturer la bande passante, j'envoie également la vie des personnages (au cas ou le joueur essayerais de tricher) pour la remettre à jour et le temps. (pour calculer le temps de transfert)

Côté client, je récupère toutes ces valeurs pour les insérer dans mes vecteurs et pour être en même temps que le serveur, je récupère le temps de transfert et je le soustrais à la vitesse d'attaque et à la vitesse de régénération du personnage.

A chaque attaque ou régénération de vie, je vide les vecteurs au fur et à mesure côté client et côté serveur, jusqu'à qu'ils soient vide, et comme le client et le serveur sont parfaitement synchronisés, les vecteurs se vident en même temps. Et bien entendu lorsque les vecteurs sont vides, je ne remet pas à jour la vie des personnages.
Lorsque les vecteurs sont vide, le serveur régénère et ré envoie une nouvelle liste pour les régénération de vie et les valeurs d'attaque ainsi que la vie des personnages et le temps.
De ce fait le client doit attendre d'avoir reçu le message avant de pouvoir remettre à jour la vie des personnages ce qui permet de faire en sorte qu'il soit en même temps, que le serveur.

J'ai testé et ça marche plutôt bien. ^^

________
Parce qu'on ne peut s'exprimer que par nos créations. ^^
  Profil
Lo



Grade : Maître
Inscrit le: 26 Dec 2007, 17:33
Ecrit le: 31 Mars 2019, 14:42             Message non corrigé

Je vais devoir faire un driver graphique pour le moteur de jeux, les drivers graphiques opensource et propriétaire ne fonctionnent pas.

J'ai télécharger les sources de Mesa pour voir comment ça fonctionne (en gros), mais il y a trop de code pour pouvoir débuguer correctement et puis il y  a trop de bugs.

Je vais donc faire un code plus simple, je pensais que c'était compliqué mais apparemment c'est du bête code c++ avec une lib pour charger des données dans la vram. (shaders, vbo, ...)
Pour le reste, les thread et tout ça, si je me fie au code source de mesa, on dirait que c'est l'os qui charge tout le code binaire du driver dans la VRAM et il appelle les fonctions opengl qui elles même appellent des pointeurs sur les fonctions du driver stocké à un endroit précis dans la VRAM pour que le GPU les exécute.

Enfin, si j'ai bien compris, parce que l'application doit charger des pointeurs sur les fonctions du driver stocké quelque part avant d'appeler les fonctions opengl.

Enfin bref..., je vais faire des essais avec une machine virtuelle pour ne pas casser l'os installé si ça ne marche pas, mais c'est un tout nouveau domaine pour moi, mais je n'ai pas le choix, de plus je ne peux pas avancé sur le jeux, je n'ai pas d'équipe, et si j'en avait une je devrais me passer des FBO et des shaders ainsi que toutes les nouvelles fonctionnalités qui du driver qui sont buguées, bref, c'est nul.

-Le driver sera codé en c++, mais il faudra passer par du C pour appeler les fonctions opengl qui ont des noms standart.
-Le fonctionnement du driver sera similaire au fonctionnement d'openGL, c'est juste une tentative de correction des bugs présents dans le driver opensoure MESA, il n'y aura pas de nouvelles fonctionnalités.
-Le driver ne sera, pour l'instant, compatible que avec ma carte graphique, en effet, je ne pourrai pas le tester sur les autres cartes graphiques parce que, je n'en possède pas d'autres.

________
Parce qu'on ne peut s'exprimer que par nos créations. ^^
  Profil
Lo



Grade : Maître
Inscrit le: 26 Dec 2007, 17:33
Ecrit le: 01 Avril 2019, 18:11             Message non corrigé

Salut!
Pour les shaders par contre, je ne sais pas trop comment faire, aparemment, il faut écrire un compilateur qui permet de traduire du GLSL en byte code compréhensible par le GPU. (et je n'ai jamais fais ça)

Apparemment tout s'exécute avec le CPU, sauf les shaders. (Je ne vois pas trop l'intérêt d'avoir un GPU)

Donc je pense faire quelque chose du genre, du c++ qui se traduit en code compréhensible par le GPU et du glsl qui se traduit en c++.

Ainsi seul les fonctions opengl seront appelée par le CPU.

Bref, maintenant que je comprends mieux le binaire, je peux tenter le coup, mais je me suis rendu compte que l'ASM de nos jours côté CPU est devenu complexe mais apparemment avec le GPU ça à l'air d'être plus simple.

Et puis le problème aussi c'est que, si le driver crée par exemple une texture au niveau du CPU, il faut que la texture soit référencée dans la VRAM, il faut donc :

-Créer un buffer et transférer les données dans la VRAM avec du DMA.

Par contre, si je fais ça, comme le code du shader sera compilé par la GPU, je pourrai créer directement le buffer dans la VRAM et le référencer dans le shader.

Et je pourrai compiler le code qui charge l'image de la texture par exemple avec le GPU, un peu comme on peut le faire avec openCL, sans avoir besoin de passer par une interface et de faire des transferts dans un buffer.

________
Parce qu'on ne peut s'exprimer que par nos créations. ^^
  Profil
 


Aller à la page : 1, 2, 3, 4.


Hébergeur du site : David
Version PHP : 5.4.45-0+deb7u2
Uptime : 332 jours 15 heures 43 minutes
Espace libre : 1529 Mo
Dernière sauvegarde : 22/10/2019
Taille de la sauvegarde : 1115 Mo


5588488 pages ont été consultées sur le site !
Dont 2373 pages pendant les 24 dernières heures.

Page générée en 2.054 secondes


Nos sites préférés
- Création d'un jeu de plateforme de A à Z avec SDL
- Zelda ROTH : Jeux amateurs sur le thème de Zelda
- Zeste de Savoir : la connaissance pour tous et sans pépins
- YunoHost : s'héberger soi-même en toute simplicité
- Site de Fvirtman : recueil de projets et de codes en C et C++
- Par ici la sortie : le site des idées de sorties


  © 2005-2019 linor.fr - Toute reproduction totale ou partielle du contenu de ce site est strictement interdite.