Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Inactif  

    Homme Profil pro
    Développeur multimédia
    Inscrit en
    mars 2013
    Messages
    162
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur multimédia

    Informations forums :
    Inscription : mars 2013
    Messages : 162
    Points : 193
    Points
    193

    Par défaut Accès simple aux buffers pixel

    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.

  2. #2
    Expert éminent
    Avatar de Kannagi
    Homme Profil pro
    cyber-paléontologue
    Inscrit en
    mai 2010
    Messages
    2 647
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : cyber-paléontologue

    Informations forums :
    Inscription : mai 2010
    Messages : 2 647
    Points : 8 112
    Points
    8 112

    Par défaut

    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

  3. #3
    Inactif  

    Homme Profil pro
    Développeur multimédia
    Inscrit en
    mars 2013
    Messages
    162
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur multimédia

    Informations forums :
    Inscription : mars 2013
    Messages : 162
    Points : 193
    Points
    193

    Par défaut

    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

  4. #4
    Expert éminent
    Avatar de Kannagi
    Homme Profil pro
    cyber-paléontologue
    Inscrit en
    mai 2010
    Messages
    2 647
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : cyber-paléontologue

    Informations forums :
    Inscription : mai 2010
    Messages : 2 647
    Points : 8 112
    Points
    8 112

    Par défaut

    Citation Envoyé par c.aug Voir le message
    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

  5. #5
    Inactif  

    Homme Profil pro
    Développeur multimédia
    Inscrit en
    mars 2013
    Messages
    162
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur multimédia

    Informations forums :
    Inscription : mars 2013
    Messages : 162
    Points : 193
    Points
    193

    Par défaut

    Citation Envoyé par Kannagi Voir le message
    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

  6. #6
    Membre éclairé

    Homme Profil pro
    Non disponible
    Inscrit en
    décembre 2012
    Messages
    478
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Non disponible

    Informations forums :
    Inscription : décembre 2012
    Messages : 478
    Points : 876
    Points
    876
    Billets dans le blog
    1

    Par défaut

    Bonsoir,

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

  7. #7
    Inactif  

    Homme Profil pro
    Développeur multimédia
    Inscrit en
    mars 2013
    Messages
    162
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur multimédia

    Informations forums :
    Inscription : mars 2013
    Messages : 162
    Points : 193
    Points
    193

    Par défaut

    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.

  8. #8
    Responsable 2D/3D/Jeux


    Avatar de LittleWhite
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mai 2008
    Messages
    24 382
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : mai 2008
    Messages : 24 382
    Points : 178 909
    Points
    178 909
    Billets dans le blog
    49

    Par défaut

    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.
    Vous souhaitez participer à la rubrique 2D/3D/Jeux ? Contactez-moi

    Ma page sur DVP
    Mon Portfolio

    Qui connaît l'erreur, connaît la solution.

  9. #9
    Inactif  

    Homme Profil pro
    Développeur multimédia
    Inscrit en
    mars 2013
    Messages
    162
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur multimédia

    Informations forums :
    Inscription : mars 2013
    Messages : 162
    Points : 193
    Points
    193

    Par défaut

    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.

  10. #10
    Membre averti Avatar de yetimothee
    Homme Profil pro
    Étudiant
    Inscrit en
    mai 2007
    Messages
    257
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : mai 2007
    Messages : 257
    Points : 382
    Points
    382

    Par défaut

    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...

  11. #11
    Inactif  

    Homme Profil pro
    Développeur multimédia
    Inscrit en
    mars 2013
    Messages
    162
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur multimédia

    Informations forums :
    Inscription : mars 2013
    Messages : 162
    Points : 193
    Points
    193

    Par défaut

    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)

Discussions similaires

  1. Accès rapide aux pixels en Python
    Par avironman dans le forum OpenCV
    Réponses: 4
    Dernier message: 26/08/2008, 17h03
  2. Réponses: 18
    Dernier message: 13/04/2007, 12h48
  3. [TOMCAT] Comment empêcher l'accès direct aux fichiers
    Par thomine dans le forum Tomcat et TomEE
    Réponses: 17
    Dernier message: 14/04/2005, 10h19
  4. [VB.NET] Accès concurrentiel aux fichiers
    Par david71 dans le forum Windows Forms
    Réponses: 6
    Dernier message: 13/12/2004, 11h19
  5. Accés rapide aux propriétés d'un Objet
    Par Alacazam dans le forum C++Builder
    Réponses: 4
    Dernier message: 28/11/2002, 21h56

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo