Diablo2 Ti92 > Aide - Page 4

Mouais bah le moteur de jeu c'est moi qui le conçois en basic ^_^
Mais si vous pouvez m'aider à utiliser des base de données ça m'interesse :P

@+

CàD ?

Imagine, tu entres 20 armes différentes dans une base de données, avec des tonnes de caractéristiques à interpréter...
Imagine toutes les caractéristiques des objets de Diablo 2...

En basic, peut-on utiliser qqchose de plus puissant qu'une matrice ?

Pur, heu... Les data. En tant que liste de listes, ça fait comme une matrice mais avec des lignes de longueurs différentes.

Une solution simple: NE METS PAS TOUTES LES DONNEES.
Trouve une astuce qqpart. Utilise de préférence des listes,
rappelle toi que plus tu vas en bat à droite d'une matrice plus ça rame,
alors utilise les listes ou les strings avec des fonctions str..., genre
pour la force c'est le premier caractère du string, tu le récupère avec
un ord(left(str,1)).

Et ne mets pas toutes les données, encore une fois, tu n'y arriveras pas, ce sera un cauchemar. Pour une arme, mets le nom, la durabilité, et
la force dans une matrice m_arme (courte en hauteur).

Quand un mec tombe sur une arme, il tombe juste sur l'arme numéro
truc, tu va chercher dans m_arme.

Que des astuces comme ça. Fais un truc simple (encore une fois),
tu compliqueras après...

Ton avis est interessant... merci pour tes remarques

Ok pour exploiter les matrices facilement... mais du coup :
Je dois créer un programmer qui génère la description de l'objet en fonction des n° entrés dans la matrice "équipement"...??
Et pour faire mieux, tu proposes quoi ?

