Début d'un nouveau système de 2D et Sprites

Je suis en train de coder une autre façon de gérer des sprites dans un environnement 2D. J'ai fait une maquette et j'aimerais connaître votre opinion à ce sujet. Il y a deux différences majeures par rapport à la gestion actuelle des sprites en Panoramic:
1. tout moment, le contenant (simialire à scene2d) connaît tous les sprites
2. non seulement la transparence est gérée comme en Panoramic, mais on peut cliquer à travers une partie transparente d'un sprite pour atteindre le sprite (ou le fond) placé en-dessous.

Ma maquette est faite à partir d'un code trouvé sur Internet à cette adresse. Mais je l'ai fortement modifié afin de pouvoir cliquer "à travers" et en transformant un code "simple" et "composant" Delphi, facilement utilisable.

Vous trouverez, dans mon WebDav, dans le dossier "Jeux", un dossier "Test_Sprites". Prenez tout le dossier (il fait 1,03 Mo au total) et lancez le programme Images.exe. Il affiche un fond (un paysage) et 3 sprites superposés. Dans le programme d'origine, j'ai également ajouté, en bas de l'écran, un affichage du sprite sélectionné. Il suffit de "tirer" un des sprites avec la souris pour le déplacer. Automatiquement, le numéro du sprite cliqué s'affichera en bas (0, 1 ou 2). Et avec 2 ou 3 sprites superposés, on peut cliquer à traversles zones transparentes d'un ou de 2 sprites pour cibler le sprite au fond - chose actuellement impossible en Panoramic. On peut aussi cacher le sprite sélectionné (par un bouton en bas) et réafficher tous les sprites, cachés ou non.

Dites-moi ce que vous en pensez, et si ça vaut la peine de pousser l'implémentation plus loin.

Salut Klaus

J’ai téléchargé le projet à partir de l’adresse que tu as indiqué.
Voulant compiler le programme moi-même (j’ai Delphi 7) j’ai reçu l’erreur suivante :

Spoiler:

J’ai téléchargé Test_Sprites à partir de ton Webdav et j’ai testé : c’est parfait !

J'ai eu la même erreur en Delphi 6 Personal Edition. J'ai simplement mis cette ligne en commentaire, et tout marche bien.

Ceci dit, ma version est largement modifiée par rapport à la version disponible par ce lien. En particulier, sur le plan fonctionnel, tu ne peux pas cliquer "à travers" les parties transparentes d'un des sprites. Mais il est intéressant de comparer les deux versions.

Je viens de poster une nouvelle version, avec un bouton permettant de passer le sprite sélectionné un cran en arrière. L'effet est immédiatement visible. Ca non plus, on ne peut pas le faire en Panoramic...

Très intéressant.

PS : j'ai arrivé à compiler en mettant la ligne en commentaire.
Merci.

Klaus a écrit:: Dites-moi ce que vous en pensez, et si ça vaut la peine de pousser l'implémentation plus loin.

Super ! La réponse est OUI !

Voilà qui donnerait une grande souplesse à l'utilisation des sprites.

Merci Klaus !

Désolé Klaus, je n'avais pas vu ce sujet avant ... Il faut absolument que je testes ça. J'ai hâte... Wink

Si ça marche bien, crois moi, je vais te faire une tonne de demandes Very Happy

Le Test est très prometteur.
Ce n' est pas une avancée mais une révolution pour la 2D avec des Sprites.

Perso, je suis preneur à 100% !

C'est extrémement prometeur Klaus. Le système marche bien. L'ordre des sprites et la transparence sont nickel et le fait de pouvoir cliquer sur les sprites, ça simplifiera beaucoup les choses.

Si tu peux rendre ce moteur facilement interfaçable, et qu'il arrive à gérer de nombreux sprites sans ralentissement excessif alors oui, ça vaut le coup de pousser plus loin puisque nous aurions des sprites rapides avec plusieurs niveaux ce qui permet énormément de choses et ta rapidité de développement pour rajouter toutes les fonctions necessaires aux sprites pou les rendre pleinement et facilement exploitable (test de collision, rotation, changement de taille, chargement depuis une image, ...).

Bref, ce serait une révolution.

Bonjour à tous,

