CPC Rulez :: Consulter le sujet - Développement CPCEmuPower

Egalement, un truc que je n'avais pas compris : si un sprite est activé (Y==crtcLine), si on reprogramme son Y entre le Y d'origine et la crtcLine où on est, la hauteur du sprite est prise en compte et change... je n'ai pas encore trouvé exactement comment bien programmé cela dans l'émulation ASIC...
j'ai également constaté : si on a dépassé le début de la ligne Horizontal Counter =0, on ne peut pas mettre un Y sur cette ligne (si pas déjà mis avant et activé le sprite) en modifiant son Y pour afficher le sprite...
pour le Y de fin, je me demande, si il n'y a pas tout simplement un calcul fait : Y+(0x10<<(magY-0x01)) (si magY est différent de 0) et une autre comparaison pour savoir où on n'affiche plus le sprite en vertical (YEnd==crtcLine) ?

Auteur :	Megachur [ 29 Mars 2020, 17:46 ]
Sujet du message :	Développement CPCEmuPower
Hello marcel ! J'ai pas mal avancé aussi sur CPCEmuPower depuis janvier sur l'émulation CPC+. Depuis 3 semaines, je suis sur la partie Sprite...il ne restait que cela Il ne me reste des soucis quand R4 est mis à 0 ce qui est le cas de Black Sabbath ou de Delirium Tremens... Si tu as des infos sur le comportement pour les sprites dans ces cas là... de ce que j'ai pu comprendre par exemple, si on prend l'exemple de Black Sabbath... avant la rupture ligne à ligne (r4=0), on a le sprite qui devrait s'afficher (Y compris entre FFFF et FFFF-16) et en fait il ne s'affiche pas (Line Counter = R4 (Vertical Total) est-ce pour cela ?) et de plus le Y bouge quand même sans l'affichage et ce qui donne le sprite vertical ou pendant que R4=0, il n'y a pas de changement de ligne du sprite, jusqu'en bas, ou finalement, les lignes restantes du sprites s'affiche... Egalement, un truc que je n'avais pas compris : si un sprite est activé (Y==crtcLine), si on reprogramme son Y entre le Y d'origine et la crtcLine où on est, la hauteur du sprite est prise en compte et change... je n'ai pas encore trouvé exactement comment bien programmé cela dans l'émulation ASIC... j'ai également constaté : si on a dépassé le début de la ligne Horizontal Counter =0, on ne peut pas mettre un Y sur cette ligne (si pas déjà mis avant et activé le sprite) en modifiant son Y pour afficher le sprite... pour le Y de fin, je me demande, si il n'y a pas tout simplement un calcul fait : Y+(0x10<<(magY-0x01)) (si magY est différent de 0) et une autre comparaison pour savoir où on n'affiche plus le sprite en vertical (YEnd==crtcLine) ? j'ai l'impression, que l'adresse initiale des data du sprite (ex : &0100) et mise dans un tampon nextADDR et n'ait pris en compte que quand on a fini de passer le compteur de magnification... et que celui est peut-être basé sur le compte de raster car il ne semble incrémenté que toutes les lignes ? la CRTC3 marche à 99%, il reste juste le point sur la reprogrammation du Y dans la plage des lignes du sprites à traiter... Tout info est la bienvenue pour m'aider ! a+

Auteur :	marcel [ 29 Mars 2020, 18:37 ]
Sujet du message :	Re: Développement CPCEmuPower
Yo! Alors au contraire d'Iron, je n'ai jamais joué avec la ligne à ligne (ou pire) et les sprites hard donc ce que je vais dire est à vérifier. Je pourrais essayer de faire une cartouche de test pour ces cas! Il me semble que le Y des sprites est comparé à une formule dépendante des compteurs de ligne dans le bloc et du compteur de bloc ça donne des effets tels que si tu mets autre chose que 8 pour le nombre de lignes par blocs, il y a une différence entre le compteur de lignes réelles et l'affichage d'un sprite Un peu comme les interruptions, j'avais voulu utiliser des blocs de 4 lignes j'avais le souci que les interruptions ne se déclenchaient pas pour toutes les (lignes réelles modulo 8)+4 C'est pareil pour les sprites hard, tu peux faire disparaitre des lignes Du coup je suppose que concernant la ligne à ligne c'est pareil! Du coup la ligne 0 de l'écran continue de s'appeler zéro sur tout l'écran et ton sprite fais de la ligne à ligne Sans même regarder le code de la BarBar d'Eliot, je pense que c'est la même technique utilisée, une ligne à ligne de CPC avec des fonctionnalités Plus actives Code : Egalement, un truc que je n'avais pas compris : si un sprite est activé (Y==crtcLine), si on reprogramme son Y entre le Y d'origine et la crtcLine où on est, la hauteur du sprite est prise en compte et change... je n'ai pas encore trouvé exactement comment bien programmé cela dans l'émulation ASIC... j'ai également constaté : si on a dépassé le début de la ligne Horizontal Counter =0, on ne peut pas mettre un Y sur cette ligne (si pas déjà mis avant et activé le sprite) en modifiant son Y pour afficher le sprite... pour le Y de fin, je me demande, si il n'y a pas tout simplement un calcul fait : Y+(0x10<<(magY-0x01)) (si magY est différent de 0) et une autre comparaison pour savoir où on n'affiche plus le sprite en vertical (YEnd==crtcLine) ? J'suis pas sûr de ce que tu avances, faudrait que je vérifie ma cartouche "sprites" publiée sur cpcwiki car je faisais des trucs bizarres dans le genre. Au minimum je modifiais le X en cours de ligne et je pouvais tripler l'affichage d'un même sprite je vais tenter de trouver du temps cette semaine pour faire un test de sprite un peu plus poussé en mettant pas mal de choses en évidence

Auteur :	Megachur [ 29 Mars 2020, 19:27 ]
Sujet du message :	Re: Développement CPCEmuPower
C'est super pour ton aide ! pour la comparaison avec le Y au niveau du crtc : crtcLine=((line_counter<<3)\|(raster_counter&0x07)); c'est le même que pour le check SPLT et le PRI (au &01ff et 03ff prêt comme expliqué dans la doc de l'ASIC sur cpcwiki) le check horizontal, c'est plus simple, c'est à chaque clock de crtc directement avec le "horizontal counter" ! sinon, y'a aussi It Was So Nice Before The Crash of the Mir Station (UK) (128K) (1999) [CPC+] [DEMO] qui donne une idée de la gestion de ce que je j'évoquai : pour le logo ZM et le scroll vertical en sprite voilà à quoi ressemble la "black sabbath" de mon côté : Pièce jointe : Black Sabbath_000.png sans hack pendant le R4=0 et ce que j'évoquais au-dessus sur le Y... La Barbar par contre marche très bien car ce n'est pas du tout la même technique : Pièce jointe : BarBar (UK) (2016) [CPC+] [DEMO]_002.png

Auteur :	marcel [ 29 Mars 2020, 22:54 ]
Sujet du message :	Re: Développement CPCEmuPower
Concernant la black sabath il est important de déclencher le PRI en début de HSYNC mais aussi en fin de HSYNC (si le crtc_line match) ce qui peut arriver avec la fin de hsync de la ligne précédente si l'écran n'a pas de border sur les côtés. Si tu ne déclenches que sur le début de la HSYNC tu te retrouves avec un décalage de 48 nops sur ce qu'il faut faire et potentiellement des artefacs à la con. Mais je trouve bizarre que les sprites soient visibles depuis plusieurs lignes comme ça... pour la delirium Kevin avait aussi expliqué quelque chose mais je ne retrouve pas (en rapport avec les ruptures verticales et un certain registre à zéro)

Auteur :	Megachur [ 31 Mars 2020, 07:35 ]
Sujet du message :	Re: Développement CPCEmuPower
hello ! j'ai fait pas mal d'essais... effectivement, d'après mes tests si une sprite est actif et qu'on reprogramme son Y avec un Y compris entre la valeur de départ et la valeur de fin, cela décale bien la fin du sprite... avec cela on voit par exemple que le sprite bleu vertical n'est plus coupé (également fixe les sprites qui cache l'écran principal de la Eerie Forest par exemple) : Pièce jointe : Black Sabbath_001.png pour la Black Sabbath... Je pensais que le display du sprite était lié au DisplayEnable du crtc mais visiblement, sur les lignes, il faut également que la ligne d'affichage du sprite soit positive. je m'explique si je programme #FFFF comme début de mon sprite, mon sprite va commencer une ligne avant la réinit du compteur de ligne (==R4). mon algo était de calcule si #FFFF est >= #0000-(la hauteur du sprite) si on a un sprite en mode 2 par exemple #FFFF >= #FFF0 (#0000-#0010) alors additionne (R4_vtr<<3)+R9_mslar+0x0001 pour retrouver une valeur positive et la comparer au compteur de ligne CRTC avec R4=26 et R9=7 classique ça nous donne : #FFFF+#0130+#0007+#0001 =#0137=311 (on est bien sur la dernière ligne possible d'affichage ) par contre, on a dans le cas de la BlackSabbath, au moment de l'affichage des sprites vumètres, R4<R7 donc la VS n'a pas eu lieu et donc on pourrait en déduire qu'on est également pas encore à la fin de l'écran ? mais cela me semble un peu complexe... mon avis et mes tests semble plutôt indiquer que l'affichage vertical n'est déclenché que quand on est à une ligne de sprite positive donc >=#0000 ! si je fais, cela effectivement, je n'ai pas le sprite qui apparait sur le scroll. également, juste pendant que le compteur de ligne arrive sur R4 (et le compteur de raster = à R9), R4 passe à zéro.... ce qui a pour conséquence que le sprite est réaffiché sur la ligne 0000 en fonction de la hauteur précédente... après ce que je vois c'est que le fait que R4=0 et R9=0 fait que le sprite reste tout le temps sur la même ligne... jusqu'au moment ou R4 et R9 sont remis à une valeur différente et l'affichage de ligne se poursuit... Code : c'est ici que cela se passe dans le code au début de la rupture ligne à ligne : 324B:ld bc,#BC04 324E:out (c),c 3250:ld bc,#BD00 3253:out (c),c ;-> c'est ici qu'on est en fin de ligne/écran... 3255:ld bc,#BC09 3258:out (c),c 325A:ld bc,#BD00 325D:out (c),c 3255:ld bc,#BC09 3258:out (c),c 325A:ld bc,#BD00 325D:out (c),c

CPC Rulez https://cpcrulez.fr/forum/

Développement CPCEmuPower https://cpcrulez.fr/forum/viewtopic.php?f=7&t=6331	Page 1 sur 2

Auteur :	marcel [ 31 Mars 2020, 08:32 ]
Sujet du message :	Re: Développement CPCEmuPower
Oui, ça n'a pas de sens d'afficher les lignes sur un Y négatif, sinon tu dois avoir des effets secondaires types un sprite qui commence avant l'écran se retrouve aussi tout en bas

Auteur :	Megachur [ 02 Avr 2020, 09:39 ]
Sujet du message :	Re: Développement CPCEmuPower
marcel a écrit : Oui, ça n'a pas de sens d'afficher les lignes sur un Y négatif, sinon tu dois avoir des effets secondaires types un sprite qui commence avant l'écran se retrouve aussi tout en bas bon, j'ai encore réécris tout, j'en suis à la troisième fois qd même et j'ai réussi a bien intégrer toutes les situations... et surtout quand on programme un Y inférieur à la position actuelle du CRTC... dans ce cas, le sprite, apparait comme s'il avait commencé au bon Y (cf sprite boule de X-Mas 2008 v2 (UK) (2015) [Original] [CARTOUCHE]). D'ailleurs pour cette dernière démo, j'ai vu un petit bug sur l'affichage de la derniére boule... le haut de la bulle ne s'affiche pas quand elle remonte... c'est pas très visible mais cela semble être le bon comportement ! il me reste maintenant à comprendre comment ça marche quand R4=0... visiblement, il y a un lien quand R9=0 (cas de la blackSabbath) on a plus de passage à la ligne suivante du sprite... contrairement à la Delirium Tremens où R9 <> 0 par exemple ! donc cela voudrait dire qu'il y a peut-être un lien entre le compteur de raster et le compteur de ligne du sprite (à pas confondre avec la magnification Y) !

Auteur :	marcel [ 02 Avr 2020, 18:05 ]
Sujet du message :	Re: Développement CPCEmuPower
Oui il y a un lien avec le compteur de lignes raster puisque si tu changes le nombre de lignes par bloc, tu peux couper un sprite en deux (ou en tronquer une partie)

Auteur :	Megachur [ 05 Avr 2020, 14:50 ]
Sujet du message :	Re: Développement CPCEmuPower
J'ai fini par trouver... en fait, c'est bien en lien avec R4 (vertical total) mais pas comme je pensai tout à fait au départ... en fait, c'est quand on est justement à la fin de l'écran (HC=0 et VT (remise à zéro compteur de ligne et de raster)) qu'on doit regarder seulement les valeurs négatives de Y. tout marche maintenant avec cela !!! Black Sabbath et cie qui utilisent R4=0 : Pièce jointe : Black Sabbath_002.png Pièce jointe : Delirium Tremens Preview (UK) (2001)_000.png Pièce jointe : Delirium Tremens Preview (UK) (2001)_001.png Pièce jointe : Funerapolis (UK) (2011) [CPC+] [DEMO]_000.png

Auteur :	marcel [ 05 Avr 2020, 19:20 ]
Sujet du message :	Re: Développement CPCEmuPower
Chouette bravo! Tu veux dire qu'une fois R4 atteint, le compte d'INT est remis à zéro? Dans ce cas, on n'a plus du tout d'interruption si on laisse se dérouler la ligne à ligne?

Auteur :	Plissken [ 06 Avr 2020, 11:53 ]
Sujet du message :	Re: Développement CPCEmuPower
Pour la funérapolis,je modifie le Y des sprites sur de la ligne a ligne. La ligne a ligne fait que la même ligne des sprites se répète tout le long de la rupture,en bougeant Y on a droit a ce genre d'effet

Auteur :	Megachur [ 06 Avr 2020, 14:23 ]
Sujet du message :	Re: Développement CPCEmuPower
marcel a écrit : Chouette bravo! Tu veux dire qu'une fois R4 atteint, le compte d'INT est remis à zéro? Dans ce cas, on n'a plus du tout d'interruption si on laisse se dérouler la ligne à ligne? non, c'est pas cela, les interruptions restent active (PRI, Raster, etc.)... c'est ce qu'explique Plissken : - en gros l'algo c'est cela (pour les 16 sprites) si les coordonnées du sprites + la hauteur du sprite dépasse 0 ----- si on a YMag différent de 0 ---------on autorise le Vertical Enable pour afficher le reste du sprite où Y+haute du sprite > 0 sinon on disable le Vertical Enable du sprite donc si tu programmes 0x0000 en sprY et R4=0 et R9=0 (avec un MagY=1) tu fais comme la black Sabbath un sprite qui se répète à la même ligne jusqu'à la fin de la rupture ligne à ligne. ici en + selon la valeur de Y (de FFF0 à FFFF (hauteur du sprite=16 car MagY=1 par exemple)), ton sprite va se répéter à la ligne qui dépasse 0 par exemple : si je mets FFF0 avant, j'arrive à 0 à la 15ième lignes et dernier ligne du sprite qui va se répéter (car R4 et R9 sont à 0). si R9 était à 1 par contre, cela n'afficherait qu'une ligne du sprite car on passerait à la ligne suivante alors que là, on se remet à la même ligne à chaque vertical total donc à la 15ième puisque sprY reste à &FFF0 ! ce que j'ai donc compris c'est que si tu reprogrammes le sprY (avec des valeurs négatives forcément, FFFF, FFFE, FFFx, etc.) et R4=0 et R9=3, (avec un MagY=3) tu vas afficher ton sprite à la ligne 1, 2, etc... à partir de la ligne crtc 0 qui se répète tout les lignes du nombre de R9 ! on peut se permettre donc de mettre SPRY High à &ff et ensuite ne changer toutes les lignes (ou 3 ) la valeur SPRY Low quand on veut que le sprite change à une autre ligne que la ligne suivante et donc si on laisse le sprY on a le sprite qui se répète à la même ligne indéfiniment... en si R9=MAG par contre il bouge à la ligne suivante... @Plissken : par hasard j'ai vu d'autres sprites dans la Funerapolis (cpc-p0wer Test), c'est utilisé dans une cheat part ?

Auteur :	Plissken [ 06 Avr 2020, 19:07 ]
Sujet du message :	Re: Développement CPCEmuPower
Megachur a écrit : @Plissken : par hasard j'ai vu d'autres sprites dans la Funerapolis (cpc-p0wer Test), c'est utilisé dans une cheat part ? Ces sprites ne sont pas utilisés

Auteur :	AsT [ 08 Avr 2020, 15:20 ]
Sujet du message :	Re: Développement CPCEmuPower
Megachur a écrit : bon, j'ai encore réécris tout, j'en suis à la troisième fois qd même et j'ai réussi a bien intégrer toutes les situations... et surtout quand on programme un Y inférieur à la position actuelle du CRTC... dans ce cas, le sprite, apparait comme s'il avait commencé au bon Y (cf sprite boule de X-Mas 2008 v2 (UK) (2015) [Original] [CARTOUCHE]). D'ailleurs pour cette dernière démo, j'ai vu un petit bug sur l'affichage de la derniére boule... le haut de la bulle ne s'affiche pas quand elle remonte... c'est pas très visible mais cela semble être le bon comportement ! Oui, c’est le bon comportement. Par contre, ce n’est et n’était pas un bug. Je voulais laisser l’impression que l’un passait derrière ^^

Page 1 sur 2	Le fuseau horaire est UTC+1 heure
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/

Auteur :	Megachur [ 08 Avr 2020, 17:24 ]
Sujet du message :	Re: Développement CPCEmuPower
AsT a écrit : Oui, c’est le bon comportement. Par contre, ce n’est et n’était pas un bug. Je voulais laisser l’impression que l’un passait derrière ^^ Salut AsT : C'était à noter car je ne sais pas si les cpciens avaient remarqué ce détail de l'artiste !