[PROJET MARIO]Topic sur les graphismes Hitskin_logo Hitskin.com

Ceci est une prévisualisation d'un thème de Hitskin.com
Installer le thèmeRetourner sur la fiche du thème

Tout 82
Vous souhaitez réagir à ce message ? Créez un compte en quelques clics ou connectez-vous pour continuer.
Tout 82

Jeu 28 Mar 2024 - Bienvenue,

Rechercher
 
 

Résultats par :
 


Rechercher Recherche avancée

Connexion

Récupérer mon mot de passe



Chatbox externe


Derniers sujets
» [JEU] Mon voisin du dessous
[PROJET MARIO]Topic sur les graphismes EmptyDim 16 Oct 2022 - 21:11 par Wistaro

» Bonne année 2018!
[PROJET MARIO]Topic sur les graphismes EmptyVen 2 Nov 2018 - 19:42 par Ti64CLi++

» Lancement du TI-Concours 2017 !
[PROJET MARIO]Topic sur les graphismes EmptySam 20 Mai 2017 - 0:27 par Paulo1026

» Chaînes Youtube des membres
[PROJET MARIO]Topic sur les graphismes EmptyVen 19 Mai 2017 - 22:41 par Wistaro

» cacul du taux d'intêret
[PROJET MARIO]Topic sur les graphismes EmptyVen 24 Mar 2017 - 21:50 par m@thieu41

» [Projet] Un mario by tout82
[PROJET MARIO]Topic sur les graphismes EmptyDim 29 Jan 2017 - 14:09 par Wistaro

» Cherche documentation assembleur TI82stat
[PROJET MARIO]Topic sur les graphismes EmptyMer 25 Jan 2017 - 12:29 par Ti64CLi++

» Probleme Ti-82 Stats fr
[PROJET MARIO]Topic sur les graphismes EmptyJeu 12 Jan 2017 - 13:56 par Ti64CLi++

» ROM 82 stats.fr
[PROJET MARIO]Topic sur les graphismes EmptyJeu 15 Déc 2016 - 10:24 par Ti64CLi++

Partenaires
TI-Planet Espace-TI : Forum

Faire un don à Tout-82...
Où va cet argent ?
Membres donateurs:- Persalteas (10€)
- Wistaro (5€)
- jo2geek (22€)

Les posteurs les plus actifs du mois
Aucun utilisateur

Le deal à ne pas rater :
Coffret dresseur d’élite ETB Pokémon EV06 Mascarade Crépusculaire
56.90 €
Voir le deal

Vous n'êtes pas connecté. Connectez-vous ou enregistrez-vous

[PROJET MARIO]Topic sur les graphismes

+2
Linkakro
persalteas
6 participants

Aller à la page : 1, 2  Suivant

Aller en bas  Message [Page 1 sur 2]

1[PROJET MARIO]Topic sur les graphismes Empty [PROJET MARIO]Topic sur les graphismes Jeu 24 Oct 2013 - 23:59

persalteas

persalteas
----------------------
----------------------

Okay, Wistaro Smile

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...

https://tout82.forumactif.org

Linkakro

Linkakro
----------------------
----------------------

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.

m@thieu41

m@thieu41
----------------------
----------------------

Linka a écrit:des surfaces pleines ou des quadrillages de points dans le jeu
Tu veux dire pour les murs/sols?

Wistaro

Wistaro
Passioné
Passioné

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...

https://www.youtube.com/user/Wistaro

persalteas

persalteas
----------------------
----------------------

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...

https://tout82.forumactif.org

Wistaro

Wistaro
Passioné
Passioné

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

Voici en gros mon idée.
[PROJET MARIO]Topic sur les graphismes 1382716803-mariabeta

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 Smile )

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...

https://www.youtube.com/user/Wistaro

Wistaro

Wistaro
Passioné
Passioné

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

https://www.youtube.com/user/Wistaro

m@thieu41

m@thieu41
----------------------
----------------------

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

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...

persalteas

persalteas
----------------------
----------------------

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

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

https://tout82.forumactif.org

m@thieu41

m@thieu41
----------------------
----------------------

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).

Wistaro

Wistaro
Passioné
Passioné

Pour les caisses/objets on utilise aussi des Sprites ?

https://www.youtube.com/user/Wistaro

persalteas

persalteas
----------------------
----------------------

On peut. Ou plus simplement, des Text-sprites Smile

https://tout82.forumactif.org

Linkakro

Linkakro
----------------------
----------------------

Je préconiserais les text-sprite.

m@thieu41

m@thieu41
----------------------
----------------------

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

ashtrail

ashtrail
Connaisseur
Connaisseur

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

http://ti-freeworld.fr1.co/

rpgcreator

rpgcreator
Connaisseur
Connaisseur

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

m@thieu41

m@thieu41
----------------------
----------------------

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.

ashtrail

ashtrail
Connaisseur
Connaisseur

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

http://ti-freeworld.fr1.co/

m@thieu41

m@thieu41
----------------------
----------------------

Ah oui exact autant pour moi.

rpgcreator

rpgcreator
Connaisseur
Connaisseur

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...

m@thieu41

m@thieu41
----------------------
----------------------

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

rpgcreator

rpgcreator
Connaisseur
Connaisseur

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 Razz), 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 Smile
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?

m@thieu41

m@thieu41
----------------------
----------------------

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

rpgcreator

rpgcreator
Connaisseur
Connaisseur

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 ˆˆ

m@thieu41

m@thieu41
----------------------
----------------------

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.

Wistaro

Wistaro
Passioné
Passioné

En décallant l'abcisse, non?

https://www.youtube.com/user/Wistaro

ashtrail

ashtrail
Connaisseur
Connaisseur

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.

http://ti-freeworld.fr1.co/

Linkakro

Linkakro
----------------------
----------------------

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.

rpgcreator

rpgcreator
Connaisseur
Connaisseur

c'est toujours une possibilité a tester Razz

m@thieu41

m@thieu41
----------------------
----------------------

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).

Contenu sponsorisé



Revenir en haut  Message [Page 1 sur 2]

Aller à la page : 1, 2  Suivant

Permission de ce forum:
Vous ne pouvez pas répondre aux sujets dans ce forum