Inscription : 13 Jan 2010, 14:25 Message(s) : 2282
fano a écrit :
Oui un overscan horizontal , le CPC+ possède les même limites que le old en terme d'occupation mémoire.Après comme le dit MacDeath c'est aussi un choix , tu peux penser à un overscan total mais c'est de la place en moins pour d'autres choses , sachant qu'au vu de l'organisation mémoire vue par le CRTC , tout bloc de 16K est utilisé de manière non linéaire.
Mais ça ne pose pas de problème sur CPC+ avec ce qui est affiché en hard ? (enfin, ya que le scrolling hard qui poserait certainement soucis)
Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
TotO a écrit :
Mais ça ne pose pas de problème sur CPC+ avec ce qui est affiché en hard ?
La seule chose qui est affiché en Hard sur +, ce sont les sprites.C'est vrai que eux sont indépendants de la mémoire écran (mais pas des réglages CRTC, ce qui amène parfois à des surprises)
Le reste , c'est ta mémoire vidéo sachant que dès que tu passes les 16K , pour l'affichage soft, tu dois prévoir un contrôle supplémentaire dans ton code pour le saut de page écran , ce qui ralentis ton code aussi.D'autre coté , les démomakers te diront ça mieux que moi mais à mon avis , ça ne doit pas être évident de gérer un scroll hard et des sprites softs sur 2 pages écran de 16K même en utilisant le split du +.
Le scroll Hard sur + n'est d'ailleurs pas nouveau puisqu'il s'agit du même que sur old.La seule différence, c'est que tu as un registre en + qui te permet de décaler l'affichage de 0 à 3 pixel en horizontal (mode 0) et de 0 à 7 pixels en vertical , tu as aussi un registre qui te facilite un peu le scroll Hard.
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
Inscription : 13 Jan 2010, 14:25 Message(s) : 2282
fano a écrit :
Le scroll Hard sur + n'est d'ailleurs pas nouveau puisqu'il s'agit du même que sur old.La seule différence, c'est que tu as un registre en + qui te permet de décaler l'affichage de 0 à 3 pixel en horizontal (mode 0) et de 0 à 7 pixels en vertical , tu as aussi un registre qui te facilite un peu le scroll Hard.
Ca devrait permettre d'avoir quelque chose de plus fluide normalement ; Surtout pour un shoot'm up. Mais effectivement si l'on ne peux pas déplacer correctement les sprites softs en fonction, le résultat doit-être foireux. Faut vraiment être motivé pour arriver à sortir quelque chose de chouette sur cette machine ! Car mettre 16 sprites et un scrolloing hard, et ne pas pouvoir s'en servir correctement, c'est un peut la loose quand même. :/ (triste pour mon moke-up ... lol)
EDIT:
Mais finalement, vouloir faire de l'overscan, alors qu'on a du mal à faire une "grande" fenêtre de jeu, ce n'est pas un peut gâcher de la puissance pour le look plutôt que l'utiliser pour le jeu ?
EDIT2 :
MacDeath26 a écrit :
les animation des explosions ont facilement 6-7 frames. et oui. Et il y en a parfois une grosse chiée à l'écran. Même les petits modules (ceux en haut et bas du vaisseau) sont animés en 8 frames ! Et le bouclier, bin euh...il a 3 skins en fait, ce qui représente vite boucoup de frames.
Bref pas simple de faire tenir ça sur un Amstrad Plus avec 64-128Ko de Ram mais un Z80 qui n'en gère que 64ko à la fois (4x16) et se retrouve à caser 16Ko de Ram vidéo dans un moniteur en 50Hz. Ajoute les sons que tu veux magnifiques...genre euh...de la zique tout le long du jeux, avec en plus des superbes sound effects pour les tirs, explosions, et autre. Et les levels qui ont pleins de patterns, de bizzarerie spécifiques à chacun, etc...
Mais c'est fini ces edits "ninja" ! (rire) Il est évidant qu'on ne peut pas garder autant de frames qu'en arcade. Faut diviser par deux, voir supprimer des anim' simples pour la plupart. Concernant le son, je ne suis pas exigent ... J'imagine juste la belle musique d'intro ST en trois voix sur la page d'accueil. (et durant la "démo" scriptée, vu qu'il n'y a pas les bruitages) Puis en in-game, 2 voix pour la musique et 1 pour les bruitages. Le CPC plus a 3 DMA pour ça quand même ...
Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
TotO a écrit :
Faut vraiment être motivé pour arriver à sortir quelque chose de chouette sur cette machine ! Car mettre 16 sprites et un scrolloing hard, et ne pas pouvoir s'en servir correctement, c'est un peut la loose quand même. :/
Pour braire encore un peu , ces sprites Hard ne sont pas vectorisés et chaque pixel tient sur 1 octet ! Mais bon , on ne peut rien y faire donc il faut s'adapter ce qui n'empêche pas de réussir à faire des trucs chouettes quand on se donne du mal.Là est une partie de la satisfaction d'ailleurs (Pis de toute façon si j'avais voulu pas avoir de mal avec le hardware, j'aurai écrit du code sur PC , quoique)
TotO a écrit :
Mais finalement, vouloir faire de l'overscan, alors qu'on a du mal à faire une "grande" fenêtre de jeu, ce n'est pas un peut gâcher de la puissance pour le look plutôt que l'utiliser pour le jeu ?
Pas obligatoirement , si l'overscan est bien adapté au style de jeu, ce n'est pas uniquement pour le look (Wildfire est dans ce cas je pense ).Dans le cas du (quasi)overscan vertical sur 16K (32*32 soit 256*256 mode 1, quoique c'est pas tout à fait un overscan) , c'est même une optimisation
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
Inscription : 13 Jan 2010, 14:25 Message(s) : 2282
fano a écrit :
Pour braire encore un peu , ces sprites Hard ne sont pas vectorisés et chaque pixel tient sur 1 octet ! Mais bon , on ne peut rien y faire donc il faut s'adapter ce qui n'empêche pas de réussir à faire des trucs chouettes quand on se donne du mal.Là est une partie de la satisfaction d'ailleurs
J'ai vu ça, c'est vraiment de la perte mémoire pour pinuts. Vu la place prise, ils auraient pu autoriser d'afficher 256 couleurs ... Ya pas un hack possible dans ce sens ?
Mais oui, s'il n'y a pas de contraintes, c'est pas vraiment "glorifiant". Pour ça que le retro-programming, c'est cool.
fano a écrit :
Pas obligatoirement , si l'overscan est bien adapté au style de jeu, ce n'est pas uniquement pour le look (Wildfire est dans ce cas je pense ). Dans le cas de l'overscan vertical sur 16K (32*32 soit 256*256 mode 1) , c'est même une optimisation
Surtout que tu peux adresser ta zone en 8bit et quand tu fais un starfield, en cas de "clipping", ça reprend de l'autre coté sans avoir à tester quoi que se soit. Idéal pour un "Stardust" au passage !!!
Bin, si c'est du Hard, c'est foorcément moins hackable...
Moi je suis persuadé que le'Amstrad + bin ils auraient du tabler sur un duop core avec 2 Z80...et ajouté des modes en 32Ko donc tu double tout. Soit un mode théorique 160x200 (pixels larges) avec 256 couleurs.et le même en full screen total en 48Ko donc. Mode 1 en 16 couleurs et Mode 0 en 4 couleurs. Sauf que si tu pase en duo core Z80...bin alors 256Ko de Ram minimum quoi...voire 512 idéalement. Et là ça aurait bien pu faire la nique au ST je pense.
Voire bien concurrencer l'Amiga finalement.
Le CPU de l'amiga ne faisait que 4 mghz me semble t'il.
Héhé, et double Asic donc musiques en 6 voix DMA... et 32 sprites hards... Et multiscrolls donc faisibles...
Rêve rêve rêve...
Ceci dit si je gagne au loto, je demande à un ingénieur de faire un tel montage : prendre deux amstrad plus (ou 2 GX4000) et en faire un tel duocore. lol. Ou plus simplement une carte permettant de relier deux 6128+ pour avoir presque un tel résultat (sauf pour le côté modes graphiques étendues, néanmoins pour la gestion et le son ça me semble faisible... Tu tourne alors en full overscan tout le temps. par le port extension...à voir.
car les options de networking n'ont pas été trés poussées sur l'Amstrad je trouve.
Plus sérieusement, les sprites hards c'est pas tant de la perte mémoire que ça car ça peut réellement bien booster la capacité graphique globale d'un jeux (voir Switchblade 2...) Autant le C64 (voir Rick dangerous) c'est moche le mélange des modes graphiques, bin ça vient surtout du fait qu'on est en 4 couleurs par sprites (3 + transparent...)
Alors que pour le Plus d'amstrad, bin euh...les Sprites hards en 16 couleurs, ça permet par exemple d'affiner le design des pseudo mode0 (antialiasing) donc ça peut passer par dessus un moteur en Mode1... Et vice versà car si c'est en mode0, la grosse palette et le nombre de couleurs sans contraintes permettent aussi de faire passer des sprites hards en pixels fins.
y'a qu'a voir rick 128+. les dégradés de gris sur les pierres au niveau 3...ça fait assez réaliste, limite, et on ne voit pas trop le côté gros pixels au final (enfin euh...).
Après c'est juste que ils ont calé des sprites presque dignes de 16 bits mais sans le support technique pour aller avec. Bref ils chargent lentement, la machine possède une mémoire d'un autre temps : 128Ko max...bof... et y'en a limite pas assez (regardez le nombre de sprties d'une séga Master système...) Mais une fois qu'ils sont dans la mémoire de l'asic (car il les stock alors), bin il ne prennent plus de place en fait me semble t'il.
j'ai toujours pensé que comme le format 16 bit est en 512Ko, bin un bon 8 bit devrait être en 256Ko...moitié quoi et pas racine carré (les vieux 8 bits sont limite en 16Ko de Ram et le premier ST était en 256Ko il est vrai) Amstrad était moins avare en mémoire avec les PCW...il faut dire qu'ils se sont bien plus vendus d'ailleurs. Mais au final c'est un CPC sans la lourdeur graphique en 16ko...quoique. Si j'en crois Wikipédia en anglais c'est 23KB de ram vidéo pour le PCW... affichant du 720 by 256 en 1 bit. Soit comme le mode2 en overscan me semble t'il (à peu presque).
Si les imprimantes couleurs avait éxisté à l'époque, le CPC et le PCW auraient surement été plus compatibles...
Bref mis à part le temps de loading dans l'Asic, un jeux genre en Rom de 512Ko (la cartouche qui était théoriquement prévus si mister sugar avait été moins greedy) c'est jouable.
Le truc c'est qu'on peut compresser les datas des sprites hards, mais il faut alors les décomprésser en Ram avant de les charger en Asic me semble t'il. donc le z80 il peut avoir du mal si c'est en plein jeux.
Dernière édition par MacDeath26 le 14 Jan 2010, 00:03, édité 1 fois.
Inscription : 13 Jan 2010, 14:25 Message(s) : 2282
Non, on en est bien loin de l'Amiga ... La version de base à une CPU 16/32bit à 7MHz et 512Ko de RAM. Il est surtout épaulé par des chipsets spécialisés (dont le bliter et ses blobs) et le tout en multitache avec de nombreux canaux DMA. Aucune chance de rivaliser avec 2 ASIC sur le CPC ; A la rigueur contre un STf.
Mais avoir un vrai "processeur graphique" dans l"ASIC avec 2 plans et des fonctions câblés n'aurait pas été un luxe. (sorte de VDP à mis chemin entre la Master System et la Megadrive)
Bin euh, l'amiga 500 (le vieux quoi) il me semble qu'à l'époque ils disaient qu'il était à 4 mghz... les Amiga 1200 sont bien plus récents.
Je vais vérifier. Ah oui tiens, il est a 7-7,4 mghz plus ou moins...
Marrant à l'époque dans la presse ils le disait à 4 mghz dans mes souvenirs. enfin, je doit confondre sans doute.
ou alors un journaliste du magazine Joystick était un con... quoique Marcus qui bossait à Tilt n'y connais rien il est vrai.
en tout cas un duo core Z80 aurait pu le faire car le matos Z80 était moins cher que le matos 16 bit... Passons.
En tout cas le problème de l'Amstrad Plus, c'est pas l'Asic, c'est le processeur.
Les bornes d'arcades des années 80 avaient par exemple souvent 2 CPU Z80. L'un pour la vidéo et le jeux, l'autre pour le son. Ajoute à ça des capacité de sprites et scrolls tout cablé (en hard quoi) et les programmes entièrement en Rom (donc comme de la Ram mais sans modifs possible, bref chargement des Datas super rapides et limités simplement à la quantité de Rom dispo...) Bin voilà quoi.
LE CPC n'ayant qu'un seul z80 il reste fondamentalement limité a 64Ko à la fois et un support hard assez limité.
C'est bien simple, la GX4000 avec ses 64Ko de Ram était finalement mieux doté qu'une mégadrive me semble t'il (32ko) et autant qu'une SuperNES (64ko aussi, je peux bien sur me tromper).
Sauf que : --Plus de coprocesseurs --cartouches bien plus grosses que les minables 128Ko de la GX. --CPU principal bien plus puissant aussi.
Et pourtant, la gamme plus possède une meilleur palette que ma mégadrive aussi.
Quand Allan sugar disait que la GX était aussi puissante que la mégadrive, c'est bien sûr stupide, sauf que la RAM et le nombre de couleurs de la palette, bin oui, y'en a plus...lol...
un véritable nioubee donc. Whaaa, j'ai plus de couleurs et plus de mémoire, je suis plus puissant.
Palmface.jpg
Dernière édition par MacDeath26 le 14 Jan 2010, 00:20, édité 1 fois.
Inscription : 13 Jan 2010, 14:25 Message(s) : 2282
Ce qu'il a manqué au CPC+ c'est d'être une machine 16bit en proposant un 68000 en plus du Z80. Le tout épaulé par un processeur graphique semblable à celui de la Megadrive. (car à l'époque ou il est sorti, le 68000 ne coutait plus rien)
Ainsi, le Z80 aurait assuré la compatibilité CPC et aurait pu servir de processeur sonore dédié pour le CPC+, comme c'est le cas en arcade, sur Megadrive ou encore NeoGeo.
Après si l'amstrad plus avait été si bien ou aurait été le challenge pour nous, rétro-merdeux à la loose légendaire ???
Le C128 était doté de 2 processeurs aussi, mais n'était pas vraiment duo core en faite. Le principe du duocore, c'est justement d'avoir 2 CPU identiques, sinon y'en a un qui est principale et l'autre simplement un co-processeur souvent subalterne d'ailleurs dans l'usage.
LE Z80 n'était là que pour assurer la compatibilité C/PM. il tournait à 2Mghz aussi. Mais y'avait peu de possibilité de faire tourner les 2 à la fois en fait me semble t'il.
Enfin ne pas oublier que si l'amstrad plus avait eut tous ces truc en plus il aurait été aussi cher qu'un amiga je pense...lol... Ou qu'un Atari ST vieux modèle (Atari les bradait d'ailleurs)
Mais moi je pense que c'est surtout que Alan sugar s'est aménnagé une marge éhontée dans le calcule du prix tout simplement et donc ça l'a tué. Et en plus il a perdu de l'argent ! lol.
Inscription : 13 Jan 2010, 14:25 Message(s) : 2282
La Megadrive avait aussi 64K de RAM et tu pouvais en rajouter dans la cartouche. Sa palette était limitée (512) mais tu pouvais en afficher 4x16 simultanément.
Enfin ... Avoir 2 Z80 ne peut pas servir à la même tache car ils ne peuvent partager le même adressage mémoire. La CPU n'est pas faite pour et tu te retrouve donc comme en arcade à devoir les utiliser pour des taches précises. Donc en principal et pour le son. Et mieux vaut un 68000 dans le premier cas.
Le CPC+ était cher à sa sortie, par rapport à son contenu . Il ne faut pas se voiler la face, Amstrad n'a pas su (ou voulu) faire évoluer le CPC.
Le fun est donc ailleurs ; la nostalgie et avoir entre les mains une machine exploitable à l'échelle humaine, pour faire des merveilles.
Quelques petites remarques sur votre discussion, qui s'éloigne quelque peu du sujet initial .
La principale faiblesse du CPC+, c'est effectivement son processeur. Mais plutôt que de mettre un 68000 et ainsi simplement "rejoindre" les stars de l'époque (ST & Amiga), Amstrad aurait pu soit booster un peu le Z80 (doublage de fréquence, comme sur certains msx2), soit le remplacer par son homologue 16bits (Z380 ? Je ne suis plus sûr de la référence). Ou encore mieux, piquer la technologie ARM a Accorn (l'Archimèdès existait déjà) et faire une vraie bête de course qui aurait tout écrasé (au prix d'une perte de la compatibilité avec le CPC).
Mais bon, il ne faut pas se voiler la face, le CPC+ n'était là que pour profiter du succès du CPC sans faire des investissements massifs. Il ne s'agissait donc que de faire un retapage minimal du hard, logique comptable oblige. M'enfin, histoire d'être un poil crédible, ils auraient pu au moins mettre un lecteur 3.1/2 interne et plus de ram. Ca ne coûtait pas cher en développement, et ça aurait rendu la machine plus attractive. Ils auraient pu même vendre des kits de transfert 3 pouces / 3.1/2 . Enfin, bon, on ne va pas refaire le monde .
Inscription : 13 Jan 2010, 14:25 Message(s) : 2282
MacDeath26 a écrit :
Ton Mock up est assez chouette. Mais un peu irréaliste selon moi.
320x200 (disont 160x200 car mode 0 mais on se comprend.)
Donc il faut se rappeler le nombre de jeux Amstrad pourtant si bien...avec pourtant un écran bien plus petit.
Je reviens sur se point ; Ce que veut proposer fano avec WildFire prend encore plus de ressource pour l'affichage, sans parler de devoir gérer l'overscan.
Ton raisonement est logique mais ça ne marche pas tout à fait comme ça.
TotO a écrit :
Donc si ça fonctionne pour son projet ... Ba je veux bien le moteur !
Bah si tu est capable de t'adapter aux contraintes et que tu peux faire tourner un programme Windows, je te donnerai l'accès au source du moteur version 2 (enfin quand il sera fini) et le support technique pour y intégrer ton travail
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 11 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
Connexion
Inscription
FAQ
