Une question qui me traverse l’esprit mais est-elle pertinente…
Dans un jeu (2D ici), on distingue d'une part le décor, d'autre part les éléments animés (personnages, monstres, etc...)
Dans sa grande majorité, le décor est inerte (pas d’animation, pas d’action, rien qu’un jolie dessin) sauf à des endroits spécifiques qui peuvent être traités comme des éléments animés (portes, piège, etc…)
Ma question est la suivant : Quelle est la méthode la plus performante pour afficher le décor inerte d’un jeu ? (ou plus généralement, afficher une image sur un écran)
Souvent (voir tjrs), comme pour les éléments animés, on utilise les Sprites, mais n’y a-t-il pas plus rapide si je souhaite seulement afficher une simple image? (pas de transparence ni de détection de collision, etc…)
En gros la structure sprite n’est-elle pas trop lourde pour afficher un décor inerte dans un jeu ? Peut-on espérer plus performant ?
Afficher une simple image sur un écran
-
lionel_om
- Messages : 1500
- Inscription : jeu. 25/mars/2004 11:23
- Localisation : Sophia Antipolis (Nice)
- Contact :
L'avantage des sprites, c'est le GrabSprite() (de mémoire).
Par contre pour une simple décor, avec juste un scolling, pas de transparence, etc -> Images à privilégier.
Mais le problème des images c'est qu'il faut une image pour chaque niveau et donc que chaque est répété. Donc pour le jeu ca sera plus rapide avec les images, (faire bien attention à LaodImage() FreeImage()), mais le fichier exe sera plus important (ou la taille des média sera plus importante).
ET ca fait moins pro...
Par contre pour une simple décor, avec juste un scolling, pas de transparence, etc -> Images à privilégier.
Mais le problème des images c'est qu'il faut une image pour chaque niveau et donc que chaque est répété. Donc pour le jeu ca sera plus rapide avec les images, (faire bien attention à LaodImage() FreeImage()), mais le fichier exe sera plus important (ou la taille des média sera plus importante).
ET ca fait moins pro...
Webmestre de Basic-univers
Participez à son extension: ajouter vos programmes et partagez vos codes !
Participez à son extension: ajouter vos programmes et partagez vos codes !
je ne pense pas qu'en pureBasic cela fasse une difference (image ou sprite)la structure sprite n’est-elle pas trop lourde pour afficher un décor inerte dans un jeu
car les sprite pureBasic ne sont pas des sprites traditionels (comme dans les autres basic) , les sprites purebasic sont des images ! rien de plus !
d'ailleurs tu peut facilement faire un pseudo sprite en utilisant une petite image a la place ! et gerer les collisions par proximité des coordonées. .
les "Vrais" sprites sont des OBJETs , je veux dire par la, qu'il ont un numero qui les differencies, une identité propre, il ne peut y en avoir qu'un a l'ecran, ses coordonées, son existence, ect.. sont gardée dans une table interne au language ....
Ce qui fait qu'un vrais sprite ne peut pas apparaitre a deux endrois different , sauf si l'on a cloné ce sprite avec une fonction du style "copysprite"
et bien sur la copie a un numero different, bref les Vrais sprite sont des entités (objets) a part entiere ...
les sprite pure basic , ce ne sont que des petites (ou pas) images
qui peuvent etre employées a l'infini, c'est un avantage dans un certain sens, puisque peut etre, plus maleable, vu que l'on peut utiliser un sprite ,en lieu et place d'une image, et l'afficher plusieurs fois sans autres protocoles,
mais tres perturbant lorsqu'on vient d'un autre langage (Dark basic, Stos ect...) qui traite "d'objet sprite", au lieu "d'image sprite" !
les collisions sont moins parlante en PureBasic
c'est pourquoi je trouve tres pratique les "objet sprite" car on peut avoir
une fonction sprite collision() qui te renvois qui a heuté qui !
(je sais que c'est faisable en Pure , mais pas d'origine
)ce qui m'amene a dire que en interne , je pense pas qu'il y ait une grosse difference d'utiliser les images ou bien les sprites !
d'ailleurs la question serai : n'y a t'il pas double emploi entre les image et les sprites en Purebasic ?
perso je priviligie les Sprites !!
je suis d'accord avec cederavic
j'ajouterai que pour afficher des image il faut passer par startdrawing() qui ralenti aussi!
Les sprites et l'écran utilisent le même format de pixel et le même style de buffer. Les échanges de données sont lus rapides... Et pas de startdrawing() pour dessiner un sprite dans un sprite où à l'écran
Dri
j'ajouterai que pour afficher des image il faut passer par startdrawing() qui ralenti aussi!
Les sprites et l'écran utilisent le même format de pixel et le même style de buffer. Les échanges de données sont lus rapides... Et pas de startdrawing() pour dessiner un sprite dans un sprite où à l'écran
Dri
Image = GDI
Sprite = DirectX
Je me trompe Fred?
Si je ne me trompe pas, comme je l'ai dis, les sprites utilise l'accélération matériel. La difference entre les 2, pour un simple ImageGadget tu n'a pas besoin d'initialiser l'usine a gaz DirectX pour afficher une image dans une fenetre.
Je ne pense pas qu'il y ai double emploie car les "Images" serait plutot destinées a etre utiliser dans une fenetre (pas un Screen (arf.. c'est dur dur le melange de termes français-anglais lol)) et les Sprite dans un Screen.
Bon je sais pas si j'ai été clair... lol désolé
Sprite = DirectX
Je me trompe Fred?
Si je ne me trompe pas, comme je l'ai dis, les sprites utilise l'accélération matériel. La difference entre les 2, pour un simple ImageGadget tu n'a pas besoin d'initialiser l'usine a gaz DirectX pour afficher une image dans une fenetre.
Je ne pense pas qu'il y ai double emploie car les "Images" serait plutot destinées a etre utiliser dans une fenetre (pas un Screen (arf.. c'est dur dur le melange de termes français-anglais lol)) et les Sprite dans un Screen.
Bon je sais pas si j'ai été clair... lol désolé
Exactement, les images ne sont pas destinées a etre affichées a une vitesse elevée, donc elle peuvent etre plus grosse et dans n'importe quel format (alors qu'un sprite est forcement dans le format actuel de l'ecran, optimisé pour la carte graphique qui va l'afficher). Un sprite a besoin d'un ecran (DirectX) pour exister alors qu'une image non.
