Désormais la classe RenderTarget peut dessiner des rendus simple avec ou sans texture avec vulkan!!! Par contre je n'ai pas encore fait d'implémentation vulkan pour les renderer et les render texture car je manque de documentation pour faire cela en plus il faut implémenter des cubemaps des per pixel linked list le rendu indirect et un système d'index pour les textures que je récupère dans un buffer bref tout ça je le fais avec opengl faire tout ça avec vulkan ça va être compliqué sans doc.
Je veux bien entendre que tu aies plus de mal pour trouver des tutos, mais ne dis pas que ça manque de documentation... Et encore, en tutoriels on peut lister les suivants :
Je sais j'ai déjà regardé plusieurs tutoriels mais il y a tellement de paramètres avec vulkan et le code source est tellement danse que je n'ai fait que du copier coller sans comprendre la moitié du code.
J'ai donc du mal à le modifier pour faire ce que je veux.
Salut je pense que je vais devoir stopper l'implémentation de vulkan je n'arrive pas à faire de rendu sur une texture j'ai pourtant regardé un exemple de code source sur internet mais quand je veux faire le rendu dans la texture la texture est vide et je ne comprends pas pourquoi en plus je n'ai pas d'erreurs avec les validation layers.
J'ai tenté une optimisation de mes renderers pour du rendu indirect pour l'instancing mais étrangement ça ne marche pas pour tout mes renderers pour certains ça crash dans le glMultiDraw alors j'ai du laisser l'ancien code.
EDIT : j'ai trouvé ce qui clochait maintenant toutes les instances se dessinent avec de l'indirect rendering dans tout mes renderers je suis passé de 60 à 70 fps.
Par contre je ne peux plus continuer le projet j'ai essayé de sauvegarder et de ré ouvrir la scène et il ne veut plus me l'afficher à cause d'un std::vector qui se vide tout seul!!!
Salut! J'ai reformaté le PC et ça règle le problème la prochaine vidéo sera sur les animations et ensuite les particules. Après je dois encore faire les ombres et les lumières avec ODFAEG Creator.
Pour la création des éléments du gameplay j'ai fais un système que je n'ai pas trouvé dans les moteurs de jeux existant pour ça que j'ai crée ce moteur de jeux c'est à dire récupérer toutes les informations sur une classe et générer une interface graphique ou l'utilisateurs pourra entrer les valeurs des paramètres du constructeur ou de la fonction pour créer ou modifier un objet.
Il y a un truc que tu pourrais faire pour améliorer tes vidéos : améliorer la gueule de l'interface de ton éditeur, qui est moche, en plus d'être illisible
Ca, ça ne ressemble à rien... Pas besoin de faire des trucs super complexes, texte blanc sur fond transparent, sur un contrôle au fond noir.
Un truc plus lisible pour les combobox, parce que là, il faut avoir vu la vidéo pour savoir que ce sont des combobox, ce qui est pas top pour une interface utilisateur, censée être compréhensible par l'utilisateur...
Des séparations entre tes champs seraient bien utiles aussi (essentielles, même, pour améliorer la lisibilité de l'interface)
- Edité par dragonjoker 24 juin 2024 à 13:21:30
Si vous ne trouvez plus rien, cherchez autre chose.
On a eu des mots par le passé et je m'excuse de m'être exprimé avec une agressivité déplacée et contre-productive. J'ai fini par arrêter de hurler en vain contre le retard technique des français, avec l'éducation nationale qui nous a appris à travailler seul et en silence comme dans les années 70, si telle est la volonté du très haut pour rabaisser notre orgueil patriotique mal placé alors ça roule je fais du 240x160 en noir et blanc.
Je redis les choses avec diplomatie, je décourage pas du tout vos expérimentations openGL, je recommande juste de pas être trop perfectionniste au niveau du rendu 3d et de plutôt vous mettre à ce qui pour l'instant fait défaut à savoir, hé bien, toute la partie vidéoludique, histoire de faire déjà des petits jeux simples, avec les deux patterns de base State/StateMachine et Pawn/Controller, histoire de rôder le reste de vos librairies en les testant dans le contexte.
OmbreNoire> Ton programme c'est... le bordel. Si t'arrives à sortir une version plus simple avec uniquement GLFW/OpenAL là je pourrais peut-être y comprendre quelque chose. Et sinon SDL est caduque depuis un moment tu peux l'abandonner.
- Edité par jaipasdideedepseudo 1 juillet 2024 à 19:00:38
Salut je sais que l'interface graphique de odfaeg creator est moche mais pour moi ça suffit. Je n'ai pas pu utiliser qt car les compilateurs en 64 bits de mingw ne compilent pas odfaeg et mon compilateur 32 bits n'est pas compatible avec qt et ne le compile pas. J'ai donc dû créer mes propres interfaces graphiques. J'ai créé mon moteur car après avoir regardé des vidéos sur unreal engine 5 et unity je n'ai strictement rien compris pour moi ces moteurs de jeux là sont beaucoup trop compliqué à utiliser je trouve odfaeg plus simple et le fait de devoir écrire du code c++ pour gérer les inputs et le gameplay c'est beaucoup plus simple pour moi que de devoir utiliser un système de blueprint ou je n'ai rien compris et une interface graphique avec pleins d'options. Pour moi l'interface graphique ça m'aide juste à créer des cartes pour le jeux mais tout le reste je préfère le coder moi même.
Salut, moi non plus je n'ai jamais utilisé de moteur, mais ça n'est pas de ça que je parlais. Je ne parlais pas de l'esthétique de l'interface, mais du fait que tu as mélangé sdl-glfw-sfml, ce qu'on n'est pas supposés faire. Un seul des trois doit suffire, et, comme je le disais, tu peux virer SDL cette librairie est deprecated.
Déjà SDL s'intègre mal dans windows, ça ne gère pas les écrans zoomés les dimensions de fenêtre sont fausses, il faut du coup appeler la librairie windows pour le corriger donc on sort du cadre portable minGW, ensuite le fullscreen fait une éspèce de freeze, et puis en prime ça ne gère pas les buffers de son statiques donc on a qu'un stream buffer avec du temps de latence.
Avec GLFW & openAL t'as quelque chose de propre et simple.
C'est pas si inhabituel de devoir faire de la compilation conditionnelle par OS dans du code portable, pour exporter des fonctions d'une lib par exemple, ou en utilisant des sockets...
Au niveau du fullscreen, je n'ai jamais experimente ce probleme en ayant utilise la SDL depuis la 2.14 jusque 2.30.2, tu pourrais poster un code reproductible du probleme?
Pour les streams audio, la SDL3 gere ca comme first class citizen, ca devrait etre mieux gere qu'actuellement dans la version 2.x, mais c'est evident que openAL devrait surpasser au niveau audio, c'est sa specialite, cependant c'est plus bas niveau, et ca demande aussi une lib tierce pour le chargement des fichiers(libsndfile par exemple), pas aussi simple a utiliser donc.
Donc de la a dire que la SDL est caduque, depreciee, et devrait etre abandonnee, ca me semble un peu extreme, mais le c++ n'etant pas mon domaine d'expertise, je peux manquer certains details importants.
Je n'avais pas eu vent qu'il y'a une SDL 3.0 donc j'ai été inexact c'est la 2.0 qu'ils n'ajournent plus beaucoup.
SDL m'a servi à débuter mais c'est incomplet et assez crade.
Avec GLFW + openAL j'ai un résultat propre et rapide avec du code simple et lisible.
Sinon je ne sais plus très bien ce que signifie l'expression "bas-niveau", autrefois ça désignait les langages machine et les assembleurs, aujourd'hui c'est plus synonyme de programmer ce qui se passe en détail dans la RAM avec uniquement des pointeurs et des procédures (comme en assembleur donc), or openAL est bien plus haut niveau que ça, c'est justement une couche d'abstraction du bas-niveau, ça te gère facilement le rendu du son en 3d.
En prime la syntaxe de la librairie openAL est facile à comprendre car elle est inspirée d'openGL, avec la même logique, on pré-remplit des buffers et on les envoie ensuite au devices audio/Vidéo, et, cerise sur le gâteau, openAL est conçu pour fonctionner avec la routine de l'écran et pas celle de la puce audio afin d'avoir une synchronisation parfaite avec l'image.
- Edité par jaipasdideedepseudo 2 juillet 2024 à 16:53:50
On a eu des mots par le passé et je m'excuse de m'être exprimé avec une agressivité déplacée et contre-productive. J'ai fini par arrêter de hurler en vain contre le retard technique des français, avec l'éducation nationale qui nous a appris à travailler seul et en silence comme dans les années 70, si telle est la volonté du très haut pour rabaisser notre orgueil patriotique mal placé alors ça roule je fais du 240x160 en noir et blanc.
Je redis les choses avec diplomatie, je décourage pas du tout vos expérimentations openGL, je recommande juste de pas être trop perfectionniste au niveau du rendu 3d et de plutôt vous mettre à ce qui pour l'instant fait défaut à savoir, hé bien, toute la partie vidéoludique, histoire de faire déjà des petits jeux simples, avec les deux patterns de base State/StateMachine et Pawn/Controller, histoire de rôder le reste de vos librairies en les testant dans le contexte.
OmbreNoire> Ton programme c'est... le bordel. Si t'arrives à sortir une version plus simple avec uniquement GLFW/OpenAL là je pourrais peut-être y comprendre quelque chose. Et sinon SDL est caduque depuis un moment tu peux l'abandonner.
- Edité par jaipasdideedepseudo 1 juillet 2024 à 19:00:38
Et toi tu n'as toujours pas compris que tes conseils tu peux te les garder. N'en déplaise à ton ego, tu ne détiens pas la vérité absolue. Et tu n'as toujours pas compris non plus nos objectifs, donc abstiens toi, merci.
Si vous ne trouvez plus rien, cherchez autre chose.
Comme son nom l'indique, SDL sert à débuter la programmation multimédia mais pas à faire des jeux.
Voici les contraintes de la gestion du son dans un jeu:
- Les sons doivent être réactifs, synchronisés sur la routine vidéo,donc des buffers statiques, il faut qu'on puisse jouer des samples midi avec un rythme basé sur le frameRate.
- Les sons doivent raisonner dans l'espace, au minimum sur l'axe X, chaque "source" doit avoir sa stereo et son volume contrôlés en temps réel.
SDL ne fournit qu'un bête buffer de stream qui permet d'émuler les vieilles consoles avec une latence d'environ 4 frames de retard, et il n'y a aucun outil pour contrôle du panning.
Salut! Tout le monde travaillant chacun dans son coin j'ai décidé de regrouper tout pleins de petits projets et d'en faire un moteur de jeux.
Sur le forum de la SFML notamment ou j'ai trouvé des projets comme la librairie thor, sfgui, sfmovie que je n'ai pas encore intégré, boost, etc...
Mais il y a aussi beaucoup de code source que j'ai écrit moi même là ou je ne trouvais pas de petites librairies. (Comme récupérer des infos sur les classes par exemple dans les fichiers)
Et là je fini ODFAEG Creator et la version 1 devrait enfin voir le jour mais il y a encore des choses à implémenter comme la lecture de vidéos pour les cinématiques du jeux et un système de voxels comme sur minecraft.
Ce que je souhaiterais implémenter aussi est un driver mysql car ceux que j'ai testé ne fonctionnent pas avec la version ancienne de mingw (tdm gcc 32 bits) seule version qui compile ODFAEG car les nouvelles versions de mingw me donne des erreurs avec le type _int128 entre autre dans le fichier random.h.
Et j'ai remarqué aussi des problèmes de compatibilité entre les différentes versions des compilateurs la SFML 1.6 ne compile pas avec mon compilateur.
On a fait quelques projets à deux à l'école pour les gros projets. Mais ici pas le choix je dois travailler seul donc je reprends du code d'autres projets c'est comme si je travaillais en équipe finalement.
Salut! J'ai encore quelques trucs à faire avec ODFAEG Creator mais c'est presque terminé.
Je dois faire un éditeur de terrain 3D.
L'importation de modèles 3D.
Le placement des box de collisions sur les modèles 3D.
Je dois tester la génération de code pour créer et modifier et supprimer des objets définis à l'aide de scripts écrit en c++.
Je dois encore faire un menu pour ajouter des scripts écrit en c++ au projet.
Je dois améliorer l'éditeur de scripts, faire des menus pour rechercher/remplacer du texte, aller à une fonction.
Je dois afficher les erreurs de compilations dans un nouveau panneau.
Je dois réparer le bouton compiler pour faire l'exécutable du projet car la commande de compilation n'est plus bonne.
Je dois améliorer l'interface graphique de ODFAEG Creator dans le but de faire un moteur de jeux qui soit vendable comme Unity, Unreal Engine, etc...
Je compte conserver l'héritage comme unreal engine plutôt que de faire un système ECS comme Unity, ce qui est bien c'est que la classe de base Entity et la vtable sont partagées entre l'éditeur et le plugin donc ça me permet de faire quelque chose de plus générique (un système de blueprint) plutôt que d'utiliser des composants et des systèmes qui ne peuvent être partagés et ça n'augmente pas tellement le framerate de faire un système ECS plutôt que d'utiliser des virtuels.
J'ai abandonné l'idée aussi d'utiliser Vulkan et plusieurs threads pour le rendu car vulkan est trop complexe pour moi et le multithreading également donc sans aide je n'y arrive pas.
Si vous ne trouvez plus rien, cherchez autre chose.
Si vous ne trouvez plus rien, cherchez autre chose.
Si vous ne trouvez plus rien, cherchez autre chose.
PXL Le retro gaming facile Thread sur le forum: https://openclassrooms.com/forum/sujet/retro-pxl
PXL Le retro gaming facile Thread sur le forum: https://openclassrooms.com/forum/sujet/retro-pxl
Si vous ne trouvez plus rien, cherchez autre chose.
Si vous ne trouvez plus rien, cherchez autre chose.