@Klaus,
La démonstration est très bonne et ça donne envie.
Le clic sur (et à travers) un SPRITE ne peut-être qu'un bien.
Je suis pour, avoir ces possibilités, mais sous quelle forme comptes-tu les développer. Je veux dire, est-ce par KGF.DLL ou par une autre manière (voir une DLL spéciale 2D).

Pour moi, ce qui est important c'est pouvoir utiliser ses fonctions avec Panoramic et qu'elles soient simples à mettre en oeuvre. Mais, je parle pour moi, ce n'est peut-être pas si facile à réaliser.

A+

Je n'ai pas d'autre moyen que mettre ces fonctionnalités dans une DLL. Techniquement, on ne peut pas (encore ?) créer des plugins pour Panoramic.

Donc, je mes mettrai dans KGF.dll (ça commence à marcher, au "labo"). Et pour la facilité d'utilisation, tu les déclares par la nouvelle commande LIBARY et tu fais une SUB pour chaque fonctionnalité - c'est ce qui se rapprochera le plus des commandes Panoramic.

Je l'avais oubliée cette nouvelle library de Panoramic,
Je ne me suis pas encore penché la dessus...
En fait, pour le moment, je ne vois pas bien comment s'en servir. J'attendais de voir des exemples apparaître sur le forum. Mais pour le moment "Nada" Very Happy

Mais ton idée est bonne, donc on verra...

A+

J'ai intégré le début de ce système dans KGF.dll. Je l'ai publié avec la dernière version, y compris un petit code de test Panoramic.

Oui, je viens de voir cela dans le poste kgf.dll.
D'ailleurs je t'ai fait une petite requête Very Happy

A+

Sur le système de sprites de PureBasic, j'aime bien le GrabSprite, le RotateSprite, le SpriteCollision, le SpriteDepth, le SpritePixelCollision et le ZoomSprite

Il y a d'autres trucs sympas mais qui me paraissent moins fondamentaux. A part peut être le TransformSprite qui peut être puissant sans doute, mais probablement assez complexe en calcul et malgré tout non utilisé tout les jours.

Bon ben ce soir, on va tester tes jolis exemple de KGF Wink

Tu verras que j'ai fait un début de gestion de collision (par rectangle englobant), mais avec une notion de "résistance" permettantà certains sprites de pénétrer dans d'autres, mais pas l'inverse... Ca, combiné à la transparence et la gestion des trous véritables, c'est déjà un vrai plus. Je vais maintenant regarder le problème de la collision par pixels.

Ca rendra un peu obsolète ton ancien travail sur les sprites, mais parallèlement ce travail que tu avais fait à l'époque peut te servir au niveau de la logique et des différentes informations utiles. Par contre ton travail actuel va permettre de très largement simplifier les codes pour arriver aux résultats d'alors. La seule question qu'il me reste c'est la rapidité en passant par les appels à une DLL.
Mais je me pose peut être des questions qui n'ont pas lieu d'être comme je n'ai pas pu tester hier soir la première maquette que tu nous as fourni.

J'espère que ça donnera des idées à Jack (s'il en a le temps) pour continuer de faire évoluer ce système de Scene_2d et de sprites, voir qu'il le remette complétement à plat pour repartir sur une base compatible mais plus facile à faire évoluer.

Moi aussi, je me pose des questions. Je fais une maquette, ou une sorte de prototype, pour voir ce que ça donne. Je me suis rendu compte qu'il n'est pas si compliqué que ça de coder un semblant de Scene2D. Au niveau des performances, ce sera à voir lorsque j'aurai avancé un peu plus dans les fonctionnalités. Mais je pense que ce sera pas mal, et sans clignotement, comme on peut déjà le voir maintenant en déplaçant un sprite avec la souris - il y a un système de double buffeur qui semble assez efficace.

En ce moment, je code des fonctions de zoom pour les sprites...

EDIT

As-tu vu que via le tableau d'interface, tu as en permanence le numéro du sprite sélectionné, ses coordonnées, ses dimensions et éventuellement le sprite collisionné ? Ces valeurs se mettent à jour automatiquement...

De toute façon, s'il y a des problème de performances, ça sera sur un certain type de jeu. Ce travail de sprites permet de toutes façons déjà des tas de choses. Te souviens tu du début (encore un programme commencé et pas fini...) de labyrinthe style "donjon master". Avec ton système, ça serait beaucoup plus facile à coder puisque l'on peut ordonner les sprites de premier plan et ceux d'arrière plan. Cliquer sur le levier ou le bouton qui ouvre une porte ou sur un monstre et beaucoup plus simple que d'avoir à effectuer les tests...

