Accueil Ti-Gen Foire Aux Questions Chat sur le chan #tigcc sur IRC
Liste des membres Rechercher Aide
Bienvenue Invité !   Se connecter             Mes sujets   
Administrer
0 membre(s) et 1 visiteur(s) actif(s) durant les 5 dernières minutes Utilisateurs actifs : Aucun membre + 1 visiteur
Avant de poster sur le forum, il y a des régles de bases à respecter pour une bonne entente et un respect de tous.
Veuillez lire la charte du forum.
  :: Index » GFA-Basic TI68K » Bugs et suggestions » Problème avec une font (106 réponse(s))
./REPRISE DU POST PRECEDENT (post n°38)   Marquer comme non lu.
Sasume Ecrit le: Mercredi 14 décembre 2005 à 17:21 Déconnecté(e)    Voir le profil de Sasume Envoyer un email à Sasume Visiter le site WEB de Sasume Envoyer un message privé à Sasume  

C'est peut-être un peu tard pour le dire, mais il y a un outil dans le package dev de preos ou pedrom qui sert à convertir un source AS vers A68k.
    
./Post n°39   Marquer comme non lu.
Kevin Kofler Ecrit le: Mercredi 14 décembre 2005 à 20:16 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Martial Demolins :
boaf, tu sais, pour les ROM calls, j'en utilise si peu... il est beaucoup plus rapide et plus court de faire un memcpy ou un memcmp à la main en asm que de faire appel à celui du tios

Les ROM_CALLs de AMS 2, ce ne sont justement pas memcpy/memcmp, mais des trucs nettement plus complexes qu'il serait dommage de réinventer. J'ai l'impression que tu ne les connais même pas, ce qui est très mauvais signe. Réveille-toi, on n'est plus en 1999!

je n'utilise les ROM call que pour les allocations mémoire et les manipulations dans la vat.

Et ben, documente-toi, parce qu'il y en a beaucoup plus.

ceci dit, les fonctions de vat.h, je les trouve vite gonflantes à utliser, j'ai relu hier soir le tuto sur la structure de la fat/vat (v1.2 de Benoit Scherrer), je sens que je vais hacker là-dedans que ça sera un vrai bonheur! :D

<SARCASM>Super</SARCASM>, vas-y, programme comme en 1999, et tes programmes seront aussi (in!)stables qu'en 1999. #roll#
Par exemple, rajouter un fichier n'importe où dans la VAT va faire foirer des trucs, parce que AMS attend une liste triée (donc faut déjà commencer par un memmove). Et il y a peut-être d'autres invariantes que tu casses avec tes hacks sans le savoir, et peut-être les versions futures de AMS en rajoutent encore d'autres.

surtout que le format ne risque pas de changer d'un jour à l'autre, donc ça sera parfaitement safe.

Bah si, il risque de changer. Par exemple, TI pourrait rajouter des champs à la structure SYM_ENTRY. La structure a déjà grandi de 2 octets entre la TI-92 et la TI-92+. S'ils font ça, tes hacks dans la VAT, bah, ils foirent totalement.

Il y a une API pour une raison: c'est l'interface par laquelle tu es censé accéder aux données. Accéder directement aux données privées -> poubelle! Cherche "information hiding" avec Google, ils t'expliqueront pourquoi c'est dingue de faire ce que tu fais.

Sasume :
C'est peut-être un peu tard pour le dire, mais il y a un outil dans le package dev de preos ou pedrom qui sert à convertir un source AS vers A68k.

C'est dans PedroM, et ça n'est fait que pour convertir la sortie de GCC pour les morceaux en C de PedroM, ça ne marchera pas avec n'importe quelle source GNU as (logique, GNU as est plus puissant que A68k, donc il est impossible de convertir toutes les sources GNU as vers A68k).
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°40   Marquer comme non lu.
FpgForce Ecrit le: Mercredi 14 décembre 2005 à 22:40 Déconnecté(e)    Voir le profil de FpgForce Envoyer un email à FpgForce Envoyer un message privé à FpgForce  

Il y a une API pour une raison: c'est l'interface par laquelle tu es censé accéder aux données. Accéder directement aux données privées -> poubelle! Cherche "information hiding" avec Google, ils t'expliqueront pourquoi c'est dingue de faire ce que tu fais.
Je suis d'accord avec Kevin là dessus c'est pas très propre d'aller tripoter directement la VAT

Celà dit tu fais ce que tu veux, si tu t'eclate à bidouiller ça, vas-y =)
    
./Post n°41   Marquer comme non lu.
Folco Ecrit le: Jeudi 15 décembre 2005 à 08:32 Déconnecté(e)    Voir le profil de Folco Envoyer un email à Folco Envoyer un message privé à Folco  


ok merci à tous, je préfère 100 fois un avis comme celui de FpgForce, capable de prévenir du problème (dont je suis parfaitement au courant Kevin, t'inquiète pas! #triroll#) tout en disant au final Fais que voudras (Rabelais pour les littéraires).

Le véritable problème est en fait celui-ci: il n'y a aucun tuto sur la VAT, qui explique ce que le TIOS attend et dans quel ordre... ce n'est pas le petit """tuto""" sur le site qui soit explicatif, surtout en assembleur en ce qui concerne les structures.
<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."
    
./Post n°42   Marquer comme non lu.
Folco Ecrit le: Jeudi 15 décembre 2005 à 11:52 Déconnecté(e)    Voir le profil de Folco Envoyer un email à Folco Envoyer un message privé à Folco  


Au fait, il y avait pas de doc avec la lib.

Donc quand j'ai arrangé le header, j'ai pas trop su si les registres détruits étaient les bons. Je regarderai le source de chaque fonction pour en être sûr.

Sinon, pourquoi a-ton des définitions de FONT_OR/MODE_OR, FONT_XOR/MODE_XOR etc... ces définitions me semblent être en fait des doublons. Il faudra que je me penche dessus, mais en tout cas, ça me parait bizare.

Sinon pour le header, pourrais-tu (geogeo %)) regarder si l'usage que j'ai donné des fonctions est bien le bon? tu verras au passage, je les ai renommées (et oui, un des avantages de l'exportation par ordinal, pas besoin de préfixes à ralonge sur les noms de fonction/vars %)), mais tu devrais t'y retrouver facilement.

Merci! :)


edit: il n'y avait quà un seul endroit du code qu'était utilisé MODE_XOR, j'ai donc viré ces définitions. Il ne reste plus que des FONT_XOR etc...
-Edité le Jeudi 15 décembre 2005 à 14:34 par Martial Demolins-
<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."
    
./Post n°43   Marquer comme non lu.
Kevin Kofler Ecrit le: Jeudi 15 décembre 2005 à 15:46 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Martial Demolins :
Le véritable problème est en fait celui-ci: il n'y a aucun tuto sur la VAT, qui explique ce que le TIOS attend et dans quel ordre...

Parce que tu es censé utiliser les fonctions au lieu d'aller trifouiller les données directement.

Martial Demolins :
Donc quand j'ai arrangé le header, j'ai pas trop su si les registres détruits étaient les bons.

Raah, ces programmeurs assembleur... ;) Une fonction est toujours présupposée détruire %d0-%d2/%a0-%a1 et %ccr (et rien d'autre).
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°44   Marquer comme non lu.
Kevin Kofler Ecrit le: Jeudi 15 décembre 2005 à 15:55 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Ensuite:
  • Quel est le problème avec la détection de modèle et de version matérielle de TIGCCLIB? Pourquoi ne veux-tu pas l'utiliser?
  • Pourquoi utiliser les fonctions de dialogue obsolètes de graphlib alors qu'il y en a de nettement plus puissantes directement dans la ROM?

C'est pour être "au fond dans le kernel"? Pour me faire ch**r? Par nostalgie? Parce que je ne vois pas d'explication rationnelle à ton refus d'utiliser tout ce qui a été développé ou découvert depuis 1999. #roll#
-Edité le Jeudi 15 décembre 2005 à 16:02 par Kevin Kofler-
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°45   Marquer comme non lu.
geogeo Ecrit le: Jeudi 15 décembre 2005 à 16:17 Déconnecté(e)    Voir le profil de geogeo Envoyer un email à geogeo Visiter le site WEB de geogeo Envoyer un message privé à geogeo  


Martial Demolins :
Au fait, il y avait pas de doc avec la lib.

Donc quand j'ai arrangé le header, j'ai pas trop su si les registres détruits étaient les bons. Je regarderai le source de chaque fonction pour en être sûr.

Sinon, pourquoi a-ton des définitions de FONT_OR/MODE_OR, FONT_XOR/MODE_XOR etc... ces définitions me semblent être en fait des doublons. Il faudra que je me penche dessus, mais en tout cas, ça me parait bizare.

Sinon pour le header, pourrais-tu (geogeo %)) regarder si l'usage que j'ai donné des fonctions est bien le bon? tu verras au passage, je les ai renommées (et oui, un des avantages de l'exportation par ordinal, pas besoin de préfixes à ralonge sur les noms de fonction/vars %)), mais tu devrais t'y retrouver facilement.

Merci! :)


edit: il n'y avait quà un seul endroit du code qu'était utilisé MODE_XOR, j'ai donc viré ces définitions. Il ne reste plus que des FONT_XOR etc...
-Edité le Jeudi 15 décembre 2005 à 14:34 par Martial Demolins-


Pour revenir à la VAT je suis 100% d'accord avec Kevin Kofler. C'est crade de la bidouiller. Néanmoins si tu te penches sur la VAT tu trouveras quantité d'infos pour exploiter correctement les fonctions du TIOS.

Concernant la lib elle fait les mêmes passages d'arguments que le TIOS. C'est à dire quel peut détruire d0/d1/d2, a0/a1 mais pas les autres registres. Les 'Destroy' sont là pour moi car GFA Basic optimise les passages d'arguments.

MODE_XXX, FONT_XXX c'est la même chose. J'utilise MODE_XXX quand je programme la librairie pour bien faire la différence entre les fonctions graphiques et l'affichage d'un caractère (gras, italique...). Mais je conseil d'utiliser FONT_XXX quand on utilise la librairie histoire d'éviter des conflits dans les constantes...
Tous tes passages d'arguments par la pile sont faux, plus précisément dans les commentaires.

dans DrawChar par exemple:

10(sp) *mem
8(sp) graphical mode
6(sp) font mode
4(sp) char
2(sp) y
0(sp) x


Devient:

0(sp) *mem
4(sp) graphical mode
6(sp) font mode
8(sp) char
10(sp) y
12(sp) x


Idem dans DrawStr

Pour terminer si j'ai mis
FONT_SIGNATURE
FONT_CHAR257
FONT_CHAR256
FONT_SIZE_Y
FONT_SIZE_X
FONT_MODE
FONT_NAME
FONT_VERSION
FONT_COMMENT

C'est parce que tout simplement ce sont des constantes qu'on ne doit pas toucher par affectation bien entendu.
L'utilisateur peut les utiliser sans les modifier contrairement aux autres variables exportées.
D'ailleur j'ai oublié de les protéger. Il faut ajouter const devant.
Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic
    
./Post n°46   Marquer comme non lu.
geogeo Ecrit le: Jeudi 15 décembre 2005 à 16:20 Déconnecté(e)    Voir le profil de geogeo Envoyer un email à geogeo Visiter le site WEB de geogeo Envoyer un message privé à geogeo  


Toute fois il est clair que le top serait de faire en sorte que les vriables modifiables du type FONT_standard_italic_size... soient des variables copiées et utilisées directement dans la pile et non dans le programme!

Faut que je revois tout ça.
Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic
    
./Post n°47   Marquer comme non lu.
Folco Ecrit le: Jeudi 15 décembre 2005 à 16:56 Déconnecté(e)    Voir le profil de Folco Envoyer un email à Folco Envoyer un message privé à Folco  


Kevin Kofler :
Martial Demolins :
Le véritable problème est en fait celui-ci: il n'y a aucun tuto sur la VAT, qui explique ce que le TIOS attend et dans quel ordre...

Parce que tu es censé utiliser les fonctions au lieu d'aller trifouiller les données directement.

Excuse-moi, je me suis mal exprimé. Je ne demande pas mieux que d'utiliser les fonctions de vat.h plutôt que de hacker, je te rassure, même si connaitre le format binaire de la vat représente un intérêt pour la curiosité personnelle. Ce que je dis, c'est que les fonctions sont décrite, mais il n'y a pas grand chose pour dire lesquelles utiliser et dans quel ordre quand on veut créer une variable, la rechercher etc...

