encore une chtite question - Page 22

OK pour les SYM*, mais pour LCD_MEM elle a déjà changé au moins deux fois, le risque n'est donc pas nul de l'apparition, disons, d'une v200 platinum avec 512ko de ram et un écran à $5200 (valeurs prises au hasard hein).

Et tu proposes quoi comme alternative (portable, c'est-à-dire utilisable en _nostub ou avec les vieux kernels)? Aller lire l'adresse dans le code de PortRestore? Ce n'est pas plus mieux à mon avis...

Extrait de Doc\Traps.txt de PreOs:

Trap 9
------
A0.L = $4004F8 + 4 * D0.W

Input : D0.W = {00...11}
Output: A0.L = $4004F8 + 4 * D0.W
D0.L = 4 * D0.W;

D0 pointer to
-- ----------
[...]
0E (RAM) LCD memory
[...]

Sauf que le trap #9 n'est pas une interface vraiment documentée non plus.
Sinon, mes patches pour CALCULATOR sous TIGCC ont été acceptés par Sebastian. Il a aussi accueilli ma suggestion de traîter _ti89ti comme un alias pour _flag_6 dans le linker, et d'utiliser cet alias dans default.h pour une meilleure lisibilité.

>Sauf que le trap #9 n'est pas une interface vraiment documentée non plus.
C'est pas avec ca qu'on recupere la file des touches ?

>Tous les programmes _nostub utilisent ces constantes, tous les programmes kernel en C aussi. (Et autant on pourrait utiliser le
>RAM_CALL pour LCD_MEM, autant il est pratiquement impossible d'utiliser des RAM_CALLs pour les offsets dans les structures.)
Ca c'est vrai.

>De plus, la structure SYM_ENTRY fait partie de l'API officielle de TI (tiams.h), donc elle ne changera pas,
Tu es naif lorsque tu veux

>Qui a envie de se lancer là-dedans?
Je le ferais. Un jour. Par tres mauvais temps.

>Ou alors on fait comme pour les niveaux de gris?
C'est mal

PpHd :
>Sauf que le trap #9 n'est pas une interface vraiment documentée non plus. C'est pas avec ca qu'on recupere la file des touches ?

Oui. Et ça marche très bien. Mais 0x4c00 marche très bien aussi.

Bah comme le reste, ça marche jusqu'à ce que ça ne marche plus

Martial Demolins
: ->Je n'ai absolument pas compris comment marche la palette...

La palette joue sur le contraste et le temps d'exposition des plans, si j'ai bien compris. (PpHd?)

->Qu'est-ce qu'une couleur transparente? Elle n'est pas affichée quand on affiche un sprite, c'est ça?

Exact.

Euh non la palette permet de modifier l'apparence des sprites utilisables avec certaines fonctions quand on choisit de l'utiliser.
Si je me rappelle bien la palette par défaut c'est la 0 (black, dark grey, light grey, white) et les couleurs sont remplacées selon la palette choisie (par exemple ce qui devrait être gris foncé est gris clair avec la palette 1, etc)

"->Qu'est-ce qu'affiche genlib (entre window, screen, dscreen, je suis un peu perdu j'avoue^^). J'ai lu et relu la description des différentes structures, mais je ne vois pas encore leur but, c'est à dire dans quel cas il sera mieux d'utiliser telle ou telle manière d'afficher. "

bah genlib n'affiche que ce que tu lui demandes... pour choisir entre Screen et DScreen c'est selon si tu utilises genlib::set_dscreen_int ou genlib::set_screen_int.
Un Screen est un écran en noir et blanc, un Dscreen est un écran en niveaux de gris (en fait, deux Screens contigus).
La "window" est juste un buffer de la taille de l'écran qui existe toujours (en fait c'est l'ancien LCD_MEM pour les hw1, et un buffer alloué sur hw2).

(note: il y a des fautes dans ma doc, si quelquechose te semble obscur relis l'original )

>Je n'ai absolument pas compris comment marche la palette...
C'est juste un convertisseur. Ca transforme ton sprite avant de l'afficher. Ainsi avec la palette 1, le gris fonce du sprite ne sera pas affiche comme un gris fonce, mais comme un gris clair. Seules quelques fonctions supportent les palettes, et peu de programmes l'utilisent.

>->Qu'est-ce qu'une couleur transparente?
>Elle n'est pas affichée quand on affiche un sprite, c'est ça?
Oui.

>->Qu'est-ce qu'affiche genlib (entre window, screen, dscreen, je suis un peu perdu j'avoue^^).
>J'ai lu et relu la description des différentes structures, mais je ne vois pas encore leur but,
>c'est à dire dans quel cas il sera mieux d'utiliser telle ou telle manière d'afficher.
99% du temps, c'est un DScreen. Le reste c'est au cas ou.
Le Window est un buffer temporaire... A toi d'en faire ce que tu veux.

>Bon, je sens que je vais pouvoir relire la doc un paquet de fois avant de pondre des lignes, ça n'a pas l'air dur de la faire marcher simplement, mais pour attaquer des choses complexes, elle ne doit pas être évidente à manipuler.
Mais si

(je parlais de fautes de concepts, pas de fautes de frappes )
Sinon, oui, genlib n'est pas aussi difficile à utiliser qu'on pourrait le penser en regardantla taille de la doc

Qu'est-ce qui ne va pas dans les fonctions actuelles ?

Oui, c'est optimisé pour des plans de tiles 8x8 ou 16x16.
(sinon pour µlib, rien à voir avec la connaissance de la lib je t'assure )

c'est une macro qui prend un paramètre, ici d0 (utilisé en fait en sortie)
(elle empile un DScreen et met le pointeur dans d0, cf doc)

ASM: genlib::PUSH_DSCREEN ds
INPUT:
Rien
OUTPUT:
Ds = Le Dscreen empilé
REGISTRES DETRUITS:
ds et SP (=a7)
DESCRIPTION:
Alloue un DScreen sur la pile.
Vous devez l'utilisez comme une instruction PUSH!
ATTENTION: VOUS NE POUVEZ PAS ALLOUER PLUS D'UN DSCREEN SUR LA PILE!
EXEMPLES:
Voir le Premier Exemple.
VOIR AUSSI:
genlib::POP_DSCREEN

>Le seul problème, c'est que pour mon projet (un jeu en hexagonal), ce n'est pas adapté...
tu sais, des gens ont fait des jeux en hexagonals sur megadrive, et elle ne gerait que les carres.

pas que je sache... m'enfin peut être...

J'en avais fait un tout simple pour mon usage perso mais il a été perdu en même temps qu'une partie des sources de TIM (disque craché )