30

> -Une matrice à laquelle est rattachée pour chaque case un sprite?
Une triple matrice (de word, de word, et de byte) + un gros paquet de tiles 16x16 (jusqu'à 560 sur certaines).

31

Oki, merci des infos !
<s'en va donner les infos aux chinois du fbi chargés de faire un CF de contrefaçon>.
avatar
Ancien pseudo : worfang.

32

33

Double matrice de sprites pour minimiser le nombre de tiles grin

34

Pour pcontrol, j'ai ajouté dans la 0.82 alpha 2, la variable system\font qui définit la taille de la police utilisé dans le shell (0, 1 ou 2).
Ex:
"0"->system\font

35

36

Est ce qu'il serait envisageable d'utiliser dans le shell la font de Side car je trouve mieux d'avoir une police à chasse fixe dans le shell.
avatar

37

Le plus simple serait de modifier ces fonctions :
DrawClipChar:
DrawStr
DrawStrWidth
FontCharWidth:
DisplayString:
StrWidthFromTo

pour qu'elle supporte une fonte supplémentaire, celle de side. Et ca serait accessible pour tous les programmes par ailleurs.
Le problème est de déterminer quelle valeur donnée à la nouvelle fonte.

38

Le numéro 3 poserait-il vraiment un problème, sachant qu'AMS n'évoluera plus sur les TI-68k ?

Si vous rajoutez une font, veillez à ne pas changer les 16 octets qui précèdent DrawStr (des adresses hautes vers les adresses basses: 'Pedr', pointeur pour F_8x10, pointeur pour F_6x8, pointeur pour F_4x6). Ils sont utilisés (pas forcément tous), dans cet ordre-là précisément, par ma routine SetupCharSet / InitFastDraw / etc. pour le support du dessin rapide de caractères et strings.
Si vous changez ça, vous rendez PedroM incompatible avec TI-Chess, ebook, TICT-Explorer (dont la v1.40 semi-unreleased comprend du code pour supporter spécialement PedroM), et quelques programmes non TICT... c'est gênant grin
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

39

40

Juste pour info: ce dont lionel parle est une interface dont lui et moi avons discuté et somme convenu pour donner les adresses des fontes sous PedroM aux programmes nostub.
Et sinon, je serai plutôt partant pour -1 smile

41

42

Je pensait également à -1 au début mais en regardant la doc de Tigcc j'ai vu ça :
unsigned char FontSetSys (short Font);

ça risque de rendre l'utisation de -1 problematique?
avatar

43

44

J'ai jamais compris pourquoi hacker autant AMS, qu'est_ce que c'est gore sick

Gore, mais pas dangereux. Mes Address/Value Hacks ne font qu'étendre sur des versions _plus vieilles ET n'évoluant plus_ d'AMS des fonctionnalités facilement accessibles sur un sous-ensemble d'AMS 2.xx. Rien à voir avec l'utilisation (non protégée par un check de version d'AMS) d'adresses absolues vers les variables du système, parfois utilisée en 1997-1999 dans certains programmes kernel-based wink
Evidemment, les Address/Value Hacks pour AMS 1.xx ne fonctionnent pas du tout sous PedroM, qui se présente comme AMS 1.xx (et il a assez raison, vu qu'il n'implémente ni les API de FlashApps ni les nombreux ROM_CALLs du CAS ajoutés dans AMS 2.xx, il a son propre CAS). C'est pour ça que:
* on s'est mis d'accord avec PpHd pour une interface permettant d'avoir les adresses des fonts;
* TICT-Explorer détecte spécialement PedroM, pour appeler des ROM_CALLs triviaux que TICT-Explorer utilise (pour gagner de la place et améliorer la localisation langue) et que j'ai contribués à PedroM wink

Bon, naturellement, en 2008, des Address/Value Hacks pour AMS 1.xx, faits en 2001-2002, ne sont plus d'aucun intérêt pratique, alors qu'ils n'étaient pas encore totalement inutiles en pratique à l'époque (2-3 ans après l'introduction d'AMS 2.xx)...
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

45

Folco (./43) :
Je vois pas pourquoi, tu peux m'expliquer ? cheeky

Parce que -1 n'est pas représentable dans un unsigned char.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

46

47

48

Parce que mettre tous les bits d'un unsigned char à 1, ça donne 255, pas -1.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

49

50

Folco (./43) :
Je vois pas pourquoi, tu peux m'expliquer ? mod.gif
Je suis pas un champion du C mais il ne me semble me tromper en disant que -1 en int donne 0xFFFF et 0xFF en char. ce qui me parait une source que problème sans compter que l'on passe de signed a unsigned.
Tant qu'on compare et calcule entre char, ca va aller. Mais dès qu'il va y avoir un conversion ou calcul avec des int c'est foutu.

