fichiers externes - Page 1

salut, qqn pourrait m'expliquer comment faire des fichiers externes pour mes map svp
j'ai des fichier .shk et .inc
aussi est ce que c plus long pour y acceder si c dans un fichier externe
merci d'avance

-

je veut po faire de lib moa

-

met les dans des strings
y'a plein de progs qui le font (par ex dans tigcc tools suite de la tict)

gugusg a écrit :
salut, qqn pourrait m'expliquer comment faire des fichiers externes pour mes map svp
j'ai des fichier .shk et .inc
aussi est ce que c plus long pour y acceder si c dans un fichier externe
merci d'avance

Tu crée un fichier binaire (mais tes fichiers shk en sont déjà normalement) et tu le transformes en fichier de type personnalisé avec ttbin2oth de la TIGCC Tools Suite. Ensuite, pour le lire, tu utilises les ROM_CALLs documentés là.

-

Orion_ a écrit :
je pense que sa serait plus simple d'utiliser des lib m'enfin, tu fait comme tu veut

Arrêtez avec vos librairies de données! Les librairies dynamiques ne sont pas faites pour les données, les fichiers de type personnalisé le sont!

Les libs c'est pas super pratique pour gérer par exemple des niveaux de jeux en externe.
Ce qui est justement pratique avec les niveaux externes c'est qu'il n'est pas nécessaire de tous les avoir en mémoire pour jouer au jeu. Or si une lib manque, impossible de lancer le jeu.
En plus ça limite à un nombre déterminé de niveaux alors qu'on peux toujours rakjouter des fichiers externes.

Ximoon a écrit :
Les libs c'est pas super pratique pour gérer par exemple des niveaux de jeux en externe.
Ce qui est justement pratique avec les niveaux externes c'est qu'il n'est pas nécessaire de tous les avoir en mémoire pour jouer au jeu. Or si une lib manque, impossible de lancer le jeu. En plus ça limite à un nombre déterminé de niveaux alors qu'on peux toujours rakjouter des fichiers externes.

Avec PreOS tu peux loader les libs dynamiquement, donc tu n'as plus ce problème

lol
tu m'envoie la version 92?

justement les strings sont compatibles avec tous les AMS, tous les kernells, tous les hw, marchent en nostub enfin bref c'est bien pratique.

-

tu les charges de la même façon, suaf que tu as une petite manip à faire pour choper l'adresse au lieu de l'avoir directement par le lib@xxxx.

Ximoon a écrit :
justement les strings sont compatibles avec tous les AMS, tous les kernells, tous les hw, marchent en nostub enfin bref c'est bien pratique.

Arrêtez de mettre vos données dans des strings! Comme l'indique le nom, ce type est fait pour des chaînes de caractères! Je ne sais pas ce qui est pire: les librairies de données ou les strings de données. Les types personnalisés sont faits pour les données!!!

Pas de types personnalisés sur 92

Il n'y a que Ximoon et PpHd pour encore programmer sur ces dinosaures.

sur 92+, c clair que les types perso, c bien pratique : archives compressées en plusieurs morceaux, extractibles séparément (ttarchive et ttpack powa !)
mais c vrai que sur 92 simple....

enfin, 92 simple powa qd même (un peu moins que 92+, mais powa qd même : ma 92+ est une 92 simple + module )

Je suis desole de continuer a programmer sur 92

Bon, mais tu devrais quand-même mettre des types personnalisés pour tes fichiers sur TI-89/92+. Il y a juste les octets à la fin à changer.

Et la compatibilite des fichiers avec la 92 ? SMA est compatible 92 II/+/89 !

Kevin Kofler a écrit :
Il n'y a que Ximoon et PpHd pour encore programmer sur ces dinosaures.

Et il n'y a que Kevin pour nous le reprocher...
D'ailleurs si tu me paye le module je te promet que je me met à programmer sur 92+.
Et puis qu'est-ce que ça chage que ce soit une string ou autre chose, à la fin? Du moment que ça marche?
Et puis y'a même po Fargo sur 92+

Le problème, c'est que AMS et/ou les logiciels de liaison (TI-GraphLink, TI-Connect, ...) pourrai(en)t faire des choses avec des chaînes de caractères qui ne feraient pas du bien à vos données, alors qu'avec un type personnalisé, ces logiciels savent qu'il peut y avoir des données binaires dedans et les traîteront par conséquent. La raison: c'est tout simplement sale de mettre des données pouvant contenir des caractères nuls dans une chaîne de caractères: ce n'est pas du tout fait pour ça! Une chaîne de caractères est un type de variable pouvant contenir tous les caractères de 1 à 255. Le caractère 0 est interdit à l'intérieur d'une chaîne de caractères (il est utilisé au début et à la fin pour la délimiter, mais interdit à l'intérieur), et donc pratiquement toutes les chaînes de caractères stockant des données binaires sont invalides!

