Discussion :

[idmapria]

Bonjour,

Je cherche à faire des expériences de moteur graphique rétro codé pixel par pixel. Pas seulement par nostalgie de la prog ms dos, mais aussi parce que je suis frustré par les moteurs graphiques tout faits qui font jamais ce que je veux

Je veux pas passer par les shaders pixel3, je veux faire du tripotage de pixels en calculs processeur à l'ancienne. Eventuellement utiliser directX pour zoom et vsync mais c'est tout.

J'aimerais que ça s'exécute sur windows au minimum, et dans l'idéal sur un navigateur web

La solution qui me parait la mieux indiquée me semble donc être c# pour .net framework, vu que ça s'exécute sur windows et aussi dans le navigateur avec silverlight plugin

Seulement vu que je veux faire un truc codé au pixel, j'ai peur que la vitesse du c# ne soit pas bonne... quand je vois la lenteur des émulateurs de gameboy en visual basic je me dis qu'en c# ça doit être encore pire, bref je ne suis pas du tout sûr que c# va gérer mon tableau de pixels à vitesse convenable.

Dans ce cas, a-t-on des meilleurs perfs avec java ?
Ou alors faut laisser tomber l'option browser et faire du c+ sur directx ?

[Kannagi]

Si tu code pixel par pixel , le conseil absolu que je te conseille c'est de faire un jeu en base résolution (meme en C++ en haute résolution , ce n'est quasiment pas possible de faire quelque chose de rapide).

Si tu peux coder au C++ c'est le mieux je pense avec directx (mais il y a opengl aussi et la SDL aussi qui peuve faire affaire).

[idmapria]

Bah si je fais ça en c++ je vais pas être limité des masses... sur les vieux process 500 mhz on faisait déjà tourner des jeux en 800*600

Par contre en c#, là j'ai peur que ça soit vraiment trop limité. faudrait que je teste...

et pour la SDL c'est non. cette lib n'est plus supportée, c'est le problème avec les béquilles gratuites... donc si je dois me taper du c+ je préfère fourrer les mains dans directx

[pyros]

Salut,

Pourquoi pas OpenGL ? Avec des textures en nearest interpolation tu aura des gros pixels, niveaux béquille toute faite c'est quand même assez bas niveaux (si ça ne fait pas ce que tu veux c'est que tu t'es mal expliqué ) et ça tourne sur tout.

[idmapria]

je me méfie d'openGL pour plein de raisons (notemment parce que j'ai eu plein de bugs avec... et aussi parce que cette lib donne des mauvaises habitudes)... quitte à mettre les mains dans le strict minimum d'une lib bas niveau autant prendre les bonnes habitudes avec directx... bon enfin, que j'utilise l'un ou l'autre ça change pas grand chose vu que je m'en sers juste pour afficher mon tableau de pixel, le reste c'est du calcul pur... opengl est plus facile donc je peux commencer par ça

mais bon je vais d'abord tenter de voir ce qu'on peut tirer du c#... si c'est vraiment trop lent je (re)passe au c+

[Mat.M]

Je veux pas passer par les shaders pixel3, je veux faire du tripotage de pixels en calculs processeur à l'ancienne. Eventuellement utiliser directX pour zoom et vsync mais c'est tout.

J'aimerais que ça s'exécute sur windows au minimum, et dans l'idéal sur un navigateur web

si tu veux faire ça il faut accéder à la mémoire vidéo et notamment au BackBuffer
Avant Direct X c'était possible en créant un pointeur long directement sur la mémoire vidéo A000:000 et même mieux en programmant le mode X ,technique qu'utilisait DOOM.

Maintenant avec Direct X il ya les méthodes Lock/Unlock d'un buffer DirectDraw..
avec SDL c'est pareil et je suppose qu'avec Openg GL ça doit être possible également ( je ne connais pas assez Open GL)

[Kannagi]

et pour la SDL c'est non. cette lib n'est plus supportée, c'est le problème avec les béquilles gratuites... donc si je dois me taper du c+ je préfère fourrer les mains dans directx

La SDL est peut être plus supporté mais elle fonctionne très bien pour les Jeux 2D et le pixel par pixel, de mon point de vue je considère que la SDL est une librairie 'fini' je vois pas ce qu'il rajouterai en plus.

