CPC Rulez :: Consulter le sujet - scroll overscan double buffer

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

scroll overscan double buffer https://cpcrulez.fr/forum/viewtopic.php?f=4&t=4536	Page 1 sur 1

Auteur :	Megachur [ 27 Mai 2011, 15:04 ]
Sujet du message :	scroll overscan double buffer
Hello, voilà, je me demandai, si cela était possible de faire un scrolling hardware en double buffer en overscan. Je m'explique : 2 x &4000 pour la première partie de l'écran en overscan 2 x &4000 pour la deuxième partie de l'écran en overscan par exemple : &0000 - &4000 pour le 1er &8000 - &c000 pour le 2ième la problématique réside que si on fait cela, même sans le système, on ne peut pas écrire en &038 et &039 (interruption en &38 avec au moins EI RET pour que ça marche). Hors, si je fais un scroll hard (double buffer), je vais écrire surement à cet endroit...ou même cela se verra à l'écran (deux octets non couleur du fond). de plus, je pense que le code devra être en bank mémoire avec des jumps...avec un minimum de code en mémoire &0000-&ffff pour les permutations... sans parler de la pile qu'il faudra bien faire pointer quelque part (donc pas de call ou push et pop quand on est en mémoire &0000-&ffff hors des banks ?) je pense qu'on doit avoir un peu de place entre les lignes de datas pour les écrans (mais de combien avec un écran large de 96 octets par exemple ?) Voilà, si vous avez des retours, car j'aimerai savoir si c'est possible sur cpc !?

Auteur :	Plissken [ 27 Mai 2011, 15:40 ]
Sujet du message :	Re: scroll overscan double buffer
J'ai déja vu des scroll en overscan. Un dans la compil zemeeting 2003(?) et l'autre dans un jeu red & blue . Je sais pas si ça peu t'aider.

Auteur :	norecess [ 27 Mai 2011, 16:17 ]
Sujet du message :	Re: scroll overscan double buffer
Yo, C'est parfaitement possible de mettre a 0 TOUTE la mémoire (les 64Kb) et donc effectuer un scroll hard 32Kb page-flippé. Pour &38, ta réponse est : soit tu executes tout ton code avec un DI (pas tres glop, depent du contexte) soit tu regardes autour de IM 2, qui te permet déplacer le saut en &38. Quant au reste, il te faudra utiliser les banks C1, C2 et C3 .. pour placer ton code + pile... Mais j'ai jamais mis en pratique, et je ne suis clairement pas un expert là-dedans.. Longshot, si tu nous lis ?

Auteur :	Megachur [ 27 Mai 2011, 20:30 ]
Sujet du message :	Re: scroll overscan double buffer
Plissken a écrit : J'ai déja vu des scroll en overscan. Un dans la compil zemeeting 2003(?) et l'autre dans un jeu red & blue . Je sais pas si ça peu t'aider. Merci pour ces exemples. Malheureusement, après analyse ils ont bien utilisé l'overscan (un scroll hard) mais pas de double buffer donc pas la totalité de la mémoire...

Auteur :	AsT [ 27 Mai 2011, 21:59 ]
Sujet du message :	Re: scroll overscan double buffer
Je pense que ce doit être possible en utilisant les 64ko de ram en video + le mode im2... Je suis certain d'avoir déjà vu ça dans une des nombreuses preview s d'over le fou.... Tu balances le code dans les 64ko supplémentaires...

Auteur :	Longshot [ 28 Mai 2011, 01:05 ]
Sujet du message :	Re: scroll overscan double buffer
@megachur Tu n'as pas besoin d'utiliser 4 banques pour afficher 2 images overscan mais 3. Donc les problèmes que tu indiques ne se posent pas. Cela implique une rupture, mais si tu veux faire un scrolling crtc, cela s'imposera Mais si tu utilisais toute la ram en vidéo, il faudrait bien que ton code soit en banque, donc il te reste les solutions indiquées par norecess: Déplacer l'adresse d'interruption avec le mode IM2 (pour déplacer le vecteur entre C000 et FFFF en supposant que tu laisses la banque 7 connectée en permanence (via C1/C3)) Désactiver les interruptions (DI, ou 1 interruption sans EI) Théoriquement, tu pourrais t'amuser à remettre les données à afficher en place avant que le CRTC les affiche et remettre juste après le code de l'interruption. C'est un problème qui devient un peu complexe si la ram cycle, car cela suppose que tu modifies la ram à partir de #38 au bon moment (sur l'interruption qui précède l'affichage de la zone) et se synchroniser pour remettre le code de l'interruption avant que la prochaine survienne. Ceci étant dit, si tu es prêt à mettre un EI/RET, autant enlever les interruptions car elles ne servent à rien. Si tu as besoin d'une synchronisation précise, il suffit de générer ton code en temps fixe.

