Discussion :

[c.aug]

Je cherche une librairie qui permette d'écrire proprement dans un pixelbuffer gpu pour avoir un rendu bien clean avec gpu stretch et vsync, comme le font les émulateurs qui switch sur diverses versions de directx & opengl pour adapter ça au mieux à la carte vidéo.

Même si l'opération a l'air simple ça demande en fait un énorme paquet de code parce qu'il faut prévoir des config diverses, donc je cherche si il existe une librairie spécialement conçue pour faire ce travail à notre place.

J'ai d'abord essayé SDL mais cette lib ne gère pas ça.

Je me tourne donc vers allegro pour voir si y'a ce que je cherche sous le capot.

J'avais cru comprendre qu'allegro est spécialement fait pour ce genre de trucs mais je ne sais pas s'il le fait bien. J'ai cherché des exemples en ligne mais sans succès, j'ai surtout vu des jeux sans vsync qui saturent le cpu et sans aucun stretching... donc j'ai un doute.

Auriez-vous un exemple simple d'un rendu pixelbuffer bien propre sous allegro, avec vsync et stretch gpu.

[Kannagi]

Mon post sera un peu HS vu que je parle de la SDL , bon personnellement vu que je utilise depuis un bon moment , j'ai toujours pu faire des jeux rétro avec.

Effectivement t'as pas accès au pixelbuffer hardware , mais tu as un peu son équivalent qui est le SDL_Surface * ecran.
Tu peux écrire pixel par pixel (avec des fonctions trouvable facilement sur le net) ou de modifier directement les SDL_Surface, même si SDL_BlitSurface permet de faire quasiment la totalité de ce qu'on veut faire.

Après désolé je peux pas d'aider (jamais utiliser allégro) , j'avais dit que c’était du HS

[c.aug]

Le moteur graphique de sdl il affiche simplement dans windows, donc pas de vsync, pas de stretch gpu, faut coder toi-même l'accès au pixelbuffer, et du coup l'utilisation de sdl n'a plus grande utilité, autant se taper directement opengl/openal

C'est pour ça que je cherche s'il existe une lib qui aurait été justement conçue pour s'occuper correctement du pixelbuffer hardware avec du dx/ogl sous le capot.

je regarde si allegro fait ça mieux mais je ne sais pas du tout ce que ça vaut

[Kannagi]

Le moteur graphique de sdl il affiche simplement dans windows

J'ai peut être pas compris , mais SDL et multiplateforme , windows , linux , Beos ,solaris,mac os, psp ect

Apres si SDL te convient as oui faut mieux regardé ailleurs

[c.aug]

J'ai peut être pas compris , mais SDL et multiplateforme , windows , linux , Beos ,solaris,mac os, psp ect

je voulais dire que le moteur graphique de sdl ne passe pas par les pixelbuffer gpu

sdl ne fait donc pas le truc que je cherche


et je suis en train d'éplucher la doc et les forums allegro, apparemment cette lib gère ça mal car ils manquent de développeurs pour adapter ça aux machines récentes
et apparemment y'a pas de hardware stretch, allegro en est toujours aux vieilles méthodes de fullscreen

[PilloBuenaGente]

Bonsoir,

je n'ai pas testé mais ceci pourrait rendre service (openGL).

[c.aug]

