PureBasic

Hello,

J'ai commencé depuis peu le coding d'un "tire sur tout ce qui vient" en reprenant les ressources (gfx + sound) de Xenon 2000. Jamais je n'arriverai à égaler les excellents Bitmap Brother mais je vais tenter de faire un truc sympa...

A ce jour, e plus gros travail fourni (c'est à dire pas grand chose) concerne le coding du MapEditor (la source est pas la, car j'ai vraiment trop honte du code et ya encore des bugs de depassements de tableaux...)

Pour le jeu, tout reste à faire, dans le sens ou pour l'instant ya que de l'affichage : scrolling paralax + vaisseau du player (controle clavier) + tir (barre espace).

Etant néanmoins content de mon avancée, je post ce début de projet qui va m'occuper quelques mois encore...
- gestion des collisions, gestion des méchants, des nouveaux tirs de folie (laser avec bezier), jouabilité...et surtout ambiance qui doit justifié le titre : Mad Fire (nom en hommage à Mad Race, un concept de jeu qu'Ubi Soft nous avait piqué, mes camarades et moi en 1989. C'est dit)

http://xdji.free.fr/Telechargement/MadFire.zip

A bientôt

Alors la !!!!!!!!!!!!! chapeau
On dirait un vrai

J'y connais rien en jeu, mais je suis épaté de voir ce que des gens comme toi arrivent a faire avec notre PB
En plus tu partage ton code, merci

J'ai toujours adoré les jeux style space invaders, car ce sont les premiers jeux que j'ai vu avec mes yeux d'enfants emmerveillés dans les bars

Et ça fait tout drole de voir le code de ce type de programmes
Ca tourne nikel sans saccade sur W2000 v4.20

J'espere que tu menera ton projet à terme.
En attendant encore bravo, comme dirais les "djeun's", j'suis bluffé

Merci mister KCC,

J'ai encore un travail d'optimisation d'affichage des tuiles du décor. Pour l'instant, il affiche encore les dalles vides !!!
Mon code n'est pas un exemple, j'ai toujours été un peu brouillon (même en assembleur 68000), je vais faire des efforts pour commenter et bien organiser les différentes parties...

Je suis content du résultat mais je pense que la qualité des graphismes améliore l'effet du truc. En revanche, comme toi, je suis épaté par les possibilités de PB en 2D => d'ou ma signature.

Ensuite, la différence entre un vrai jeu et cette démo représente un énorme travail. Le développement est assez ingrat en ce sens car c'est assez facile et rapide d'afficher des trucs qui bougent, mais ensuite assurer la gestion des ennemis, des tirs...ce sont toutes des choses qui ne se voient pas et qui sont essentiels (j'ai fait le plein de coca pour m'aider dans cette tache)

Bravo !

J'espère que ça va motiver d'autres codeurs !

Bonne continuation !

bonjour Cool dji
super ovni
avec une telle puissance de feu on comprend pourquoi
il y a personne qui se présente en face lol
excellent graphisme, animation et les détails du vaisseau etc..
merci pour le code
trop top
au revoir

Bonjour,

Thanx Misters Huibit & Kernadec !!!

J'avance à la vitesse de l'escargot et j'ai commence la gestion des collisions :
J'utilise SpritePixelCollision pour une détection fine des sprites.
J'avais commencé par tester collision entre tuile et ovni et je me suis aperçu d'un soucis de présision
Devant, ce doute, j'ai fait un exemple dans le vide avec 2 ovnis.

La collision entre 2 ovnis est détectée et je m'aperçois qu'une collision concernant le bord des ailes (à gauche ou à droite) n'est pas détectée.
Est-ce que tous les pixels des sprites sont réellement testés un par un ?
Est-ce que le clipsprite n'interfere pas avec le spritepixelcollision ?

http://xdji.free.fr/Telechargement/MadFire.zip

Quand la collision est détectée, j'affiche le sprite sans effet de transparence => c'est visuel !!

Je ne comprends pas, j'ai regardé un grand nombre d'exemples sur le forum et n'ai pas trouvé de cas similaires...
Spritepixelcollision est imprécis ou c'est mes yeux (ref : les bronzés font du ski )

ps : je pose ça la car je ne pense pas que ce soit un bug de purebasic !

tu ne testes que ton sprite 1
If (SpritePixelCollision(1, PosplayerX, PosplayerY, 1, 200,200))
Alors que les bords sont constitués du sprite 3, il faut faire un test de collision pour ce sprite , et pour les 4 positions que tu as déterminées

vu l'ampleur que peut prendre un jeu de ce type, tu as peut-être intérêt à structurer tout de suite

C'est bien pour des petits codes les gosub, mais ensuite il est préférable de privilégier les procédures.


Je crois bien que je n'ai jamais utilisé les gosub avec PureBasic.
Avec d'autres Basic c'était obligatoire, y'avait rien d'autre.

Pense aussi à utiliser les structures, comme pour ton vaisseau principal et les ailes , tu peux faire une structure qui regroupe toutes les données nécessaires pour l'affichage , les animations et les collisions.
ou une structure distincte pour les animations, c'est à toi de voir.

Cool Dji a écrit :Bonjour,

Thanx Misters Huibit & Kernadec !!!

J'avance à la vitesse de l'escargot et j'ai commence la gestion des collisions :
J'utilise SpritePixelCollision pour une détection fine des sprites.
J'avais commencé par tester collision entre tuile et ovni et je me suis aperçu d'un soucis de présision
Devant, ce doute, j'ai fait un exemple dans le vide avec 2 ovnis.

