Discussion :

[elekis]

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

[Laurent Gomila]

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.

[FVIRTMAN]

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

[Paul Atreide]

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

[cyber_N]

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)

[elekis]

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

[SKZ81]

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.

[Laurent Gomila]

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 ?

[FVIRTMAN]

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)

[aristide2012]

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.