Format de MAPE - Page 1

Salut, j'essai de creer un format pour afficher un MAPE avec la possibilite d'activer les NVG.
Voici le format que j'ai pondu :

*************************************
*   Created 05/07/2005; 15:11:04    *
*        ExtLiB 1.00                *
*   TI-92plus,TI-89, V200           *
*      Par Andoh Wilfried           *
*                                   *
*************************************


Un fichier d'extension 'MAPD' regroupe des images(sprites) qui
servent a dessiner une carte(mape); la carte etant definie par
un tableau contenant les index de position des images.


Format d'un MAPE
------------------

VAR_NAME_TAG = 0
OTH_TAG = 248
_________________________________________________________
Bytes  | Comments 
_________________________________________________________
2  |FileSize 
_________________________________________________________
2  |SpriteFunc 0-> Spr8, 1-> Spr16 ,2-> Spr32
_________________________________________________________
2  |SpriteHeight 
_________________________________________________________
2  |Width[ >= SpriteHeight ]
_________________________________________________________
2  |Height[ >= SpriteHeight ]
_________________________________________________________
2  |AllSpriteCount<=255 
_________________________________________________________
AllSpriteSize |AllSpriteDATA_MAPE
_________________________________________________________
2  |MapRow nbre de Lignes du Mape 
_________________________________________________________
2  |MapCol nbre de Colonne du Mape
_________________________________________________________
2  |ViewRow nbre de Lignes a Afficher 
_________________________________________________________
2  |ViewCol nbre de Colonne a Afficher
_________________________________________________________
2  |MapeCount =  1, 2 ou  3
_________________________________________________________
For Each MAPE
2          | GrayMode {  0 = PLAN_1_2 , 1 = PLAN_1 , 2 = PLAN_2 }
_________________________________________________________
For Each MAPE
     2  | NbrAnim
     2  | AllNbrSprAnim
     For Each ANIMATION
     2  | NbreSprAnim
     For Each ANIMATION
     AllSpriteAnimSize |AllSpriteDATA_ANIM 
_________________________________________________________

For Each MAPE
MapTable | AllMapTable 1 octet par index de sprite
_________________________________________________________
7  |  VAR_NAME_TAG, 'M', 'A', 'P', 'D', VAR_NAME_TAG, OTH_TAG 
_________________________________________________________


NB : S'il y a 1 seul mape dans le fichier, avec GrayMode = 0,
       les NVG ne sont pas active.

Je sais que beaucoup ici ont deja fait des jeux, alors s'il y a des suggestions
sur un meilleur format, elles sont les bienvenues.

t'en a pas marre de faire des trucs que personne ne va utiliser ?

non, c'est pour mon plaisir, je me fais un language Basic On-TI un peu genre ETP.
Vu que c'est presque fini, faut bien que je l'acheve.
Et puis c'est un peu normal que mes projets ne servent pas a grand chose.
Ca fait un peu plus d'1 ans et demi que j'ai commencer a apprendre le C sur TIGCC
en commencant par ce projet.
Ca me donne un air d'inacheve, alors faut que finisse.

Jyaif
: t'en a pas marre de faire des trucs que personne ne va utiliser ?

heu... tu considères que du monde "utilise" tes programmes, vraiment ? si c'est pas pour le plaisir ou pour apprendre, je vois mal ce que qqun irait foutre à coder des jeux et applications sur ti...

En fait le plaisir que je tire a coder ce gros truc, c'est d'apprendre a coder.
Depuis que ya GTC, j'ai ressorti mes projets non acheves.

En l'occurence ExtLiB, j'avais deja ceder la phase Tokeneisation, le seul truc que j'avais pas fait c'etait creer les tables de saut
pour les structures de controles. Alors maintenant que j'ai un peu de courage pour m'y remettre, faut que quelqu'un essai de me decourager.

Ca pourrait etre sympa d'avoir un Basic qui plus rapide pour faire du graphique, et des manipulations de memoire,
tout en permettant de faire joujou avec le Ti-Basic en meme temps et tout ca On-Calc.

C'est un peu ca l'objectif de mon programme maintenant.
Au debut c'etait une librairie, qui fonctionnait au dessus du TIOS. C'etait rapide mais inutilisable car la syntaxe etait
dans le style Vertel; Ce qui n'aide franchement pas quand on fait des 100taines de ligne de code.

C'est pour ca que j'ai utiliser le soft de K.K. pour rendre les fonctions accessible en TI-Basic directement.

Mais finallement la vitesse ne m'a pas satisfait. Alors j'ai decider de faire un autre Basic.

Je pense que si je ne me decourage pas d'ici un mois on verra apparaitre un autre Basic.
Je sais qu y a GTC on-calc maintenant mais, je prefere l'idee d'avoir un language qui ne demande
pas achaque fois de recoder les routines de base.

