Sprite en niveau de gris - Page 1

Salut tt le monde. J'aimerai savoir comment faire pour fre afficher un srite facilement en niveau de gris sans que cela devienne lourd a gerer et que ca ne prenne pa trop de temps. En fait je voudrai si possible que cela soit un peu comme qd il n'y a que le noir et le blanc. Merci d'avance pour vos réponses.

tu utilise graphlib pour le gray, et il te sort deux plans
tu affiche ton sprite comme en n&b, suf que ce sera sur 2 plans, c tout

J'ai essayer, mais le deuxieme plan ne s'affiche pas. Ou est mon erreur?
  INCLUDE "tios.h"   include "flib.h"   include "graphlib.h"   xdef _main   xdef _comment   xdef _ti89   _main:    jsr graphlib::gray4    move.w #1,graphlib::choosescreen    move.l graphlib::plane0,a1  ;Charge l'adresse du premier écran virtuel    jsr graphlib::clr_scr  ;Pour ensuite l'effacer    move.l graphlib::plane1,a1  ;Charge l'adresse du second écran virtuel    jsr graphlib::clr_scr  ;Pour ensuite l'effacer    move.w #100,d0    move.w #50,d1    move.l graphlib::plane0,a1  ;Charge l'adresse du premier écran virtuel    lea sprite0(pc),a0    JSR  graphlib::put_sprite    move.l graphlib::plane1,a1  ;Charge l'adresse du second écran virtuel    lea sprite1(pc),a0    JSR  graphlib::put_sprite    clr.w      graphlib::choosescreen    jsr graphlib::gray2       ; Attend l'appuie d'une touche     ; ----------------------------     JSR     flib::idle_loop ; on lance la fonction     RTS

Regarde les sources de Graytst, elles doivent etre fournies avec doors

heu ,met le idle_loop avant de desactiver les gray ptet

gugusg> merci ca marche a merveille, lol, mais g honte d'avoir ft une erreur aussi conne.
Paxal> merci, mais ce fichier ne m'est d'aucune utilité car il ne ft qu'afficher des bandes horizontales, merci qd meme.

po grave ca arrive à tout le monde

Merci. Maintenant grace a toi, je sui un pro du gray
En fait au début je voulé fre un RPG en TI-Basic, ms vu a kel vitesse va FF7, et pui vu que les graphism sont pa top, je me suis décidé a le fre en ASM. J'avais déja un peu modifié certain prog pour essayer de comprendre l'ASM, mais je ne m'y été encore jamais mi kom mntnt. Là g vraiment envie de savoir programmé en ASM.
Et kom il fallai bien commencé par kelke chose, g comencé par la partie graphique: afficher un sprite. Et comme j'aurai été trè vite limité avec 2 couleur, g préféré en utilisé 4, voir 7. Maintenant que je sais comment fre pour l'affichage (grace a toi), je v me lancer dans une autre partie. Encore merci!!

gugusg a écrit :
tu utilise graphlib pour le gray, et il te sort deux plans
tu affiche ton sprite comme en n&b, suf que ce sera sur 2 plans, c tout

Utilise plutôt TIGCCLIB et ExtGraph.

 include "OS.h"
 xdef _nostub
 xdef _ti89

 movem.l a3-a5,-(a7)
 move.l $c8,a5

 bsr GrayOn
 move.l __L_plane(PC),a3
 move.l __D_plane(PC),a4

 pea.l (a3)
 pea.l (a4)
 bsr ClearGrayScreen2B ;fonction de ExtGraph, efface les 2 écrans virtuels en même temps
 addq.l #8,a7

 pea.l (a3) ;argument: dest2
 pea.l (a4) ;argument: dest1
;émule le format de sprites de graphlib - si tu convertis tes sprites, ça sera plus simple
 lea sprite0(pc),a0
 lea sprite1(pc),a1
 move.w (a0)+,d0 ;hauteur
 move.w (a0)+,d1 ;largeur en octets
 move.w d1,-(a7) ;argument: bytewidth
 move.w d0,d2
 mulu.w #30,d2
 mulu.w d1,d2 ;taille d'un plan du sprite
 pea.l 0(a1,d2.w) ;argument: mask2
 pea.l 0(a0,d2.w) ;argument: mask1
 pea.l (a1) ;argument: sprite2
 pea.l (a0) ;argument: sprite1
 move.w d0,-(a7) ;argument: h
 pea.l 100*65536+50 ;arguments: x et y
 bsr GraySpriteX8_MASK ;routine de sprites la plus flexible de ExtGraph
 lea.l 32(a7),a7

 move.l ngetchx*4(a5),a0
 jsr (a0) ;Attend l'appui d'une touche

 bsr GrayOff
 movem.l (a7)+,a3-a5
 rts

tu changera jamais toi

erf, selon toi tout le monde compile avec tigcc... pfff

ça devient lourd a force...

lol Kevin
il a demandé un truc simple et apparemment il utilisait déjà graphlib
pas besoin de l'embrouiller encore plus en le plongeant dans une guerre dont il ne connait peut-être pas même l'existance!

Au risque de vous decevoir je compile avec tigcc, mais bon, pa en nostub.

Ne t'inquiète pas.
Seul Kevin sera déçu.
Enfin à moitié.
Mais il s'en remettra.
Il est très endurant.
Il va revenir à la charge.
Sacré Kevin alors!

EagleLIONHEART
a écrit : Au risque de vous decevoir je compile avec tigcc, mais bon, pa en nostub.

Pourquoi pas? Ce n'est pas dur de se mettre à jour. Il suffit de lire mon tutorial.

