Sprite en niveau de gris en mode nostub - Page 1

bonjour

je débute dans la prog asm et j'aimerais savoir comment on affiche un sprite avec des niveaux de gris en mode nostub.
j'essaye d'utiliser cette fonction mais je n'y arrive pas
void Sprite8 (short x, short y, short height, unsigned char *sprite, void *vm_addr, short mode);

Que faut il faire et où trouver de la doc sur la prog graphique en asm ??

attend que kevin arrive, et il te donnera un lein pour ce que tu cherches.

-

Lol je sais , j'essaye juste de convertir cette fontion en asm

j'obtiens :

move.w #0,-(a7)
pea.l $4c00
pea sprite(pc)
move.w #12,-(a7)
move.w #50,-(a7)
move.w #150,-(a7)
jsr Sprite8
lea.l 16(a7),a7

sprite dc.b $FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF
ça a l'air de marcher mais :
- je pige pas pkoi je peux pas mettre :

move.l Sprite8*4(a5),a0
jsr (a0)

- y'a pas de niveaux de gris :P

- j'ai pas compris à quoi correspondait les plans

-

Utilises TIGCC, et plus particulièrement la librairie TIGCCLIB et les fonction de gray.h pour pouvoir employer les niveaux de gris.

1. S'il veut utiliser Sprite8, il utilise déjà TIGCCLIB.
2. Tu as quelle version de TIGCC? Dans les bêtas les plus récentes, TIGCCLIB utilise le passage par registres pour les fonctions implémentées en C (les fonctions implémentées en assembleur n'ont pas encore été converties): les 4 premiers scalaires sont passés dans les 4 premiers registres de données, les 4 premiers pointeurs sont passés dans les 4 premiers registres d'adresses. Donc:
- x en d0
- y en d1
- height en d2
- sprite en a0
- vm_addr en a1
- mode en d3

ben j'utilise la version 0.93 et apparemment c toujours la pile pour les paramètres.
Sinon ou trouver des bons tutoriaux pour la prog graphique en nostub ?

Mais on en parle de toutes façons dans la doc de TIGCC non ?

tigrou
a écrit : ben j'utilise la version 0.93 et apparemment c toujours la pile pour les paramètres.

Dans la 0.93 oui.
Mais la 0.93 est vieille.

sinon dans ton tutorial tu utilises les plans et les niveaux de gris mais je comprends pas trop à koi ça correspond . Et ça c pas dans la doc de tigcc

Si, ça y est. C'est juste que j'accède aux plans directement parce que la macro C GrayGetPlane (vieux nom: GetPlane) n'est pas accessible en assembleur.

La 0.93 est la release officielle. Et Tigcc ne supporte pas la compatibilite ascendante du code (Faut toujours corriger a la main son code). C'est penible.

je souhaiterais utiliser cette fonction de la lib extgraph:

void GraySprite8_XOR(short x,short y,short h,unsigned char* sprite1,unsigned char* sprite2,void* dest1,void* dest2);

mais je comprends pas pkoi il faut deux sprites et deux destinations.

Si quelqu'un pouvait m'aider ça serait cool.

PpHd
a écrit : La 0.93 est la release officielle. Et Tigcc ne supporte pas la compatibilite ascendante du code (Faut toujours corriger a la main son code). C'est penible.

On fait tout ce qu'on peut pour la compatibilité ascendante.
Le code qui a dû être modifié est presque toujours du code utilisant quelque chose qui n'est pas documentée. Sinon, un programme écrit pour TIGCC 0.5 devrait toujours marcher avec TIGCC 0.94 bêta 18!

J'ai même passé mon temps à remettre du vieux code de GCC 3.0.4 dans GCC 3.1 pour rester compatible avec les programmes qui utilisent des constructeurs par transtypage pour construire du code exécutable!

tigrou a écrit :
je souhaiterais utiliser cette fonction de la lib extgraph:

void GraySprite8_XOR(short x,short y,short h,unsigned char* sprite1,unsigned char* sprite2,void* dest1,void* dest2);
mais je comprends pas pkoi il faut deux sprites et deux destinations.

Un pour chaque plan de gris.

Et attention, ExtGraph prend ses paramètres sur la pile.

Utilisait des appels a bsr grayOn, bsr Sprite8, avec passage des parametres par les registresm, c 'est pas officiel ca ? (Cf informations pour programmeurs, Sprite8, et libs statiques en assmebleur de la doc de tigcc).
Et tu vas me dire apres que le passage par registre est pas un truc officiel.
Soyons serieux. C'est une faute grave (A mon avis), meme si elle ne devrait pas traiter en consequence.

PpHd a écrit :
Utilisait des appels a bsr grayOn, bsr Sprite8, avec passage des parametres par les registresm, c 'est pas officiel ca ? (Cf informations pour programmeurs, Sprite8, et libs statiques en assmebleur de la doc de tigcc). Et tu vas me dire apres que le passage par registre est pas un truc officiel.

L'ABI (application binary interface) de TIGCCLIB n'est pas documentée. (On a juste documenté celle des ROM_CALLs!)
Je vais discuter avec Zeljko et Sebastian pour changer ça maintenant qu'on a le passage par registres disponible et qu'on ne prévoit pas de changement d'ABI.
Mais le bien des librairies statiques, c'est justement de pouvoir améliorer l'ABI sans causer des problèmes de compatibilité. Le seul problème est que les programmes en assembleur (et seulement les programmes en assembleur, pas ceux en C) doivent être portés si on veut les réassembler avec une version améliorée de la librairie. Si TIGCCLIB était une librairie dynamique, on n'aurait pas pu améliorer l'ABI, et donc on serait restés bloqués sur une ABI inefficace (passage des paramètres par la pile).

ça marche tjs pas , voilà mon code actuel :

 bsr GrayOn  move.l __L_plane(PC),a3  move.l __D_plane(PC),a4  pea.l (a3)  pea.l (a4)  bsr ClearGrayScreen2B ;  addq.l #8,a7  pea.l (a3) ;  pea.l (a4) ;  pea sprite(pc)  pea sprite0(pc)  move.w 12,-(a7) ;hauteur  pea.l 100*65536+50 ;arguments: x et y  bsr GraySpriteX8_OR   lea.l 22(a7),a7  move.l ngetchx*4(a5),a0  jsr (a0)   bsr GrayOff sprite dc.b $FA,$CB,$1F,$35,$67,$CF,$DF,$68,$99,$45,$AB,$FF sprite0 dc.b $FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF

alors ça n'affiche rien.
peut etre il faut activer les plans avec extgraph.

enfin avec des exemples ça aurait été plus simple quand meme #triso

Kevin Kofler a écrit :
L'ABI (application binary interface) de TIGCCLIB n'est pas documentée. (On a juste documenté celle des ROM_CALLs!)
Je vais discuter avec Zeljko et Sebastian pour changer ça maintenant qu'on a le passage par registres disponible et qu'on ne prévoit pas de changement d'ABI. Mais le bien des librairies statiques, c'est justement de pouvoir améliorer l'ABI sans causer des problèmes de compatibilité. Le seul problème est que les programmes en assembleur (et seulement les programmes en assembleur, pas ceux en C) doivent être portés si on veut les réassembler avec une version améliorée de la librairie. Si TIGCCLIB était une librairie dynamique, on n'aurait pas pu améliorer l'ABI, et donc on serait restés bloqués sur une ABI inefficace (passage des paramètres par la pile).

que ca soit une libraire statique ou dynamique ne change rien : il va falloir reecrire les bouts de code assembleur appelant vos ABI a la main. Merci beaucoup. C'est pas ce qu'on appelel de l'incompatibilite ?
Et si tu lisais le praragraphe de Zj de la doc, tu verrais qu'il ne faisait pas du tout reference exclusivement aux rom-calls, mais parlait de tout type de fonction standards C.

Il va falloir vous décider de ce que vous voulez: d'abord, vous râlez que TIGCCLIB n'utilise pas le passage par registres, maintenant vous râlez qu'elle l'utilise.
Et l'avantage de la librairie statique dans ce cas, c'est que personne ne vous empêche d'utiliser une ancienne version.

Et je confirme que l'utilisation de TIGCCLIB en assembleur n'a jamais été officiellement supportée par l'équipe de TIGCC. (Elle y est dans mon tutorial, mais ce n'est pas une publication officielle de l'équipe de TIGCC.)

Nan, nana, je ne rale pas contre le passage par registre, mais contre le fait que vous ayez rendu incompatible les futurs programmes assembleur compiles avec la 0.93 ou autre. Il faut garder la compatibilite ascendante ! C'est primordial !
Et dis moi alors pkoi Zj a fait un chapitre Information for Assembly Programmers
Et dans le The A68k Assembler on a :
and functions from TIGCCLIB, which need no header file at all (for example, bsr GrayOn is enough to call the GrayOn function).
?

>Et dans le The A68k Assembler on a :
>and functions from TIGCCLIB, which need no header file at all (for example, bsr GrayOn is enough to call the GrayOn function).

Bon, d'accord, j'ai mis ça, moi, et j'aurais mieux fait de ne pas le mettre.
Et c'est soit ça, soit garder une ABI inefficace pour toutes les versions futures de TIGCCLIB.

Et le nombre de programmes en assembleur qui utilisent TIGCCLIB de TIGCC 0.93, je pense qu'il se compte avec les doigts d'une main.

Et personne ne t'empêche de recompiler TIGCCLIB en changeant __ATTR_LIB_C__.
Mais il est vrai que j'ai très envie de changer aussi les fonctions implémentées en assembleur (pour la consistence), et donc ça ne sera plus aussi facile.
Mais je peux vous faire une tigcclib-compat.a si vous voulez.
Ceci dit, je pense que la solution bien meilleure est que vous adaptiez vos programmes en assembleur, vu que si vous programmez en assembleur, pour vous la taille et la vitesse comptent, et que le passage par registres est plus efficace.

sinon pour mon problème comment on fait ?

thibaut, Nitro, les autres : regardez : j'ai gagne !!!!!!!

>>Et le nombre de programmes en assembleur qui utilisent TIGCCLIB de TIGCC 0.93, je pense qu'il se compte avec les doigts d'une main.
Ben la ca se tient comme argument, m'enfin c'etait pour la forme.

Garder une tigcclib-compat.a de la version 0.93 sous la main. Ca fera pas de mal

tigrou a écrit :
sinon pour mon problème comment on fait ?

As-tu bien pensé à initialiser a5 quelque part avant de l'utiliser dans: move.l ngetchx*4(a5),a0?

PpHd a écrit :
thibaut, Nitro, les autres : regardez : j'ai gagne !!!!!!!

C'est juste que comme l'ABI de TIGCCLIB n'est pas finalisée, c'est normal qu'il y ait encore des changements à faire dans les programmes en assembleur qui l'utilisent. Je ne vois pas ce qui est bizarre. Ça n'empêche pas de l'utiliser quand-même.

ben oui quand meme

move.l $c8,a5 ;place la table des ROM_CALLs en a5

YAHOUUUUUUUUUU
DANSE DE LA VICTOIRE

merci kevin c ta réponse sur l'autre thread niveaux de gris qui m'a mis sur la voie.

vive la TI