Ca pourrait etre sympa d'avoir un Basic qui plus rapide pour faire du graphique, et des manipulations de memoire, tout en permettant de faire joujou avec le Ti-Basic en meme temps et tout ca On-Calc.

Vive les projets éparpillés!!!

oui c'est dommage... à moins que ton basic apporte un vrai plus en terme de langage

dans tous les cas, pensez à mon idée: http://www.tigen.org/forum/index.php?action=sujet&forum=14&cat=132&topic=2473&page=1#0

A mon avis, si on ne fait de l'interpreté que là où la vitesse n'est pas primordiale, y a de quoi faire des merveilles avec de tels outils.

Il se porte déjà mieux il me semble j'ose pas imaginer ce qu'il aurait sorti quelques mois auparavant

J'ai essayer une fois GFA, mais c'est vraiment pas tres proche Ti-Basic et c'est dommage.
Mais bon Si tu voulais rien ne t'empeche d'implementer les MACRO comme en C ;
pour qu'on puisse personnaliser la syntaxe a sa guise.

C'est dommage de restreindre les utilisateurs de GFA, pour des questions de syntaxe ou de language.

Moi je code uniquement en C, je ne vois pas en quoi je pourrai contribuer au projet GFA ; il est en Assembleur je suppose.

Si on bien dans la logique communautaire, on pourrait meme demander a Pollux de diffuser son preprocesseur comme un programme a part. Ce qui je pense aiderait enormement. C'est vrai qu'on ne va pas systematiquement se mettre a recoder
ce que les autres ont deja fait.

Le préprocesseur de GTC dépend d'une certaine infrastructure de parsing et de structures de données qui serait peut-être un peu trop lourde si on n'utilise pas le parseur C avec... Et puis c'est vraiment très très facile de réécrire un préprocesseur from scratch, surtout si on n'a pas besoin de se plier à la norme ANSI comme ça serait le cas pour geogeo s'il voulait rajouter un préprocesseur à son Basic ^^

Par contre, ce qui serait utile si qqun veut faire un autre langage compilé on-calc, ce serait de réutiliser le linker et le format de libs statiques de GTC ; là pour le coup il y aurait un gros avantage à avoir de l'interopérabilité entre les compilos (mélange de code C/asm/autre langage/libs statiques)

.1/
Comme j'ai déjà une petite expérience sur les jeux 2d, voici ce que je suggère.

Je pense que les paramètres "view*" ne sont pas nécessaire. En effet, il me semble que c'est au programmeur de se préocuper du nombre de ligne à afficher via le gestionnaire de caméra.

Ayant définit 3 types de taille de tiles via SpriteFunc, je ne pense pas qu'il soit nécessaire de donner à nouveau la taille des tiles (SpriteHeight width/height). L'info risque d'être redondante et vu que tu utilise 3 valeurs, code cela sur 1 octet (ça te laissera 253 autres valeurs)

L'info concernant le fait que ce soit en niveaux de gris ou non, je pense que cela dépend plutôt de la table de tiles et donc du code qui lira le contenu du fichier.

N'oublie pas de gérer le cas où la map est plus petite que la taille physique de l'écran. Sasume m'a confirmé que le TileMap Engine ne gère malheureusement pas ce cas là.

Ajoute un flag qui indique si la table d'indexes de la map est comprésée ou non. Cela risque d'être utile dans le cas de grosses et nombreses maps.

Voilà pour les suggestions et remarques.

Fred.

En fait dans le gestionnaire de camera :
- il y a les parametres de vue aussi
- je crois que j'ai mis la vue dans le MAPE pour definir la vu maximale et borner ainsi la vue.

En fait SpriteHeight est la taille reelle des sprites.Il faut savoir que les fonctions de sprite affiches des sprites de taille variable

- SprFunc1 : <=8
- SprFunc1 : <=16
- SprFunc1 : <=32

Les parametres Width/ Height sont les pas de deplacement entre l'affichage de chaque sprite.
Il peu arriver qu'on ai envie de laisser des espaces entre les sprites( dans le cas ou on ne fait pas un jeux )

L'ancien format du MAPD contenait des info sur 1 octet. Mais il a vite fallut reviser tout ca car pour lire les donnees,
a partir d'un pointeur char*, short* ou long* a n'importe quelle adressse, il est preferable qu'elle soit paire.

En fait le soucis que j'ai maintenant, c'est comment trouver une astuce pour integrer des animations dans un MAPD ?

J'ai bricoller le format afin d'avoir des animations dans chaque MAPE correspondant au differents plan.

Je debute sur TI et j'ai installe GTC , certaine sources TIGCC fonctionnent mais tous se qui a un rapport au virgule flottante bug
je n'arrive pas a compile des que j'ai le type float dans mes sources << il m'indique une erreur "," >> aidez moi !