je me méfie d'openGL pour plein de raisons (notemment parce que j'ai eu plein de bugs avec... et aussi parce que cette lib donne des mauvaises habitudes)... quitte à mettre les mains dans le strict minimum d'une lib bas niveau autant prendre les bonnes habitudes avec directx...

Opengl donne des mauvaise habitude ? O_o
Je vois pas pourquoi elle donne des mauvaise habitude c'est une lib portable qui est plutôt bien faite , et largement suffisant pour faire du pixel par pixel.
La seule différence c'est que faudra recodé(bon c'est pas un souci) par rapport a la SDL qui possède déjà pas mal de fonction pour le 2D.

[idmapria]

si tu veux faire ça il faut accéder à la mémoire vidéo et notamment au BackBuffer
Avant Direct X c'était possible en créant un pointeur long directement sur la mémoire vidéo A000:000 et même mieux en programmant le mode X ,technique qu'utilisait DOOM.

Maintenant avec Direct X il ya les méthodes Lock/Unlock d'un buffer DirectDraw..
avec SDL c'est pareil et je suppose qu'avec Openg GL ça doit être possible également ( je ne connais pas assez Open GL)

je vais plutôt raisonner comme un émulateur, balancer mon tableau de pixels dans une texture que je peux zoomer à n'importe quelle taille

Kannagi > bah en fait je peux utiliser n'importe quoi, peu importe la librairie, ça changera pas le code de mon tripoteur de pixels...

[pyros]

Le problèmes est que les cartes actuelles ne sont plus faite pour faire du rendu pixel par pixel. Elles font de la rasterization de triangle. Donc le moyen le plus efficace du faire du rendu pixel est d'utiliser des texture en nearest interpolation et de dessiner des quads alignés sur une grille de pixel.

Si tu essaye d'envoyer des données pixel par pixel au framebuffer, tu aura des perf catastrophiques (même pire que sur des anciennes machine), car l'architecture n'est absolument pas faite pour ce genre d'utilisation. Les GPU on un débit de plusieur GPixels/s, mais une latence de quelques ms. Donc, si tu envois les pixels 1 par 1, tu aura au mieux du 1000Px/s.

Pour te donner une idée, j'avais fait il y a longtemps un raterizer full CPU qui envoyait les pixels 1 par 1 au framebuffer (à coup de setPixel, absolument pas optimisé ^^). Sur un AMD 3200+ (single core, 2.5Ghz), j'ai à peu près les même perf que sur un PII 200Mhz MMX, c'est à dire quelques dizaines de second par frame en 1600x1200. Donc, pour ce qui est de C# VS C++, ça ne change pas grand chose car ton problème ne viendra pas du langage mais des accès GPU.

Par contre, tu peux toujours faire un rendu full CPU dans un tableau en mémoire et envoyer le buffer en une seul fois à chaque frame à coup de glDrawPixels() (pour OpenGL, je ne connais pas du tout DirectX ). Mais pour le coup, c'est à toi de tout gérer (layer, position, etc...)

Ps: OpenGL ne bug pas (sauf pour des cas assez pointu). Mais c'est vrai qu'elle ne fait pas souvent ce qu'un débutant espère

[Mat.M]

Le problèmes est que les cartes actuelles ne sont plus faite pour faire du rendu pixel par pixel. Elles font de la rasterization de triangle. Donc le moyen le plus efficace du faire du rendu pixel est d'utiliser des texture en nearest interpolation et de dessiner des quads alignés sur une grille de pixel.

je serais tenté de dire que j'acquiesce à 100% .
J'avais fait un petit jeu d'Asteroid il y a un an ou plus pour participer au forum , une version en 3d temps réelle avec des fichiers 3d au format .X et
une version 2d avec des bitmaps affichées sur des quads.

Eh bien pourtant la version avec de vrais objets 3d me semble bien plus fluide que la version 2d avec des bitmaps.

( ici )
Donc concernant un rendu pixel par pixel ça n'améliore pas forcément les performances.
Ou alors il faut passer par les pixel shaders..

[idmapria]

Hé bien en fait je veux balancer mon tit tableau de gropixel dans une lib 3d qui l'affiche en texture sur un rectangle composé de deux triangles... voilà.

Bon à part ça je viens de tester de la bidouille pixel en c# et à ma grande surprise les perfs sont encore pires que sur le flash plugin donc on ferme la parenthèse

donc bon hop je repasse au c+ , et puis pour l'option browser je vais ressortir alchemy du placard, quitte à utiliser un plugin ria pourri (pléonasme) autant choisir le standard

