Discussion :

[RedSkidy]

bah justement j'ai cru comprendre que pixeltoaster utilisait OpenGL et DirectX
et si je veut créer un "deuxième OpenGL", utiliser OpenGL surchargerais pour rien non ?

[Obsidian]

Le mieux que tu aies à faire à ce stade est télécharger les sources de Pixel Toaster : http://sourceforge.net/projects/pixeltoaster/
… et voir comment il s'y prend. Mais ça risque de t'occuper un bon moment.

Je ne connais pas cette bibliothèque en particulier mais ça a effectivement l'air d'être un concurrent de la SDL, développé de longue date à une époque où les différents frameworks n'étaient pas unifiés. Beaucoup d'entre eux sont redondants à présent, et il est possible qu'une bibliothèque, même en 2D, s'appuie sur OpenGL si celle-ci est disponible, ou au contraire choisir de volontairement ne pas le faire, car c'est une manière simple d'être automatiquement compatible avec les plateformes qui n'ont pas encore été étudiées.

Regarde aussi le framebuffer du noyau Linux : c'est une interface proposée par le kernel faite pour accéder facilement à la mémoire vidéo sans recourir à d'autres ressources.

[RedSkidy]

est-ce qu'il est possible d'utiliser ce framebuffer sur windows ?
sinon je veut bien utiliser un pixel shader mais est-ce qu'on peut le séparer du vertex shader ?

[Obsidian]

est-ce qu'il est possible d'utiliser ce framebuffer sur windows ?

Non.

sinon je veut bien utiliser un pixel shader mais est-ce qu'on peut le séparer du vertex shader ?

Es-tu certain de savoir ce que tu veux faire au final ? À la base, tu es venu ici pour écrire un programme en assembleur. Est-ce toujours le cas ?

D'autre part, as-tu bien compris, en fin de compte, comment l'ordinateur affiche un pixel à l'écran une fois toutes les couches franchies ? Si oui, pourquoi n'essaies-tu pas d'écrire pour commencer un petit programme en assembleur qui affiche un pixel sur ton architecture à toi, avant de vouloir passer une bonne dizaine d'années à réécrire la SDL ? Après tous ces commentaires, ça ne te tente pas de passer enfin à la pratique ?

[RedSkidy]

si je suis venu ici c'était pour savoir si il fallait utiliser l'assembleur pour utiliser la carte graphique.
donc si je peut passer par du c++ plutot que par de l'assembleur je préfère.
je pensait qu'on pouvait faire un petit code de 10-15 lignes qui affiche un pixel mais apparemment ce n'est pas le cas.
si je voulais de l'assembleur c'était aussi pour éviter passer justement par toutes ces "couches" qui causent du lag
écrire un programme qui affiche un pixel sur mon écran je veut bien mais comment (en 1920x1080) c'est aussi pour ça que je suis venu :p

[Obsidian]

si je suis venu ici c'était pour savoir si il fallait utiliser l'assembleur pour utiliser la carte graphique.
donc si je peut passer par du c++ plutot que par de l'assembleur je préfère.

De l'assembleur, du C ou du C++. Dans tous les cas, il suffit d'utiliser un pointeur vers la mémoire vidéo.

je pensait qu'on pouvait faire un petit code de 10-15 lignes qui affiche un pixel mais apparemment ce n'est pas le cas.

Si, c'est le cas.

Une fois que tu as correctement initialisé la carte vidéo et que tu as obtenu les droits d'écrire en mémoire. C'est ça qui est difficile. Initialiser le mode, c'est le travail du pilote. Jusqu'à VGA, les cartes étaient (et sont encore) compatibles directement au niveau matériel. Si tu travailles sans OS, tu peux taper dedans pour initialiser ta carte jusqu'à 800×600 ou 1024×768. Au dessus, si tu travailles sans pilote, alors il te faudra écrire toi-même ce pilote.

si je voulais de l'assembleur c'était aussi pour éviter passer justement par toutes ces "couches" qui causent du lag.

C'est louable en soi mais ces couches ne sont pas là pour rien non plus. Si tu t'en passes, tu vas devoir te passer de pas mal de fonctionnalités et systèmes de protection. Mais admettons.

écrire un programme qui affiche un pixel sur mon écran je veut bien mais comment (en 1920x1080) c'est aussi pour ça que je suis venu :p

