Api apo! Je reposte çà ici, à des fins d'apprentissage ou pour bidouiller, etc. RUN"FX en basic, le source asm est fourni aussi.
1) on met l'écran en &4000 au lieu de &C000 Comme çà on peut mettre le code en &C000. Avantage? compatible avec les modes 7FC1 7FC2 7FC3
2) passage au mode 7FC2 On met tout (basic+OS) dans les 64Ko supérieurs. Alors quand le système met des choses à l'écran, on voit rien: logique, puisque seul les 64Ko inférieurs sont accessibles par la vidéo, or là l'écran en 4000 dans les 64Ko ben on ne le voit pas. Mais confirmé: le basic est toujours là.
3) chargement des écrans dans la ram vidéo LOAD 4 fois pour 4 écrans en 0000 4000 8000 C000; on charge d'abord en 4000 dans les 64Ko supérieurs, et puis on recopie dans les 64Ko inférieurs via les modes 7FC1 7FC3.
4) ze fx boucle: affiche écran en 0000 affiche écran en 4000 affiche écran en 8000 affiche écran en C000 color-cycling & goto boucle
Prérequis: 4 écrans générés par RUN"GEN-FX, pour avoir 4 sous-étapes avant le color-cycling.
Suites possibles ? . en asm ou par des pokes dans la palette directement, colorcycling sur 16 couleurs . un dessin plus compliqué ou différents: dots, lignes, ... . jouer avec les 4 bits des 16 couleurs pour 4 pseudo bit-plans, x4 car 4 écrans = 16 étapes ...
Bon amusement!
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
Il semble que là ça prend quand même pas mal de RAM pour stocker tout ça bien sûr, c'est pour du 128K ou du 64K ? L'avantage du mode0 est que le nombre de couleurs offre plus de possibilité de cycle de couleurs bien sûr.
Passer en mode "fullscreen" est il possible en cycle sur 4 images ?
Après tout l'image affichée en plein écran ferait plus dans les 24K que 32K, mais mais les banks faisant 16K ça peut ne pas être aussi simple.
Quelle marge de manoeuvre restent au CPU et à la mémoire ? Je suppose qu'ajouter des sprites soft serait vite plus délicat, déjà parceque ça oblige a se garder des encres "fixes" mais sinon ça ferait (dans le cas présent avec 4 images de base) du quad-buffering... (sort of).
Sur le PLUS on aurait un peu moins de problèmes de par les sprites hards, mais ils pomperait de la RAM car ils sont en "8bpp" quand même. Un chargement en cours (genre le chargement continu de type Batman démo) serait il possible ?
C'est là vraiment le problème du CPC. la RAM est toujours trop juste si on veut faire de la grosse video. C'est là que je suis toujours envieux du TO8D dont le seul défaut est de ne pas avoir bénéficier d'un AY-3-8910 par exemple..quoique avoir le CPU overclocké en 2mhz aurait aussi été ultime) mais qui aligne fièrement un très bon 256K très adapté aux écrans vidéos 16K de type "CPC".
Dans ton exemple, un "couloir wormhole hexagonale", les images sont calculées quand on charge ou c'est précalculé (chargé direct depuis la D7) ? Donc sur une version 128K voire plus, il peut peut être y avoir moyen si c'est codé en Assembleur, d'implémenter un mouvement en cours de route du couloir. Ce mouvement serait peut être assez lent par contre... en gros alors que l'ordi affiche l'un des configurations visuelle (plusieurs images et cycles d'encres) il calcule aussi les prochaines frames sur d'autres banks de RAM, puis on échange le set de frames, et on recalcule le prochain sur le suivant... Si on part sur une anime en 3 frames ça libèrerait sans doute des banks de RAM (théoriquement 32K... si on part sur des écrans en 16K de pseudo VRAM) permettant de garder le code et autre effets (musique).
Autres variantes sinon, utiliser d'autres dimensions d'écran, avec effet cinémascope ou écran vertical... c'est certes moins impressionnant qu'un vrai "overscan" total, mais aussi moins lourd (on reste facilement en version 16K) et toujours plus sympa qu'un écran classique en "160x200" avec un cadre de border sur les 4 côtés. Et puis bon, pouvoir afficher hors du cadre reste le truc en plus du CPC par rapport à la plupart des autres 8bits... pourquoi s'en priver ?
Bref ça serait sympa de savoir si il ne vaut mieux pas calculer l'image ou la charger depuis la D7 en cours de route, à voir niveau performance, mais un lecteur FlapieFloppy c'est pas toujours fiable de nos jours (oh bien sûr un Disque dure serait sympa...).
L'avantage si on peu (re)-calculer l'image, c'est que moins de multiloading et possiblité (héhé, néologisme) d'avoir un superbe boucle longue et "aléatoire", et on reste dans l'esprit démo et non simple "lecteur de fichiers .avi sur CPC". Partir sur une base de 3 frames d'animation aura aussi le désavantage d'être sans doute moins fluide visuellement mais là la notion de design intelligent entre alors en compte, et ça libère pas mal de Banks de RAM.
Par rapport à la Backtro, qui me semble t'il utilise ce genre de technique (je trompe-je ?) là (dans l'exemple avec le wormhole Hexagonal) on part sur des images plus simples calculées/calculables avec des figures géométriques plus simples non ? Genre Glory Holes de bénédiction mais pas avec des ronds...
Donc on devrait pouvoir changer les angles/directions du Wormhole/Vortex car l'image de départ est plus facile à calculée que pour celles de la Backtro quand même.
Pour une version fullscreen, comme je l'ai dit (et comme vous le savez de toute manière probablement) l'écran affichable ferait plus dans les 24K que 32K, donc il reste des pavés de 8K dans certaines banks de RAM permettant peut être de caller du code, mais il faut bankswitcher et addresser comme un porc, et pas certain qu'il soit aisé de partir sur des frames changeantes par calcul de toute manière.
Mais avoir des images calculées, même si ça pompe toujours autant en "VRAM" pour les frames à afficher, au moins ça pompe relativement peu en RAM de Datas/Code stocké...
le problème étant aussi que image à calculer plus grosse = plus de temps pour le CPU pour les faire... et les Banks de 16K du CPC sont vite plus prises/squattées aussi par la vidéo.
Question, 2 images "fullscreen" de 24K (à peu presque) peuvent elles être mises en 3 banks de 16K ?
Quoique même en partant sur un anime en 3 frames et 2 sets, ça fait du euh... ouch... 144k... ça laisse peu de marge aux seulement 128k d'usine d'un 6128 et les espaniols vont râler car ça tourne pas sur un 464...
Après si la vitesse de création d'une nouvelle image est assez rapide, on joue sur le buffering du fait d'avoir 3-4 frames et on calcule le nouveau set sur l'ancien alors qu'on affiche la fin du set... mais alors il ne faut sans doute pas que l'effet aille à fond la caisse.
Désolaid je suis sans doute partis sur pleins de trucs non "faisibles" car j'ignore tout du timing et des ressources CPU de ce genre d'effet. J'ignore complètement si le CPC en chie grave et est en bout de course ou si au contraire il ne chauffe même pas son bankswitcheur ou son Z80.
Mmmh... du cycling de couleur après chaque affichage écran (on est en 50Hz ou en 25Hz ?) même si on change pas mal d'encres ça doit pas être si compliqué vu que ce se fait pour la flashouille... sans doute même plus facile sur PLUS ? De même switcher d'un page RAM à une autre en VRAM c'est techniquement le principe de la flashouille... C'est juste que il y a un algorithme pour les cycles d'encres... niveau code, en Assembleur ça doit pas être bien lourd quand même non plus ?
Le problème c'est donc surtout que calculer ce genre d'écran (dans ce genre Wormhole hexagonal) peut être vite plus chiant qu'il n'y parait, le tout en continuant les routines d'affichages, et que le "Quadribuffering" pompe vite 64K.
Sans compter que si on veut par exemple mettre des couches de "trames" pour avoir des transitions plus smooth entre les couleurs, c'est vite aussi largement plus lourd sans doute pour créer une telle image...
Citer :
Prérequis: 4 écrans générés par RUN"GEN-FX
ah oui en effet c'est pas très rapide quand même... ouch. ça calcule/construit en usant du firmware/Basic ? C'est possible de le faire en vachté plus rapide en assembleur ? C'est codé avec des mouffles ou c'est déjà fait chirurgicalement ? le "Run"gen-fx est il surtout là pour montrer ce qu'il se passe ou c'est exactement ce que l'ordi fait pendant qu'il load la démo/effet ?? En tout cas faire ça en 1 affichage écran risque d'être problématique finalement.
Après altérer les frames existantes pour offrir un "glissement" du Wormhole ne nécessite en théorie pas de faire les gros hexagones complets, bref pas de tartiner une page écran complète, mais il faut encore calculer ça ce qui n'est pas spécialement plus simple alors... en gros des "anneaux hexagonaux" patchés sur les frames précedentes... moins facile à faire faire à l'Amstrad qu'à dire.
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 41 invité(s)
Vous ne pouvez pas publier de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas insérer de pièces jointes dans ce forum