[MoDDiB]

Bon à part ça je viens de tester de la bidouille pixel en c# et à ma grande surprise les perfs sont encore pires que sur le flash plugin donc on ferme la parenthèse

C'est que tu n'as pas procédé de la bonne manière : en unsafe tu as des performances très proches du C++.
Maintenant en silverlight je ne pense pas que tu aies accès à l'unsafe.

Je bosse en C++ et C# et je remarque à peine 10% de perte de performance maximum ; c'est largement compensable par le le matos et bien souvent ces 10% ne seraient nécessaires que pour un AAA....

[idmapria]

Merci de l'info MoDDiB je vais tester ça...

Mais bon je vais trancher pour c++ je pense... pour un moteur cpu gropixel ça me parait être la solution la plus portable

[idmapria]

Bien donc je suis en train d'étudier direct3d9 (histoire de partir sur un truc compatible avec tous les windows) et houlàlà que c'est compliqué... Je n'ai aucunement l'ambition d'apprendre la 3d sur directx (si je veux me lancer dans un moteur d'affichage 3d y'a xna pour ça) je cherche juste le strict minimum pour afficher correctement mon tableau de pixels en texture dans windows

donc, faut que je fasse un rectangle avec deux triangles et puis que j'affiche ma texture croppée dedans... bon c'est pas que je veux pas le faire (c'est pas la partie la plus difficile) mais histoire de pas réinventer la roue pour rien, y'a pas une fonction toute faite pour afficher de la 2d avec direct3d9 ?

[math_lab]

Franchement, passe par la SDL. Pour ce que tu as envie de faire, le fait qu'elle soit plus supportée ne changera rien. T'as juste a créer ta fenêtre, créer un buffer, et le tripoter comme tu veux pour dessiner dedans. C'est ce que je fais pour mon raytracer (qui n'est pas temps réel, certes), et c'est franchement ce que je trouve le plus pratique.

[idmapria]

ouaif... si je me décourage je me rabat sur sdl (il y'a pas mal d'émulateurs qui s'en servent)... mais bon j'aimerais bien réussir à emballer mon p'tit truc dans quelque chose de propre

[idmapria]

je suis en train de faire mumuse avec directx et je vois que quand on zoom la fenêtre ça floute les pixels de mon petit triangle 3d

donc en théorie j'ai nullement besoin de m'embêter à faire une texture sur un rectangle, il suffirait que j'ai directement accès aux pixels du backbuffer

[idmapria]

arf... y'a directx qui m'enguirlande parce que je fais des lectures illégales dans la vram... bon c'est un chouilla trop bas niveau pour moi d'aller trifouiller dans les swap chain, je vais me taper la texture sur 2 triangles ça sera plus propre

[Mat.M]

donc, faut que je fasse un rectangle avec deux triangles et puis que j'affiche ma texture croppée dedans... bon c'est pas que je veux pas le faire (c'est pas la partie la plus difficile) mais histoire de pas réinventer la roue pour rien, y'a pas une fonction toute faite pour afficher de la 2d avec direct3d9 ?

ce que j'ai écris a été lu partiellement: il faut que tu passes par un DirectDrawSurface9 (vérifier dans le MSDN) ce qui te permettra de gérer des zones contigües de mémoire vidéo. (je connais un site internet pour le code source)
Avec 2 triangles tu ne peux pas accéder pixel par pixel.
Ceci dit concernant la méthode avec DirectDrawSurface9 j'ai vite abandonné c'est très lent..


Pour résumer pour afficher de la 2d sous Direct3d9 il y a 3 méthodes:
-soit utiliser 2 triangles au format FVF ( Flexible Vertex Format ) et créer une structure de ce type.
Après on attache une texture dessus qui est en fait la bitmap
-soit utiliser un D3DXSprite assez facile à utiliser mais un peu plus lent qu'avec un Quad précédent
-soit accéder à une DirectDrawSurface9 accessible avec la méthode GetAttachedSurface de l'objet Direct 3d9 (faut voir dans le SDK de Direct X)

Avec Direct X d11 il ya une interface Direct2d

[idmapria]

Ben en fait pour des questions de compatibilité je veux pas commencer par dx11 (trop récent) ni directdraw (trop vieux)

je vais commencer par le dx3dsprite ou les 2 triangles