On a écrit une page entière de commentaires pour te l'expliquer : il faut obtenir l'adresse de la mémoire vidéo et écrire dedans. Pour ce faire, il faut — aujourd'hui — que tu la demandes à ton système d'exploitation. Pour cela, il faut trouver l'API correspondante (par exemple, quelque part sur MSDN si tu fais cela sous Windows). Et cela, ça demande un peu de recherche de ta part. Dans tous les cas, c'est précisément parce qu'il y a des dizaines de manières différentes de le faire que des produits comme la SDL ont été écrits, spécialement pour uniformiser tout cela sous une couche d'abstraction.

Ça, c'est vrai si tu veux faire le travail toi-même. Si tout ce qui t'intéresse est effectivement d'afficher un pixel dans le contexte normal d'utilisation, alors il faut demander au système graphique en place, qui lui exploite ta carte vidéo, de le faire. Là encore, il s'agit de trouver la bonne API. Sous Windows, il y a la GDI qui sert formellement à faire à peu près la même chose que ce que tu ferais dans MS Paint : http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx tracer des points, des lignes, des ellipses, etc. dans le contexte actuel sans se soucier du mode, de la résolution, etc. Par contre, c'est très lent. Ce n'est fait que pour le bureau Windows. Sous Unix, on utilise généralement X-Window. X-Window est un serveur graphique qui ne tourne même pas forcément sur la même machine que l'application. Pour communiquer avec, on utilise la X-Lib : http://tronche.com/gui/x/xlib/ . Dans ces deux derniers cas, on envoie des ordres à un logiciel qui se charge de faire le travail pour toi.

Si tu as un Linux sous le coude, essaie déjà, dans un premier temps, de déterminer quelles sont les plages utilisées par ta carte vidéo. Tape par exemple « lshw -c display » dans un Shell (il te faudra éventuellement installer lshw au préalable si nécessaire). On verra ensuite comment écrire dedans.

[chrtophe]

Pour conclure :

Tu as OpenGL qui permet de faire de la 3D
Tu as la SDL pour la 2D

Il y en a d'autres, mais celles-ci sont reconnues par la communauté.

Ces 2 APis te permettent de programmer sur Windows, Linux, Mac OS, sur certains terminaux, tu n'as donc à te préoccuper ni de la plateforme, ni de la carte graphique. Et tu peux faire quasiment tout ce que tu peux avoir besoin.

Ça m'étonnerais que tu puisses faire mieux. Et ce sont en plus des solutions, testés, approuvés, bien documentés, et sur lesquels tu pourras être facilement assisté.

Bien que ne l'utilisant pas, je pense que tu peux dessiner par exemple un carré de couleur avec la SDL en 5-6 lignes de C, et du coup 3-4 pour afficher un pixel (en comptant l’initialisation)
Regardes les screenshots de la page wikipedia :

http://fr.wikipedia.org/wiki/Simple_DirectMedia_Layer

Tu penses pouvoir faire mieux à la main ?

Par rapport à ce que dit Obsidian :

Si tu as un Linux sous le coude, essaie déjà, dans un premier temps, de déterminer quelles sont les plages utilisées par ta carte vidéo. Tape par exemple « lshw -c display » dans un Shell (il te faudra éventuellement installer lshw au préalable si nécessaire). On verra ensuite comment écrire dedans.

En VESA, selon la résolution, tu vas avoir un espace d'adressage mémoire mappé dans l'espace mémoire de l'ordinateur correspondant à la RAM vidéo, mais que l'OS t'interdira de modifier because mode protégé. regardes les spécifications VESA si tu veux Avec les drivers propriétaires, c'est un peu le même principe mais en général non documenté. Pour ce qui est 3D, il te faut attaquer directement le processeur spécifique à la carte Vidéo, mais personne ne fait ça, mis à part les développeurs du constructeur, sinon on passes par OpenGL ou directX pour Windows.

Je peux te reconstituer le code permettant d'afficher un pixel après avoir activé une résolution bien précise, mais tu ne pourras pas l'exploiter depuis un SE, il te faut connaitre un minimum l'assembleur x86, le mode protégé, le BIOS (qui maintenant est remplacé par l'EFI en plus), et le VESA

[RedSkidy]