Et il y a 2 raisons pour lesquelles je vous reproche d'encore programmer pour TI-92:
- Celle-ci.
- Le fait que programmer pour TI-92 signifie programmer pour kernel.
Ces 2 techniques sont dépassées ("deprecated"), et il faudra s'y adapter (c'est-à-dire utiliser les nouvelles techniques qui les remplacent).

Et Ximoon, tu as la chance d'avoir une calculatrice dont on peut mettre à jour le matériel, donc profites-en, au lieu de râler parce que les programmeurs ne pensent plus aux calculatrices dépassées!

Alors la explique moi comment programmer sur 92 sans kernel !
Si utilisez les backup. Tres rigolo en effet

Et puis la tu cherches des noises pour rien.

Euh, relis bien ce que j'ai dit, je pense que tu n'as pas bien compris.
Il faut abandonner les TI-92 justement parce qu'elles ne permettent pas le _nostub!

Ou alors on fait comme Samuel Stearley avec YAPT: on fait 2 versions séparées: une _nostub pour TI-89/92+ et une autre pour Fargo.

Moi j'aimerais plutot que les kernels evoluent pour assurer une compatibilite 92/92+/89, mais c'est pas gagne.

ça va pas être triste pr assurer sur 92 simple ce qu'on a sur 92+ !

Kevin Kofler a écrit :
Le problème, c'est que AMS et/ou les logiciels de liaison (TI-GraphLink, TI-Connect, ...) pourrai(en)t faire des choses avec des chaînes de caractères qui ne feraient pas du bien à vos données, alors qu'avec un type personnalisé, ces logiciels savent qu'il peut y avoir des données binaires dedans et les traîteront par conséquent. La raison: c'est tout simplement sale de mettre des données pouvant contenir des caractères nuls dans une chaîne de caractères: ce n'est pas du tout fait pour ça! Une chaîne de caractères est un type de variable pouvant contenir tous les caractères de 1 à 255. Le caractère 0 est interdit à l'intérieur d'une chaîne de caractères (il est utilisé au début et à la fin pour la délimiter, mais interdit à l'intérieur), et donc pratiquement toutes les chaînes de caractères stockant des données binaires sont invalides!

l'expérience prouve que ça marche bien quand même, et pour les miennes ça a même tendance à les mettre en lecture seule, c'est donc très pratique!

Et il y a 2 raisons pour lesquelles je vous reproche d'encore programmer pour TI-92:
- Celle-ci. - Le fait que programmer pour TI-92 signifie programmer pour kernel.

Nan sérieux?

Ces 2 techniques sont dépassées ("deprecated"), et il faudra s'y adapter (c'est-à-dire utiliser les nouvelles techniques qui les remplacent).
Et Ximoon, tu as la chance d'avoir une calculatrice dont on peut mettre à jour le matériel, donc profites-en, au lieu de râler parce que les programmeurs ne pensent plus aux calculatrices dépassées!

J'ai franchement pas que ça à faire que de claquer $99 pour te faire plaisir...

bon, j'ai essaye la methode librairie read_only
j'ai deux problemes:
- il me demande une entree main alors que j'en ait po besoin (et orion n'en a po mis)
- je voudrait mettre mes fichiers .inc et .shk
je sais comment acceder aux points shk (ce sont des incbin), mais pour les .inc je sais po comment y acceder car ce sont des includes et j'en ait besoin pour decompresser

mais dans ce cas si je met ma routine de decompression dans le fichier externe, est ce que si je fait un lea table,a0 dans mon prog principal, le a0 pointera t-il tjrs sur table si je veut m'en servir dans le fichier externe ???

merci d'avance

gugusg a écrit :
bon, j'ai essaye la methode librairie read_only
j'ai deux problemes:
- il me demande une entree main alors que j'en ait po besoin (et orion n'en a po mis)

Ajout xdef _library

- je voudrait mettre mes fichiers .inc et .shk
je sais comment acceder aux points shk (ce sont des incbin), mais pour les .inc je sais po comment y acceder car ce sont des includes et j'en ait besoin pour decompresser

Ben je ne sais pas trop. Moi je ne m'en sers jamais.
Tu peux les mettre comme des variables :
include "machin.inc"
drivdata@001A: dc.w machin_include

mais dans ce cas si je met ma routine de decompression dans le fichier externe, est ce que si je fait un lea table,a0 dans mon prog principal, le a0 pointera t-il tjrs sur table si je veut m'en servir dans le fichier externe ???
merci d'avance

Oui. C'est le principal avantage.