1. #1
    Membre habitué

    Profil pro
    Inscrit en
    avril 2004
    Messages
    421
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : avril 2004
    Messages : 421
    Points : 186
    Points
    186

    Par défaut definition d'un moteur graphique

    bonjour,

    voila, je me posais la question suivante, qu'est ce qu'un moteur graphique,
    je veux dire que dois faire un moteur 2D (on va commencer par la)

    quelle est le but premier d'un moteur, ou commence le moteur et ou s'rrette il?? etc..etc..

    merci

    a++

  2. #2
    Rédacteur
    Avatar de Laurent Gomila
    Profil pro
    Développeur informatique
    Inscrit en
    avril 2003
    Messages
    10 651
    Détails du profil
    Informations personnelles :
    Âge : 33
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2003
    Messages : 10 651
    Points : 16 452
    Points
    16 452

    Par défaut

    Tout ça est très subjectif, on pourra fournir un moteur qui propose des fonctionnalités bas niveau, tout comme on pourra faire quelque chose de très haut niveau mais qui laissera moins de flexibilité à l'utilisateur. Idéalement, prévoir les 2 n'est pas une mauvaise idée. Après il faut voir quelle est la finalité du moteur : être distribué en tant que tel, ou être utilisé par une appli bien spécifique ?

    Sinon pour essayer de te donner des éléments : un moteur graphique doit bien sur encapsuler l'API sur laquelle il repose, fournir des fonction d'affichage plus évoluées, gérer automatiquement la "scène" (pour un moteur 3D : culling, partitionnement de l'espace, collisions, ...) de manière à ce que le rendu soit optimisé et que l'utilisateur soit déchargé de cette gestion.

    Après il peut aussi fournir divers outils plus ou moins en rapport avec les applications qui vont utiliser le moteur : outils de debugging, de gestion de fichiers, de l'input, de l'audio, (là on sort du moteur graphique, mais il est courant que ce genre d'outils soient inclus). Tu peux aussi fournir des éditeurs de niveaux, des plugins pour importer/exporter des modèles 3D, ... Tout dépend de la finalité du moteur.

  3. #3
    Membre à l'essai
    Inscrit en
    janvier 2005
    Messages
    17
    Détails du profil
    Informations forums :
    Inscription : janvier 2005
    Messages : 17
    Points : 20
    Points
    20

    Par défaut

    moi je te dirais qu'un moteur 2D , bas niveau (on commence par simple) sait faire ceci :

    - il a 1 type spécifique : la Surface :
    la surface est un bitmap, donc une matrice de pixels.
    - il gere le double buffering, c'est a dire que pendant qu'une image est affichée sur l'écran, on travaille sur l'autre.
    une commande FLIP() pour intervertir les 2 images
    - et surtout : une fonction BLIT() qui copie une image, ou un bout d'image, sur une autre (copier/coller)
    - il gere une couleur transparente : c'est a dire que quand tu dessines un gars, il s'incrit dans un rectangle (sa surface), mais autour de lui, tu définis une "couleur de fond" qui ne sera pas affichée au blitting.

    A partir d'uniquement cela, tu reprogrammes tous les jeux NES et SuperNES...

  4. #4
    Membre du Club
    Inscrit en
    juin 2002
    Messages
    37
    Détails du profil
    Informations forums :
    Inscription : juin 2002
    Messages : 37
    Points : 42
    Points
    42

    Par défaut

    Pour moi, un moteur 2D, c'est un ensemble de routines et de types de données. Elles fournissent un espace de travail (une bitmap, un tableau, ... bref un gros tas d'octets représentant une image) et des primitives graphiques facilitant le dessin sur cet espace. Ainsi lorsqu'un programmeur veut dessiner un cercle, il n'a pas besoin de connaitre la formule et d'allumer un à un les pixels : il lui suffit de faire appel au moteur 2D avec quelque chose du style "DrawCircle(10 , 10, 5)".

    Après le moteur peut être plus ou moins évolué : il peut fournir des fonctions de bases (lignes, cercle, affichage de texte), des fonctions plus complexes (dégradé de couleurs), optimiser l'affichage (anti-crénelage, transparence), optimiser la rapidité, ...
    Windows XP - Delphi 7
    Nous ne controlons une chose que si nous sommes capables de la détruire à tout moment. [Frank Herbert - Dune]

  5. #5
    Membre régulier
    Profil pro
    Inscrit en
    juin 2004
    Messages
    195
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2004
    Messages : 195
    Points : 82
    Points
    82

    Par défaut RE: moteur 2D

    Salut elekis!! 8)

    On va pas faire de blabla car un moteur de jeu est assez "long" à coder (cela dépend de ce que tu envisages de faire);
    Je te propose de te passer un de mes moteurs de jeu "BASIC" (pas le langage de prog. !!) mais qui peut très bien servir de modèle pour n'importe quel jeu 2D et qui est assez évolutif !!
    Tu peux très bien y intégrer des fonctionnalités graphiques comme un moteur de sprite, .... C'est toi qui vois ....

    Recontacte moi si tu désire de plus amples infos .... BYE. 8)

  6. #6
    Membre habitué

    Profil pro
    Inscrit en
    avril 2004
    Messages
    421
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : avril 2004
    Messages : 421
    Points : 186
    Points
    186

    Par défaut

    grand merci pour tout,

    cyber je t'ai envoi un mp. merci.

    j'ai jsute une petite question encore,

    sachant que c'est un bete moteur deux d ( j'essaie d'apprendre avec sdl) et que ca doit pas revolutionner le monde,

    en combien je dois tavailler , 16 24 ou 32 bits?? pour les pixels???

    bon je me doute que si c'est un moteur 3d c'est 32 bits, mais pour un 2 d classic dois je laisser en 32???

    merci

    a++

  7. #7
    Membre habitué
    Profil pro
    Inscrit en
    septembre 2003
    Messages
    133
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2003
    Messages : 133
    Points : 161
    Points
    161

    Par défaut

    Ca dépend du mode graphique utilisé.

    En mode VGA (obsolète), les pixels sont codé sur 8 bits, et la couleur est en fait un index vers une palette (stockée dans la carte graphique), où chaque composante (Red/Green/Blue) est elle même codée sur 6 bits (64 valeurs). On ne pouvait donc afficher que 256 couleurs simultanément à l'écran, mais ces 256 était paramétrable dans un ensemble qui en comportait 262144.

    En mode TrueColor, c'est différent. Chaque composante est codée sur 8bits, et il n'y a pas de palette. Chaque pixel est donc codé par 24 bits, mais alignés sur 32, pour des problème d'optimisation de l'utilisation du bus lors des transferts carte <=> processeur.
    Les 8 bits d'intervales sont parfois utilisé pour un "seuil alpha", je ne sais pas si la carte sais interpréter ce truc (que je connais très peu).
    Et dans ce mode, pas de palette, les valeurs 24/32 bits de chaque pixel permettent directement de représenter les couleurs à l'écran.

    Je n'ai jamais été confronté à la technique HiColor (16 bits) mais j'imagine que le principe est le même que TrueColor, avec des composantes sur 5 bits (plus 1 bit de garbage).

    Le plus sipmle, vu l'état des technos actuelle, est d'utiliser directement TrueColor.
    Gaïa n'est pas une marchandise.

  8. #8
    Rédacteur
    Avatar de Laurent Gomila
    Profil pro
    Développeur informatique
    Inscrit en
    avril 2003
    Messages
    10 651
    Détails du profil
    Informations personnelles :
    Âge : 33
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2003
    Messages : 10 651
    Points : 16 452
    Points
    16 452

    Par défaut

    Ca ce sont des détails dont tu ne devrais pas te soucier en phase de conception. Tu devrais tout d'abord te concentrer sur le design de tes classes, les fonctionnalités du moteur, etc... Ensuite ce genre de considération technique sera résolue naturellement.

    Le mieux est sans doute de laisser le choix de la résolution à l'utilisateur non ?
    Sinon autre option : tu fixes des réglages par défaut optimisés selon la config de l'utilisateur et les possibilités de l'API sous-jacente (SDL dans ton cas).


    PS : le problème reste le même pour un moteur 3D, pourquoi 32 bits forcément ?

  9. #9
    Membre à l'essai
    Inscrit en
    janvier 2005
    Messages
    17
    Détails du profil
    Informations forums :
    Inscription : janvier 2005
    Messages : 17
    Points : 20
    Points
    20

    Par défaut

    SKZ81 >
    ton explication sur les bits/pixels est bonne.
    Je tiens cependant a rectifier qq chose sur le mode 16 bits :
    tu dis 3*5 + 1 bit de garbage.
    Ce n'est pas existe :
    on code le rouge et le bleu sous 5 bits, mais le vert sous 6 bits
    Pkoi le vert ? --> On a démontré que l'oeil humain distingue mieux les nuances de vert

    elekis >
    tu dis que 32 bits pour la 3D et moins pour la 2D :
    le nombres de bits par pixels n'a rien a voir avec le nombre de bits caractéristique de la puissance d'une console

    Ce que je veux dire par la, c'est qeu tu peux avoir des jeux 2D sous 32 bits par pixels, et des jeux 3D a 8bits par pixels avec effet dithering.

    Autre précision sur le couleurs :
    le mode 24 bits se comprend aisément :
    1 octet par couleur : 8*3
    le mode 32 bits se comprends moins facilement :
    on a créé le mode 32 bits pour pouvior sauter d'un pixel a l'autre en ajoutant 4, et non 3, ce qui est plus propre en ce qui concerne l'alignement mémoire. Les 8 bits en trop, plutot que de les gacher, ont été attribué a ce qu'on appelle un canal Alpha : une donnée qui sert a gérer la transparence...

    Dernier précision :
    Il est fort peu probable que l'avenir augmente cette précision, donc qu'on aie + de 32 bits/ pixels :
    en effet, si on oublie le canal alpha, on a 8 bits par couleur, donc 256 nuances pour chance composante (rouge,vert, bleu)
    L'oeil humain "standard" est capable d'en différencier une centaine a peine : il y a donc + de nuances affichables que ce que l'on peut voir.
    Si par exemple je mets du rouge a 254 et du rouge a 255 a coté, seuls les meilleurs yeux du monde sauront différencier, et encore !!
    donc etre plus précis et faire un 255.5 (si j'ose dire) serait ridicule...
    Donc a mon avis, pour le rendu, 32 bits ne sera jamais augmenté.
    (PS : ceci n'est pas vrai pour l'imagerie médicale, et les scanners médicaux de précision, en effet, avoir bcp de nuances permet, a un programme (et non pas a l'oeil nu) de détecter des débuts de cancer)

  10. #10
    Membre du Club

    Homme Profil pro
    Étudiant
    Inscrit en
    janvier 2012
    Messages
    35
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : janvier 2012
    Messages : 35
    Points : 45
    Points
    45
    Billets dans le blog
    1

    Par défaut Pixel

    Bonjour ,
    Je viens au niveau de ce topic du faite que l'on a pas coché résolu.
    Je voudrais puisqu'il s'agit d'une discussion tournant autour des moteurs ,2d de concetpion de jeux.Posez de petites questions:
    Je voudrais savoir qu'est ce qu'un pixel au niveau des surfaces pour sdl?
    Je n 'arrive pas à donner une vision claire à cette abstraction.
    Ensuite quelqu'un voudrais bien m'expliqué ce code, pourquoi l'on multiplie i*Taille_bloc avant le collage.
    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
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    objectifsRestants = 0;
    for (i = 0 ; i < NB_BLOCS_LARGEUR ; i++)
    {
    for (j = 0 ; j < NB_BLOCS_HAUTEUR ; j++)
    {
    position.x = i * TAILLE_BLOC;//comprend pas pourquoi?
    position.y = j * TAILLE_BLOC;
    switch(carte[i][j])
    {
    case MUR:
    SDL_BlitSurface(mur, NULL, ecran, &position);
    break;
    case CAISSE:
    SDL_BlitSurface(caisse, NULL, ecran, &position);
    break;
    case CAISSE_OK:
    SDL_BlitSurface(caisseOK, NULL, ecran, &position);
    break;
    case OBJECTIF:
    SDL_BlitSurface(objectif, NULL, ecran, &position);
    objectifsRestants = 1;
    break;
    }
    }
    }

    Bon j attend vos réponses merci.

Discussions similaires

  1. [Singleton] Moteur graphique : Singleton est-il un bon pattern ?
    Par Takusen dans le forum Design Patterns
    Réponses: 3
    Dernier message: 16/09/2008, 11h40
  2. Demande d'éclaircissements : modèles et moteur graphique
    Par Menontona dans le forum Développement 2D, 3D et Jeux
    Réponses: 6
    Dernier message: 10/09/2008, 11h10
  3. Important: Conception d'un moteur graphique
    Par LightniN dans le forum Développement 2D, 3D et Jeux
    Réponses: 1
    Dernier message: 18/11/2007, 14h26
  4. Créer un moteur graphique commercial
    Par taftouf dans le forum Moteurs 3D
    Réponses: 11
    Dernier message: 26/02/2007, 10h17
  5. entiers ou réels pour un moteur graphique?
    Par f56bre dans le forum Moteurs 3D
    Réponses: 2
    Dernier message: 22/10/2006, 18h25

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