Salut, je me demandais si tu pourrais updater ton moteur pour les compilateurs plus récents comme mingw 5+ ou bien TDM
A priori, il n'y a qu'une erreur : NazaraEngine-master\src\Nazara\Network\Win32\SocketImpl.cpp
#ifdef NAZARA_COMPILER_MINGW
// MinGW is lacking Mstcpip.h and that's too bad
struct tcp_keepalive
{
u_long onoff;
u_long keepalivetime;
u_long keepaliveinterval;
};
#define SIO_KEEPALIVE_VALS _WSAIOW(IOC_VENDOR,4)
#else
#include <Mstcpip.h>
#endif // NAZARA_COMPILER_MINGW
SocketImpl.cpp:13:8: error: redefinition of 'struct tcp_keepalive'
struct tcp_keepalive
^
In file included from C:/i686-5.4.0-release-win32-sjlj-rt_v5-rev0/mingw32/i686-w64-mingw32/include/ws2tcpip.h:301:0,
"MinGW is lacking Mstcpip.h and that's too bad", le fichier est finalement inclue, donc il faudrait enlever ce "workaround"
Aussi, je me demandais à quoi servent : -EncodeResources.bat -Generate_GlobalIncludes.bat -Generate_UnicodeData.bat
Sont-ils exécuté dans le build process ou bien c'est dans l'éventualité d'ajouter des ressources?
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
Je viens de faire un correctif pour la compilation, merci de l'info.
J'ai laissé (et étendu le workaround) pour les éventuelles personnes qui utiliseraient toujours un vieux MinGW (malheureusement ça a toujours été le bordel entre MinGW et les includes systèmes).
Maeiky a écrit:
Aussi, je me demandais à quoi servent : -EncodeResources.bat -Generate_GlobalIncludes.bat -Generate_UnicodeData.bat
Sont-ils exécuté dans le build process ou bien c'est dans l'éventualité d'ajouter des ressources?
EncodeResources sert à transformer tous les fichiers dans les dossiers Resources des modules en header pouvant être inclus dans un .cpp (et donc dans le binaire), ça me sert surtout quand je mets à jour les shaders/autres ressources ce n'est pas vraiment destiné à l'utilisateur mais ça ne pose aucun problème s'il l'utilise.
Generate_GlobalIncludes sert à mettre à jour les includes globaux de modules (Nazara/Core.hpp par exemple), encore une fois c'est surtout destiné en cas d'ajout/suppression de classe et pas vraiment pour l'utilisateur lambda.
Generate_UnicodeData est un parser de références Unicode, afin d'intégrer toutes les données Unicode dans le programme (dans le but de pouvoir faire fonctionner certaines features, comme l'uppercase d'accent, etc.), il n'est malheureusement pas fini (il manque peu de choses pourtant).
Ces trois .bat ne sont que des raccourcis pour m'éviter d'exécuter l'action via premake (vu que je me promène rarement avec la console sur Windows).
Alors concernant le manque de nouvelles du dernier mois, j'ai beaucoup de choses à vous annoncer et j'attends encore un peu pour le faire, néanmoins comme je viens de casser l'interface du moteur je suis obligé de vous spoiler un peu :D
J'ai déprécié l'interface SFML-like de gestion des événements du moteur (Window::PollEvent/Window::WaitEvent), elle est toujours présente mais ne fonctionnera que si activée:
window.EnableEventPolling(true);
Maintenant la fenêtre et ses événements sont gérés par la méthode:
void Window::ProcessEvents(bool block = false);
Un appel à cette fonction traite tous les événements en attente de la fenêtre, ces événements sont mis dans la queue si le pooling est activé (système qui va partir du moteur).
De plus, l'application appelle automatiquement cette fonction pour les fenêtres qu'il gère.
Ainsi pour effectuer des actions en fonction d'événements, la classe EventHandler vient de faire son apparition, celle-ci représente un ensemble de signaux appelés lorsqu'un événement se produit, par exemple:
Nz::EventHandler& eventHandler = window.GetEventHandler();
eventHandler.OnKeyPressed.Connect([](Nz::EventHandler*, const WindowEvent::KeyEvent&)
{
// Action en cas d'appui sur une touche
});
Cette syntaxe peut paraître un peu lourde, mais dans le cadre d'une véritable application l'ancienne boucle événementielle devenait beaucoup plus difficile à gérer (du fait du traitement des événements au même endroit).
Ceci va aussi énormément faciliter l'introduction d'une éventuelle GUI, ou la gestion des événements par la console
J'ai aussi fait en sorte que la fenêtre se ferme toute seule lorsqu'il lui est demandé.
Voilà pour le petit bulletin d'information provisoire, mais j'ai encore beaucoup de choses à annoncer, le temps de préparer tout ça :)
Alors le renderer actuel ne fonctionne qu'à partir d'OpenGL 3.3, et je suis curieux de savoir quel hardware tu possèdes pour ne pas le supporter (parce qu'on parle de quelque chose de relativement ancien).
Pour ce qui est du nouveau Renderer de Nazara, il sera basé sur OpenGL ES 2/OpenGL 3 et Vulkan, cependant j'ajouterai le support d'OpenGL 2 si ça ne demande pas trop de travail (à voir, mais ce n'est malheureusement pas prioritaire).
C'est surtout à jeter aux oubliettes, un renderer OpenGL 2 est certainement plus viable, même en supposant l'utilisation de techniques avancées de type AZDO.
Quant à savoir si c'est une bonne idée de supporter tous les GPUS sur le marché même ceux pré 2008 (c'est vieux, OpenGL 3...), pour mon moteur j'ai décidé que non, ce n'était pas une bonne idée, chacun ses choix, mais je suis sur que Lynix est d'accord avec moi
Si vous ne trouvez plus rien, cherchez autre chose.
Pourquoi pas un renderer software ? Pour que ça marche vraiment PARTOUT (même avec des perfs moyennes)
Le gros problème du renderer software est qu'il est très rare qu'un processeur suffisamment rapide pour permettre du temps réel ne soit pas accompagné au moins par un chipset graphique intégré (supportant d'ailleurs OpenGL >= 3.3), c'est donc un boulot conséquent pour au final pas grand chose.
Il y a un argument qui me donne envie de faire un renderer software (outre le fait que la nouvelle architecture du renderer le supporterait sans problème, surtout au niveau des shaders), ce serait pour les serveurs, j'ai administré des serveurs de jeux pendant pas mal d'années et j'ai toujours trouvé qu'il manquait une fonctionnalité permettant de voir la partie "graphiquement" sans pour autant devoir se connecter.
Demander au serveur de générer une image de la partie serait possible avec un renderer software, et à ce moment-là les performances du rendu software ne seraient plus vraiment un problème.
Je précise aussi que l'occlusion culling que j'ai prévu dans Nazara va de toute façon se baser sur un rasterizer software, donc à un moment donné il faudra bien que je m'y mette.
dragonjoker a écrit:
C'est surtout à jeter aux oubliettes, un renderer OpenGL 2 est certainement plus viable, même en supposant l'utilisation de techniques avancées de type AZDO.
Quant à savoir si c'est une bonne idée de supporter tous les GPUS sur le marché même ceux pré 2008 (c'est vieux, OpenGL 3...), pour mon moteur j'ai décidé que non, ce n'était pas une bonne idée, chacun ses choix, mais je suis sur que Lynix est d'accord avec moi
En effet, cependant je nuance un peu plus depuis que je prépare le nouveau Renderer de Nazara, car il se pourrait que je puisse très facilement ajouter le support OpenGL 2 à partir du renderer OpenGL 3
Il y a un argument qui me donne envie de faire un renderer software (outre le fait que la nouvelle architecture du renderer le supporterait sans problème, surtout au niveau des shaders), ce serait pour les serveurs, j'ai administré des serveurs de jeux pendant pas mal d'années et j'ai toujours trouvé qu'il manquait une fonctionnalité permettant de voir la partie "graphiquement" sans pour autant devoir se connecter.
Demander au serveur de générer une image de la partie serait possible avec un renderer software, et à ce moment-là les performances du rendu software ne seraient plus vraiment un problème.
Ca serait excellent ça ! J'imagine que ça se fait nulle part en plus
Euh... OpenGL est prévu pour ça, en fait. Et je gage qu'il est encore pas mal utilisé de cette manière, une des raisons pour lesquelles on se traine une rétro-compatibilité lourdingue.
Si vous ne trouvez plus rien, cherchez autre chose.
Euh... OpenGL est prévu pour ça, en fait. Et je gage qu'il est encore pas mal utilisé de cette manière, une des raisons pour lesquelles on se traine une rétro-compatibilité lourdingue.
Oui et non.
Oui car en théorie et dans le principe, OpenGL est basé sur un modèle client/serveur, non parce qu'OpenGL utilisé de façon moderne ne montre plus du tout signe de ce fameux modèle (il est toujours présent mais on peut complètement l'oublier).
Et bien sûr, dans 99% des cas, le client c'est le terme pour désigner le CPU, et le serveur le terme pour désigner le GPU (et au final bien souvent ce ne sont que deux parties d'un même driver graphique).
Par contre, bien qu'il soit possible de l'utiliser à travers le réseau, c'est très peu (voire pas du tout) utilisé et pas du tout la cause de la rétro-compatibilité d'OpenGL.
De toute façon, le roi est mort, longue vie à Vulkan. :D
Pour s'initier à la 3D en général (je présume que tu parle dans le monde de la programmation, et que la personne a déjà des bases en mathématiques), je pense qu'il vaut mieux commencer avec une librairie 3D (comme Three.JS). Puis éventuellement de passer à OpenGL. Et une fois qu'OpenGL est très (TRÈS) bien maîtrisé, et SI C'EST NÉCESSAIRE, passer à Vulkan. Car il vaut mieux BIEN utiliser OpenGL, que MAL utiliser Vulkan!
Vulkan est certes, TRÈS compliqué ! Mais ce n'est pas pour autant qu'OpenGL est facile... ni mort pour autant...
Il y a bien des personnes et des jeux qui utilisent encore le vieux vieux OpenGL déprécié, donc bon, de l'OpenGL moderne c'est déjà pas mal.
Vive Vulkan, pour ça je suis d'accord, mais OpenGL est mort? Je crois qu'on a (malheureusement?) encore le temps avant que ça arrive :/
Nass0931 a écrit:
Vulkan est certes, TRÈS compliqué ! Mais ce n'est pas pour autant qu'OpenGL est facile... ni mort pour autant...
OpenGL est comme mort, ça fait deux ans depuis sa dernière mise à jour (qui n'apportait pas grand chose) et je doute qu'une nouvelle véritable mise à jour arrive à nouveau.
Bien sûr l'API va encore "vivre" plusieurs années, mais l'utiliser deviendra de plus en plus une mauvaise idée, et au final dans cinq ans, dix ans, les cartes graphiques dévoileront certainement encore bien plus de potentiel qu'OpenGL ne sera plus en mesure d'exploiter.
Cependant OpenGL reste plus facile et pour le moment également plus portable que Vulkan, et je serai fou de conseiller Vulkan à un débutant en 3D.
Je suis donc d'accord avec ce qui se dit au dessus, un débutant en 3D devrait commencer par utiliser un moteur de rendu (ça tombe bien j'en connais un pas trop mal ) et ensuite essayer de comprendre ce qui est fait, avec OpenGL pour commencer.
Mais soyons clairs, ni Vulkan ni OpenGL ne sont faits pour les débutants, ils sont faits pour les personnes expérimentées, connaissant un minimum le rendu 3D et la carte graphique (surtout pour Vulkan).
Vouloir apprendre OpenGL "pour apprendre" est un peu comme vouloir apprendre le C pour savoir comment les programmes fonctionnent vraiment, et Vulkan se compare alors au brainfuck.
La différence majeur entre vulkan et opengl est qu'avec vulkan on peut avoir plusieurs thread qui utilise la carte graphique ce qui n'est pas possible avec OpenGL donc faire plein de traitement de carte graphique en parallèle.
La différence majeur entre vulkan et opengl est qu'avec vulkan on peut avoir plusieurs thread qui utilise la carte graphique ce qui n'est pas possible avec OpenGL donc faire plein de traitement de carte graphique en parallèle.
C'est loin d'être la différence majeure et ce n'est pas impossible avec OpenGL non plus.
Vulkan permet à certains objets d'être construits par plusieurs threads différents (les commands buffers notamment), l'intérêt est de minimiser le temps de construction de la scène, mais néanmoins ces commands buffers doivent être soumis par un seul thread au driver graphique, comme l'illustre ce schéma:
Quant aux traitement de la carte graphique en parallèle, rien ne change entre Vulkan et OpenGL : une carte graphique est un appareil extrêmement parallélisé (possédant des milliers de processeurs), ce parallélisme se voit surtout au niveau du traitement, disons des shaders par exemple.
Vulkan n'a absolument pas changé ce fonctionnement, seulement facilité le multithreading au niveau de l'application elle-même, mais l'utilisation du GPU n'a pas bougé d'un poil (c'est d'ailleurs pour ça que si votre application voit son goulot d'étranglement au niveau du fillrate, que ça soit OpenGL ou Vulkan n'y changera rien).
Pour le multi-threading avec OpenGL dont j'ai parlé au début, c'est possible via l'utilisation de plusieurs contextes OpenGL, ils peuvent être indépendants (une même application peut faire un rendu vers plusieurs fenêtres de façon parallèle) mais les ressources peuvent également être partagés entre les contextes, on peut donc imaginer qu'il soit possible de préparer les ressources en parallèle (je ne m'y suis jamais essayé mais je pense que c'est possible).
Mais la vraie grande différence entre OpenGL et Vulkan n'est pas le multithreading, c'est le niveau d'abstraction (et l'abstraction résultante).
Je n'ai pas envie de transformer le topic de Nazara en débat OpenGL/Vulkan, je serai ravi de participer à un autre topic ou donner des informations ici si c'est demandé, mais un débat nuirait je pense aux personnes qui suivent le topic en espérant des nouvelles à propos du moteur (bientôt !), je vais donc tâcher de ne plus répondre à des débats ici, surtout si je vois qu'ils commencent à partir en vrille et je vous demande de faire de même (mais n'hésitez pas à faire un topic, ça m'intéresse).
Juste un dernier poste a propos de Vulkan , j'ai regardé un peux sont utilisation mais pour un projet amateur je trouve ça trop compliqué.
Je pense qu'OpenGL et Vulkan coexisteront très très longtemps.
Après le langage des shaders (vertex fragment geometry et compute shader ) ça ne change pas.
Moi je suis déçu de vulkan car j'aurais voulu une abstraction supplémentaire des cartes graphiques , de leurs paramètre d'être plus générique et moins spécialisé dans la 3D.
Avec CUDA aujourd'hui une carte graphique c'est juste un calculateur massivement parallèle qui un jour pourrait remplacer le CPU ou le CPU sera juste l’ordonnanceur des taches a exécuter en parallèle.
- Edité par Banisardevidad 7 septembre 2016 à 13:40:29
Juste un dernier poste a propos de Vulkan , j'ai regardé un peux sont utilisation mais pour un projet amateur je trouve ça trop compliqué.
OpenGL pour un projet amateur est déjà trop compliqué, ou une mauvaise idée, un moteur de rendu est une bien meilleure idée.
Banisardevidad a écrit:
Je pense qu'OpenGL et Vulkan coexisteront très très longtemps.
Je pense qu'on entendra plus parler d'OpenGL d'ici cinq à dix ans.
En informatique, on évolue constament ou on meurt.
Banisardevidad a écrit:
Après le langage des shaders (vertex fragment geometry et compute shader ) ça ne change pas.
Ça par contre c'est faux, OpenGL ne comprend que le GLSL et Vulkan ne comprend que le SPIR-V, le fait qu'il existe des outils pour compiler une version modifiée du GLSL en SPIR-V ne signifie absolument pas que Vulkan supporte le GLSL.
Sinon on peut aussi compiler le SPIR-V en GLSL, mais ça signifie pas qu'OpenGL supporte le SPIR-V pour autant.
Banisardevidad a écrit:
Moi je suis déçu de vulkan car j'aurais voulu une abstraction supplémentaire des cartes graphiques , de leurs paramètre d'être plus générique et moins spécialisé dans la 3D.
Vulkan est une abstraction destinée au rendu graphique, mais tu peux également l'utiliser pour les calculs (via les compute shaders), même si un framework entier dédié à ça (OpenCL) est à mon avis plus profitable.
Banisardevidad a écrit:
Avec CUDA aujourd'hui une carte graphique c'est juste un calculateur massivement parallèle qui un jour pourrait remplacer le CPU ou le CPU sera juste l’ordonnanceur des taches a exécuter en parallèle.
Et pour les tâches qui ne peuvent pas s'exécuter en parallèle ? Le GPU et le CPU ne sont pas concurrents, ils sont conçus différemment, par exemple les performances d'un GPU s'effondre en présence de branching, là où le CPU arrive à les gérer plutôt rapidement, pareil pour les caches.
Le GPU impose de nombreuses contraintes que n'a pas un CPU, je pense que les deux vont cohabiter très, très longtemps (au moins jusqu'au moment où la science nous permettra d'inventer une nouvelle architecture pour nos ordinateurs (ordinateur quantiques, ce genre de chose).
Il faut se rappeler au début les cartes graphique n'était pas programmable.
Après il y avait un assembleur rudimentaire pour créer uniquement des vertexs et fragment shader.
Après il y a eu un langages plus évolué le GLSL.
Après il y a eu les computes shaders.
Donc plus ca va plus la carte graphique fait de chose donc il est légitime qu'un jour elle remplace le CPU vu qu'elle fait une partie de ce qu faisais le CPU avant.
La différence c'est que le CPU n'a jamais été conçu pour le rendu en temps réel, les carte graphiques sont arrivées très rapidement quand on en a eu besoin.
Et bien sûr, le CPU n'a pas été conçu à l'origine pour le multi-traitement, ce que la carte graphique se révèle efficace à faire, mais ça s'arrête là, il y a beaucoup de fonctionnalités qui ne peuvent pas bouger sur un GPU, ou qui ne peuvent en profiter que très peu de part l'architecture des GPUs.
Donc non, rien ne laisse supposer que le GPU va remplacer le CPU, que ce soit dans dix, vingt, voire même trente ans.
un GPU est un CPU avec beaucoup plus de coeurs qui sont spécialisé pour la 3D ou d'autre calcul scientifique donc qui ne peuvent pas faire toutes les taches d'un CPU car il y a des limitations techniques.
L'augmentation du nombre de coeur de CPU (logique et physique ) , montre bien que CPU tend vers le GPU surtout avec l'hyperthreading
Il sur qu'un jour il n'y aura plus de CPU ni de GPU mais un mélange des deux.
Dernière réponse de ma part parce que sinon ça va encore repartir en débat, mais je t'invite à ouvrir un topic si ça t'intéresse.
Banisardevidad a écrit:
un GPU est un CPU avec beaucoup plus de coeurs qui sont spécialisé pour la 3D ou d'autre calcul scientifique donc qui ne peuvent pas faire toutes les taches d'un CPU car il y a des limitations techniques.
Un coeur de GPU n'est pas du tout équivalent à un coeur de CPU, ce qui permet d'avoir autant de coeurs sur le GPU est surtout le fait qu'ils soient très simplifiés (on en parle du branch predictor, du réordonnanceur, des caches L1-L2, de la fréquence, ...).
L'augmentation du nombre de coeurs du CPU montre justement qu'on préfère augmenter la parallélisation côté CPU plutôt que de tout miser sur le GPU.
Mais étant donné que les coeurs du GPU ne fonctionnent pas indépendamment et qu'ils ne valent pas les coeurs du CPU, non, rien ne permet de dire qu'on tend vers un mélange des deux, on gagne bien plus en ce moment à garder deux architectures totalement distinctes et je ne vois pas de raison (à court ou a moyen terme) qui ferait changer ça.
Les coeurs de CPU sont de type logique et physique donc pour quoi ne pas imaginer n'avoir un troisième type de coeurs qui ressemble a celui des cartes graphique pour plus de puissances.
Il y a déjà des instructions de processeur qui font des additions/multiplications en parallèle.
D'ailleurs les processeurs intel integre un GPU.
Donc il est évident qu'on verra arrivé des architectures qui sont des fusions de CPU et de GPU
Je vois que tu comptes utilisé Vulkan, je suppose que tu as déjà passer le stade mais j'avais écris quelques petits articles à propos de Vulkan, mais il y a néanmoins quelques petites coquilles qui ont pu s'y glisser. Si des gens veulent avoir une vue d'approche sur Vulkan (bien que ce soit pas parfait) ça se passe ici http://cpp-rendering.io/
Ensuite je recommande de lire les blogs de nvidia etc, il y a pas mal d'article sur Vulkan ou méthodes de rendu qui sont intéressantes ^^.
Voilà des bisous !
Et encore félicitation pour ton travail
http://cpp-rendering.io : Vous trouverez tout ce dont vous avez besoin sur Vulkan / OpenGL et le rendu 3D !
Les coeurs de CPU sont de type logique et physique donc pour quoi ne pas imaginer n'avoir un troisième type de coeurs qui ressemble a celui des cartes graphique pour plus de puissances.
Tout simplement parce que les cœurs physiques sont physiques et les logiques sont logiques. Autrement dit, les logiques ne sont pas physiques.
Les cœurs logiques de CPU sont uniquement des cœurs simulés pour permettre des threads supplémentaires, rien à voir avec les cœurs physiques ou ceux de GPU.
Banisardevidad a écrit:
Il y a déjà des instructions de processeur qui font des additions/multiplications en parallèle.
Si tu parles des threads, alors oui, ça existe depuis un moment. Mais dire que "un processeur fait du parallélisme comme un GPU donc ça tend vers une fusion CPU/GPU", ça relève de la logique "Socrate est mortel, les poneys sont mortels, donc Socrate est un poney".
Autrement dit, aucun sens.
Banisardevidad a écrit:
D'ailleurs les processeurs intel integre un GPU.
Oui, les chipsets, qui sont considérablement moins performants qu'une carte graphique. Bonne chance pour obtenir la puissance d'une CG sur un processeur ridiculement petit en comparaison.
Banisardevidad a écrit:
Donc il est évident qu'on verra arrivé des architectures qui sont des fusions de CPU et de GPU
J'espère que tu connais ton sujet, parce qu'affirmer "il est évident que" sans vraiment savoir de quoi on parle, c'est relativement présomptueux.
Je n'ai aucune envie d'entrer dans un débat donc je ne répondrai probablement pas à une potentielle réponse, mais je pense qu'avant d'affirmer ses idées il faut déjà maîtriser son sujet. Ce qui, sans vouloir être vexant, n'est manifestement pas ton cas.
> mais je pense qu'avant d'affirmer ses idées il faut déjà maîtriser son sujet. Ce qui, sans vouloir être vexant, n'est manifestement pas ton cas.
Ce qui est rigolo c'est que c'est exactement l'impression que j'ai aussi, alors que je n'y connais strictement rien en C++, 3D, matériel physique et autre. Quand tu arrives à passer pourquoi quelqu'un d'incompétent auprès de gens vraiment incompétents (comme moi), c'est qu'il y a clairement un problème.
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
GZE, un moteur multiplateforme, adapté pour de la 2D, 3D et création de logiciels.
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Si vous ne trouvez plus rien, cherchez autre chose.
Si vous ne trouvez plus rien, cherchez autre chose.
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Si vous ne trouvez plus rien, cherchez autre chose.
Si vous ne trouvez plus rien, cherchez autre chose.
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Si vous ne trouvez plus rien, cherchez autre chose.
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
RaZ, moteur de rendu en C++