Pas de description.
Non, mets un nom simple, et puis fais des lignes réduites
(nom, force, durabl, description) dans une seule matrice,
chaque arme étant une ligne, (mais pas trop d'arme, surtout si
t'es sur 92)

Et n'oublies pas la taille des textes, c'est énorme, surtout par rapport
à la mem d'une 92...

Mieux vaut (selon moi...) enlever des fonctionnalités et mettre
plus de dialogues, de temps de jeu, d'ambiance etc par les textes,
plutôt que l'inverse, joli jeu complexe, mais sans but, ni background, etc...

Et si t'as d'immenses contraintes, gère en string ton équipement et
génère ta description. Ex: chaque arme a 4 lettres de description,
la première dit le type
[code]
If ord(left(desc,1))=4 Then
"un fouet"->descrip
ElseIf ........
If ord(mid(desc,2,1))=1 Then
descrip&" rouillé"->descrip
ElseIf ord(mid(desc,2,1))=2 Then
descrip&" de feu"->descrip
...
EndIf
[/code]
Et essaies de réduire la taille du code. Par exemple pour le ElseIf
j'aurais dû mettre une variable égale à ord(mid(desc,2,1)) et la
réutiliser à chqeu fois, vu que c'est constant.

Ainsi t'as une description construite en temps réel et de taille très réduite.

Ok merci pour toutes ces précisions
je vais voir ce que je peux faire avec tout ça

Blue Silk-> c quand même trop trop chelou de mêler asm à basic, si ta la compétence pour faires des trucs "super optimisés" en ASM, alors pourquoi ne fais-tu pas tout en assembleur???

nounoun> Tu devrais pas chercher à le comprendre... (enfin, si qq1 voit ce que je veux dire )

Ah ouais et l'aide elle est où O_o

Je bosse tjs tout seul... c'est pas très motivant... un coéquipier de développement en Basic ça n'existe pas ? pffuuuu

GoldenCrystal :
nounoun> Tu devrais pas chercher à le comprendre... (enfin, si qq1 voit ce que je veux dire )

tu m'expliques ????

nounoun
: Blue Silk-> c quand même trop trop chelou de mêler asm à basic, si ta la compétence pour faires des trucs "super optimisés" en ASM, alors pourquoi ne fais-tu pas tout en assembleur???

Parceque compétences d'optimisation != connaissance de la plate-forme.
Donc un gros bourrin qui a déjà de la sérieuse prog derrière lui, qui est trop fort et
maitrise chaque instruction du 68000 en sachant laquelle est la plus rapide (appelons-le Arnaud,
voulez-vous ? ) ne peut pas débarquer sur TI et tout faire....
Et au-delà de ça, comme je sais presque faire tout ce qui m'intéresse, ben j'aime
le Basic , il est beau le Basic, simple, et quand on veut faire très rapidement
un truc, on peut en Basic, et pas avec le reste. Et puis un moteur de RPG intéressera bien plus
de monde s'il est utilisable en Basic plutôt qu'en C ou en ASM, à cause du nombre de programmeurs Basic.

Thommas > Je veux bien t'aider, mais même si je connaît par coeur le Basic 92+/89,
la 92 j'ai pas essayé. Il y a des instructions identiques, je devrais t'être utile,
mais c'est pas ma spécialité...

BlueSilk :
Parceque compétences d'optimisation != connaissance de la plate-forme.
Donc un gros bourrin qui a déjà de la sérieuse prog derrière lui, qui est trop fort et
maitrise chaque instruction du 68000 en sachant laquelle est la plus rapide (appelons-le Arnaud,
voulez-vous ? ) ne peut pas débarquer sur TI et tout faire....

Si. Les ROM_CALLs sont documentés, il suffit de les utiliser.

Après les avoir appris, ce qui ne se fait pas en 20 secondes...

La référence est là pour qu'on n'ait pas à tout apprendre par cœur...

Le problème étant qu'on ne va pas en pratique voir chaque fonction au moment où on
en aura besoin seulement, vu que toute la structure du prog en dépend.

Ex: Il faut que tu saches à l'avance comment marche l'allocation de mem sur TI, que ça se
fait bien par handles 16 bits, pour réserver 2 octets sur ton stackframe. La déclaration des
variables en C ne peut se fait pas à la dernière minute, contrairement au C++ hein Kevin
(#et_PAN#). En C ça va encore, on ajoute une var à la déclaration. Mais en Assembleur, le
mec doit remonter dans son code pour changer le stackframe ou ajouter une var ? Il va finir
par se gourer.

BlueSilk :
Le problème étant qu'on ne va pas en pratique voir chaque fonction au moment où on en aura besoin seulement, vu que toute la structure du prog en dépend.

Tu crois que j'ai fait comment pour AutoClBr (mon premier vrai programme en assembleur, RUNPROG 1.00 qui le précédait était un simple appel à userlib::runprog)? Ben j'ai regardé à chaque fois s'il y a un ROM_CALL pour l'endroit que je voulais coder. Si je n'en ai pas trouvé, j'ai codé l'algorithme en fonction de ceux que j'ai trouvés.

Ex: Il faut que tu saches à l'avance comment marche l'allocation de mem sur TI, que ça se fait bien par handles 16 bits, pour réserver 2 octets sur ton stackframe.

Quel stackframe? En assembleur optimisé, on ne réserve pas les octets sur le stackframe à l'avance! On utilise des registres, et quand on n'en a plus, on spille les registres sur la pile. Et d'ailleurs on n'utilise pas nécessairement un stackframe, la stratégie -fomit-frame-pointer est d'habitude la plus efficace.
Quant au C, on ne réserve pas non plus les octets comme ça, le compilateur le fait.

La déclaration des
variables en C ne peut se fait pas à la dernière minute, contrairement au C++ hein Kevin (#et_PAN#).

Si, en C99, ça se fait. GCC le gère depuis la version 3.0!

En C ça va encore, on ajoute une var à la déclaration. Mais en Assembleur, le
mec doit remonter dans son code pour changer le stackframe ou ajouter une var ? Il va finir par se gourer.

S'il utilise les registres comme il faut, pas vraiment.
Évidemment, il faut se rappeler qu'est-ce qu'on a mis dans quel registre... Mais ça fait partie des "compétences d'optimisation"!

[cite]Kevin Kofler :

1) Ben oui, mais justement: t'as regardé à l'avance ce que tu pouvais faire,
ce qui était programmé, ce qui ne l'était pas. Donc même un expert nouveau venu
doit commencer par ça...

*Quel stackframe? En assembleur optimisé, on ne réserve pas les octets sur le stackframe à l'avance!*
Oui, c'est au cas où, si le programmeur veut en savoir plus sur le C par exemple,
qu'il fonctionne comme le C, ben il alloue son stackframe (*généralement*)
et donc s'il ne sait pas la taille des handles, il faut qu'il l'apprenne, et n'est
donc pas un expert TI du moment qu'il est un expert PC par exemple.

*Si, en C99, ça se fait. GCC le gère depuis la version 3.0!*
C'est dégueulasse. Le C99 me paraît maintenant si éloigné du K&R que je
devrais faire des versions du GCC non C99 pour mon système POSIX...

*S'il utilise les registres comme il faut, pas vraiment.
Évidemment, il faut se rappeler qu'est-ce qu'on a mis dans quel registre... Mais ça fait partie des "compétences d'optimisation"!*
Oui, pour le meilleur et pour le pire.

ça sufit les trolls là? merci

Pour en revenir au sujet du topic SVP

Mon projet a bien avancé aujourd'hui, j'ai redéfini une liste pour toutes les données du jeu...

Très bientôt j'espère pouvoir faire tourner un combat et traverser la première zone, les Contrées du Sang ^_^

"Thommas > Je veux bien t'aider, mais même si je connaît par coeur le Basic 92+/89,
la 92 j'ai pas essayé. Il y a des instructions identiques, je devrais t'être utile,
mais c'est pas ma spécialité..."
TI92+ et TI92 ça doit être très très similaire si tu veux mon avis
Alors oui ton aide me serait utile pour faire 2/3 morceaux de programme...

Si t'arrive à faire un système d'objet capable de respecter qqs contraintes, ça serait cool... je vais t'envoyer un mail si possible

Sur MSN : ThommaSC@hotmail.com

@+

lol thommas veux que que bss fasse les deux tiers [citation] 2/3 [/citation] de son prog !!!

Yeah

Le jeu tourne :P
c'est un petit peu lent... mais c'est du basic donc c'est logique...
D'ailleurs j'ai prévu cela... avec des "LOADING" pour faire classe lol... enfin disons plutôt qu'on sait que ça charge ^^
Est-il possible de compiler une bonne fois pour toute un prog basic pour que la ti n'est plus à le faire ???

Maintenant il ne me reste plus que qqs petits détails à implémenter... et bien sûr mettre la belle base de donnée des monstres de l'acte 1 et des caractéristiques des zones...
Sans oublier les quêtes...

Et le tout sera fun ^^

Je cherche tjs des volontaires pour m'aider...

Il me faut notamment un gars capable de me faire qqs graphismes !!

@++

"lol thommas veux que que bss fasse les deux tiers [citation] 2/3 [/citation] de son prog !!!"
J'ai pas compris... BSS = ???

Thommas :
"lol thommas veux que que bss fasse les deux tiers [citation] 2/3 [/citation] de son prog !!!" J'ai pas compris... BSS = ???

dsl planté dans le pseudo

nounoun > Ne soit pas désolé, tu as dit juste.

Bon je veux bien faire des graphismes, j'ai Diablo 2 et assez d'outils pour faire qqch avec les screenshots.

[SPECULATION]Pour la compilation on appelle ça la tokenisation. Le truc c'est qu'une fois que t'as fini ton programme soit sûr qu'il
ne puisse pas planter (des blocs Try), archive-le. Un programme Basic non archivé qui est simplement ouvert va être
considéré comme modifié et re-tokenisé. Dans la phase de développement on peut encore s'en foutre, mais pendant
le jeu lui-même, ben.... Faudra mettre dans le readme d'envoyer le jeu et de tout archiver tout de suite[/SPECLUATION]

(Tout ce qui est ci-haut paut être faux. Mais ça peut être vrai.)

La tokenisation n'est pas à proprement parler une compilation, car un prog tokenisé est encore interprêté. Il n'y a pas de risque de plantage avec un prog non tokenisé, mais des problèmes de compaptibilité dus au langage utilisé pour coder en Basic (français, anglais, etc).
Une fois tokenisé, le programme devient compaptible à 99% avec les calc dans toutes les langues.
99% car des chaînes de caractères comme "NONE", etc, ne sont pas tokenisées d'une manière particulière, elles sont juste évaluées à leur propre valeur. Et d'une langue à l'autre, ces chaînes de caractères varient, d'où des incompaptibilités.

BSS :
[/SPECLUATION] Faudra mettre dans le readme d'envoyer le jeu et de tout archiver tout de suite[/SPECLUATION]

En fait, le simple fait de verouiller le programme en RAM, sans l'archiver, suffit à empêcher la détokenisation.

Mais l'archivage a ses avantages lors d'un reset (peu probable dans ce cas, en effet)

De toutes façons s'il programme sur 92 simple ça règle le problème.

Oui.