Okay, Wistaro

Alors, on a plusieurs options qui s'offrent à nous:

• Utiliser une Pic (ou deux, ou plus) (programme léger et très rapide mais variables supplémentaires lourdes et non recopiable à la main)
  
• Tracer des graphismes avec des Ligne() à gogo (programme lourd mais rapide)
  
• Tracer des graphismes avec une base de données et un algo Moins lourd, mais plus lent
  

Qu'est-ce qui te tente ?

Pour le menu ?
Pour le corps du jeu ?

Je peux aussi vous apprendre à créer facilement un système de fenêtres, c'est pratique pour les jeux qui ont plein de messages à donner.

Mais je suis pas sur que ce soit utile ici...

Moi je me demande si je dessinerai des surfaces pleines ou des quadrillages de points dans le jeu.
La taille du personnage aussi joue.
Et cela change un peu les objectifs du moteur.

Linka a écrit:des surfaces pleines ou des quadrillages de points dans le jeu

Tu veux dire pour les murs/sols?

Pour le jeu en lui-même, il me semble que tracer des lignes une par une semble très long et lourd dans le programme. A la limite, pour le menu pourquoi pas.

En revanche, je ne comprend pas sa:

Persal a écrit:
Tracer des graphismes avec une base de données et un algo Moins lourd, mais plus lent

Ou sinon, partir sur un sytème de Tillmapping pour le jeu, comme disait Linkakro


Et aussi, on n'a pas parlé du scroll dans le jeu...

A propos du jeu lui même, je pense qu'il faudra un peu attendre de voir comment le moteur avance, justement pour ces histoires de scrolling, de savoir si ça marche avec les statplot, etc...

Mais pour les éventuels menus, etc...

J'ai réfléchis au différentes partie du jeu, et je commence par les "platFormes".

Voici en gros mon idée.


Cette image montre tout les niveaux de hauteurs des plates formes principales

En bas, une série de signe PI, qui dessinent le sol grâce à un boucle (plus sympa qu'une simple Shade(), je trouve  )

Puis 7 pixels de blancs pour laisser passer le Mario  (il faudrait mettre 8, pour éviter les RecallPics inutiles  et les bugs d'affichages). Ensuite, une plaque de 5 pixels d'épaisseur, puis encore 7 pixels de vide...Tout cela encore 5 fois.

Voici le code (un peu useless,mais bon...)

Code:


:ClrDraw
:0→Xmin:1→∆X
:0→Ymin:62→Ymax
:DelVar KDelVar ADelVar B
:Repeat K=45
:   getKey→K
:   For(A,50,55
:      Horizontal A
:   End
:   For(A,38,43
:      Horizontal A
:   End
:   For(A,26,31
:      Horizontal A
:   End
:   For(A,14,19
:      Horizontal A
:   End
:   Text(0,1,"π
:   Text(12,1,"π
:   For(A,1,90,2
:      Text(57,A,"π
:   End
:End

Bien sûr, ce n'est que les plaques principales, des obstacles viendrons ensuite sur ces niveaux, mais c'était juste pour présenter mon principes de création des différentes plates-forme, et ne pas partir sur un système aléatoire.

La longueur de chaque platforme sera établit aléatoirement, voire inexistante, et pourquoi pas plus le lvl est haut, moins les plaques sont grandes et existantes...

En fait on peut faire beaucoup mieux avec les base de données et les StatsPlots :p

Mais on pourra toujours rajouter des plateformes grâce à un gestionnaire d'objets .

Donc il faudrait voir les graphismes pour:
_mario
_différents ennemis
_différents objets à ramasser pour faire "évoluer" mario
_les plates formes
_les caisses qu'il faut tapper pour faire sortir les objets à ramasser
_d'autres nouveautés...

Je propose de récupérer les vrais sprites ou des équivalents open source

De toutes façons, tant qu'on a pas de WLIB pour ça...

Pour l'instant je fais les tests avec du texte de toute façon.
Mais même si on veut récupérer les vrais sprites il va falloir les adapter (noir et blancs, dimension 8*8...)
Pour la dimension on peut faire plus que 8*8 à condition de séparer l'objet en 2. Tant que l'objet est immobile c'est bon (parce que sinon ça risque d'être compliqué à gérer si je dois le faire se déplacer en 2 parties).

Pour les caisses/objets on utilise aussi des Sprites ?

On peut. Ou plus simplement, des Text-sprites

Je préconiserais les text-sprite.

Mauvaise idée sauf si vous souhaitez tout faire ramer encore plus...
Ce serait beaucoup mieux d'utiliser Wlib ici...

Ouais je suis d'accord avec m@t si vous mettez trop de text sprites ça va être ultra-lent.

les sprites originaux...regardez le super mario land 2 de 1992 sur game boy monochrome
pour le petit mario, il fait 8*8 pixels, mais le grand, c'est 8*16 par contre. ca tombe bien puisque pour le perso, j'ai utilisé le sprite original de 1985 (super mario bros sur NES) en noir et blanc.
regardez ca:
mario land 2
mario evolution

Ils font bien plus que 8*8 et 8*16...
Mais le problème n'est pas là: il faut que ça tienne sur une "case" de 8*8 sinon c'est trop compliqué à gérer et ça va être trop lent. Ou sinon on peut agrandir la taille des cases, mais la vision se rétrécit du coup si les objets grossissent. Et il faudra faire un scroll encore plus souvent, donc ce n'est pas une bonne idée.

Dans le premier lien y en a des touts minis qui devraient tenir en 8x8.

Ah oui exact autant pour moi.

ouais c'est vrai
retenez quand meme ceux de la selection du monde, ils devraient etre suffisamments petits pour tenir sur 8*8 pixels
celui que j'ai fait tient sur 32*16 alors laissez tomber...

Qu'entends tu par "ceux de la sélection du monde"? ...

ceux qui sont tout petits, au milieu
je vous l'accorde, j'ai quand meme une grande culture du jeu video (ca me permet de mieux comprendre les blagues du joueur du grenier ), donc bien sur, j'y ai joué
pour la sélection du monde, le sprite est celui dont parlait ashtrail qui correspond a tes exigences
tu parlais des boulettes a envoyer: tu peux les remplacer par un champignon qui rase le sol, comme dans super mario land 4, toujours sur game boy monochrome. ca serait une idée?

La boule de feu est tout aussi simple à faire, après c'est juste une question de graphismes.

non, mais la faire rebondir, c'est plus compliqué que de faire un champignon qui rase le sol :p
je pense qu'utiliser de l'assembleur pour les sprites, ca serait pas de trop ˆˆ

rpg a écrit:je pense qu'utiliser de l'assembleur pour les sprites, ca serait pas de trop ˆˆ

C'est ce qu'on a de prévu, on attend pour ça que matref nous le code dans Wlib, et ceux qui font les graphismes s'y mettront.

rgp a écrit:non, mais la faire rebondir, c'est plus compliqué que de faire un champignon qui rase le sol

Alors tu n'as pas lu ce que j'ai dis. Je parle simplement de changer de sprite, pas d'un vrai rebond. En changeant simplement la hauteur de la balle par rapport au sol on peut donner l'impression qu'il y a un rebond.

En décallant l'abcisse, non?

m@thieu41 a écrit:Je parle simplement de changer de sprite, pas d'un vrai rebond. En changeant simplement la hauteur de la balle par rapport au sol on peut donner l'impression qu'il y a un rebond.

Ben donner l'impression c'est tout le principe du jeu vidéo non? En vrai la machine ne fait que des bêtes calculs qui n'ont aucuns sens pour elle.
C'est toujours le cas même pour les déplacements, tu remets juste le sprite plus loin après avoir effacé l'écran : c'est pas un vrai déplacement.
En gros c'est toujours une impression... Y aura jamais de vrai rebond. Du coup je vois pas trop l'intérêt de cette explication.

Voici mon interprétation des rebonds de m@thieu41.
Le jeu est divisé en cases de 8*8 et les techniques utilisées actuellement ne permettent pas de placer les sprite en chevauchant plusieurs cases.
Donc un rebond dessiné sur une échelle inférieure à 8pixels ne peut pas être de cette manière réalisé en déplaçant un unique sprite.
Il faut plusieurs sprites contenant un dessin décalé et le changement de sprite créera l'animation de rebond.
De plus l'image de la balle peut être modifiée : déformation, impact etc.

Mais des sprites transparents ou clipped par WLIB peuvent être affiché en chevauchant les cases donc je ne pense pas que cela soit un problème.

Ce qui semble difficile pour l'un mais pas pour l'autre : la mécanique de déplacement et rebond.
Cela est composé de plusieurs choses mais ne me paraît pas difficile a priori.

c'est toujours une possibilité a tester

Voilà Linka a (je crois) compris ce que je voulais dire:
au lieu de modifier l'ordonnée de la boule de feu pour la faire "monter" ou "descendre", on affiche un sprite de 8*8 différent: au lieu que la balle soit sur les pixels supérieur elle est sur les pixels inférieur, et vice versa. Du coup ce n'est pas un "vrai" déplacement vertical (ok ash il n'y a pas vraiment de vrai déplacement, ce que j'entends par là c'est que les coordonnées de la balle (du moins son ordonnée) ne changent pas. Lorsque les coordonnées changent on peut considérer ça comme un "vrai" déplacement non? Du moins du point de vue des variables).