D'ailleurs, flib.h est totalement dépassé:
1. Cette librairie s'appelle util depuis qu'elle existe sur TI-89/92+.
2. util est également dépassée, et elle ne fait que rediriger vers userlib dans les kernels récents.
3. idle_loop est une fonction totalement dépassée et inutile. La ROM_CALL ngetchx (doorsos::ngetchx si tu travailles toujours en mode kernel) fait exactement la même chose et t'évite d'utiliser une librairie (donc gain de place).

Ximoon a écrit :
Ne t'inquiète pas.
Seul Kevin sera déçu.
Enfin à moitié.
Mais il s'en remettra.
Il est très endurant.
Il va revenir à la charge. Sacré Kevin alors!

Je ne suis pas déçu. La bataille vient juste de commencer.

Et s'il utilise TIGCC pour compiler, c'est déjà un point de gagné.

Kevin Kofler a écrit :
Pourquoi pas? Ce n'est pas dur de se mettre à jour. Il suffit de lire mon tutorial.

D'ailleurs, flib.h est totalement dépassé:
1. Cette librairie s'appelle util depuis qu'elle existe sur TI-89/92+.
2. util est également dépassée, et elle ne fait que rediriger vers userlib dans les kernels récents.
3. idle_loop est une fonction totalement dépassée et inutile. La ROM_CALL ngetchx (doorsos::ngetchx si tu travailles toujours en mode kernel) fait exactement la même chose et t'évite d'utiliser une librairie (donc gain de place).

Pour l'instant je ne cherche pa du tout a optimisr un code qui n'existe pas encore, je veu tout simplement savoir fre ca, c tt. Et pui je n'ai pa l'intention de laisser le idle_loop, c juste pour avoir le temps d'admirer le menu, lol. Car de tte facon apré je mettrai un getkey!
Ensuite, pour me mettre a jour il fodrai que je passe du nostub au kernel (sans vouloir te vexer), or je sui deja au kernel, donc je sui deja a jour!

Kevin Kofler a écrit :
Je ne suis pas déçu. La bataille vient juste de commencer.

Et s'il utilise TIGCC pour compiler, c'est déjà un point de gagné.

C'est pour celà que j'ai dit que tu ne serais qu'a moitié déçu!

EagleLIONHEART a écrit :
Ensuite, pour me mettre a jour il fodrai que je passe du nostub au kernel (sans vouloir te vexer), or je sui deja au kernel, donc je sui deja a jour!

Ne te fais pas avoir par la propagande de PpHd et consortes! Les kernels sont loin d'être "à jour". Ce sont des TSRs créés pour émuler le plus possible un environnement Fargo, c'est-à-dire un environnement de TI-92 simple. C'est donc quelque chose de très vieux. La plupart des fonctions des librairies dynamiques ne sont présentes que pour la compatibilité avec de vieux programmes. Il y a des ROM_CALLs équivalents dans AMS et on perd une quantité importante de place en les réécrivant (ou en utilisant des librairies qui les réécrivent). idle_loop en est l'exemple par excellence. Par conséquent, les kernels ne sont plus "à jour" depuis que Zeljko Juric a documenté les ROM_CALLs les plus importants dans sa documentation de TIGCCLIB (maintenant intégrée dans la documentation de TIGCC), c'est-à-dire depuis janvier 2000.

Je considère que "se mettre à jour" ne veut pas dire migrer vers des méthodes qui ont 5 ans et qui sont dépassées depuis 2 ans (mode kernel), mais de migrer de ces vieilles méthodes vers les méthodes plus récentes (mode _nostub).

Petit coquin!!!
Qui est-ce qui fait de la propagande ici
Laisse-le programmer kernel s'il le veux.
C'est plus simple pour commencer non?
Et puis il a dit lui même qu'il préférait ainsi, sans préjugés.

Allez, laisse-tomber, c'est de bonne guerre cette fois-ci

Je ne fais pas de la propagande, je rappelle juste les faits!

Nan nan nan.
Vilain Kevin.
tu fait de la propagande pro-nostub.
je ne dis pas que c'est mal.
Je veux juste que tu le reconnaisse.

Et aucun de nous ne l'a incité à programmer en kernel.
Il l'a fait tout seul.
Et pas la peine d'impliquer PpHd qui n'a pas posté ici.

putain kevin, c'est pas croyable! mais fous la paix aux gens! laisse les faire ce qu'ils veulent! on te paye pour démolir les kernels et faire de la pub pour le _nostub??

franchement, je trouve pas que les kernels soient dépassés... (en tt cas c PpHd ki va être content d'entendre que PreOs est dépassé )

En plus ,Kevin a lui-même participé à PreOs.

sBibi> lol .. c vrai que ca va encore partir en couilles ...

Ximoon a écrit :
En plus ,Kevin a lui-même participé à PreOs.

Seulement parce que ça permet de lancer de vieux programmes sans le HW2Patch. Ce n'est pas une raison de programmer de nouveaux programmes en un mode de programmation dépassé.
En plus l'URL que tu as donnée pour mon site est fausse.

Mea culpa.
J'ai presque pas fait exprès
n'empèche que j'étais pas loin

Ximoon : LOL pour l'url
Kevin Kofler : OUI je l'admet, je suis passé du côté obscur du nostub !
Arrrggg vais je être banni de T3 pour ca ?

TechNIC
a écrit : Kevin Kofler : OUI je l'admet, je suis passé du côté obscur du nostub !

Cool (sauf pour l'appellatif "côté obscur" )!