Question pointue :
Dans la doc, il est écrit qu’avec la commande ClipSprite() « Le #Sprite [ainsi créée] se comporte alors exactement comme un nouveau sprite »
S’il est clair que le sprite clippé se manipule et se comporte comme un nouveau sprite,
le terme « exactement » veut-il dire que le sprite clippé est aussi performant en rapidité d’affichage qu’un sprite ayant directement la meme taille (que le sprite clippé) ?
Performance des sprites clippés
a propos des sprites :
j'ai remarqué que lors d'une rotation d'un sprite3D (ou d'un ZOOM)
le sprite obtenu apres rotation, ne fonctionne plus avec les fonction de collision !!
en fait, il ne fonctionne pas avec les nouveaux atribus de l'image du sprite !
tout se passe comme si le sprite n'avais pas subit de transformation !
comme si , qu'il n'y avait QUE l'image du sprite qui avait été transformé
pas le sprite (la cellule ) lui-meme !!
c'est tres embetant surtout avec le ZOOM car on zoom un sprite 8x8
pour en faire un sprite 128x128 et la collision aura lieu , avec la cellule 8x8 , malgres que l'image fasse 128x128 !!
m'expliqu'ai-je bien ?
un bon exemple vaut mieux qu'un grand discourt !:
j'ai remarqué que lors d'une rotation d'un sprite3D (ou d'un ZOOM)
le sprite obtenu apres rotation, ne fonctionne plus avec les fonction de collision !!
en fait, il ne fonctionne pas avec les nouveaux atribus de l'image du sprite !
tout se passe comme si le sprite n'avais pas subit de transformation !
comme si , qu'il n'y avait QUE l'image du sprite qui avait été transformé
pas le sprite (la cellule ) lui-meme !!
c'est tres embetant surtout avec le ZOOM car on zoom un sprite 8x8
pour en faire un sprite 128x128 et la collision aura lieu , avec la cellule 8x8 , malgres que l'image fasse 128x128 !!
m'expliqu'ai-je bien ?
un bon exemple vaut mieux qu'un grand discourt !:
Code : Tout sélectionner
; prg realisé par Dobro
#dobro=1
#Police=1
#sprite=1
Enumeration
#sprite_cible
#sprite_souris
#sprite_text
#sprite_cible3D
#sprite_souris3D
EndEnumeration
Structure sprite
x.w
y.w
EndStructure
Dim sprite.sprite(1)
Structure balle
x.w
y.w
EndStructure
Dim balle.balle(1)
Dim ecran(640,400)
For x = 0 To 640 ; un écran de couleurs aléatoires
For y = 0 To 400
r=Random(255)
g=Random(255)
b=Random(255)
c=RGB(r,g,b)
ecran(x,y)= c
Next y
Next x
; ***********************************
Resultat = InitSprite()
InitSprite3D()
FontID = LoadFont(#Police, "arial", 18, #PB_Font_Bold )
EcranX = GetSystemMetrics_(#SM_CXSCREEN):;=largeur de l'ecran
EcranY = GetSystemMetrics_(#SM_CYSCREEN):;=hauteur de l'ecran
WindowID = OpenWindow(1, 0, 0, 800, 600, #PB_Window_SystemMenu|#PB_Window_BorderLess |#PB_Window_ScreenCentered , "hello")
WindowID = WindowID(1)
Result = OpenWindowedScreen(WindowID,0,0, 800, 600, 1, 0,0)
CreateSprite( #sprite_cible, 64, 64,#PB_Sprite_Texture) ; sprite exemple
StartDrawing(SpriteOutput( #sprite_cible) ) ; on dessine dedans
Box(0, 0, 64, 64, RGB($FF,$0,$80))
StopDrawing()
CreateSprite3D(#sprite_cible3D,#sprite_cible)
CreateSprite( #sprite_souris, 32, 32,#PB_Sprite_Texture) ; sprite souris
StartDrawing(SpriteOutput( #sprite_souris) ) ; on dessine dedans
;Box(0, 0, 64, 64,RGB($13,$F8,$7))
Circle(16, 16, 16, RGB($13,$F8,$7))
StopDrawing()
CreateSprite3D(#sprite_souris3D,#sprite_souris)
CreateSprite(#sprite_text, 150,14) ; le text
StartDrawing(SpriteOutput(#sprite_text) ) ; on dessine dedans
DrawText(bord$)
StopDrawing()
balle(1)\x=WindowWidth()/2
Resultat = InitMouse()
Repeat
ExamineMouse()
Event=WindowEvent()
sprite(1)\x=WindowWidth()/2
sprite(1)\y=WindowHeight()/2
;- ACTIVER CECI POUR VOIR LE BLEM !!
; ZoomSprite3D(#sprite_cible3D,200, 200) ; ACTIVER CECI POUR VOIRE LE PROBLEMME !!
Start3D()
DisplaySprite3D(#sprite_cible3D, sprite(1)\x, sprite(1)\y, 127)
DisplaySprite3D(#sprite_souris3D, MouseX(), MouseY(), 127)
Stop3D()
DisplaySprite( #sprite_text, 10, 10)
If SpritePixelCollision(#sprite_cible, sprite(1)\x, sprite(1)\y, #sprite_souris, MouseX(), MouseY())<>0
bord$="touché !! "
Else
bord$=" "
EndIf
StartDrawing(SpriteOutput(#sprite_text) ) ; on dessine dedans
DrawingMode(0)
DrawText(bord$)
DrawText(" ")
StopDrawing()
If MouseButton(2)
End
EndIf
FlipBuffers():; affiche l'ecran
ClearScreen(0, 0, 0) :;efface l'ecran
Until Event=#PB_Event_CloseWindow
en fait ce n'est que le rendu qui est zoomé ou tourné...
le sprite en lui même ne change pas. Il faudrait des routines justement qui prennent en compte un rotozoom...
Une solution : créer un sprite qui contiendrait le rendu du sprite3D mais ca implique de trouver les dimensions du nouveau sprite et aussi de savoir quelles coordonnées lui donner. Un bon ptit challenge mathématique auquel je ne me risquerait pas ^^
Dri
le sprite en lui même ne change pas. Il faudrait des routines justement qui prennent en compte un rotozoom...
Une solution : créer un sprite qui contiendrait le rendu du sprite3D mais ca implique de trouver les dimensions du nouveau sprite et aussi de savoir quelles coordonnées lui donner. Un bon ptit challenge mathématique auquel je ne me risquerait pas ^^
Dri
Une solution : créer un sprite qui contiendrait le rendu du sprite3D mais ca implique de trouver les dimensions du nouveau sprite et aussi de savoir quelles coordonnées lui donner.
pas si compliqué que ça !! puisque avant le zoom on connais la taille du sprite !
il suffirai d"échanger les coordonée ancienne (avant le zoom) avec les nouvelles inscrite dans la fonction du zoom , pour que d'un coup toutes les fonctions de collision prennet en compte le nouveau "carré" (cellule) crée apres le zoom !
sprite 8x8
zoom (128x128)
a ce moment la nouvelle taille est transmise par le pure (en interne)
aux variables interne qui avait l'ancienne taille (ici:8x8)
bref un zoom transmetrai les nouvelles taille au sprite !! alors qu'actuellement la nouvelle taille n'est pas transmise ! ....
un simple transfere d'information entre des variables ne devrai pas poser de probleme a Fred !
ha d'accord !!
bien que le principe de la detection de collision par pixel est déja pas évident , je pense pas que ce soit une reel difficultée pour Fred en fait !
une fonction de collision dans le genre de celle que tu avait présenté , pourrai
resoudre le probleme ! en fait la collision en testant 2 "boite" comme c'est fait actuellement , ne me parait pas top !, rapide , mais pas top !
en fait une collision testant la proxité des pixels composant les sprites pourrai etre tres interressante ! , car a partir de ce moment , on ne test plus la "cellule " vide du sprite mais bien l'image, donc peu importe la position de celle-ci ou de sa taille , vu que le test aurai lieu QUE sur les pixels des 2 images des sprites testé !
cela pourrai d'ailleurs permetre l'utilisation de ce genre de fonction de collision pour les images , pas seulement pour des sprites !
je veut dire que si l'on dessine un fond a l'ecran la collision de sprite
pourrai detecté les pixels dessiné sur le fond de l'ecran (ce n'est pas le cas actuellement ! )
ce qui faciliterai la creation de jeux utilisant des images en décors au lieu de sprite ! ... du moins nous aurions le choix !
actuelement avec une collision qui ne test que des "cellule" (rectangle)
on ne peut envisager de simulation realiste comme du sable ou chaque grain serai un sprite qui s'ecoulerai dans un verre dont le fond serai rond !
ou irregulié ... je sais que c'est tordu, mais c'est un exemple ! ..
en bref les fonction de collision actuelle ne sont pas parfaite loin de la !
meme si c'est bien quand-meme !
bien que le principe de la detection de collision par pixel est déja pas évident , je pense pas que ce soit une reel difficultée pour Fred en fait !
une fonction de collision dans le genre de celle que tu avait présenté , pourrai
resoudre le probleme ! en fait la collision en testant 2 "boite" comme c'est fait actuellement , ne me parait pas top !, rapide , mais pas top !
en fait une collision testant la proxité des pixels composant les sprites pourrai etre tres interressante ! , car a partir de ce moment , on ne test plus la "cellule " vide du sprite mais bien l'image, donc peu importe la position de celle-ci ou de sa taille , vu que le test aurai lieu QUE sur les pixels des 2 images des sprites testé !
cela pourrai d'ailleurs permetre l'utilisation de ce genre de fonction de collision pour les images , pas seulement pour des sprites !
je veut dire que si l'on dessine un fond a l'ecran la collision de sprite
pourrai detecté les pixels dessiné sur le fond de l'ecran (ce n'est pas le cas actuellement ! )
ce qui faciliterai la creation de jeux utilisant des images en décors au lieu de sprite ! ... du moins nous aurions le choix !
actuelement avec une collision qui ne test que des "cellule" (rectangle)
on ne peut envisager de simulation realiste comme du sable ou chaque grain serai un sprite qui s'ecoulerai dans un verre dont le fond serai rond !
ou irregulié ... je sais que c'est tordu, mais c'est un exemple ! ..
en bref les fonction de collision actuelle ne sont pas parfaite loin de la !
meme si c'est bien quand-meme !
Pour ce dont tu parles, il y a bien plus souvent un "module" qui gère les collisions indépendemment des graphismes...
Par exemple pour une physique de billard, il est bien plus performant d'avoir d'un côté les calculs de déplacements et collisions et de l'autre un moteur de rendu en temps réel. On peut par exemple faire un rendu vectoriel (redimensionable) ou 3D avec le même "module" de calculs.
Dri
Par exemple pour une physique de billard, il est bien plus performant d'avoir d'un côté les calculs de déplacements et collisions et de l'autre un moteur de rendu en temps réel. On peut par exemple faire un rendu vectoriel (redimensionable) ou 3D avec le même "module" de calculs.
Dri