Je lance quelques idées comme ça, mais ce serait pareil pour un damier avec des pions pour un jeu de dame. Fini les tests de position du clic. On récupère directement le numéro du pion Smile

Ca laisse pas mal de possibilités.

Je n'ai pas encore testé, ce qui est déjà fait car j'ai passé tout mon temps à régler correctement mon jeu de glouton.
Je l'ai déposé sur mon webdev, car il est terminé.

Je pense commencer à faire des essais sur ton nouveau Système 2D, demain, Klaus.

A+

Bonjour à tous,

Je relance ce sujet pour ne pas continuer à grossir le sujet sur les nouveautés de KGF.dll.

J'ai fait mes premiers pas avec ce nouveau système 2d et Sprites, que j'ai nommé pour raccourcir "K2D".

Les premiers essais sont excellents.
Ce n'est pas trop compliqué, à condition d'avoir sous la main KGF.chm, car n’étant pas habitué je dois consulter, cette doc, souvent.

Je viens de me fabriquer un programme de création d'ImageList pour les animations des Sprites K2D.
Je le publierais quand je l'aurai débogué complètement.

A ce sujet (ImageList) j'ai une requête à faire à Klaus.
Dans PANGINE2D, pour animer un sprite on n'a pas besoin de découper une planche de sprite pour lancer une animation.
Est-ce possible d'avoir quelque chose de similaire pour créer une ImagList à partir d'une planche.
Ou bien, avoir un outil qui découpe automatiquement une planche de sprite en plusieurs images.
Bien sur, je parle de Sprites carrés car je crois que ImageList n'accepte que des images carrées.
Exemple une planche de 4 rangées de 6 sprites de taille 64x64 a les dimensions 64x6=384 et 64x4=256.
Ce qui nous donne une planche de taille 384x256.
Il faudrait un truc qui découpe cette planche en 32 images de 64x64.

Est-ce réalisable ?

A+

Citation :: Est-ce possible d'avoir quelque chose de similaire pour créer une ImagList à partir d'une planche.

Bien sûr ! Voici l'outil que j'utilise, et que j'ai d'ailleurs déjà publié:

Code:: ' decomposer_image_en_sprites.bas

label ouvrir, extraire, librairie

dim f$, res%, w%, h%, a$, b$, w1%, h1%, i%, j%, nl%, nc%, n%, IL%, blanc%
blanc% = (255*256+255)*256+255

full_space 0

open_dialog 1
image 2
picture 3 : top 3,40 : left 3,10

button 10 : top 10,10 : left 10,10 : caption 10,"Ouvrir BMP" : on_click 10,ouvrir
alpha 11 : top 11,10 : left 11,100

alpha 12 : top 12,10 : left 12,200 : caption 12,"Lignes: "
alpha 13 : top 13,10 : left 13,350 : caption 13,"Colonnes: "

spin 22 : top 22,10: left 22,250 : width 22,60 : min 22,1 : max 22,300 : position 22,1
spin 23 : top 23,10: left 23,410 : width 23,60 : min 23,1 : max 23,300 : position 23,1

button 30 : top 30,10 : left 30,600 : caption 30,"Extraire" : on_click 30,extraire
button 31 : top 31,10 : left 31,700 : caption 31,"Librairie" : on_click 31,librairie

dll_on "KGF.dll"

end

ouvrir:
filter 1,"Images BMP|*.bmp"
f$ = file_name$(1)
if f$="_" then return

res% = dll_call3("AnalyzeImageFile",adr(f$),adr(w%),adr(h%))
caption 11,"WxH = "+str$(w%)+"x"+str$(h%)
width 3,w% : height 3,h%
file_load 3,f$

end

extraire:
a$ = file_extract_name$(f$)
a$ = left$(a$,len(a$)-4)
nl% = position(22)
nc% = position(23)
w1% = w%/nc%
h1% = h%/nl%
message "Taille d'un sprite: "+str$(w1%)+"x"+str$(h1%)

