Fichier Externe (Sprites) - Page 1

Bonsoir,
je continue lentement mais surement mon TripleTriad 68K mais voila la barre fatidique des 64Ko est passée.
Je voudrais savoir comment faire pour créer un fichier externe qui contiendrait tous les sprites des Cartes (qui représente la moitié de la taille du jeu) afin de régler le problème.

Autre question: comment peut-on appeler les Sprites dans une fonction ensuite vu qu'ils sont dans un autre fichier??

Merci d'avance pour vos réponses...

Utilise PreOS : t3

Tu mests tous tes sprites dans une lib, et tu exportes tes sprites ou tes tables de sprite. Tu adresses ces sprites directement depuis ton programme. Le kernel s'occupera de lier ton code vers les données visées au chargement de ton programme.

Ouais c'est une bonne idée.
Mais il n'y aurait pas une solution sans PreOS (j'aimerais que mon prog reste nostub).

Sinon, tu peux aussi le faire à la main. Ça se fait en deux étapes : d’abord un programme (sur PC ou TI) crée le fichier externe, ensuite tu l’utilises dans ton jeu.

Pour créer le fichier, si tu fais ça depuis ton PC, tu dois écrire un prog qui crée un fichier contenant tes données, dans le format qui te convient, puis tu le convertis en un fichier à envoyer sur ta TI avec ttbin2oth. Si tu préfères réaliser cette étape à partir d’un programme sur TI, celui-ci doit copier tes données dans une zone mémoire, puis créer un fichier dans la vat associé à ces données (voir les fonctions de vat.h).

Ensuite, pour utiliser les données du fichier externe, tu peux, à partir des fonctions de vat.h, obtenir l’adresse du début des données. À partir de là tu pourras retrouver tout le reste.

(effectivement, PreOs te simplifie grandement la tâche)

c'est un peu dommage de changer de technique de programmation juste pour un "problème" qui n'en est pas un et qui n'est pas bien compliqué à résoudre...

C'est une solution comme une autre (je vois aussi la "dll nostub").

On est amateurs, ça lui ouvre un horizon qu'il ne connait pas, c'est tout. 99% des nostubiens sur TIGCC l'étant par ignorance totale de ce que propose PreOS à un développeur, je ne pense pas que ce soit inutile de lui dire que "là aussi, il y a une solution qui existe", et qui est par ailleurs de loin beaucoup plus simple que la solution de Sasume.

"Je préfère le nostub parce que c'est mieux" est souvent la seule connaissance du mode kernel qu'on la plupart des développeurs sur TI (merci à Kernel Killer d'avoir travaillé à cet état d'obscurantisme)...

La solution de Sasume marche très bien évidemment, mais je la préfère pour quand on bosse sur des fichiers éditables on-calc. Le kernel faisant tout ce qui est recherche dans la VAT + lock + libération, on se passe de pas mal d'étapes, sans parler des étapes de ttbin2oth sur PC.

Merci Sasume,
j'ai deja télécharger TI Tool suite http://www.ticalc.org/pub/win/tt.zip
mais c'est moi qui rêve ou il n'y a pas toute la doc dedans ??(on dirait
qu'il ya que la docs pour convertir des ebooks et celle sur ttstart rien d'autre)

La TI Tools Suite est intégrée à GCC4TI ( http://trac.godzil.net/gcc4ti/ )
Celle de Ti-Calc, je ne sais pas si elle est exempte de bugs. Après, ça dépend aussi de quel utilitaire tu as besoin.

Folco , limite je pourrais sortir 2 versions du jeu (nostub et kernel) mais faut-il changer beaucoup de chose au code sources et au niveau d'extgraph pour que ça fonctionne avec
PreOS??

Non, rien. Tu pourras même enlever certaines choses qui sont déjà prises en charge par PreOS.

Ah tu as raison Folco les fichiers sont bien présent dans GCC4TI\bin j'avais pas vu
et Sasume au niveau d'exgraph c'est bon avec PreOS??

sam22 : http://www.mirari.fr/pM1v

La page rapide et magique de tout ce que t'apporte PreOS. Pour info, sache que TIGCC en fait à peine la moitié, et en plus en te disant "c'est du nostub !"... alors qu'en fait chaque programme embarque un équivalent de mini-preos pour faire tout ce qu'il a à faire (code de démarrage, "DLL nostub" et toutes ces conneries).

Ce sont les fonctions LibsBegin et Libs* qui auraient pu t'intéresser.

Si PreOS est là, c'est pas pour être inutile, mais bien que ce qu'il propose est très utilse ou indispensable. Le nostub ré-invente la roue du kernel pour chaque programme. Perso (mais c'est -ton- programme), je m'en tiendrais à une seule version et basta .

(cross) Oui, aucun souci pour utiliser ExtGraph avec PreOS, PreOS ne saura même pas que ExtGraph est utilisé, vu que c'est linké en statique.

(euh à mon avis sam22 ne connaît pas l’ASM, donc il ne risque pas de comprendre Ramcalls.txt )

Pas de problème pour extgraph, mais c’est vrai, comme l’a fait remarquer Zephyr, si ton programme est déjà bien avancé ce n’est pas forcément intéressant d’utiliser PreOS…

Ya beaucoup d'exemples en C (notamment ceux qui pourraient de l'intéresser). Puis l'avancement du programme n'est définitivement pas un argument, désolé

Je me permets juste de signaler que le topic est devenu tout sauf objectif depuis le post ./6.

Folco, on a déjà eu Kevin qui cherchait à convertir tout le monde au nostub à son époque, évite de faire la même chose dans le sens inverse... mentionner que le kernel existe et qu'il présente d'autres avantages, très bien. Raconter n'importe quoi pour essayer de le vendre, niet, tu fais un topic perso et tu colles tout dedans si tu y tiens, mais pas de propagande ailleurs.

Folco (./2) :
Utilise PreOS : t3

N'importe quoi, PreOs ne facilite en rien l'utilisation d'un fichier de données en C.

Tu mests tous tes sprites dans une lib

N'importe quoi. Les données, ça se met dans un fichier de données, pas dans une lib!

Va voir les fonctions de vat.h pour lire un fichier de données. Sinon, le linker de TIGCC propose aussi la création automatique d'un fichier de données pour ton programme, mais avec certaines limitations (par exemple, tu ne peux pas avoir des tableaux de pointeurs globaux qui nécessitent des relogements à l'intérieur des données). Je conseille plutôt de créer le fichier de données pour tes sprites à la main.