Auteur :	Megachur [ 28 Mai 2011, 05:52 ]
Sujet du message :	Re: scroll overscan double buffer
Merci pour votre aide et vos conseils. @Longshot : ce que je veux faire, c'est bien un scrolling double buffer en overscan. Pourquoi m'indiques-tu que je n'aurai besoin alors que de 3 écrans ? si je mets 2x&4000 pour le 1er écran, j'ai bien besoin de 2x&4000 pour le deuxième... Effectivement, l'idée de modifier en &38 au moment où le CRTC y accède pour afficher à l'écran est une bonne idée...mais vu que la RAM cycle (c'est un scrolling) il va falloir coder très précis pour cela (ex : un jump en &38 vers un morceau de code qui fait ld hl,0 ld (&38),hl ei ret et ensuite dans le programme faire un di et avant le ei : ld hl,&c9fb ld (&38),hl après que le CRTC est passé la zone &38 en affichage ! Sinon, ta proposition d'enlever complètement les interruptions semble bonne également... Je devrais juste avoir du code constant en tps machine ou tout simplement me caler après une synchro de vbl... Donc, si je comprends bien, cela va demander un effort supplémentaire dans tous les cas, je vais voir si mon code en vaut le coup par rapport à l'effort !

Auteur :	TotO [ 28 Mai 2011, 09:00 ]
Sujet du message :	Re: scroll overscan double buffer
Je ne sais pas si c'est lié à cela, mais si tu utilises 24K par écran, tu as bien 3 screens. En 384x256 ou encore 368x264.

Auteur :	shap [ 28 Mai 2011, 10:02 ]
Sujet du message :	Re: scroll overscan double buffer
Ce que dit totO est juste, effectivement, si tu veux deux double buffer fullscreen, ça fait bien 48k soit 3 pages. En fait, dans la plupart des démos cpc utilisant des scroll hard, c'est à la bourrin, c'est à dire que le codeur affiche, décale son affichage et laisse boucler le tout sur 16k ce qui n'est absolument pas nécessaire. en fait il faut juste te contenter de boucler sur la longueur nécessaire, et dans ce cas tu peux préserver la zone 0 si tu as besoin des interruptions. évidemment c'est un peu plus compliqué et ça implique que tu auras un buffer à cheval sur deux pages... Mais à vaincre sans péril, on triomphe sans gloire Pour info (on va encore m'accuser d'être pro-the demo...) si tu examines la phenix part de longshot, tu t'apercevras qu'il n'aurait pas pu faire un scroll hard-> une page de 16k... (je prend cet exemple car ça m'avait beaucoup travaillé à l'époque ou c'est sorti).

Auteur :	Longshot [ 28 Mai 2011, 11:20 ]
Sujet du message :	Re: scroll overscan double buffer
Comme l'indiquent Shap et Toto, pour faire 1 image overscan, tu n'as pas besoin de 32 k Il suffit donc que tu utilises (16k + 8k) x 2 Tu es par contre obligé d'utiliser le cyclage "matériel" de la ram, également pour la banque qui contient les 2 morceaux de 8 k La méthode qu'évoque shap est le cyclage "logique" de la ram. Pour éviter le cyclage "matériel", il suffit de le gérer "logiquement". Cela sert lorsque 2 fois la taille du buffer video affiché est inférieur à 16 k. Tout dépend donc de la ram que tu veux "sauver". Cela consomme 2 fois la taille du buffer vidéo affiché et il faut gérer 2 fois le rafraichissement des données au lieu d'un (en général, lorsqu'on a calculé les données entrantes il suffit de mettre à jour les 2 "rubans" en même temps). Ainsi c'est le programme qui remet le pointeur vidéo au début du "double" buffer. Tu as donc en permanence 2 fois le même buffer en ram pour pouvoir permuter.

Auteur :	Supersly [ 28 Mai 2011, 14:23 ]
Sujet du message :	Re: scroll overscan double buffer
Un vrai fullscreen bien plein fait plutôt 26Ko que 24Ko. Mais 24Ko, c'est déjà très bien la plupart du temps. Mais si vraiment tu regrettes l'overscan de 26k, je pense qu'il y a encore une solution. Tu gères chaque écran sur 2 plages de 16k (donc 32k, comme ton idée de départ) mais réduis le R9 du CRTC à la valeur minimum (donc entre 5 et 6, mettons 6 pour un écran de 28k) et tu cales tes interruptions en mode IM2 dans la zone non affichée de ton choix (les 2 derniers Ko d'une des 4 plages mémoire). La précision du mode IM2 étant de 256 octets (donc 257 occupés), tu ne devrais pas avoir de problème compte tenu qu'il te reste 4x2Ko inutilisés en mémoire centrale. Sauf si je me trompe, bien sûr ; mon truc, c'est plutôt de colorer les pixels, vous savez...

Auteur :	shap [ 28 Mai 2011, 14:40 ]
Sujet du message :	Re: scroll overscan double buffer
Supersly a écrit : Un vrai fullscreen bien plein fait plutôt 26Ko que 24Ko. ça dépend des moniteurs, j'en ai un sur lequel mais un écran de 26k ne rempli pas tout... Supersly a écrit : réduis le R9 du CRTC à la valeur minimum (donc entre 5 et 6, mettons 6 pour un écran de 28k) ça dépend de la quantité de RAM balayé par le CRTC par ligne (R1)...

Auteur :	Megachur [ 28 Mai 2011, 17:40 ]
Sujet du message :	Re: scroll overscan double buffer
Merci à tous pour vos idées et commentaires, cela m'éclaire bien sur les possibilités... y'a plus qu'à mettre cela en œuvre si mon prog le mérite !

Auteur :	TotO [ 15 Nov 2011, 21:58 ]
Sujet du message :	Re: scroll overscan double buffer
shap a écrit : ça dépend des moniteurs, j'en ai un sur lequel mais un écran de 26k ne rempli pas tout... Parce qu'un vrai overscan PAL fait 384x288, soit 27Ko. La taille de 384x272 (270 sur les émulateurs) est arbitraire et non standard.

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