Necstasy

Est ce que Jackie Chan utilise le bug pce pour l'effet des colonnes ou c'est une autre astuce ?

C'est bien ça, on joue sur le fait que le VCE essaye d'afficher un sprite/BG avec des priorités particulières.

D'ailleurs il n'est pas absolument obligatoire d'avoir un fond noir.

Je sais plus où est ma vieille démo de sonic et des cristaux de glace mais c'est le méme principe.

Celle-ci ne me dis rien du tout. J'ai pourtant pas mal de tes démos.

xav a écrit :C'est bien ça, on joue sur le fait que le VCE essaye d'afficher un sprite/BG avec des priorités particulières.

Donc les colonnes à l'écran sont des sprites qui recouvrent les mêmes colonnes plus foncées de l'arrière-plan et lorsque le sprite du perso arrive sur elles ça fait apparaître celles de l'arrière-plan.

Correct ?

Tu peux facilement décortiquer l'effet en jouant avec les options de sprite et de BG dans Ootake ou ME ; très instructif comme reverse-engineering :)

Kaminari a écrit :Tu peux facilement décortiquer l'effet en jouant avec les options de sprite et de BG dans Ootake ou ME ; très instructif comme reverse-engineering

C'est clair

Merci mais je le savais. C'était juste pour gagner du temps.

Tout es dans le titre

A récupérer ici : http://www.pcedev.net/demos/transparency/test0.zip
C'est pas énorme, mais l'effet est bluffant .

L'explication est là :

The transparency is realtime (Amiga planar style). That is to say, it uses the VDCs 4bit planar mode to do hardware assist transparency effects. The demo was never polished and finished, but you can still see the results. I had this crazy idea; instead of using fixed point entries as code lists with RTS instruction for the embedded video in st1/st2 opcodes, one would use the hsync interrupt or the TIMER interrupt to set a time limit to the transfer. You push the return address on a special stack or place in ram, jump to the address and let the cpu run hog wild. When the interrupt counter completes, you manually change the real stack with the special/saved address and return to that instead. Of course, you'll need a buffer in vram for over spill since neither the hsync interrupt or timer interrupt is fine enough cycle wise to do accurate stopping on an exact instruction. Crazy? Yup, but it's totally doable.

Ceux qui comprennent pas comment c'est fait, allez jouer sur MD

PS: Je vous le dit, perso, j'ai rien compris

Pareil, je ne vois pas des masses ce que ça a à voir avec la choucroute. J'aurais préféré un bout de code.

Mais si j'ai tout compris ça revient à la technique sur c64 pour avoir du code gourmand synchro avec les interruptions. En gros quand tu arrives dans l'interruption, la valeur du registre PC (en gros là où tu te trouvais avant que l'interruption pète) et le registre de statut sont poussés sur la pile. Le code de l'interruption est exécuté et quand rti (return from interrupt) est rencontré, les registres de statut et PC sont dépilés. Tu te retrouves alors là où tu avais été interrompu.

La technique consiste donc à pousser l'adresse du code "gourmand" ainsi que la valeur du registre de statut sur la pile. Tu te retrouves donc avec 2 tuples PC, statut sur la pile. A la fin du code de l'interruption, le rti t'envoie alors sur le code "gourmand". Mais tu n'es plus dans le contexte de l'interruption. Les autres interruptions peuvent claquer et tu as moins de chance d'exploser la synchro. Un truc important à noter, c'est que tu as toujours l'adresse du code "standard" et la valeur du registre de statut associé dans la pile. Il faut que le code "gourmand" se termine par un rti.

Niveau code ça donne un truc du genre:

Code : Tout sélectionner

interrupt_handler:
    ; Save registers
    pha
    phx
    phy

    ; Push routine adress
    lda    #high(uber_routine)
    pha

    lda    #low(uber_routine)
    pha

    ; Fake status register value
    cla
    pha

    ; [ISR code...]

    ; Let's jump to uber_routine
    rti

Code : Tout sélectionner

uber_routine:
    ; [do a lot of complicated stuff]

    ; Restore register
    ply
    plx
    pla

    ; Jump back to the "main" code
    rti

Bon après pour l'effet de transparence en lui même, je vois pas trop comment c'est fait. Ma première intuition est qu'il fait clignoter un sprite... Mais je doute que ce soit ça. Il faudrait que je regarde la ROM.

Merci pour l'explication ..
J'avais vaguement compris un truc dans le genre, et je ne voyais pas non plus le rapport, donc je me suis dit, "bah j'ai rien compris"

..

D'ailleurs je sais pas trop non plus comment il fait, mais bon je suis pas sur que ce soit réellement faisable hors d'une demo .
Y'a aucun sprite dedans, c'est que du background, il utilise les BP pour faire ça, comme sur amiga .
Ca doit surement limiter les tile concernées à 2bpp, donc 4 couleurs seulement/tile, voire moins peut être .

Ok je vois le truc. C'est un peu ce que j'avais fait pour avoir 4 damiers qui scrollaient indépendamment.
C'est vrai que pour 2 maps ça doit bouffer pas mal de VRAM et de temps CPU.

Oui et il doit surement aussi réserver des couleurs dans la palette pour la transparence.

Je viens de tester et c'est beau. Miam, en esperant qu'il utilise l'effet dans le jeu qu'il compte developper.

10 ans plus tard, Tom remet le couvert... et partage ses progrès sur GitHub !

https://www.youtube.com/watch?v=qWRT9JvUBTU

Necstasy

Démos de transparence [Tom]

Re: Nouvelles démos de Tom (transparence inside)

Re: Nouvelles démos de Tom (transparence inside)

Re: Nouvelles démos de Tom (transparence inside)

Re: Nouvelles démos de Tom (transparence inside)

Re: Nouvelles démos de Tom (transparence inside)

Re: Nouvelles démos de Tom (transparence inside)

Re: Nouvelles démos de Tom (transparence inside)

Effet de transparence de Tom sur une simple PCE

Re: effet de transparence de tom sur une simple PCE

Re: effet de transparence de tom sur une simple PCE

Re: effet de transparence de tom sur une simple PCE

Re: effet de transparence de tom sur une simple PCE

Re: Effet de transparence de Tom sur une simple PCE

Re: Démos de transparence [Tom]