Ce tutorial devrait t'aider (et désolé pour les problèmes de charset qui font que les caractères accentués n'apparaissent pas correctement, je vais faire mon possible pour corriger ça au plus vite).

Et ne te fais pas avoir, c'est toujours TIGCC (http://tigcc.ticalc.org/) le vrai TIGCC, pas GCC4TI!

Et sinon, voici une release de la TIGCC Tools Suite en standalone, qui marche avec TIGCC. Si Lionel ne fera plus de releases standalone, j'en ferai, pour l'instant, utilisez celle-là qui fonctionne très bien.

Et ne te fais pas avoir, c'est toujours TIGCC ( http://tigcc.ticalc.org/ ) le vrai TIGCC, pas GCC4TI!

Tu es incorrigible, Kevin... mais on ne peut pas te répondre, ça serait trop off-topic.
Pas plus qu'on ne peut continuer sur kernel/AMS native, d'ailleurs.

Oui, je compte faire des releases standalone des TI-68k Developer Utilities, ce que tu savais déjà. Dors un peu plus, tu te souviendras peut-être mieux des choses...
J'en profite pour rappeler que "TI-68k Developer Utilities" est un nom sur lequel nous nous sommes mis d'accord tous les deux dans un autre topic. Le lien est dans le changelog du commit implémentant le changement de nom, dans le repo SVN de GCC4TI. J'avais l'accord de Thomas pour procéder à un changement de nom.
(bon, ça aussi était off-topic, mais vu que je ne peux pas lui répondre là où il m'a posé la question parce qu'il s'est déconnecté, et qu'il a aussi abordé le sujet ici...)

Kevin on a dit stop au subjectif ! Sam, sache que GCC4TI existe et qu'il est très bien. Il parait qu'il est plus à jour que TIGCC.

-Il paraît +Il est un fait que. TIGCC 0.96 Beta 8 fêtera bientôt ses trois ans.
Mais ce n'est pas le sujet

Lionel Debroux (./18) :
Oui, je compte faire des releases standalone des TI-68k Developer Utilities, ce que tu savais déjà.

Je sais que tu le prévoyais, mais comme tu ne l'as toujours pas fait, je me suis dit que tu as peut-être changé de plan.

Et il est aussi un fait que certains des changements de GCC4TI ont introduit des régressions, que les corrections de bogues qu'il y a eu depuis TIGCC 0.96 Beta 8 ne concernent pas grand monde (donc une release n'est pas urgemment nécessaire) et que si vraiment vous rencontrez un bogue déjà corrigé dans le CVS, j'envoie une version à jour du binaire concerné sur demande (comme je l'ai toujours fait, c'est toujours valable). (Offre non valable pour les exécutables en Delphi parce que je n'ai pas Delphi et que je suis donc moi-même obligé de demander à quelqu'un de les compiler pour moi pour les releases. Mais ce n'est pas là que se trouvent les bogues qui vous empêcheront de travailler de toute façon. )

Oui, je compte faire des releases standalone des TI-68k Developer Utilities, ce que tu savais déjà.

Je sais que tu le prévoyais, mais comme tu ne l'as toujours pas fait, je me suis dit que tu as peut-être changé de plan.

Je sais que je change plus facilement d'avis que toi, mais je n'ai pas changé de plan là-dessus
C'est toi qui avais expliqué pourquoi ça avait du sens de continuer à faire des releases standalone, et pas seulement pour les gens qui utilisent TIGCC.

Et il est aussi un fait que certains des changements de GCC4TI ont introduit des régressions

Il y a une régression en particulier, passée à travers les tests, et son erratum est dûment documenté sur le site de GCC4TI.
Un autre fait est que celui qui ne fait rien, ne risque pas de se tromper

Voila j'ai enfin eu le temps de me replonger un peu sur le problème. Donc, grâce au tuto de Kevin (merci d'ailleurs)
j'ai réussi à créer un fichier contenant un Sprite et à l'afficher en lisant ce fichier (c'est juste un test pour le principe)
mais (je vais peut-etre paraître bête) comment récupérer ce fichier qui se trouve seulement sur TiEmu???

C'est le tuto de Benjy, pas le "tuto de Kevin".

Tu envoies ce fichier depuis la calculatrice émulée par TiEmu comme tu l'enverrais à une autre calculatrice, TiEmu attend déjà en réception côté PC normalement (mais si ça ne marche pas, vérifie que l'option soit cochée dans le menu, elle l'est par défaut).

MERCI Kévin ça marche!!
Je vais enfin pouvoir continuer mon projet.

On peut arrêter les conneries deux minutes ?