n% = 0
2d_target_is 3
for i%=1 to nl%
for j%=1 to nc%
2d_image_copy 2,(j%-1)*w1%,(i%-1)*h1%,j%*w1%-1,i%*h1%-1
file_save 2,a$+"_"+str$(n%)+".bmp"
n% = n% + 1
next j%
next i%
message str$(n%)+" sprites enregistrés."
return

librairie:
a$ = file_extract_name$(f$)
a$ = left$(a$,len(a$)-4)
nl% = position(22)
nc% = position(23)
w1% = w%/nc%
h1% = h%/nl%
message "Taille d'un sprite: "+str$(w1%)+"x"+str$(h1%)
f$ = a$+".ilb"
IL% = dll_call2("CreateImageList",w1%,h1%)

n% = 0
2d_target_is 3
for i%=1 to nl%
for j%=1 to nc%
2d_image_copy 2,(j%-1)*w1%,(i%-1)*h1%,j%*w1%,i%*h1%
res% = dll_call4("AddImageToImageList",IL%,0,1,blanc%)
n% = n% + 1
next j%
next i%
res% = dll_call2("SaveImageList",IL%,adr(f$))
message str$(n%)+" sprites intégrés dans "+f$+"."
return

Citation :: à condition d'avoir sous la main KGF.chm

C'est accessible également en ligne (à partir de mon site, ou à partir de ma signature), par exemple à cette adresse:
http://klauspanoramic.esy.es/KGF.html?SommaireIndex.html

Mais pourquoi je n'ai pas posé la question plus tôt !

Voila un utilitaire qui fait gagner un temps fou. Je ne l'ai pas vu passer ou alors je n'est pas tilté dessus.

Merci Klaus.

A+

J'ai poursuivi mes tests,
Je n'ai pas encore rechargé la nouvelle dll.

J'ai remplacé la barrière par une fontaine animée (c'est chouette).
J'ai quelques petits soucis avec la fréquence en millisecondes de la transparence dans l'animation du glouton.
Si elle est trop faible (50) l' autre Sprite (le stroumf) bloque une bonne seconde en cas de collision du glouton avec la fontaine (il pédale sans avancer). Si je change le paramètre à 100ms, le blocage est beaucoup plus court.
J'ai constaté également que mon processeur tourne à 29% et ma mémoire à 36% (environ) pendant que ce programme tourne. Ce n'est pas encore de trop, mais je vais surveiller, surtout quand j'ajouterai d'autres Sprites.

Par contre, il faut faire attention de ne pas avoir un autre Panoramic.exe qui tourne (suite à un plantage), car du coup ça bloque dur dur (Processeur à 75%).
Je pense qu'il va falloir pousser les tests en ajoutant pas mal de sprites avec des déplacements automatiques, animation, etc. pour voir jusqu'où on peut aller.

Pour le moment je n'ai rien mis mon webdev, on verra plus tard.

A+

C'est certain: tout ce qui est animation, est géré de façon interne par des timers individuels. Il faudra voir à l'usage et lors d'une montée en en charge si le concept tient la route ou si je dois trouver une autre solution. Il y en a, bien sur, mais c'est plus lourd à programmer.

Pour le moment, ça tient la route. C'est à nous de programmer en conséquence.

Je ne me gêne pas pour charger le programme. C'est volontaire, car se sont des tests.
Rien que l'image de fond est assez lourde (1600x1200, 2.37Mo), le stroumf 2x1.08Mo (aller + retour).
Concernant les 2 ImageList du shtroumf, il faut que je revois la création de ces 2 ImageList, car j'ai un doute sur ce que j'ai fait.
Je te tiendrai au courant...

Dans l'état, on peut déjà faire des jeux relativement complexes, si on abuse pas sur les animations automatiques.
Mais c'est l'avenir qui nous le dira, car les tests sont assez longs à faire: il faut à la fois se familiariser avec les fonctions de la dll (c'est le plus difficile), et imaginer ce que l'on peut avoir besoin pour un jeu.

Au passage, j'ai trouvé un site qui décompose des GIF et nous les envois dans un fichier ZIP. C'est ici => http://www.bloggif.com/gif-extract.
Et une bonne collection de GIF à copier ici => http://www.gifgratis.net/

A+

» Extracteur de sprites
» Sprites
» KGF_dll - nouvelles versions
» Début d'un autre IDE
» Début d'un jeu de labyrinthe