j'avais vu la fonction setpixel de l'api windows et c'est ce qu'il me faut mais le problème c'est qu'elle est très lente et marche que sur windows
comme je veut faire une api graphique il vaut mieux qu'elle soit rapide, multi plateforme marche en toutes les résolution FHD, UHD... et d'après ce que j'ai compris pour répondre a tous ces critères il vaut mieux utiliser OpenGl et faire en sorte qu'il fonctionne autrement que ce qui est prévu

[chrtophe]

SetPixel, tu vas la trouver sous SDL, OpenGL, Directx

[Obsidian]

comme je veut faire une api graphique il vaut mieux qu'elle soit rapide, multi plateforme marche en toutes les résolution FHD, UHD...

Il y a encore d'autres cas à prendre en considération : comme on te l'a dit, sur une station de travail UNIX ou assimilée, le framework graphique est X-Window. Il s'agit d'un serveur graphique auxquelles les applications se connectent. La plupart du temps, aujourd'hui, ce serveur est lancé sur la même machine mais ce n'est pas nécessairement le cas. Si l'afficheur se trouve sur une machine distante, tu n'auras pas d'autres choix que d'utiliser le protocole de communication du serveur, et donc la X-Lib. De là, soit tu utilises directement les primitives graphiques qui te sont proposées (pixels, lignes…), soit tu travailles sur des morceaux de buffer que tu modifies en local et que tu mets à jour côté serveur à intervalles définis et en essayant d'optimiser le tout. C'est passionnant aussi, mais l'approche n'est pas du tout la même.

et d'après ce que j'ai compris pour répondre a tous ces critères il vaut mieux utiliser OpenGl et faire en sorte qu'il fonctionne autrement que ce qui est prévu

C'est-à-dire qu'OpenGL a exactement les mêmes problèmes et s'appuie, autant que possible, sur les infrastructures existantes. S'appuyer soi-même sur OpenGL est effectivement une façon propre de résoudre le problème. Mais si ton API ne propose rien de plus que ce qui existe déjà dans OpenGL, alors elle sera inutile par définition.

Qu'est-ce que tu veux faire exactement au final ? C'est peut-être parce que ce n'est pas clair de ce côté que tu t'enlises sur l'approche à suivre.
Ton API est censée proposer quel genre de services ? À quel types de clients ? Il s'agit simplement de permettre de tracer des lignes, des cercles et des pixels ou bien as-tu l'intention de faire quelque chose de plus évolué ? Pour quels types d'applications ?

[chrtophe]

Pour compléter ce que dit obsidian, tu auras des primitives de type setPixel si tu utilises x-lib.

[chrtophe]

J'ai oublié : pour les probs de lenteur, regardes du coté du double buffering, afficher des pixels l'un après l'autre via fonction setpixel est inadapté. Pour la 3D, je n'ai pas de compétences.

[RedSkidy]

enfaite je voudrais essayer de faire du rendu 3D sans triangle en utilisant juste des pixels ce qui augmenteras la qualité des meshs mais obligeras a avoir une des millions de points pour un cube par exemple mais comme cela évite d'avoir a calculer quels pixels font partie du triangle ou non, ça va gagner en rapidité et permettra de tenir avec un nombre de sommet qu'une carte graphique n'aurais pas supportée avec une utilisation classique (je pense que les sommets ne seront pas dans la mémoire graphique mais directement dans le disque dur, comme la technique utilisée par euclideon) il y auras aussi d'autres optimisations qui permettront d'afficher le moins de points possible... j'ai calculé, avec une bonne carte graphique et par exemple 2000 cycles d'horloge utilisés pour traiter un point il devrais pouvoir en afficher jusqu'a 100 millions

[chrtophe]

faire de la 3d sans triangles, ça me parait de la science fiction, mais je n'en fait pas. Si quelqu'un a de la doc abordable pour ma culture personnelle... je suis preneur. Tout est basé sur les polygones j'ai cru comprendre (qui sont divisibles en triangles, mis à part les cercles).

[RedSkidy]

oui c'est ça et même les celcles (ou plutot spheres) sont la plupart du temps fait en triangle exemple : http://www.klopfenstein.net/public/U...02_normals.png
c'est vrai que les triangles sont très utilisés mais je pense qu'on peut changer ça et faire en sorte d'avoir un résultat photoréalistique pour pas énormément plus gourmand en ressources que le système actuel, il faut juste avoir une carte graphique potable (impossible d'avoir un mesh moins détaillé, ça ferait des trous dedans de près) et faire les bonnes optimisations

