PureBasic

Juste une petite question, comment cela se passe au niveau collision ? cela marche pareil que les sprites classiques ? car j'ai pas vu de fonctions particulières.


Autre chose lors de l'utilisation de Sprite3D à priori InitEngine3D() n'est pas obligatoire, cela dit est ce que c'est mieux de le mettre ? ou c'est complètement inutile ?

merci d'avance.

Je pose une colle ou une question crétine ?

Juste une petite question, comment cela se passe au niveau collision ? cela marche pareil que les sprites classiques ? car j'ai pas vu de fonctions particulières.


Autre chose lors de l'utilisation de Sprite3D à priori InitEngine3D() n'est pas obligatoire, cela dit est ce que c'est mieux de le mettre ? ou c'est complètement inutile ?

merci d'avance.

1) Oui, mais perso, j'utilise mes propres fonctions
2) InitEngine3D() c'est pour ogre, pas pour les sprite, donc c'est inutile.

je me doutais aussi pour initengine3D mais bon comme les sprites3D utilise l'accélération matérielle....Je pensais que....

tout la malentendu viens du nom employé !!

Fred aurai du appeler les Sprite3D() les "Bob()"

en reference aux Amiga qui utilisaient le hardware pour un certain type de sprites et qui s'apelaient "Bob" en reference a "blitter objects"

bien sur les Sprite Soft, s'appelaient Sprite

Dobro a écrit :tout la malentendu viens du nom employé !!

Fred aurai du appeler les Sprite3D() les "Bob()"

en reference aux Amiga qui utilisaient le hardware pour un certain type de sprites et qui s'apelaient "Bob" en reference a "blitter objects"

bien sur les Sprite Soft, s'appelaient Sprite

A oui c'est vrai.....j'avais oublié ça .... ça me rappelle l'Amos ... Merci Dobro de m'avoir reveillé tout ces souvenir enfouit

il y a toujours la fastidieuse solution de tester les coordonnés X et Y. Certes c'est très long à mettre au point, mais pour un jeu en 2D cela est acceptable ( certes tout dépend du type de jeu, mais pour un jeu de tir ou plate-forme, ça marche bien. Mais avec la puissance actuelle des machines, Fred est sûrement vivement sollicité à ce sujet).


http://www.purebasic.fr/german/viewtopic.php?t=9093

