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

Ca nous fait donc une matrice de sprite, et ensuite ? Les objets je suppose pour une, mais la dernière ?

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

Ok

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

J'ai jamais compris pourquoi hacker autant AMS, qu'est_ce que c'est gore Et après le kernel c'est pas bien ?!? Sans compter que PedroM se traine justement des lourdeurs parce que chacun se pointe avec ses impératifs de compatibilité...

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

Ben c'est bien ce que je reproche aux programmes nostub justement, même si c'est vu avec toi ^^ Le problème n'existerait pas en kernel propre !

sinon, +1 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?

Je vois pas pourquoi, tu peux m'expliquer ?

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.

Lionel Debroux (./44) :
parfois utilisée en 1997-1999 dans certains programmes kernel-based

Ca, les vieilles habitudes des pionniers qui n'avaient pas tigccdoc, dur de leur en vouloir quand même. Ce que je trouve juste marrant, c'est qu'à chaque fois que t'as un problème qui se pose, tu refais tout le boulot d'un kernel. Mais bon, des masos, il en faut
Sinon j'ai vu tes contributions (et je m'en suis même servi ), vu que j'ai lu pratiquement tout PedroM.

Kevin Kofler (./45) :

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

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

J'ai jamais compris pourquoi on pouvait pas mettre à 1 tous les bits d'un unsigned char et appeler ça -1. C'est complexe le C

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

Et on peut pas comparer un unsigned char à -1 c'est ça ? Ca compile pas ?

Pusi de toute façon, c'est que pour les nouveaux programmes, et ils utiliseront des signed char maintenant, ça marchera.

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

Lionel Debroux (./56) :
On pourrait leur en vouloir parce qu'utiliser des adresses absolues vers des variables internes du système est une programmation particulièrement sale

On pourrait peut-être aussi les remercier, perso j'aime pas cracher dans la soupe d'hier. M'enfin bon, on doit avoir le même âge, et j'étais bien content de jouer aux jeux kernels bourrés de hacks en 98 et toi aussi.

Lionel Debroux (./56) :
On pourrait aussi leur en vouloir de ne pas avoir cherché à regarder mieux que ça ce qu'il y avait dans AMS.

D'un autre côté, étudier sans pondre une ligne de source n'est pas non plus la solution. Je sais que tu t'es pas mal penché sur AMS, mais moi aussi j'ai tracé des romcalls non documentés (particulièrement au niveau du clavier), mais ça reste un minimum de mon temps. Je comprends alors pourquoi tu mets des années à corriger des bugs ou sortir un update. ok c'est piquant, mais toi t'es pareil avec nos anciens et je supporte pas ça, na !

Lionel Debroux (./56) :
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

T'as tout compris Lionel !!! Tu savais que j'en ai rien à péter des hacks du kernel ? Et que justement il est là pour que moi, j'ai pas à écrire tous les hacks dans lesquels tu te délectes ? Et quand un update casse un hack (les adresses des kb_vars (pas de trolls sur ces adresses, je les utilise pas, c'est juste que PreOS assure la compatibilité) 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. Je ne demande pas mieux, et surtout, ej ne vois strictement pas le problème.

Lionel Debroux (./56) :
Par rapport à SetupCharSet, il est très lent

Qu'en ais-je à foutre que PreOS mette une seconde à s'installer ? Nan mais vraiment

Sinon SetupCharSet c'est quoi, ya rien dans tigccdoc

Et donc, pourquoi pas 3 ?

"Tout est relatif" ©

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!