[Kannagi]

Tu dois très mal calculer , je connais pas le cycle horloge d'une affectation sur un x86 mais si je suppose que c'est 3 cycle , alors pour une simple image de 32x32 en RGB tu as donc 3072 affectation a faire pour mettre ton image en mémoire (soit 9216 cycle horloge) , pour une simple image de 32x32 , son faire de boucle pour affectation (sinon ça fait plus) , sans parlé des calcul alpha en plus si on en met.
Les cartes graphiques sont a peine plus performante pour afficher des pixel mais beaucoup plus pour faire des calcul trigonométrique et de nombre flottant.

Si tu voudrais afficher a peine un cube en 3D en pixel 3D un 32x32x32 en RVB prendrait en place mémoire a peu prés 100ko , un model 3D cela représente un personnage avec 15000 polygone , il y a une sacrée différence...
Et en nombre de cycle horloge en serait a 300 000 cycle a peu prés.
Apres , c'est sans parlé que tu devra faire des calcul sur chacun de tes points , par rapport a la vue ce qui alourdie considérablement les calculs.
La 3D existe depuis surement avant ta naissance et si le choix ne s'est pas fait sur les pixel 3D (qui est le choix le plus logique) , c'est que il n'a pas pu percé a cause de ces calcul trop élevé et son coup mémoire énorme , donc que je t’entend dire pour du HD (1920 x1024) alors que rien que pour du 32x32x32 en aurait des perf assez mauvaise (équivalent a un polygone de 15 k) , ça me fait sourire.

Maintenant si tu veux t'amusé a faire ce genre API , tu prend les conseil qu'on t'a donné ,avec la SDL , ça prend 3 lignes pour créer une fenêtre + récupérer les pixel:

Code :

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

1
2
3
4
 
SDL_Surface *ecran = NULL;
ecran = SDL_SetVideoMode(640,480, 24,SDL_HWSURFACE | SDL_DOUBLEBUF);
unsigned char *pixel = ecran->pixels;

Et si tu trouve ça trop 'long' pour tes calcul il y a OpenCL qui permet de faire des calcul parallèle avec ta CG.

[Forthman]

Bien justement, si la 3D fonctionne avec des surfaces et pas avec des points, c'est uniquement pour gagner de la vitesse
Quels sont tes "calculs" pour affirmer pouvoir afficher 100M de points (pas seconde j'imagine?), et pour quel type d'image ?

[Obsidian]

enfaite je voudrais essayer de faire du rendu 3D sans triangle en utilisant juste des pixels ce qui augmenteras la qualité des meshs mais obligeras a avoir une des millions de points pour un cube par exemple mais comme cela évite d'avoir a calculer quels pixels font partie du triangle ou non, ça va gagner en rapidité et permettra de tenir avec un nombre de sommet qu'une carte graphique n'aurais pas supportée avec une utilisation classique (je pense que les sommets ne seront pas dans la mémoire graphique mais directement dans le disque dur, comme la technique utilisée par euclideon) il y auras aussi d'autres optimisations qui permettront d'afficher le moins de points possible... j'ai calculé, avec une bonne carte graphique et par exemple 2000 cycles d'horloge utilisés pour traiter un point il devrais pouvoir en afficher jusqu'a 100 millions

Densifier le nombre de points est la pire chose à faire : non seulement parce que tu vas sérieusement plomber tes performances (ici, tu as besoin d'une carte de compétition pour afficher… un cube !) et parce même dans ce cas, tu vas toujours te retrouver avec des zones non couvertes. La plupart de tes pixels vont se recouvrir sur les surfaces éloignées (et donc être inutiles) tandis que les surfaces proches vont invariablement s'étioler en une trame de points.

À la place, on fait de la rasterisation. Voir plus bas.

faire de la 3d sans triangles, ça me parait de la science fiction, mais je n'en fait pas. Si quelqu'un a de la doc abordable pour ma culture personnelle... je suis preneur. Tout est basé sur les polygones j'ai cru comprendre (qui sont divisibles en triangles, mis à part les cercles).

Ça dépend de ce que tu veux faire. Si la vitesse de rendu n'est pas trop un problème, tu peux faire de la géométrie dans l'espace par exemple, à partir de solides génériques qui sont faciles à modéliser mathématiquement. C'est utile pour le raytracing et c'est ce que fait POV par exemple. Ça permet d'avoir un rendu exact quelque soit la résolution, ce qui est l'équivalent du dessin vectoriel en 2D. Et c'est justement pour décrire de façon déterministe des courbes qui sortent des simples cercles et ellipses que l'on a inventé les courbes de Bézier.

oui c'est ça et même les celcles (ou plutot spheres) sont la plupart du temps fait en triangle exemple : http://www.klopfenstein.net/public/U...02_normals.png
c'est vrai que les triangles sont très utilisés mais je pense qu'on peut changer ça et faire en sorte d'avoir un résultat photoréalistique pour pas énormément plus gourmand en ressources que le système actuel, il faut juste avoir une carte graphique potable (impossible d'avoir un mesh moins détaillé, ça ferait des trous dedans de près) et faire les bonnes optimisations

On utilise les triangles parce que trois points dans l'espace sont la figure la plus simple après la droite mais également et surtout parce qu'ils se trouvent toujours forcément dans un même plan, ce qui n'est pas le cas avec des polygones à plus de trois sommets. C'est aussi la raison pour laquelle un trépied n'est jamais bancal. Il y a également une autre raison : un triangle orienté arbitrairement dans l'espace ressemble toujours à un triangle, ce qui n'est pas le cas avec les autres figures non plus.

Pour faire une projection — et donc un rendu — d'un triangle plein dans l'espace, il suffit de relever les coordonnées x et y sur le triplet <x,y,z> de chaque sommet (donc aucun calcul à faire à ce stade) et de déterminer les droites qui les relient. Ensuite, on détermine le sommet le plus haut et le sommet le plus bas du triangle sur l'image, puis le plus à gauche et le plus à droite, pour se limiter à la zone dans laquelle le triangle est suceptible de se trouver. On passe alors en revue tous les pixels de l'image finale dans cette zone, de gauche à droite et de haut en bas, et on vérifie si ils se trouvent entre deux côtés du triangle, auquel cas on le colorie. De cette façon, on sait que le nombre de pixels à traiter ne sera jamais supérieur à la surface couverte par le triangle sur l'image finale. Plus précisément, on aura toujours à remplir entre 0% et 50% du rectangle dans lequel est inscrit le triangle en question.

Pour savoir si on se trouve à gauche ou à droite d'un côté, il suffit de vérifier si x est inférieur ou supérieur au point de la droite de même ordonnée. Et pour trouver ce point, une simple règle de trois suffit. Une multiplication et une division. Il est donc très facile de faire cela en assembleur même sur les vieilles machines. J'avais fait des prototypes sur 486DX33 à l'époque (sur lesquelles les démos fonctionnaient déjà fort bien, telle que Second Reality en 1993). On pouvait éventuellement travailler en virgule fixe pour faire la même chose sur des machines sans FPU tout en restant rapide et il est probable que les cartes graphiques 3D le fassent aussi dans certaines conditions. On peut aussi, à échelle raisonnable, calculer le coefficient directeur de la droite une fois pour toute et ramener ces opérations à une seule addition par ligne.

Bien justement, si la 3D fonctionne avec des surfaces et pas avec des points, c'est uniquement pour gagner de la vitesse

En fait, c'est avant tout pour pouvoir modéliser l'objet à rendre.

[chrtophe]

Et je pense que l'utilisation des triangles, c'est en rapport avec la trigo

@Obsidian +1 pour les souvenirs. C'est moche maintenant, mais à l'époque c'était un exploit, surtout sur PC.

[Forthman]

On utilise les triangles parce que trois points dans l'espace sont la figure la plus simple après la droite mais également et surtout parce qu'ils se trouvent toujours forcément dans un même plan, ce qui n'est pas le cas avec des polygones à plus de trois sommets. C'est aussi la raison pour laquelle un trépied n'est jamais bancal. Il y a également une autre raison : un triangle orienté arbitrairement dans l'espace ressemble toujours à un triangle, ce qui n'est pas le cas avec les autres figures non plus.

Oui, et comme la surface est sur un même plan, c'est plus rapide à calculer (moins de calculs en fait)

Mais encore une fois, tout dépend de ce que l'on souhaite afficher, gestion de la lumière ou non ? si gestion de la lumière, gestion des ombres ? gestion des reflets ?

Dans la 3D ce n'est pas tant le temps d'affichage des points qui compte mais le temps de calcul