Bon pour une fois je ne vous harcelle pas avec mes mock-up de speccyports foireux en mode1...lol.
Quelques petites questions concernant bien sûr les plus du PLUS.
Sprites Hards : j'arrive à voir en gros le concept. Mais la "magnification" (zoom) bin ça reste trouble pour moi.
Donc en gros 16 sprites hards de 16x16 pixels avec 15 couleures plus 1 couleur de transparence. Que l'on peut magnifier. En zieutant sur les différents documents en la matière, il m'a semblé que l'on peut rêgler cette magnification pour le X et le Y.
Sachant que la taille minimum des pixels serait équivalente à du pixel de mode 2. Soit un pixel de 1/2 sur 1 si on prend le mode 1 comme référence (vu que c'est le type de pixel le plus carré à peu presque).
Magnification : Ensuite on peut magnifier donc en x2 ou x4 me semble t'il pour avoir du pixel de mode 1 et de mode 2.
Et pour la magnification Y comment ça marche ?
magnification X : x2 = mode 1 x4 = mode 0 peut on faire en x3 ?
magnification Y : Bin euh... le pixel faisant la même hauteur quelque soit le mode je ne voit pas trop comment ça marche.
Possède t'on donc en magnification X et Y x4 un pixel d'équivalence mode 1 de 2 pixels sur 4 ? Et si ces derniers se déplacent, se déplacent t'il par paquet (donc par blocs de la taille des pixels magnifiés) ou par pixel de mode habituels ?
Transparence : Ces sprits (lutins) ont accés à une couleur de transparence.
Et quid des choses non Hard ? certaines personnes quand ils décrivent les caractéristiques vidéo du cpc affirment par exemple que le nombre de couleures est supérieur de 1 aux nombres que l'on connait tous.
Certains disent donc (CPCwiki il me semble mais j'avoues ne plus trop savoir quelles sources en fait) que : Mode 0 = 17 couleurs. Mode 1 = 5 couleures... etc... Donc je suppose que soit ils parlent d'une transparence(?), soit ils parlent de la couleur du Border (?!) qui il est vrai reste +1 couleure affichable à l'écran.
Mais si ce n'est pas une transparence, comment fait on pour avoir cette dite transparence alors en soft ? Le plus permet t'il des améliorations en la matière à part sur les sprites Hards ?
Chargement des sprites Hards en mémoire : Bon je suppose que ces sprites Hards peuvent être animés, ce n'est donc pas vraiment une image fixe de 16x16pix que l'on peut placer et déplacer mais plutôt un emplacement de tuile notament.
Ils sont stockés/gérés par l'Asic parraitrait il. Euh...ceux qui sont effectivement affichés ? ou non ? Comment ça se passe en fait ?
Dans le cadre d'un jeux par exemple comment ça s'utilise ? --1 emplacement de sprite peut il représenter plusieures choses en fait (pas en même temps bien sûr) ?
Exemple : genre un Shmup : 1 vaisseaux adverse est en sprite hard. on peut bien sûr le détruire. quand ceci est fait, je suppose qu'il peut réapparaitre par la suite ? voir le slot de sprite peut alors être utilisé par un autre model de vaisseau ?
Bien sûr tout cela oblige sans doute à mettre des tuiles et animations en mémoire quelque part (banque des tuiles probablement) et peut même prendre pas mal de mémoire vu que l'on peut avoir tendance à utiliser des sprites boucoup plus colorés notament. Genre les pixels de type mode1 avec 15 couleures ça prend vite de la mémoire surtout si c'est animé.
Avez vous des exemples d'applications connues de ces sprites Hards ? Notament sur les jeux cartouche... Boucoup d'entre eux n'étant que des reports de la version CPC ça n'est pas parlant, mais quelques hélas trop rares jeux GX4000 étaient clairement des jeux usant bien du PLUS : --Pang. --Robocop 21. --Navy Seal. --Switchblade peut être ? les jeux de tennis aussi je suppose.
Bref dans quelle mesure utilisaient ils les sprites Hards ?
C'est que bien que ça reste du 16x16 pix, dans certains cas de jeux ça peut largement suffire a couvrir une belle surface.
Quand on sais que le Mode 0 peut vraiment bien rendre graphiquement grace aux antialiasings et le nombre respectable de couleures...
Bin on se prend à rêver d'un jeux de baston à la Street fighter 2 avec l'intégralitée des sprites hards utilisés pour les combattants je pense. Un sprites de type "mode0" bin ça fait une surface de 32x16 pix ( de mode1) par sprites (avec le côté blocky bien sûr, mais au moins c'est gros) Et avec les pixels de type Mode0 ça devient vite de grosses bestioles sans doute plus impressionnantes que pour le minable No-Exit.
Et le Zoom/magnification, si on peut effectivement le faire en X ou Y indépendament, ça laisse des possibilitées de gameplay interessantes. Je pense par exemple à un perso genre Dalsim (SF2) qui pouvait allonger ses membres...
Bref merci si vous pouvez me donner quelques indications en la matière.
Tant que j'y suis je vais enchainer sur un autre sujet sur les modes vidéos en fait. Bon en gros le VGA et le CRTC s'occupent de ça sur les bon vieux CPC. CRTC : pour l'affichage. VGA : pour les couleures et la génération des pixels. Il semblerai que c'est l'horloge constante qui empèche de fait une meilleur résolution avec plus de couleures.
Je suppose que bien sûr on ne peut pas vraiment over-clocker les trucs sous peine de griller quelques composants. Et si on veut améliorer il convient aussi alors de passer à plus de 16Ko de mémoire écran ce qui est problématique avec les moins de 64Ko gérables effectivement par le CPC.
Quoique le "overscan" permet bien sur d'afficher plus de surface pour plus de mémoire mais hélas pas de faire du 16 couleures avec des petits pixels. Enfin pas sans abimer potentielement le matos.
C'est pas possible avec un "écran en 32ko" de placer un écran double mode0 dans la surface d'un écran normal en modifiant le balayage du CRTC par exemple ?
Genre c'est le CRTC qui "attend" le VGA ou c'est l'inverse ? Et en utilisant les scanlines entrelacées ou alternées ? arf ça revient à du raster ou la technique de Sylvestre ça, donc ça clignote peut être un poil trop pour les yeux...
Mais pour les Plus bin c'est l'Asic qui remplace le CRTC me semble t'"il (c'est bien ça ?) et le VGA est un autre composant.
L'Asic peut donc faire bien plus de choses et c'est un composant fabriqué exprés par Amstrad me semble t'il...enfin y'avait un truc dans le genre.
Mais en gros esque les plus pourraient être reprogramés pour avoir des modes vidéos un poil mieux que ceux du CPC de base ?
Euh, je sais que là j'ai dit sans doute pas mal de bétises (enfin des approximations plutot) surtout sur la fin avec VGA et CRTC...rassurez vous je vais aller revoir les docs et éditer le post pour virer les plus grosses conneries et je me doute bien que la démoscene à déjà essaillé plein de choses, mais j'aimerai aussi comprendre un poil mieux ces choses.
Overscan et redimensionement de l'écran/fenêtre : Bon comme je l'ai plus ou moins rappelé, on peut aggrandir le classique 160x200/320x200/640x200 non pas en modifiant la taille des pixels mais en en ajoutant plus affichables à l'écran.
La Fameux Overscan qui fit la côté "Awesome" d'Arkanoid, de Titan et de Ghouls and Ghosts...
En gros pour avoir un écran aussi gros que celui de ces jeux pas besoin de doubler vraiment l'affichage car ça ne rentrarais pas vraiment dans l'écran (je n'ai pas les valeures éxactes en tête mais c'est pas grave).
Donc avec 1,5 écrans ça peut déjà faire un truc affichable trés bien semble t'il. C'est vraiment proportionel de la sorte ?
écran normal : 16Ko. écran x1,5 : 24Ko...etc ?
Ensuite il me semble que même un écran normal de 16Ko on peut l'afficher différament, par exemple faire une bande de (presque) toute la largeur de l'écran mais bien sûr plus étroite en hauteur.
Euh une telle technique ne me semble pas avoir été particulièrement utilisée.
Esque re-formuler l'écran ainsi pompe de la ressource ou esque c'est surtout que les programmeurs de l'époques ne maitrisaient pas tous/bien la technique ?
Réseau et CPC : Il me semble que des Expériences en la matières furent plus ou moins tentée.
Comment ça se passe ? Quel genre d'ordinateur faut il pour gérer ce réseaux ? (un Atari ST ? un PC ? ou un simple CPC...) Dans quel mesure ça pourrait être utilisé par des CPC ?
Genre j'avais plus ou moins soumis l'idée d'une manette CPC avec un total de 12 boutons (en fait mettre les 2 joysticks en 1 seul de configuration moderne). Soit 1 pad directionel et 8 boutons ou alors double pad directionel et 4 boutons.
Il serait possible donc d'avoir par exemple un jeux genre midnight resistance/Forgotten World/Ikari Warrior utilisant de tels pads "doubles" afin d'avoir le mode comme sur l'arcade : --1 pad pour se déplacer. --1 pad pour choisir la direction des tirs. --et une chiée (4) de boutons pour tirer et user des options...
ça je suppose que oui... Mais ensuite serait il possible alors d'avoir néanmoins un mode multijoueur sur un tel jeux en passant par un réseaux/connection de plusieurs machines ?
C'est que ce genre de super-manette ne permet alors que difficilement d'avoir 2 joueurs sur une même machine (même avec le clavier c'est galère quand même le double pad directionnel).
Et même pour un jeux plus simple geznre Bomber man. Un mode 6 joueurs grace à un réseau, c'est faisible ? (genre atomic Bomberman sur PC, quesque j'ai pu m'éclater avec mes potes et notre réseau de 3 PC dans le temps, à faire des parties avec 8 joueurs...)
Bref si par exemple on possède une machine plus puissante en "Serveur" esque ça permet de gérer plus de chose ? Genre les CPC ne servent alors que de "borne d'affichage" individuelle et d'interface controle, sons, etc... mais les calcules et gestions du jeux sont plutot gérés par le serveur.
enfin un truc dans le genre quoi...
Et euh...ça serait lourd et lent ou vraiment exploitable ?
Dernière édition par MacDeath26 le 19 Avr 2009, 08:38, édité 1 fois.
Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
Wow ! sacré pavé, je vais essayer de t'apporter des réponses sur ce que je sais :
Magnification : en fait, la magnification tient sur 2bits pour X et 2 bits pour Y donc ça te donne 4 possibilités pour la taille du pixel :
X 00 non affiché 01 pixel mode 2 10 pixel mode 1 11 pixel mode 0
Y 00 non affiché 01 1 pixel vertical (equ mode 1) 10 2 pixels 11 4 pixels
Comme tu vois, pas de *3
La transparence pour le Hard, c'est l'encre 0, pour le soft, c'est comme tu veux en fait, tout dépend comment est écrite ta routine sachant que c'est elle qui fait le blitting.Le Plus ne permet pas d'améliorations sur les sprites Hard par rapport au CPC old sachant que sur CPC old il n'y pas de sprites Hard... Sur CPCwiki ils doivent surement compter le border effectivement.Tout est question de calcul.Sachant que tu as 4 bits en mode pour exprimer ta couleur, ça fait 2^4 = 16, en mode 1 , 2bits, 2^2 = 4 etc.Enfin, ça reste purement théorique car les rasters ça permet beaucoup plus , il y a des spécialistes ici pour t'en dire plus à ce propos.
Le stockage des pixels des sprites Hard , c'est 16 slots de 256octets chacun mappés sur la mémoire. Le problème, c'est que doit y accéder et les remplir, et 256 octets mine de rien ça prends du temps.Après tu peux utiliser des techniques pour rendre ça plus rapide mais pour un sprite seul c'est au moins 2 fois plus gourmand en mémoire mais sur des animations tu peux regagner la mémoire perdue. Le problème est aussi que tes sprites peuvent aussi se manger le balayage pendant la modification donc des effets de cisaillement pas beau et tout et tout... Sinon, un petit gestionnaire de sprites tout simple peu te permettre d'éviter ce genre de problèmes et ça te permet aussi de gérer tes slots. Perso, pour le stockage des sprites avec 128K je songe à utiliser la quatrième bank de ram supplémentaire comme ça je peux la connecter en #C000 et connecter l'ASIC en #4000.Ca me fait 16K pour les sprites, ça devrait être suffisant.
Navy Seal et Pang sont deux bons exemples, tu peux jeter un oeil aux registres dans WinApe, c'est instructif
J'ai bien pensé à de gros sprites Hard mais comme je le dis plus haut, le problème c'est le temps de mise à jour des sprites.Longshot parlait d'un système de flipping en modifiant un sprite non affiché puis en le permutant avec l'ancien mais ça te réduit le nombre de sprites affichables.
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
Merci à toi c'est déjà un bon début de réponses...
Pour la magnification c'est clair que j'avais oublié le "pas affiché" mais je me doutais qu'il y avait 4 modes.
Après les magnifications genre Yx4 ça peut peut être permettre certains effets exploitables au final, je vais voir ça.
Sinon moi qui pensais que ces sprites Hards permettaient une débauches de sprites en Mode 1 avec moult couleures échappant ainsi au mode 0, il me semble que en fait pas vraiment sauf si on ne fait que des petits truc en 16x16 pix... (genre un Bomber man par exemple). Bref la solution est je pense de rester en pseudo mode 0 et même essayer parfois de mettre un peu de sprites pixélisés en 2x2... Ce qui peut bien rendre aussi parfois.
Pour le cisaillement je suppose qu'il faut bien maitriser l'interuption ou un truc dans le genre.
Et pour le truc consistant à garder des sprites en réserve (inusités) afin de rendre les changements plus rapides, euh... il faut la moitié des sprites ou moins ?
Bon, je reprend tout pour te répondre... (t'as pas moyen de poser tes questions unes par unes plutôt que de nous faire des posts énormes ???
MacDeath26 a écrit :
Salut.
Bon pour une fois je ne vous harcelle pas avec mes mock-up de speccyports foireux en mode1...lol.
C'est toi qui l'a dit... Mais puisque tu le dis, oui éffectivement...
MacDeath26 a écrit :
Quelques petites questions concernant bien sûr les plus du PLUS.
Sprites Hards : j'arrive à voir en gros le concept. Mais la "magnification" (zoom) bin ça reste trouble pour moi.
Donc en gros 16 sprites hards de 16x16 pixels avec 15 couleures plus 1 couleur de transparence. Que l'on peut magnifier. En zieutant sur les différents documents en la matière, il m'a semblé que l'on peut rêgler cette magnification pour le X et le Y.
Sachant que la taille minimum des pixels serait équivalente à du pixel de mode 2. Soit un pixel de 1/2 sur 1 si on prend le mode 1 comme référence (vu que c'est le type de pixel le plus carré à peu presque).
Magnification : Ensuite on peut magnifier donc en x2 ou x4 me semble t'il pour avoir du pixel de mode 1 et de mode 2.
Et pour la magnification Y comment ça marche ?
magnification X : x2 = mode 1 x4 = mode 0 peut on faire en x3 ?
magnification Y : Bin euh... le pixel faisant la même hauteur quelque soit le mode je ne voit pas trop comment ça marche.
Possède t'on donc en magnification X et Y x4 un pixel d'équivalence mode 1 de 2 pixels sur 4 ? Et si ces derniers se déplacent, se déplacent t'il par paquet (donc par blocs de la taille des pixels magnifiés) ou par pixel de mode habituels ?
Pour le Zoom. l'encodage ce fait dans un quartet de poids faible. Je te donne une représentation à l'octet de celui-ci:
Bits: 0000XXYY
Tu as donc 4 possibilités pour chaque zoom. La valeur 0 rendant le sprite invisible (ce n'est pas pour cela qu'il n'est pas pour autant géré).
Des zooms avec un Y changeant ont été utilisés dans divers jeux (Robocop 2). Sinon de grosses résolutions dans Navy Seals (helico et bagnole)
MacDeath26 a écrit :
Transparence : Ces sprits (lutins) ont accés à une couleur de transparence.
Et quid des choses non Hard ? certaines personnes quand ils décrivent les caractéristiques vidéo du cpc affirment par exemple que le nombre de couleures est supérieur de 1 aux nombres que l'on connait tous.
Certains disent donc (CPCwiki il me semble mais j'avoues ne plus trop savoir quelles sources en fait) que : Mode 0 = 17 couleurs. Mode 1 = 5 couleures... etc... Donc je suppose que soit ils parlent d'une transparence(?), soit ils parlent de la couleur du Border (?!) qui il est vrai reste +1 couleure affichable à l'écran.
Mais si ce n'est pas une transparence, comment fait on pour avoir cette dite transparence alors en soft ? Le plus permet t'il des améliorations en la matière à part sur les sprites Hards ?
Si tu te poses ce genre de questions c'est que tu as encore beaucoup de choses a apprendre avant de commencer quoi que ce soit... Il serait trop long de t'expliquer tout cela d'un seul coup... Cible tes questions, nous y répondrons plus vite que si tu nous colles une tartine ou on survole le tout.
MacDeath26 a écrit :
Chargement des sprites Hards en mémoire : Bon je suppose que ces sprites Hards peuvent être animés, ce n'est donc pas vraiment une image fixe de 16x16pix que l'on peut placer et déplacer mais plutôt un emplacement de tuile notament.
Justement non, les sprites du CPC+ ne sont pas indéxés... Leur adresse et fixe et hormis changer leur contenu en remplassant les données déjà présentes, tu ne pourras pas changer l'adresses de leur données (enfin disons que pas vraiment)
MacDeath26 a écrit :
Ils sont stockés/gérés par l'Asic parraitrait il. Euh...ceux qui sont effectivement affichés ? ou non ? Comment ça se passe en fait ?
Affichés ou pas... Rien ne t'oblige a les mettre a l'écran (je parle bien d'ecran, pas de moniteur)
MacDeath26 a écrit :
Dans le cadre d'un jeux par exemple comment ça s'utilise ? --1 emplacement de sprite peut il représenter plusieurs choses en fait (pas en même temps bien sûr) ?
Exemple : genre un Shmup : 1 vaisseaux adverse est en sprite hard. on peut bien sûr le détruire. quand ceci est fait, je suppose qu'il peut réapparaitre par la suite ? voir le slot de sprite peut alors être utilisé par un autre model de vaisseau ?
Bien sûr tout cela oblige sans doute à mettre des tuiles et animations en mémoire quelque part (banque des tuiles probablement) et peut même prendre pas mal de mémoire vu que l'on peut avoir tendance à utiliser des sprites boucoup plus colorés notament. Genre les pixels de type mode1 avec 15 couleures ça prend vite de la mémoire surtout si c'est animé.
Ca pour prendre de la place ca en prend !!! 1 pixel=1octet. Pour le stockage tu as tout interet a reunir les quartets sinon tu vas te tapper 4Ko de données pour 16 sprites (contre 2Ko si tu réunis les quartets). Que ton sprite soit en n'importe quelle résolution il occupera dans tous les cas la même place en mémoire. Autant faire du mode 2 en 15 couleurs si tu n'as pas besoin de 50000 sprites...
MacDeath26 a écrit :
Avez vous des exemples d'applications connues de ces sprites Hards ? Notament sur les jeux cartouche... Beaucoup d'entre eux n'étant que des reports de la version CPC ça n'est pas parlant, mais quelques hélas trop rares jeux GX4000 étaient clairement des jeux usant bien du PLUS : --Pang. --Robocop 21. --Navy Seal. --Switchblade peut être ? les jeux de tennis aussi je suppose.
Bref dans quelle mesure utilisaient ils les sprites Hards ?
C'est que bien que ça reste du 16x16 pix, dans certains cas de jeux ça peut largement suffire a couvrir une belle surface.
Niveau jeux, les sprites sont souvent mal utilisés pour faire des choses qui n'auraient pas forcement été plus difficile a faire en soft. Utiliser les sprites hard juste parce qu'on ne sait pas faire un sprite masqué en soft c'est de la grosse connerie et la honte totale... Après l'interet est le plus souvent de gagner du temps machine. L'exemple le plus convainquant d'utiliser des sprites hard de façon originale et intelligente est visible dans la preview de "delirium tremens" que j'ai sorti il y a un moment (ne marche pas sur emulateur). Tu verras que l'on peux remplir un ecran avec des sprites hard même en résolution mode 1... Ce n'est pas très utilisable dans un jeu (voir pas du tout) mais au moins ca te montre ce qu'on peux faire.
MacDeath26 a écrit :
Quand on sais que le Mode 0 peut vraiment bien rendre graphiquement grace aux antialiasings et le nombre respectable de couleures...
Bin on se prend à rêver d'un jeux de baston à la Street fighter 2 avec l'intégralitée des sprites hards utilisés pour les combattants je pense. Un sprites de type "mode0" bin ça fait une surface de 32x16 pix ( de mode1) par sprites (avec le côté blocky bien sûr, mais au moins c'est gros) Et avec les pixels de type Mode0 ça devient vite de grosses bestioles sans doute plus impressionnantes que pour le minable No-Exit.
C'est drole comme tu rêves... Autant t'enlever tes illusions tout de suite, si tu comptes faire un SF2 avec les sprites hard c'est peine perdue d'avance. Essaye déjà d'animer un seul perso histoire de te rendre compte que bas ... T'as plus de Tps machine. Petit rappel pour les fans du genre: Une bonne conversion serait un jeu rapide et jouable. Tout l'inverse de ce qui a été fait jusqu'a présent. Non franchement lances toi plutôt dans du shoot (regarde le jeu Burger Party, jeu diffusé a l'état de preview mais jamais terminé, cela te donnera une idée).
MacDeath26 a écrit :
Et le Zoom/magnification, si on peut effectivement le faire en X ou Y indépendament, ça laisse des possibilitées de gameplay interessantes. Je pense par exemple à un perso genre Dalsim (SF2) qui pouvait allonger ses membres...
Bref merci si vous pouvez me donner quelques indications en la matière.
Bein de rien
MacDeath26 a écrit :
Tant que j'y suis je vais enchainer sur un autre sujet sur les modes vidéos en fait. Bon en gros le VGA et le CRTC s'occupent de ça sur les bon vieux CPC. CRTC : pour l'affichage. VGA : pour les couleures et la génération des pixels. Il semblerai que c'est l'horloge constante qui empèche de fait une meilleur résolution avec plus de couleures.
Je suppose que bien sûr on ne peut pas vraiment over-clocker les trucs sous peine de griller quelques composants. Et si on veut améliorer il convient aussi alors de passer à plus de 16Ko de mémoire écran ce qui est problématique avec les moins de 64Ko gérables effectivement par le CPC.
Quoique le "overscan" permet bien sur d'afficher plus de surface pour plus de mémoire mais hélas pas de faire du 16 couleures avec des petits pixels. Enfin pas sans abimer potentielement le matos.
C'est pas possible avec un "écran en 32ko" de placer un écran double mode0 dans la surface d'un écran normal en modifiant le balayage du CRTC par exemple ?
Genre c'est le CRTC qui "attend" le VGA ou c'est l'inverse ? Et en utilisant les scanlines entrelacées ou alternées ? arf ça revient à du raster ou la technique de Sylvestre ça, donc ça clignote peut être un poil trop pour les yeux...
Entrelacé alterné tout ce que tu veux, ca ne sera jamais a 50Hz ca sera moche comme ce que fait l'autre.
MacDeath26 a écrit :
Mais pour les Plus bin c'est l'Asic qui remplace le CRTC me semble t'"il (c'est bien ça ?) et le VGA est un autre composant.
L'Asic peut donc faire bien plus de choses et c'est un composant fabriqué exprés par Amstrad me semble t'il...enfin y'avait un truc dans le genre.
Mais en gros esque les plus pourraient être reprogramés pour avoir des modes vidéos un poil mieux que ceux du CPC de base ?
Rien de plus niveau ASIC pour les résolutions et autres considère les plus du plus comme étants: une palettes de 4096 couleurs; des sprites hard; un DMA son; Des interruptions programmables; De la rupture+; un retard vidéo hard et... Bein c'est tout !!!
MacDeath26 a écrit :
Euh, je sais que là j'ai dit sans doute pas mal de bétises (enfin des approximations plutot) surtout sur la fin avec VGA et CRTC...rassurez vous je vais aller revoir les docs et éditer le post pour virer les plus grosses conneries et je me doute bien que la démoscene à déjà essaillé plein de choses, mais j'aimerai aussi comprendre un poil mieux ces choses.
Overscan et redimensionement de l'écran/fenêtre : Bon comme je l'ai plus ou moins rappelé, on peut aggrandir le classique 160x200/320x200/640x200 non pas en modifiant la taille des pixels mais en en ajoutant plus affichables à l'écran.
La Fameux Overscan qui fit la côté "Awesome" d'Arkanoid, de Titan et de Ghouls and Ghosts...
En gros pour avoir un écran aussi gros que celui de ces jeux pas besoin de doubler vraiment l'affichage car ça ne rentrarais pas vraiment dans l'écran (je n'ai pas les valeures éxactes en tête mais c'est pas grave).
Donc avec 1,5 écrans ça peut déjà faire un truc affichable trés bien semble t'il. C'est vraiment proportionel de la sorte ?
écran normal : 16Ko. écran x1,5 : 24Ko...etc ?
Ensuite il me semble que même un écran normal de 16Ko on peut l'afficher différament, par exemple faire une bande de (presque) toute la largeur de l'écran mais bien sûr plus étroite en hauteur.
Euh une telle technique ne me semble pas avoir été particulièrement utilisée.
Esque re-formuler l'écran ainsi pompe de la ressource ou esque c'est surtout que les programmeurs de l'époques ne maitrisaient pas tous/bien la technique ?
Ca ne prend aucune ressources. Ce n'est pas une question de maitrise mais une question de vouloir. Les ecrans sont plus souvent reformatés que tu ne le crois, sauf que c'est plus souvent plus petit que "l'origine".
MacDeath26 a écrit :
Réseau et CPC : Il me semble que des Expériences en la matières furent plus ou moins tentée.
Comment ça se passe ? Quel genre d'ordinateur faut il pour gérer ce réseaux ? (un Atari ST ? un PC ? ou un simple CPC...) Dans quel mesure ça pourrait être utilisé par des CPC ?
Voir le reseau virtual net. Ca ne fonctionne qu'avec des CPCs. Ajouter une autre machine c'est de la dépendance, donc poubelle.
MacDeath26 a écrit :
Genre j'avais plus ou moins soumis l'idée d'une manette CPC avec un total de 12 boutons (en fait mettre les 2 joysticks en 1 seul de configuration moderne). Soit 1 pad directionel et 8 boutons ou alors double pad directionel et 4 boutons.
Il serait possible donc d'avoir par exemple un jeux genre midnight resistance/Forgotten World/Ikari Warrior utilisant de tels pads "doubles" afin d'avoir le mode comme sur l'arcade : --1 pad pour se déplacer. --1 pad pour choisir la direction des tirs. --et une chiée (4) de boutons pour tirer et user des options...
ça je suppose que oui... Mais ensuite serait il possible alors d'avoir néanmoins un mode multijoueur sur un tel jeux en passant par un réseaux/connection de plusieurs machines ?
C'est que ce genre de super-manette ne permet alors que difficilement d'avoir 2 joueurs sur une même machine (même avec le clavier c'est galère quand même le double pad directionnel).
Une telle manette ce serait tomber sur des interférences clavier; un gros bordel qui au final ne fonctionnerait pas. Essayes de brancher plusieurs manettes, et utilises les 2 fire en faisant des mouvements... tu comprendras pourquoi dans certains jeux, le joueur 2 utilises le fire 2 et non pas le 1...
MacDeath26 a écrit :
Et même pour un jeux plus simple geznre Bomber man. Un mode 6 joueurs grace à un réseau, c'est faisible ? (genre atomic Bomberman sur PC, quesque j'ai pu m'éclater avec mes potes et notre réseau de 3 PC dans le temps, à faire des parties avec 8 joueurs...)
Completement faisable et serait interessant. La encore interesses toi au reseau virtual net.
MacDeath26 a écrit :
Bref si par exemple on possède une machine plus puissante en "Serveur" esque ça permet de gérer plus de chose ? Genre les CPC ne servent alors que de "borne d'affichage" individuelle et d'interface controle, sons, etc... mais les calcules et gestions du jeux sont plutot gérés par le serveur.
enfin un truc dans le genre quoi...
Et euh...ça serait lourd et lent ou vraiment exploitable ?
Ca serait stupide, tu dépendrais d'un autre machine merdique qui plante tout le temps (le contraire d'un CPC quoi), donc tu dépendrais; que de nombreuses personne refuseraient d'utiliser (avec raison). De plus communiquer avec les autres machines serait une vraie galère a tous les coups. Idée a oublier.
Merci BDCIron, bien que je te trouve un peu intransigeant avec le noob en coding que je suis...
bon je vais voir déjà pour le réseaux virtuel.
Après pour la manette avec 12 boutons, disont que la seconde manette bin c'est surtout le pad directionnel qui servirai vraiment en fait. Pour le reste 2 boutons de tirs suffisent largement.
Pour le conflit entre les 2 manettes, j'ai effectivement le souvenir qu'avec le doubleur de manette (quand j'était mino) bin il arrivait qu'on s'engueule avec mon frêre passque "arrète de bouger tu me contrôle en même temps" lors de parties de je ne sais plus quel jeux.
En tout cas je me souviens que Rampage en mode 3 joueurs bin les conflits de la sorte arrivaient bien souvent (pourtant on jouaient avec 2 claviers et 1 joy...)
Et franchement je ne me souvient pas de boucoup de jeux qui prenaient en compte le deuxième bouton...ce qui était assez chiant avec une speed king par exemple.
Et promis dès que mon CPC est à nouveau en service, je lance ta démo délirium trémens...
Citer :
C'est toi qui l'a dit... Mais puisque tu le dis, oui éffectivement...
Whaaaa...il rend bien le level 2 de R-type retouché...
Inscription : 28 Août 2008, 23:41 Message(s) : 261
Tu peux bien sûr télécharger le B-Asic. (http://logon.system.free.fr) C'est je pense une bonne boite à outils pour manipuler les capacités du Plus. Ainsi, tu auras des réponses plus directes à tes questions sur les zoom et déplacements de sprite.
Bon, tant que j'ai de bons codeurs sous la main (vous donc...) j'aurais une autre question.
Oui elle est peut être nioube donc je m'en excuse à l'avance.
--Je sais qu'il est possible de passer du standard écran en 16Ko à 32Ko, le fumeux "overscan" (terme faux mais accepté). Bien que oui il n'est pas nécessaire d'aller jusqu'à 32Ko pour couvrir tout l'écran en fait. Mais que donc on peux faire gérer en théorie 2 écrans simultanés malgré le fait que ça pompe pas mal de ressource (mais Arkanoid le fait bien malgré des ralentissements...enfin euh...)
--Je sais aussi qu'il est possible de faire du "Raster" voir du split screen raster (ou un truc dans le genre...). histoire de dire telle partie de l'écran c'est tel mode graphic avec telles couleurs et telle autre partie tel mode et telles couleurs (encres)...
les créateurs de démos ont d'ailleur bien poussé le concept parrait il. Mais finalement même les miteux Speccy ports arrivent à placer des Rasters...histoire de cacher la misère.
--Je sais aussi qu'il est possible plus ou moins en soft de faire de la couleure transparante. Enfin un truc qui fait comme.
Bin voilà je me pose cette question : Est il possible de superposer 2 écrans différents ?
Genre : -1 fond en mode par exemple 1. -1 dessus en mode 0 mais avec de la transparence à gogo.
Cette technique serait exploitable (si bien sûr c'est possible) par exemple pour un jeux genre Space crusade/Heroquest (genre un jeux d'escarmouche en tour par tour de figurines donc).
L'idée est que ça permettrait de placer des créatures en mode 0 (donc en couleur) sur un "plateau" en 4 couleurs (mode 1). Et les espaces entres les "sprites" des créatures serait de la transparence.
Un peu comme le système des calcque pour les utilitaires Graphix de maintenant (Paint.net ou The Gimp...).
Donc logiquement ça obligerai peut être a alterner (à la sauce sylvestre ?) les écran 1 coup sur 2... et donc pourrait clignoter. ensuite vu que la zone avec les sprites de "figurines" ne serait pas partout sur l'écran...bin a voire donc mais ça ne devrais pas faire non plus 32Ko.
Ensuite puisqu'il s'agirait alors d'un jeux "tour par tour" on n'a pas vraiment à animer cela non plus (enfin pas trop quoi...). Pas de scrollings et actions de sprites super animés donc...
Bref estceque c'est possible ou alors il vaut mieux faire du raster pour chaque figurine ???
Après je suis conscient qu'un tel jeux si on y applique un système de Wargame d'escarmouche à la "Dungeon and Hammer Quest" (lol) bin ça devient vite lourd aussi... Mais vu que le "CPC Plus" peut aussi en théorie avoir les sons en DMA (facilitant le boulot du Z80) et aussi de la ROM (cartouches)...et 128Ko virtuels (voire des Extensions parrait il...).
Enfin n'anticipons pas.
Esque ça peut se faire ou faut il trouver un système plus lourd ? ou différent comme approche ?
Ou simplement se contenter de faire en Mode 0... simplement...après y'a moins de challenge lol... (bon je sais c'est le plus simple donc clairement la réponse, mais que ça ne vous empèche pas de répondre...)
Merci de ne pas m'incendier pour la connerie potentielle due à mon ignorance.
Tiens d'ailleurs... (Bon désolaid pour la tartine de texte...). Concernant sinon le "split-raster"... En général les jeux font en 1 split raster (genre antiriad avec du mode 0 pour le jeux et du mode 1 en bas pour la "jauge de l'armure") mais esque faire 3 zones différentes voire 4 c'est super lourd sinon ? Sachant que l'on reste aussi dans un jeux tour par tour donc pas si nécessairement fluide et actif en animations que ça...
Et sachant alors que l'on mélangerai des splits horizontaux ET verticaux (couper l'écran en 4 quoi...).
Merci d'avance pour vos réponses.
Enfin je change de sujet mais j'ai réçament essayé Copter 271 sur émulateur. bin c'est clairement la cata. ça ralenti autant sur machine originale ? Genre mêm la musique semble s'arrèter... ils n'auraient peut être pas du tenter de mettre du scrolling horizontal, ça alourdi le jeux et n'apporte pas grand chose... Et faire des sprites peut être plus petits, lol... Passons, fin de la parenthèse.
--Je sais qu'il est possible de passer du standard écran en 16Ko à 32Ko, le fumeux "overscan" (terme faux mais accepté).
Justement personnellement je n'accepte pas ce terme. Au passage passer en fullmonitor (la c'est plus réaliste) n'oblige pas a avoir 32 Ko d'ecran. Tu peux tout a fait garder 16Ko... Ce sera juste répété.
MacDeath26 a écrit :
Bien que oui il n'est pas nécessaire d'aller jusqu'à 32Ko pour couvrir tout l'écran en fait. Mais que donc on peux faire gérer en théorie 2 écrans simultanés malgré le fait que ça pompe pas mal de ressource (mais Arkanoid le fait bien malgré des ralentissements...enfin euh...)
Arkanoïd a juste un ecran agrandi verticallement... Et racourci horizontallement. Je n'ai pas regardé mais ca doit tenir dans 16 Ko tout simplement.
MacDeath26 a écrit :
--Je sais aussi qu'il est possible de faire du "Raster" voir du split screen raster (ou un truc dans le genre...). histoire de dire telle partie de l'écran c'est tel mode graphic avec telles couleurs et telle autre partie tel mode et telles couleurs (encres)...
Tu confonds tout... Un Raster est un changement de couleur durant le balayage. On appel Raster, un raster qui fait la largeur du moniteur. Un split raster signifit simplement qu'une couleur est changée plusieurs fois sur une même ligne. Changer le mode en court de balayage ce nomme du "multi mode". Celui ci peut être fait a chaque ligne sans soucis. En revanche le faire plusieurs fois par ligne impose de passer par la rupture verticale... Et la tu dis au revoir a ton jeu.
MacDeath26 a écrit :
Les créateurs de démos ont d'ailleur bien poussé le concept parrait il. Mais finalement même les miteux Speccy ports arrivent à placer des Rasters...histoire de cacher la misère.
Le but de faire des rasters n'est pas de cacher la misère mais de rajouter des couleurs... que nommes tu "Speecy ports" ???
MacDeath26 a écrit :
--Je sais aussi qu'il est possible plus ou moins en soft de faire de la couleure transparante. Enfin un truc qui fait comme.
Bin voilà je me pose cette question : Est il possible de superposer 2 écrans différents ?
Genre : -1 fond en mode par exemple 1. -1 dessus en mode 0 mais avec de la transparence à gogo.
NON. Les modes ne ce mélangent pas. La seule possibilité est sur cpc+ d'utiliser les sprites hards, que tu pourras alors mettre dans la résolution que tu souhaites.
MacDeath26 a écrit :
Mais vu que le "CPC Plus" peut aussi en théorie avoir les sons en DMA (facilitant le boulot du Z80) et aussi de la ROM (cartouches)...et 128Ko virtuels (voire des Extensions parrait il...).
La ROM de la cartouche n'est pas de la ROM supplémentaire... 128Ko de virtuels ????? Arretes de fumer.
MacDeath26 a écrit :
Merci de ne pas m'incendier pour la connerie potentielle due à mon ignorance.
Tu as bien fait de supplier, j'avais comme une envie de te trouver des noms d'oiseaux.
MacDeath26 a écrit :
Concernant sinon le "split-raster"... En général les jeux font en 1 split raster (genre antiriad avec du mode 0 pour le jeux et du mode 1 en bas pour la "jauge de l'armure") mais esque faire 3 zones différentes voire 4 c'est super lourd sinon ? Sachant que l'on reste aussi dans un jeux tour par tour donc pas si nécessairement fluide et actif en animations que ça...
Ce ne sont pas des splits rasters mais du MULTIMODE !!! Tu peux changer a chaque ligne de mode si tu le désires. En revanche comme dit plus haut, changer plusieurs fois sur une même ligne est bien plus lourd à gérer; tu n'aurait plus de CPU; de la HBL au milieu de l'écran et a gerer ce serait une catastrophe.
MacDeath26 a écrit :
Et sachant alors que l'on mélangerai des splits horizontaux ET verticaux (couper l'écran en 4 quoi...).
Voir réponse précédente.
MacDeath26 a écrit :
Merci d'avance pour vos réponses.
De rien...
MacDeath26 a écrit :
Enfin je change de sujet mais j'ai réçament essayé Copter 271 sur émulateur. bin c'est clairement la cata. ça ralenti autant sur machine originale ? Genre mêm la musique semble s'arrèter... ils n'auraient peut être pas du tenter de mettre du scrolling horizontal, ça alourdi le jeux et n'apporte pas grand chose... Et faire des sprites peut être plus petits, lol... Passons, fin de la parenthèse.
Comment te dire si cela ralentis plus sur la VRAI machine que sur emul puisqu'un emul n'émule pas correctement la machine...
Mais cela dit il y a effectivement des ralentissements dans ce jeu. Ceci n'est pas du au scrolling vertical mais bien aux routines d'affichage trop lentes et a un surplus de sprites trop gros qui arrivent tous en même temps (évenementiel mal gérée).
Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
BDCIron a écrit :
Comment te dire si cela ralentis plus sur la VRAI machine que sur emul puisqu'un emul n'émule pas correctement la machine...
Je m'incruste dans la conversation et je prends ton propos au vol car c'est un sujet qui m'intéresse au plus au point histoire de pas avoir un code qui se comporte de manière innatendue le jour où je veux le lancer sur un + Tu as constaté quelles différences entre le + et l'émulation sous WinApe (à part le timing de changement de couleurs) ?
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
Je vais être global: rien ne fonctionne correctement sous winape.
Les interruptions n'ont pas lieu au bon moment. Les rupture+ ne sont pas prises en compte au bon moment. Le CRTC ne réagit pas normallement (timing mauvais). etc... Si tu veux que cela fonctionne sur un vrai plus, code sur un vrai plus ou contentes toi de faire des choses très simples.
Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
Tu me fait peur là C'est vrai que j'avais vu que Délirium Trémens ne fonctionnait pas correctement sous Winape (en fait c'est Winape qui ne fonctionne pas correctement avec DéliriumTrémens). J'utilise les interruptions et le split programmables, c'est trop le pied et je me vois pas m'en passer dans mon projet.De quel ordre sont les différences de timing, c'est prédictible ? Malheureusement, je n'ai toujours pas de + en silicium et plastique... ...mais ça viendra
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
Ok merci pour ne pas avoir donné de noms d'oiseaux.
"speecy port" : portage de spectrum. Speccy étant le nom affectueux du ZX spectrum de sinclair. (se prononce "Spéky") ce sont des jeux avant tout conçu pour le Spectrum puis "adaptés" à l'arrache et économiquement sur amstrad car le Z80 commun aux deux permet de le faire rapidement. Problème : l'amstrad ne gère pas les couleures comme un spectrum donc ces jeux sont alors en "2 couleurs". Mais pour cacher la misère, bin ils changent les couleurs pour les barres de vie et autres scores. Sinon en général c'est le Mode 1 qui est utilisé sur amstrad, mais la fenètre de jeux est réduite de 320x200 (CPC) a 256x192 (ZX). Après il arrive bien souvent que les graphismes soit fins et bien fait...mais pas colorés convenablement. exemples typique : Black Tiger, R-Type, Hate, Pacmania... Ces jeux étaient en fait souvent moins colorés que sur ZX et moins fluides aussi sur amstrad.
Après certains de ces jeux arrivaient tout de même à être bien en fait. Voir mes "mock-up" de tels jeux recolorés en mode CPC (R-Type, Black Tiger.) Et quand je disais "cacher la misère..."bin euh c'est justement ajouter faussement des couleurs à l'écran, sauf que le jeux en lui même (la zone avec l'action) et finalement en 2 couleurs (Black Tiger typiquement affiche 7 couleures à l'acran mais le jeux n'en a que 2...c'est donc un cache misère. Disons que ça permettait de prendre un graphiste pour simplement des trucs fins pour les 2 machines, alors que utiliser du Mode0 nécessitait un autre graphiste (ou du temps de graphiste) car le Mode0 est typiquement particulier quand même. Donc c'était quand même travaillé mais monochrome donc.
Bon donc je résume :
--Ce que l'on appel de manière érronée "Overscan" est donc en fait du "FullScreen" ou "full monitor". Okay. Ensuite tu me dit que ça peut ne prendre que 16ko ? Il sagit donc alors de simplement redimensionner l'écran en gardant la même surface mais répârtie différament. C'est donc assez utilisé par exemple pour des fullscreen horizontaux ou verticaux car le border n'est pas si large que ça à la base donc y'a pas toujours beaucoup de rognure a faire dans l'autre sens. Star sabre me semble t'il le fait trés bien. Préhistorik 2 aussi. (en horizontal) Après je ne me souvenais pas que Arkanoid était rogné sur les cotés...mais bon il est vrai aussi que peu de jeux exploitaient l'intégralité de l'écran 320x200 (mode 1) et faisaient plus facilement dans l'écran réduit (bien souvent en 256x192 de ZX spectrum d'ailleurs.) voire encore moins : les jeux dynamic par exemple avaient de beaux Graphx en Mode0 mais des écrans de jeux minuscules....
--les "rasters" ne changent pas de mode graphiques mais changent les encres disponibles en cour de ligne..
--le multimode ne permet pas vraiment de faire 2 zones de mode différents en vertical, ni d'entrelacer les zones ou alors avec les limitations drastiques dess sprites Hard du "CPC+".
--La Rom des cartouches est plus une super disquète à chargement semi-instantanée que de la "Ram non modifiable".
--128Ko virtuels..bon d'accord c'est éxagéré. Donc pour un 6128 : Donc en fait 64ko de lecteur virtuel et 48Ko de ram véritable, et 16Ko utilisé de fait par l'affichage...
Sinon : --le multimode (horizontal) c'est possible de multiplier les zones ? Genre 1 zone Mode 1 en haut, une zone Mode 0 en milieux et 1 autre zone Mode 1 en bas à nouveaux. C'est lourd ou pas ?
--Changer les encres assez souvent genre chaque figurine du jeux (genre heroquest donc) changeant de sets d'encre. Chiant ? lent ? dure a bien paramétrer ?
--Sinon avoir des écrans rapetissés, c'était passque les Graphistes étaient payés au caractère de 8x8 ou passque ça allégeait l'effort du CPU ? Bon plus simplement aussi passque ça permettait de garder le codage du spectrum bien souvent.
En fait le Spectrum aura tué la qualité des Jeux Amstrad en tirant ses performances graphique vers le bas. Reste à voir aussi si les codages 100% Amstrad auraient pu être plus fluides ou rapides....
--La Rom des cartouches est plus une super disquète à chargement semi-instantanée que de la "Ram non modifiable".
Pas forcement, tu peux très bien faire tourner reellement un programme dans la cartouche sans avoir a le decompresser en RAM.
MacDeath26 a écrit :
--128Ko virtuels..bon d'accord c'est éxagéré. Donc pour un 6128 : Donc en fait 64ko de lecteur virtuel et 48Ko de ram véritable, et 16Ko utilisé de fait par l'affichage...
Non... Un 6128 c'est 128Ko de RAM. Point barre. Pour l'affichage c'est 16Ko mini mais tu peux tout re-parametrer. Et rien ne t'obliges a utiliser 16 Ko tu as le droit de redéfinir via CRTC la taille de l'ecran.
MacDeath26 a écrit :
Sinon : --le multimode (horizontal) c'est possible de multiplier les zones ? Genre 1 zone Mode 1 en haut, une zone Mode 0 en milieux et 1 autre zone Mode 1 en bas à nouveaux. C'est lourd ou pas ?
tout a fait possible, cela oblige juste à ce synchroniser et a avoir une routine a 50Hz pour gerer cela (sous interruptions par exemple).
MacDeath26 a écrit :
--Changer les encres assez souvent genre chaque figurine du jeux (genre heroquest donc) changeant de sets d'encre. Chiant ? lent ? dure a bien paramétrer ?
Attention, sur un CPC old, changer une couleur prend mini a l'ecran 2cm... Donc si tu veux changer toutes les encres, tu multiplies d'autant...
MacDeath26 a écrit :
--Sinon avoir des écrans rapetissés, c'était passque les Graphistes étaient payés au caractère de 8x8 ou passque ça allégeait l'effort du CPU ? Bon plus simplement aussi passque ça permettait de garder le codage du spectrum bien souvent.
Pas forcement. raccourcir la largeur d'ecran permet des otpimisations d'affichage. Par exemple ne pas avoir d'incrementation du poids fort d'une adresse a l'écran en court de ligne. Cela permet de faire des INC L au lier de INC HL, soit une économie de temps.
Ensuite erreur que tu semble commettre dans tes autres posts (ou tu nous montres tes gfxs). Changer de mode ne te fais pas gagner de place en mémoire... Pour la même taille d'écran tu as la même quantité de données.
MacDeath26 a écrit :
En fait le Spectrum aura tué la qualité des Jeux Amstrad en tirant ses performances graphique vers le bas. Reste à voir aussi si les codages 100% Amstrad auraient pu être plus fluides ou rapides....
Le spectrum a permis a beaucoup de jeux de sortir alors que ceux ci n'auraient peut être tout simplement jamais été fait.
Que veux tu dires par les "codages 100% amstrad" ???
Tu me fait peur là C'est vrai que j'avais vu que Délirium Trémens ne fonctionnait pas correctement sous Winape (en fait c'est Winape qui ne fonctionne pas correctement avec DéliriumTrémens). J'utilise les interruptions et le split programmables, c'est trop le pied et je me vois pas m'en passer dans mon projet.De quel ordre sont les différences de timing, c'est prédictible ? Malheureusement, je n'ai toujours pas de + en silicium et plastique... ...mais ça viendra
Délirium tremens ne fonctionne pas du tout sur emulateur et ce pour plusieurs raisons: L'offset de la rupture plus sous winape est foireux: pris en compte a la louche. Hors je l'adresse a chaque ligne... Le CRTC est foireux (par ailleur je crois me souvenir que dans la version diffusée de delirium la rupture est merdique... Mais reste que cela fonctionne sur un vrai cpc+)
Pour ce qui est des interruptions ou de la rupture+, temps que tu ne sera pas callé a raz du cul dessus tu ne devrais pas avoir trop de probleme.
Pas forcement, tu peux très bien faire tourner reellement un programme dans la cartouche sans avoir a le decompresser en RAM.
Ok donc on peut en théorie stocker les datas (tuiles par exemple) sur une cartouche ROM et ainsi soulager la RAM ?
Citer :
Non... Un 6128 c'est 128Ko de RAM. Point barre. Pour l'affichage c'est 16Ko mini mais tu peux tout re-parametrer. Et rien ne t'obliges a utiliser 16 Ko tu as le droit de redéfinir via CRTC la taille de l'ecran.
Ok, mais le Z80 n'est il pas limité à 64Ko ? Ou c'est seulement en Basic et l'Assembleur permet mieux ?
Citer :
Attention, sur un CPC old, changer une couleur prend mini a l'ecran 2cm... Donc si tu veux changer toutes les encres, tu multiplies d'autant...
2 cm ? euh tu parles d'une distance là ou autre chose ?
Citer :
Ensuite erreur que tu semble commettre dans tes autres posts (ou tu nous montres tes gfxs). Changer de mode ne te fais pas gagner de place en mémoire... Pour la même taille d'écran tu as la même quantité de données.
Oui ça je le sais en fait. Après avoir a gérer 2x plus de tuiles ça ne peut pas alourdir parfois ? Je sais pas, genre pour les scrollings ou animation par exemple. Enfin c'est clair aussi que les tuiles Mode 1 (8x8pix) font aussi 2x moins de poid en mémoire que 1 grosse tuile Mode 0 (8x8 aussi mais 16 couleures et pix plus larges).
Citer :
Que veux tu dires par les "codages 100% amstrad" ???
J'avoue ne pas trop connaitre les différences réelles entre le ZX et le CPC. Niveau vidéo je connais le concept du color clash du ZX... Mais après y'a peu être malgré le même CPU (z80) des choses qui permettent des techniques plus efficaces. Enfin passons.
Merci BDCIron pour ta patience. Je me doute que je dois te faire criser parfois.
Bon donc esque c'est réaliste de penser à un jeux utilisant à la fois une cartouche et une disquette ? Pour les Svg bien sûr, mais pas que ça peut être.
Après c'est pas toujours facile d'avoir des Cartouches bricolées et des éproms adéquattes.
Sinon euh...il me semble que personne n'arrive a faire des cartouches sans en charcuter une éxistante ? De même les Cartouches 256Ko ou 512Ko n'ont finalement pas été faites ? Sont elles faisable quand même ?
Sur certains sites ils disent que la puce servant de sécurité n'est pas trop reproductible et qu'ils ne savent pas vraiment comment elle fonctionne. Amstrad aurait il gardé le secret ?
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 4 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