PControl beta 3 - Page 2

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

Double matrice de sprites pour minimiser le nombre de tiles

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

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.

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.

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

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

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?

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

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
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

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)...

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

Parce que -1 n'est pas représentable dans un unsigned char.

Parce que mettre tous les bits d'un unsigned char à 1, ça donne 255, pas -1.

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

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.

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.

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.

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 :/

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).

(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)

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
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
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

Et donc, pourquoi pas 3 ?

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 ). C'est OSdequeue qu'il faut utiliser!