int save_font = FontGetSys(); 
... reste du programme ...
SetFontSys(save_font);(

devrait restaurer la valeur retourner 255 et non -1.
avatar

51

Uther (./42) :
Je pensait également à -1 au début mais en regardant la doc de Tigcc j'ai vu ça :
unsigned char FontSetSys (short Font);

ça risque de rendre l'utisation de -1 problematique?

Pas vraiment. Il suffit que l'on mappe tout et qu'on ne fasse que les tests, en interne, par rapport à des char; ce qui est déjà le cas. (en gros, les bits de poids fort du short ne comptent pas du tout).
Kevin Kofler (./48) :
Parce que mettre tous les bits d'un unsigned char à 1, ça donne 255, pas -1.

C'est pareil ! C'est juste un représentant de la classe qui est différent.
Folco (./49) :
Et on peut pas comparer un unsigned char à -1 c'est ça ? Ca compile pas ?

Si, très bien même.

52

PpHd (./51) :
Folco (./49) :
Et on peut pas comparer un unsigned char à -1 c'est ça ? Ca compile pas ?
Si, très bien même.

Et ce sera toujours faux:
unsigned char c=-1;
if (c == -1) ...

échouera toujours, parce que c est promu en int avant la comparaison, et donc on compare 255 == -1 et c'est faux. Seul:
if (c == (unsigned char)-1)
fonctionne.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

53

PpHd (./51) :
C'est pareil ! C'est juste un représentant de la classe qui est différent.

Non, à cause de la promotion automatique (un)signed char -> int :/

« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)

54

Pollux (./53) :
Non, à cause de la promotion automatique (un)signed char -> int :/


Mais là tu compares 255 et -1 de int à 255 / -1 de uchar, ce qui n'est pas pareil. (M'enfin, c'est pas le sujet, donc j'arrête).

55

(le problème c'est que le -1 de uchar n'est pas le même que le -1 de schar, contrairement au -1 de uint qui est le même que le -1 de sint : ça empêche pas d'écrire un programme correct, mais c'est très casse-gueule et ça oblige à rajouter des casts)

« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)

56

Ca, les vieilles habitudes des pionniers qui n'avaient pas tigccdoc, dur de leur en vouloir quand même.

On pourrait leur en vouloir parce qu'utiliser des adresses absolues vers des variables internes du système est une programmation particulièrement sale wink
Même si les adresses utilisées n'ont pas changé dans toute la série des AMS 1.xx, ce qui a permis à ce hack sale de fonctionner aussi longtemps.
On pourrait aussi leur en vouloir de ne pas avoir cherché à regarder mieux que ça ce qu'il y avait dans AMS.

Au fait, j'ai oublié de relever un truc dans ./44: le fait de rechercher en binaire, sur des dizaines de milliers d'octets, les fonts d'AMS - ce que font les kernels - est un gros hack sur AMS, Martial wink
Par rapport à SetupCharSet, il est très lent, et ne prend pas en compte la redéfinition des fonts possible sous AMS 2.xx (rarement utilisée en pratique, on est d'accord - en revanche, tous les utilisateurs d'AMS 2.xx souffrent du fait que cette capacité ralentit beaucoup DrawChar/DrawStr). PpHd a changé la spec dans PreOS pour toujours chercher la font dans le boot code, ce qui maintient la compatibilité avec le comportement "vieux style" (pas adapté aux AMS postérieurs à 1999) des kernels précédents.
Par rapport à la phrase précédente: quand on dit que le kernel-based, c'est une technologie dépassée, on a évidemment raison. Ca ne souffre d'aucune discussion, et ça n'en a d'ailleurs jamais souffert sur un quelconque argument que ce soit. Ce n'est que par pur esprit de contradiction que certains osent encore contester ce fait absolument indiscutable. Point à la ligne tongue
dehors
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

57

58

Et donc, pourquoi pas 3 ? grin
avatar
Que cache le pays des Dieux ? - Forum Ghibli - Forum Littéraire

La fin d'un monde souillé est venue. L'oiseau blanc plane dans le ciel annonçant le début d'une longue ère de purification. Détachons-nous à jamais de notre vie dans ce monde de souffrance. Ô toi l'oiseau blanc, l'être vêtu de bleu, guide nous vers ce monde de pureté. - Sutra originel dork.

59

60

Folco (./57) :
les adresses des kb_vars [...] qui sont passées au-delà de $8000 au passage de AMS 3.01 -> 3.10 par exemple), ben une nouvelle version du kernel sort.

Et ça n'arrange pas les programmes qui utilisaient un adressage .w pour cette adresse (et il y en a sans doute sick). C'est OSdequeue qu'il faut utiliser!
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité