clipping - Page 1

Juste pour tester une idée que j'ai lue dans un des derniers topics,
je voulais essayer d'utiliser un écran virtuel plus grand que 3840 pour clipper les sprites
et essayer en meme temps le scrolling, mais quand j'ajoute 1 à l'adresse de mon buffer
ça me décale de 8 pixels au lieu d'un...Je comprends pourkoi(un octet code pour 8 pixels) mais j'arrive pas à décaler d'un seul...

void *v_screen = NULL;
void _main(void)
{
v_screen = malloc(4352);
memset(v_screen,0,4352);
PortSet(v_screen,255,135);
static unsigned short sprt[]={1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17};
Sprite16(0,0,16,sprt,v_screen,SPRT_XOR);
memcpy(LCD_MEM, v_screen+0x01, 3840); // ça décale de 8 bits ???
ngetchx();
free(v_screen);
}

Et oui, pour décaler d'un pixel, il faut utiliser les fonctions << et >>.
Mais c'est plus compliqué que ça...
Si tu fais seulement des décalages, tu auras des trous blancs :
Imagine la suite de deux octets : 00000001 10000000, si tu les décales vers la gauche tous les deux, tu obtiendras : 00000010 00000000 alors que tu aurais voulu 00000011 00000000. Il faut donc penser à récupérer le bit de poids fort de l'octet suivant (quand scrolle vers la gauche).

Mais oublie tout ça car tu n'en as pas besoin si tu utilises des sprites : la fonction de sprite fait toute seule le bon décalage.
Il faut juste que tu affiches ton sprite dans ton écran virtuel plus large et que tu ne recopies à l'écran réel que la partie "visible" de ton écran virtuel plus large.

Sauf que les fonctions de sprites sont faites pour un écran 240×128 (avec éventuellement les 80 pixels en bas et les 28 pixels à droite non affichés).

Oui, mais il suffit de modifier les fonctions d'extgraph pour que ça fonctionne.
Et la fonction sera même plus rapide ! (au lieu de multiplier par 30, on multiplie par 32 pour une fonction 8x8, donc un seul décalage suffit pour calculer l'offset. Enfin, ça reste vraiment très négligeable...)

Kevin Kofler
a écrit : Sauf que les fonctions de sprites sont faites pour un écran 240×128 (avec éventuellement les 80 pixels en bas et les 28 pixels à droite non affichés).

Visuellement le résultat est le même, les sprites apparaissent clippés, c'est le principal

Edit

<jackiechan> Vertyos> je crois que kevin a précisé que les fonctions de sprites étaient faites pour un écran 240*128 juste parce que ça ne marchera pas avec une écran virtuel plus grand car pour calculer l'offset selon y, on multiplie par 30 quand on a 240 pixels de largeur, mais si le nombre de pixels de largeur est différent, il faut multiplier par autre chose

Heu... Ouais pê

Ok merci bien j'ai compris pour les decalages...
Je pense que ça devrait tomber pile pour mon grand buffer, etant donné que la longueur horizontale est aussi multiple de 8.
Je ne sais pas comment marchent exactement les fonctions de scrolling, bien que j'ai entendu parler de scrolling différentiel rapidement, mais je me dis qu'utiliser la fonction de scrolling d'extgraph et de reafficher le sprite au bord par cette techniquede grand buffer peut etre pas mal...
Enfin bref merci pour cette utile explication

Attention, tu devras adapter les fonctions de scrolling de ExtGraph si tu utilises un écran virtuel plus grand que 240×128, et je t'avertis tout de suite: c'est de l'assembleur.

arf faut bien payer un peu

Kevin Kofler a écrit :
Attention, tu devras adapter les fonctions de scrolling de ExtGraph si tu utilises un écran virtuel plus grand que 240×128, et je t'avertis tout de suite: c'est de l'assembleur.

Tu peux détailler? ca ne fonctionne pas si on prend un buffer de plus de 3840?

Non, parce que les fonctions de ExtGraph, comme celles des autres librairies graphiques pour TI-89/92+/V200 d'ailleurs, sont codées exclusivement pour un buffer 240×128.

Utilises AMS. C'est clippe et tu peux redefinir la taille du buffer.
<Cette blague vous a ete genereusement offerte par PpHd>

fait plutot une fonction de clipping sur ton buffer avant d'afficher au lieu de modifier les fonctions d'extgraph.

Détaille, parce que je ne comprends pas ta solution, et donc je doûte que Bylos et alndbx comprennent. Et surtout j'ai l'impression que ta solution n'en soit pas une, mais sans les détails, je ne peux pas le dire.

Et d'ailleurs, si vous êtes patients, vous n'avez qu'à attendre la prochaine version de ExtGraph, qui intègrera des routines clippées.

Je croyais qu'elle n'offrait que le support asm ?

Ben non, pas seulement

Vu qu'il utilises les fonctions les fonctions de scroll, je pense qu'il devrait scroller normalement (sans clipping) puis qu'il applique son clipping sur le buffer qui sert de scroll avant d'afficher.

C'est ce dont on parle dès le début, et ça présuppose des routines de scrolling adaptées au nouvel écran virtuel. Celle de ExtGraph ne marchent qu'en 240×128.

Heurf, désolé, je ne savait pas, je pensais que c'était comme la plupart des ecrans virtuel pour le scroll ...

Vous pourriez pas donner une date pour la sortie de extgraph?? Chais pas moi pour les vacances... dans une semaine...

Vous voulez que ça se finisse comme GTC (repoussé en permanence)?

Une date de sortie, personnellement, je ne sais pas du tout.
Il nous reste encore pas mal de fonctions à écrire (surtout qu'il faut après réécrire toutes les fonctions n&b pour les nvg).

jackie: ca va, c'est pas le plus dur ca

Non, mais ça fait beaucoup de fonctions quand même.
Il n'y a que quelques changements à faire pour passer de l'une à l'autre, mais c'est quand même pénible, étant donné le nombre de fonctions : chaque fonction de sprite doit être disponible pour les mode OR/AND/XOR/MASK/BLIT, pour les tailles 8/16/32/X8, et après, il faut toutes les refaire pour les niveaux de gris, puis enfin, toutes ces fonctions doivent exister en 2 versions : une __stkparm__ et une __regparm__.
Donc ça fait pas mal de fonctions au total (5*4*2*2=80), et j'en ai peut-être oubliées

, ca va craindre ca pour la place prise ..... nan

Ben vu que c'est une lib statique, c'est pas trop grave.
Mais en général dans un jeu, on n'utilise pas toutes les fonctions.
On utilise soit le mode __regparm__, soit le mode __stkparm__ (donc ça divise déjà le nombre de fonctions par 2) ensuite, en fait un prog soit en n&b, soit en nvg, donc ça divise encore par 2 le nombre de fonctions, et aussi ça m'étonnerait qu'on prog utilise à la fois de fonctions clippées et non clippées (autant prendre tt le temps les clippées, même si elles sont légèrement plus lentes), et enfin, je doute que dans un même jeu on utilise plusieurs taille de sprites différentes...

Ah oui, au fait, j'avais oublié dans le post précédent que toutes les fonctions sont soit clippées, soit non clippées, ce qui multiplie encore par 2 le nombre de fonctions (ça fait 160 maintenant, et ce ne sont que les fonctions de sprite).

jackiechan a écrit :
Ben vu que c'est une lib statique, c'est pas trop grave.
Mais en général dans un jeu, on n'utilise pas toutes les fonctions.
On utilise soit le mode __regparm__, soit le mode __stkparm__ (donc ça divise déjà le nombre de fonctions par 2) ensuite, en fait un prog soit en n&b, soit en nvg, donc ça divise encore par 2 le nombre de fonctions, et aussi ça m'étonnerait qu'on prog utilise à la fois de fonctions clippées et non clippées (autant prendre tt le temps les clippées, même si elles sont légèrement plus lentes), et enfin, je doute que dans un même jeu on utilise plusieurs taille de sprites différentes...

1) Ca fait quand mm beaucoups de fonctions et j'ai franchement peur pour la place, on verra bien.
2) Il est assez courant d'avoir à utiliser plusieurs tailles de sprites.
3) Les fonctions devraient toutes être clippées, comme ca, pas possibilité de plantage, je suis sur qure certains nioobs vont gueuller pke ca plante leur prog alros qu'ils ont pas utilisé la fonction clippée.

Bref, avis-à-voir

nEUrOne
a écrit : 1) Ca fait quand mm beaucoups de fonctions et j'ai franchement peur pour la place, on verra bien.

Oui, ça fait beaucoup de fonctions, la lib prendra de la place, mais je ne pense pas que les utilisateurs utiliseront beaucoup de fonction différentes. Et elles sont programmées en assembleur, donc elles prennent probablement moins de place que leur équivalent en C. (par exemple, la fonction sprite16_OR clippée prend 152 octets, ce n'est pas énorme...)

2) Il est assez courant d'avoir à utiliser plusieurs tailles de sprites.

Je ne pense pas, mais de toute façon dans ce cas, il n'y a pas d'autre moyen que d'utiliser toutes ces fonctions différentes...

3) Les fonctions devraient toutes être clippées, comme ca, pas possibilité de plantage, je suis sur qure certains nioobs vont gueuller pke ca plante leur prog alros qu'ils ont pas utilisé la fonction clippée.

Oui, je suis d'accord, mais les fonctions non clippées sont plus rapides (bon, ok l'argument est un peu nul). Pour ce qui est des nioobs, ils n'ont qu'à lire la doc...

Sinon, on pourrait ne mettre que les __regparm__ vu qu'elles sont légèrement plus rapides et ne prennent pas plus de place (voire moins), mais par souci de compatibilité avec les anciennes version d'extgraph, il y aura les deux (__stkparm__ et __regparm__)...

1) L'utilisation des routines de sprites en mode OR est douteuse ... j'en vois pas vraiment l'utilité; faites plutot de la transparence !

2) Voué, XLib a toutes ses fonctions clippées, enfin, aura pour vous

En blanc et noir, OR == transparence.

Mias pour une lib graphique, le noir et blanc, ne doit pas être une priorité, et donc, bien entendu, dans mon propos, je parlais en niveaux de gris ...