Oui je connais ce doc... son principe consiste bêtement à se taper tout le travail soi-même en fourrant les mains dans la carte vidéo, et uniquement pour opengl qui ne fera pas du boulot aussi propre et fiable sur windows que le matériel de microsoft (les jeux opengl+windows j'ai très souvent des bugs bien relou avec), donc il faut en plus se taper les deux versions du pixelbuffer directx pour faire du vrai boulot propre, prévoir également une version windows gdi, bref exactement tout le travail qui est fait sur les émulateurs console correctement programmés... et ça implique en plus avoir une équipe qui va assurer le suivi du truc et les trente mille retours de bug. ça s'appelle développer et maintenir une librairie bas niveau quoi, ça demande une équipe et un suivi, j'ai pas ça sous la main sinon j'irais pas fouiller du côté des sdl-allegro-etc

Donc justement l'objet de mon post c'est que je cherche s'il existe une librairie qui ferait ce travail là. Une librairie commerciale qui gère ça je doute fort que ça existe vu que la méthode "gros pixel" c'est un pur truc de jeux amateur/indie, donc je herche du côté des librairies amateur/open/free/etc.

Allegro le fait en théorie mais en pratique j'ai regardé les jeux et émulateurs faits avec allegro et c'est tout crade... alors j'ai un peu un doute sur la fiabilité de la librairie.

C'est pour ça que j'ai besoin de l'avis de ceux qui maitrisent allegro.

[LittleWhite]

Bonjour,

J'ai vraiment du mal à voir, car vous rejeter tout ce qui est proposé.

Il faut savoir, que le bas niveau côté GPU, il n'y a que DirectX et OpenGL. Après on remonte un peu plus haut niveau, là où des bibliothèques commencent à aider le développeur. Malheureusement, peu sont celles qui recouvrent DirectX et OpenGL à la fois, tout en laissant dessiner du gros pixels (même si cela est possible).
La SDL n'est pas du tout GPU (du moins, pas en version 1.2).
Allegro, je ne sais pas trop.

Je conseillerai SFML. Même si dans l'idée, je me demande s'il ne font pas juste une copie des sprites sur une zone mémoire CPU, puis pour afficher, juste un envoi de texture et hop, c'est fini.

[c.aug]

Je rejette pas directx-opengl (j'ai même les mains en plein dedans)... je viens juste me renseigner voir s'il existe une lib spécialisée dans la gestion des pixelbuffer qui faciliterait le travail.

Bon mais j'en doute fort... l'intérêt d'un tel outil serait limité au développement players video, emulateurs gameboy et jeux amateur gropixel, pas grand chose pour motiver une équipe d'open coders.

SFML j'ai pas encore regardé comment ça marche, mais effectivement au niveau des résultats ça m'a l'air déjà plus propre que sdl/allegro. Le coup de la copie dans une texture c'est bêtement la méthode moderne pour rendre un pixelbuffer propre, c'est plus souple et sécurisé que l'ancienne technique qui consistait à écrire directement dans le backbuffer. Si SFML le fait alors c'est parfait.

[yetimothee]

Je ne suis pas sûr de comprendre ce que tu demandes (), mais je vais tout de même tenter d'exposer un peu ce que je sais :

Alors, dans Allegro (je parle de la version 5), tu as deux types de bitmaps : les bitmaps en mémoire vive, et les bitmaps vidéo.

De manière classique, l'on ne dessine que dans des bitmaps vidéos, parce que Allegro 5 est spécialement taillé pour dessiner en utilisant la carte vidéo (il suffit de créer son ALLEGRO_DISPLAY* avec l'option ALLEGRO_RENDER_METHOD à 1 pour utiliser l'accélération matérielle)
https://www.allegro.cc/manual/5/al_s..._display_flags
https://www.allegro.cc/manual/5/al_s...display_option

Donc supposons que tu ais un ALLEGRO_BITMAP* gpu_buffer;

Tu le créé ainsi :

Code :

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

1
2
al_set_new_bitmap_flags (ALLEGRO_VIDEO_BITMAP);
gpu_buffer = al_create_bitmap (LARGEUR, HAUTEUR);

https://www.allegro.cc/manual/5/al_create_bitmap
https://www.allegro.cc/manual/5/al_set_new_bitmap_flags

Normalement, à chaque fois que tu appelleras une routine graphique, allegro devrait utiliser la carte graphique (c'est ce que j'ai compris du schmilblick, maintenant tout ce que je dis est à prendre avec précaution hein !).


Alors pour dessiner, ça ressemblera à ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
void je_dessine (ALLEGRO_DISPLAY* display, ALLEGRO_BITMAP* gpu_buffer) {
    al_set_target_bitmap (gpu_buffer);
    // Dessin...
    al_set_target_backbuffer (display);
    al_draw_scaled_bitmap (gpu_buffer, 
                           0.0f, 0.0f, 
                           (float) al_get_bitmap_width (gpu_buffer),
                           (float) al_get_bitmap_height (gpu_buffer),
                           0.0f, 0.0f, 
                           (float) al_get_display_width (display),
                           (float) al_get_display_height (display)
                          );
    al_flip_display ();
}

https://www.allegro.cc/manual/5/al_set_target_bitmap
https://www.allegro.cc/manual/5/al_s...get_backbuffer
https://www.allegro.cc/manual/5/al_draw_scaled_bitmap
https://www.allegro.cc/manual/5/al_flip_display

Pour la syncronisation verticale, al_flip_display va l'attendre si l'option ALLEGRO_VSYNC a été mise à 1 avant la création de la fenêtre.

J'imagine qu'il faille faire deux threads dans sa mainloop : un pour ce qui est du cycle de jeu, l'autre pour l'affichage et la capture des évenements (en fait, l'un associé à la fenêtre, et l'autre au programme en lui même). Allegro permet nativement l'utilisation de threads et de mutex.

Je t'avouerais que je n'ai pas encore compris comment faire en sorte que la synchronisation verticale n'influe pas sur la fluidité de l'affichage...

[c.aug]

Merci de me mettre sur la piste yetimothee.. mais pas évident de savoir s'il y'a une optimisation pbo derrière ces fonctions.

En fait, afficher un rendu cpu avec stretch et vsync dans une texture, c'est facile à faire avec gl/dx tant que tu utilises une texture dynamique avec une mise à jour bête, qui bloque le cpu en while() en attendant que le gpu ait fini de copier les pixels.

Chez moi ça bloque environ 4% du cpu 2*3ghz pour rendre un buffer video de 800*600, sur mon PC c'est pas bien grave, sur un smartphone avec un cpu de 300 mhz par contre là ça posera problème.

Dans la source montrée par PilloBuenaGente, ils expliquent comment faire ça en remplaçant le bête tableau d'int des pixels par un pixelBufferObject, qui permet de zapper cette consomation inutile de cpu avec du double buffering. Ce "pbo" c'est un objet qui embed le bête tableau de byte dans lequel tu écris tes pixels, et qui va le synchroniser élegemment avec le gpu en zappant le temps d'attente gaspilleur de cpu.

C'est donc l'équivalent précis de cette optimisation là que je cherche dans allegro, sfml, mais galère... (j'ai également échoué à trouver l'équivalent dans directx, je me suis découragé après avoir passé des plombes à tester leur cinquante mille manières de ranger les pixels en ram)

Opengl a le mérite d'être clair et lisible à ce niveau de la pipeline donc finalement je me demande si effectivement la manière la plus facile de gérer mon affichage, ça serait pas de rester bêtement sur opengl au lieu d'utiliser .1% des capacités d'une libraire intermédiaire.

(donc c'est le monsieur qui m'a dit d'utiliser opengl qui aurait raison et qui sort vainqueur du débat)