Martial Demolins :
Donc quand j'ai arrangé le header, j'ai pas trop su si les registres détruits étaient les bons.

Raah, ces programmeurs assembleur... ;) Une fonction est toujours présupposée détruire %d0-%d2/%a0-%a1 et %ccr (et rien d'autre).

mais oui bien sûr je suis c*n :D
je vais appliquer ça, merci =)

Kevin Kofler :
Ensuite:
  • Quel est le problème avec la détection de modèle et de version matérielle de TIGCCLIB? Pourquoi ne veux-tu pas l'utiliser?
  • Pourquoi utiliser les fonctions de dialogue obsolètes de graphlib alors qu'il y en a de nettement plus puissantes directement dans la ROM?

C'est pour être "au fond dans le kernel"? Pour me faire ch**r? Par nostalgie? Parce que je ne vois pas d'explication rationnelle à ton refus d'utiliser tout ce qui a été développé ou découvert depuis 1999. #roll#

Parceque le jour où ta détection de HW foirera avec une nouvelle ROM/TI, tu patcheras tous les programmes nostub, tandis que je regarderai PpHd mettre PreOS à jour :p

Pour graphlib, j'ai juste cherché à regarder les fonctions, par curiosité encore une fois, rien de plus. :)



geogeo->
MODE_XXX, FONT_XXX c'est la même chose. J'utilise MODE_XXX quand je programme la librairie pour bien faire la différence entre les fonctions graphiques et l'affichage d'un caractère (gras, italique...). Mais je conseil d'utiliser FONT_XXX quand on utilise la librairie histoire d'éviter des conflits dans les constantes...

ok, je comprends. en fait, ça a plus eu tendance à m'embrouiller qu'à me simplifier la vie :D

Tous tes passages d'arguments par la pile sont faux, plus précisément dans les commentaires.

ah oui? dans un appel de ROM call, les arguments sont passé en ordre inverse. Donc le *mem de la fin d'une définition doit être passé en premier sur la pile non? donc on le trouve à 10(sp) et non à 0 (sp)... Je ne comprends pas pourquoi tu dis ça, je devrai regarder le code pour réellement comprendre.

C'est parce que tout simplement ce sont des constantes qu'on ne doit pas toucher par affectation bien entendu

avec un const ou pas, en asm, ya pas grand chose qui tienne la route hein %)
cependant, je me demande s'il est vraiment bon d'exporter toutes ces variables. par exemple, à quoi bon exporter SIGNATURE, STANDARD_ITALIC_SIZE_, ITALIC_SIZE et même SPRITE_POINTER? à part à permettre à l'utilisateur de hacker tranquillement, ce qui te foutra bien dedans le jour ou tu voudras toucher un tant soi peu à ton propre format...

Merci pour vos réponses à tous les deux, merci geogeo de m'aider dans la compréhension et le port de ta lib! :)

-Edité le Jeudi 15 décembre 2005 à 16:57 par Martial Demolins-
<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."
    
./Post n°48   Marquer comme non lu.
Kevin Kofler Ecrit le: Jeudi 15 décembre 2005 à 19:45 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Martial Demolins :
Excuse-moi, je me suis mal exprimé. Je ne demande pas mieux que d'utiliser les fonctions de vat.h plutôt que de hacker, je te rassure, même si connaitre le format binaire de la vat représente un intérêt pour la curiosité personnelle. Ce que je dis, c'est que les fonctions sont décrite, mais il n'y a pas grand chose pour dire lesquelles utiliser et dans quel ordre quand on veut créer une variable, la rechercher etc...

Il y a le tuto de Benjy dans lequel j'ai corrigé les erreurs: http://www.tigen.org/pws/index.php?mod=articles&ac=commentaires&id=84. Mais tu l'as déjà vu celui-là, d'après les commentaires.
Et ensuite, il y a la source de logiciels comme Backgammon, Spread89 et plein d'autres (par différents auteurs) qui utilisent aussi des fichiers externes. En assembleur, bah au-delà du fameux tigcc -S, tu as aussi par exemple XtraKeys qui crée 2 petites fonctions TI-BASIC sous AMS <3.10.

Parceque le jour où ta détection de HW foirera avec une nouvelle ROM/TI, tu patcheras tous les programmes nostub, tandis que je regarderai PpHd mettre PreOS à jour :p

Il y a une solution beaucoup plus simple que patcher, ça s'appelle recompiler, l'auteur fait ça une fois et le problème est règlé. #roll# (C'est tout l'intérêt d'utiliser le code de TIGCCLIB au lieu d'en écrire ton propre. Enfin, ça facilite aussi les patches vu que tout le monde utilise le même code.) Les patches, c'est pour les programmes dont les auteurs sont trop paresseux pour les recompiler (et n'ont pas laissé leurs sources - <RANT>d'habitude les auteurs qui sont les plus possessifs avec leurs sources sont aussi ceux qui se cassent sans se f**tre de la moindre des manières de la compatibilité de leurs logiciels avec les nouveaux modèles #roll#). Les programmeurs, si déjà vous n'êtes pas fichus recompiler vos programmes pour les nouveaux modèles, laissez au moins vos sources (sous une licence convenable, de toute façon si la licence dit "interdit de recompiler pour faire marcher le programme avec un nouveau modèle", tout le monde va s'en f**tre et le faire quand-même) pour qu'on puisse le faire pour vous!</RANT>

Pour graphlib, j'ai juste cherché à regarder les fonctions, par curiosité encore une fois, rien de plus. :)

Ce n'est pas ce que tu as dit à PpHd sur l'autre forum. #roll#

C'est parce que tout simplement ce sont des constantes qu'on ne doit pas toucher par affectation bien entendu

avec un const ou pas, en asm, ya pas grand chose qui tienne la route hein %)

Si, un equate. :) Je ne comprends pas pourquoi il stocke la constante dans le code au lieu de la mettre en equate tout simplement, d'ailleurs.
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°49   Marquer comme non lu.
geogeo Ecrit le: Jeudi 15 décembre 2005 à 19:49 Déconnecté(e)    Voir le profil de geogeo Envoyer un email à geogeo Visiter le site WEB de geogeo Envoyer un message privé à geogeo  


ah oui? dans un appel de ROM call, les arguments sont passé en ordre inverse. Donc le *mem de la fin d'une définition doit être passé en premier sur la pile non? donc on le trouve à 10(sp) et non à 0 (sp)... Je ne comprends pas pourquoi tu dis ça, je devrai regarder le code pour réellement comprendre.


Arf j'ai du caca dans les yeux tu as raison. %)
J'ai affiché en effet l'ordre de passage des argument donc *mem se retrouve bien en 10(%SP).

avec un const ou pas, en asm, ya pas grand chose qui tienne la route hein
cependant, je me demande s'il est vraiment bon d'exporter toutes ces variables. par exemple, à quoi bon exporter SIGNATURE, STANDARD_ITALIC_SIZE_, ITALIC_SIZE et même SPRITE_POINTER? à part à permettre à l'utilisateur de hacker tranquillement, ce qui te foutra bien dedans le jour ou tu voudras toucher un tant soi peu à ton propre format...


Les variables que j'exportes donnent des infos sur la fonte utilisée rien d'autre.
En effet en ASM on peut hacker (mais quel est le but? aucun). Mais c'est vrai que le mieux est de copier ça dans la pile pour être tranquil!

Ca sera plutôt l'utilisateur (le hacker) qui sera dans le caca pas moi. Mais sérieux je vois pas ce qu'on peu hacker avec ça. A moins d'être un peu taré!
Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic
    
./Post n°50   Marquer comme non lu.
geogeo Ecrit le: Jeudi 15 décembre 2005 à 19:51 Déconnecté(e)    Voir le profil de geogeo Envoyer un email à geogeo Visiter le site WEB de geogeo Envoyer un message privé à geogeo  


Si, un equate. Je ne comprends pas pourquoi il stocke la constante dans le code au lieu de la mettre en equate tout simplement, d'ailleurs.


Bon je vais être plus clair c'est une variable statique liée au fichier.
Le fichier contient des infos comme Nom de la fonte, taille x, taille y, version...
Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic
    
./Post n°51   Marquer comme non lu.
Kevin Kofler Ecrit le: Jeudi 15 décembre 2005 à 19:58 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Au fait, si, il y a un moyen de t'empêcher de hacker les variables en ASM:
cmp valeur_attendue,variable
jbeq 0f
trap #2
0:

:D
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°52   Marquer comme non lu.
geogeo Ecrit le: Jeudi 15 décembre 2005 à 20:54 Déconnecté(e)    Voir le profil de geogeo Envoyer un email à geogeo Visiter le site WEB de geogeo Envoyer un message privé à geogeo  


%) Y a pas plus crade et inutile? :D
Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic
    
./Post n°53   Marquer comme non lu.
Folco Ecrit le: Lundi 19 décembre 2005 à 16:25 Déconnecté(e)    Voir le profil de Folco Envoyer un email à Folco Envoyer un message privé à Folco  


la lib marche, c'est super!!! #love#
merci pour ton boulot geogeo!! #top#

Kevin-> oui, je vais aller voir des sources.
sinon, pourquoi recompiler plein de programmes quand on peut juste changer un seul et unique kernel??? #confus# et il apporte un paquet d'avantages... le nostub me fait penser aux progs kernels de première génération, qui contenaient leur propre code de démarrage, qui auraient pu contenir par la suite leur code de détection HW, AMS, tous les hacks, etc... :/

geogeo-> c'est un risque... et en lib dynamique, ça prend la place d'une exportation, je vais les retirer. et de toute façon changer le code pour utiliser les constantes en valeur immédiates et plus en variables.
<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."
    
./Post n°54   Marquer comme non lu.
Folco Ecrit le: Mardi 20 décembre 2005 à 12:49 Déconnecté(e)    Voir le profil de Folco Envoyer un email à Folco Envoyer un message privé à Folco  


et au fait pour graphlib et ses fenêtres, je suis en train de faire un wrapper pour les utiliser facilement, y mettre texte, menus, boutons, images etc...
<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."
    
./Post n°55   Marquer comme non lu.
Kevin Kofler Ecrit le: Mardi 20 décembre 2005 à 14:35 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Quel est l'intérêt par rapport aux dialogues AMS qui font déjà tout ça et qui sont dans la ROM? Pourquoi réinventer la roue?
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°56   Marquer comme non lu.
FpgForce Ecrit le: Mardi 20 décembre 2005 à 14:57 Déconnecté(e)    Voir le profil de FpgForce Envoyer un email à FpgForce Envoyer un message privé à FpgForce  

parce que ça sera plus joli/rapide au hasard ?
    
./Post n°57   Marquer comme non lu.
Kevin Kofler Ecrit le: Mardi 20 décembre 2005 à 15:10 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Plus rapide -> on s'en fout, les dialogues sont par définition limités par la vitesse d'entrée de données de l'utilisateur, les dialogues d'AMS arrivent déjà à tenir tête aux entrées utilisateur, ça ne sert à rien d'aller plus vite!
Plus joli -> le design des dialogues d'AMS fait partie du look&feel de la plateforme, même si vous trouvez un autre look&feel plus joli (ce qui est très subjectif et ne correspondra pas forcément à l'avis de vos utilisateurs, personellement je trouve les dialogues de graphlib et PedroM très moches, les coins ne sont même pas arrondis), ce n'est pas une raison de casser la consistence du look&feel. Si vous voulez un look&feel graphlib avec l'API de dialogues AMS, utilisez PedroM qui fait exactement ça.
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
  :: Index » GFA-Basic TI68K » Bugs et suggestions » Problème avec une font (106 réponse(s))
Pages : 3/6     « 1 2 [3] 4 5 6 » »|

.Répondre à ce sujet
Les boutons de code
[B]old[I]talic[U]nderline[S]trikethrough[L]ine Flip Hori[Z]ontallyFlip [V]erticallySha[D]ow[G]low[S]poilerCode [G][C]ite
Bullet [L]istList Item [K] Link [H][E]mail[P]icture SmileysHelp
Couleurs :
Saisissez votre message
Activer les smileys
     

Forum de Ti-Gen v3.0 Copyright ©2004 by Geoffrey ANNEHEIM
Webmaster: Kevin KOFLER, Content Admins: list, Server Admins: Tyler CASSIDY and Kevin KOFLER, DNS Admin: squalyl
Page générée en 60.61ms avec 18 requetes