Pour mettre essayé il y a fort longtemps de cela, à l'assembleur sur Amiga, et m'y être cassé les dents ( n'est pas Andrew Braybrook qui veut) cette machine gère 4 sprites "cablé en hard", sprites dont il était possible de diviser pour en avoir davantage (mais avec moins de couleur pour chaque).

Mais avec déjà 1Mo, un amiga 500 + 512 ko ou amiga500+, l'utilisation de bob était déjà courante, les sprites était seulement utilisé pour les petits objets rapide comme les tirs d'un vaisseau par exemple.

Sur du matos sortis depuis 2005/6, à partir de la génération geforce6/7, nous pouvons être heureux car nous n'avons plus aucune contrainte technique dans l'utilisation de "sprite3D" de pb.

beauregard a écrit :il y a toujours la fastidieuse solution de tester les coordonnés X et Y. Certes c'est très long à mettre au point, mais pour un jeu en 2D cela est acceptable ( certes tout dépend du type de jeu, mais pour un jeu de tir ou plate-forme, ça marche bien. Mais avec la puissance actuelle des machines, Fred est sûrement vivement sollicité à ce sujet).


http://www.purebasic.fr/german/viewtopic.php?t=9093

Pour mettre essayé il y a fort longtemps de cela, à l'assembleur sur Amiga, et m'y être cassé les dents ( n'est pas Andrew Braybrook qui veut) cette machine gère 4 sprites "cablé en hard", sprites dont il était possible de diviser pour en avoir davantage (mais avec moins de couleur pour chaque).

Mais avec déjà 1Mo, un amiga 500 + 512 ko ou amiga500+, l'utilisation de bob était déjà courante, les sprites était seulement utilisé pour les petits objets rapide comme les tirs d'un vaisseau par exemple.

Sur du matos sortis depuis 2005/6, à partir de la génération geforce6/7, nous pouvons être heureux car nous n'avons plus aucune contrainte technique dans l'utilisation de "sprite3D" de pb.

Juste pour rectifier les petites erreurs sur l'amiga. Pour les amigas "originaux" (500,1000,2000,3000), copié/collé de wikipedia :
# 8 sprites matériels (utilisés pour le pointeur de souris par exemple) d'une largeur de 16 pixels et d'une hauteur variable avec 3 couleurs (plus une quatrième « couleur » pour le masque de transparence). Deux sprites peuvent être joints pour faire un sprite unique de 15 couleurs.

* bien que ce ne soit pas une caractéristique officielle, le Copper peut être utilisé pour changer les registres de sprite (entre autres) au milieu d'une ligne de balayage. Ce qui permet d'afficher plus de sprites par ligne. Une astuce qui a été employée par certains jeux comme Battle Squadron.
* il est possible de simuler une largeur de sprite variable en plaçant des sprites de 16 pixels de larges côte à côte. Et ceci jusqu'au maximum de 128 pixels de large pour des sprites de 3 couleurs, et de 64 pixels de large pour des sprites de 15 couleurs. Cependant, plus large est ce pseudo-sprite, moins il est possible d'afficher de sprites sur une ligne de balayage.



En ce qui concerne les sprites3d, bien qu'il soit possible d'en afficher vraiment beaucoup, la résolution et le nombre de couleurs sont encore un facteur limitatif, même sur des cartes récentes. Et ça ne s'améliore pas avec l'utilisation des couches alpha.

djes a écrit : En ce qui concerne les sprites3d, bien qu'il soit possible d'en afficher vraiment beaucoup

C'était aussi le cas avec des sprites classiques, mais l'avantage avec les sprite3D, c'est que tu peux aisément gérer la transparence sans chute nombre i/s.

djes a écrit : la résolution et le nombre de couleurs sont encore un facteur limitatif, même sur des cartes récentes.

j'utilise le 1024*768 et même le 1440*900, en 16bit ou en 32bit peut importe ! puisque c'est aussi fluide avec l'un comme avec l'autre... alors autant rester en 32 bit (alors qu'avec des sprites classiques, ce n'est pas la même musique).

Mais le 1024*768 est une résolution largement suffisante pour un jeu 2D, et bien pratique rapport à l'utilisation de tiles, puisque comme tu le sais divisible par 64 ou 32...( utile pour l'utilisation de tiles bien carré, mais là je t'apprend rien).

Quant à la taille des sprite3D, je ne vois pas trop ce qui t'ennui, car pour beaucoup de jeux, les objets "carré" permettent une gestion aisé des collisions, sans faire appel à des fonctions inutilement gourmande en ressource...

Je met la touche finale au premier jeu en pb (titre: ghost21), et là tu pourras étudier le code.

djes a écrit : Et ça ne s'améliore pas avec l'utilisation des couches alpha.

heu... là, je ne sais pas.


Mais ma conclusion du moment, c'est qu'on peut tout faire, uniquement avec des sprites 3D ! C'est trop beau !

Pour ma part je n'utilise les sprite3D uniquement si un sprite a besoin de certaines spécificité (alpha, light, rotation, zoom....) sinon j'utilise de la 2D.

Crystal Noir a écrit :Pour ma part je n'utilise les sprite3D uniquement si un sprite a besoin de certaines spécificité (alpha, light, rotation, zoom....) sinon j'utilise de la 2D.

C'est ce que je me disais jusqu'à maintenant, mais je commence à croire qu'il n'y a pas réellement d'intéret aux sprites, par rapport aux mal-nommés sprites3D.

Je n'en suis pas si certains, avec de l'alpha afficher plus de 300 sprites3D et ca rame grave

J'ai fait le test avec mes feux d'artifices.

Dans une boucle à chaque pet je créé 300 sprites3D

donc 300 particules flare. En Sprite3D ils sont redimensionnés (pour que ce soit plus petit), ont une transparence et changent de couleurs.

La boucle a une variable tempo = 20 à laquelle j'enlève 1 à chaque tour, quand c'est à 0, il créé mes 300 particules.

La variable tempo est petite pour permettre de faire un "final de feu d'artifice" donc le feu n'a pas fini de péter qu'un autre pète derrière.

Ce qui fait afficher plus de 300 particules à l'écran. avec des sprites3D ca se met à ramer au bout de 5 secondes

Avec des sprites2d simples déjà redimensionné (donc image de bonne taille), c'est très rapide....et ca rame pas.

D'ailleurs on peut lire dans la doc :

Les sprites 3D sont proposés pour réaliser facilement des effets hors du commun, mais il ne faut pas oublier qu'ils sont moins rapides que les sprites classiques et plus restrictifs en termes de taille par exemple.

Ceci étant effectivement je n'ai aucun effet alpha avec les sprites2D, et si on prend le meme principe en appliquant DisplayTransculentSprite ca va ramer encore plus que si c'était tout du 3D.

Mais dans le cas d'un jeu, les psrites qui ont besoin d'effets particuliers, oui mais les autres autant éconoiser les ressources et les traiter en simple sprite.

comme il est possible d'utiliser les 2 méthodes d'affichages, c'est plus un problème de bien choisir en fonction de l'objectif à atteindre, qu'un choix technique.

Car avec les cartes graphique/vidéo/3D de ces dernières années, nous sommes désormais confrontés à un choix, mais avant il n'y avait pas le choix, donc c'est mieux maintenant, non ?

D'un autre côté, si vous développez un grand logiciel depuis des lustres, et que vous êtes entrain de le terminer, et là, paf, sprite3D, milliard ! C'est une remise en question qui doit vachement vous emmer... embêter. Et je compatis car c'est mon cas avec un autre basic tout pourris ( notez la rime).

et c'est lequel l'autre basic tout pourris ?