La collision entre 2 ovnis est détectée et je m'aperçois qu'une collision concernant le bord des ailes (à gauche ou à droite) n'est pas détectée.
Est-ce que tous les pixels des sprites sont réellement testés un par un ?
Est-ce que le clipsprite n'interfere pas avec le spritepixelcollision ?

http://xdji.free.fr/Telechargement/MadFire.zip

Quand la collision est détectée, j'affiche le sprite sans effet de transparence => c'est visuel !!

Je ne comprends pas, j'ai regardé un grand nombre d'exemples sur le forum et n'ai pas trouvé de cas similaires...
Spritepixelcollision est imprécis ou c'est mes yeux (ref : les bronzés font du ski )

ps : je pose ça la car je ne pense pas que ce soit un bug de purebasic !

ton projet est bien cool. A la vue du code:
- tu n'utilise pas de procédure( voir jeu vers l'infini par exemple hein), alors quand ton code fera plusieurs millier de lignes de code...
-StartSpecialFX est à mon avis désuet, vive les sprites3D

Est-ce que le clipsprite n'interfere pas avec le spritepixelcollision ?
bonne question, heu..., mais vaut mieux faire çà:
-SpritePixelCollision marche bien, mais avant vaut mieux calculer une zone de détection( x et y ou commande SpriteCollision() ), et une fois qu'un objet rentre dans la zone d'un autre, et bien là tu utilise la fameuse commande. tu peux juste tester un seul petit pixel( que tu n'affichera pas à l'écran pour la version finale bien sûr). Donc je vois cela comme çà: un pixel à gauche et un autre à droite... et pis un autre en haut et en bas tiens.

mais perso je testerai juste les positions x et y, à l'ancienne, c'est plus long à mettre en oeuvre mais cà bouffe rien en temps machine.

SpritePixelCollision marche bien, mais avant vaut mieux calculer une zone de détection( x et y ou commande SpriteCollision() ), et une fois qu'un objet rentre dans la zone d'un autre, et bien là tu utilise la fameuse commande. tu peux juste tester un seul petit pixel( que tu n'affichera pas à l'écran pour la version finale bien sûr). Donc je vois cela comme çà: un pixel à gauche et un autre à droite... et pis un autre en haut et en bas tiens.

C'est totalement inutile, la fonction SpritePixelCollision le fait déjà, elle ne teste les pixels qui si les deux sprites se chevauchent (box collision).

Etant un fan de shoot'em up dans le passé (Z-Out, R-Type, Cybernoid, Xenon 2...) je te soutiens dans ton projet. Bravo à toi.

Hello à tous,

Merci de vos remarques et conseils.
Avant de poursuivre, je vais réorganiser mon code et remplacer les gosub (que j'aimais tant, ça me rapelle les jsr - rts ) par des procédures => le message est entré (merci Comtois et Beauregard)

Concernant le spritepixelcollision, j'ai fait un test avec 2 sprites sans utiliser le clipsprite et le test fonctionne parfaitement .
Dans l'exemple posté sur le forum, les 2 sprites (vaisseau) sont les 2 issus de clipsprite et la detection à l'air de se réaliser uniquement sur la première image (les ailes penchées sont plus courtes que les ailes droites : donc pas de collision).
J'ai pris les mêmes sprites pour eliminer d'éventuelles erreurs provenant d'une mauvaise sélection de tuile du décor...

Je vais donc tronçonner tous les sprites en sprite individuels et ne plus utiliser le clipsprite.
Ensuite, pour les collisions entre sprite et décor, je test uniquement les tuiles qui sont dans la zone d'un sprite (je ne fais pas un test de coordonnées, ce sont les coordonnées du sprite qui pointent sur la bonne ou les bonnes tuiles du Map).

Effectivement, j'avais utilisé Sprite3D dans le Memory (je sais pas pourquoi j'ai utilisé SpecialFX - )

Merci encore pour vos encouragements (Guidev : yes +SWIV, Battle Squadron). Je voulais me dépecher de faire un prototype pour voir ce que ça pouvait rendre. Maintenant, je vais réfléchir à la structure du jeu et du programme pour éviter le brouillonage...
L'objectif n°1 est de terminer ce qui est commencé.

hybris aussi :p

Moi aussi j'aime bien les gosub (aussi l'habitude des des JSR!). Franchement je pense que de temps en autre le gosub et le goto sont valables, d'autant que les procédures sont plutôt lentes en PB. Et un JMP, c'est une instruction du processeur que tout le monde utilise sans s'en rendre compte, tout le temps (y compris pour appeler une procédure!).

Cool Dji a écrit :Je vais donc tronçonner tous les sprites en sprite individuels et ne plus utiliser le clipsprite.

à ta place j'y réfléchirai à 2 fois*... mmh, peut-être faut-il faire simple: placer un carré de 64*64( ou 56*56 placé au milieu/bas, car le bout des ailes et le nez peuvent mordre un peu sur le décor, c'est pas un drame) sur ton vaisseau, et tu teste les collisions avec ce carré et le tour est joué. Après tout, la collision du vaisseau/décor n'a pas besoin d'être un monstre de précision...

... j'imagine que le vaisseau n'explose pas au contact du décor, comme view point, sauf si le vaisseau est acculé au bas de l'écran bien sûr... c'est bien çà ?


* car beaucoup trop contraignant, aussi bien pour la découpe/retouche d'image que pour coder tout les loadmachin...