En lisant les Articles Wikipédants English sur le C64... J'avais vu un truc : -8 sprites Hards par Scanlines.
Et là je vois qu'ils parle d'une technique de sprite Multiplexing. Qui permet alors d'afficher plus que les 8 sprites hards normaux.
LA question : l'Amstrad Plus possède de l'interuption Hard, du Scrolling Smooth Hard, des Sprites Hards...comme le C64.
Peut il faire ça ?
Je me doute que l'Asic du Plus n'est pas vraiment un "VIC-II (Video Interface Chip II)"...Que ça ne se programme pas de la même manière, ni ne fonctionne avec la même logique. Mais bon.
Y'a t'il un équivalent ?
Bien sur les Sprites Hard du Amstrad Plus sont me semble t'il plus gourmands.
Les Sprites Hards C64 : -- 8 "seulement" --24 × 21 pixels (12 × 21 multicolor) --Et le C64 est un peu comme le Spectrum : nombre de couleurs limités par caractère/sprite (mais plus de 2 quand même...).
Alors que pour l'Amstrad bin les Sprites ont 15(16) couleurs, sont au nombre de 16 et font 16x16 pixels avec magnification ("Zoom"). Soit boucoup plus de données voir de pompage ressource.
Sinon ils parlent aussi de ce jeux, : http://www.youtube.com/watch?v=_J4saQEatbQ soit disant le top en matière de possibilitées du C64 en matière de sprites et autres... C'est vrai que ce genre de production manque sur l Format Amstrad, Old comme Plus.
Tiens, sinon : http://en.wikipedia.org/wiki/List_of_mo ... B_palettes trés bon article pour comparer les palettes et pour voir que oui, le CPC même Old avait quand même plus de possibilitées Graphiques.. D'ailleurs y'a quelques images sur la palette du CPC old : "3-level RGB" Qui ont l'avantage d'être classées, ça vas bien pour se faire ses dégradés...
Inscription : 20 Août 2007, 18:21 Message(s) : 4992
il existe une technique pour multiplier les sprites hard, AST/iMPACT m'en a vaguement parler a la CC4. La bidouille consiste a modifier les coordonnées X/Y de ton sprites avant la fin du balayage écran ou un truc dans le même genre
Il faudrait cogiter a un truc autre que des effets a base de boules avec les sprite hards.
Genre (je dis surement une grosse connerie, mais c'est pour le principe de la chose) dans la Phat 1, il y a le tunnel. Imaginons qu'on mettre dans les sprites hard des "carres" et qu'on soit capable de les afficher sur tout l'ecran verticalement, peut-etre qu'on peut refaire l'effet de la Phat 1 en 50hz. C'est qu'un exemple comme ca qui me vient apres 2 secondes de reflexion..
En gros, faut se retirer de la tete les bouboules et voir de l'avant. Vla.
Bin euh. Moi je parlais de ça pour attirer l'attention sur un truc sans doute courant sur C64 mais probablment inusité sur Amstrad+ (en fait c'est l'Amstrad + qui est inusité, lol).
Perso, je ne pourrais rien en faire, je fais principalement du design, pas du code.
MAis attirer l'attention sur des idées et approches différentes peut servir à d'autre qui sont tellement dans le codage qu'ils ne pensent pas forcément à élargir leur champ de conscience (lol, ça fait new-age ça).
Un peu comme pour le Rick Dangerous 128+ de Fano. Il n'avait pas pensé à mettre plutôt du son digitalisé (Whaaaaaaaaa!) et ça sera finalement l'ajout le plus marquant selon moi.
Euh, ça bug encore un peu hélas, mais c'est sur la bonne voix.
Ensuite la démo synergie Impact (voir image) est assezchouette. Mais ça reste une démo Amstrad classique je trouve.
Donc oui trop axée sur des boules, un test scrollant, Quelques Rasters... mais un chouette Graphisme par contre...
Le coup des bouboules comme tu dis, c'est en fait je pense une certaine facilité : En effet une boule, tu ne l'animes pas. Tu la déplaces mais pas d'animation vraiment (genre plusieurs frames quoi). Donc ça évite du recharger du sprite Hard (nouvelle tuile), ou d'utiliser 2 Sprite pour 1 (gain de vitesse de changement de tuiles).
Après il faudrait en savoir plus sur cette technique sur Amstrad. Ce que ça pompe, et tout et tout, les limitations aussi...
Il est peut être possible de faire alors des "demi sprites hards" ? Genre bin transformer un sprite Hard 16x16 en 2 sprites 16x8... Après il me semble que l'Asic gère ces sprites Hard plus ou moins indépendament de l'écran... Mais oui, du "pseudo Raster" aplliqué à ça...faut voir. Donc modifier les coordonnées du sprite en cours de génération donc. Faut voir niveau temps machine/mémoire comment ça se passe. (moi aussi je dit des conneries)
C'est que l'Amstrad est tellement gourmand en Vidéo...
Voir aussi comment ils font sur C64 et à quoi ça sert.
Un des problème semble être qu'on est limité par scanline. Donc on peut multiplier verticalement mais pas horizontalement. Néanmoins pour certains jeux, ça peut permetre d'ajouter quelques monstres qui ne seraient pas sur les même plateformes par exemple (pas sur les même hauteurs donc.) De même peut être sur les gros monstres, ou certaines tuiles sont réutilisées...a des hauteurs différentes ?
Pour des Shmup verticaux sans doute, c'est applicable. Genre pour les "tourelles" fixes sur le décors... Voire pour certains tirs genre des missiles tirant verticalement.
En tout cas, si mes approximations sont relativement justes, bin un jeux de plateforme genre Black tiger, Green Berets, Gryzor peut en caser sporadiquement si y'a pas trop de risque que les monstres changent trop de plateformes, ont des patterns pré-établies, et le Level Design/gameplay doit alors en tenir compte je pense.
Un des avantages probable de l'Amstrad+ serait qu'il possède 2x plus de sprites Hards. Après ils sont plus petis aussi (16x16) mais avec la magnification, bin passer en pseudo mode0 (donc 32x16 en pix2x1) permet bien vite de caler une bonne surface horizontale... Et le Mode0 en 16 couleurs, bin y'a moyen de faire du beau aussi... Bref on peut sans doute se garder un peu de Sprites en rab pour les rotations d'animation. Enfin euh, c'est donc aussi plus gourmand, lol.
Bref les 128Ko et les 4MgHz seront de toute façon mis à rude contribution, lol.
Il me semble que les techniques sur C64 sont a étudier "Plus" largement pour l'Amstrad Plus. En effet les C64istes ont forcément une grande expérience en matière de trucs Hards que les Amstradistes (trop souvent Oldistes) n'ont pas. C'est qu'un Bon Codeur sur Old, bin les Scrolling smooth hard, les Sprites Hards, etc...il ne connait pas à la base.
C'est à mon avis pour ça que les Oldistes boudent le Plus. ça remet en cause trop de choses.
Bien sûr, machines différentes, composants différents, ça ne doit pas marcher pareil que sur C64. Mais bon ça peut aussi donner des idées non ?
Enfin il me semble que Fano peut être intéressé par cette possibilité, vu qu'il tente un Shmup certes horizontale mais néanmoins basé sur du quasi "Full sprite Hards"...
Dernière édition par MacDeath26 le 03 Sep 2009, 15:46, édité 1 fois.
Ben, pour en avior un peu fait le tour, les sprites sont pas mal limités sur CPC.. le fait que tu ne puisses les updater que par copie (plutot que de les faire pointer n importe ou en memoire) c'est plus que primitif. oua lors tu as un sprite animé.. mais que ca, un seul.
Le big interet du Plus, c'est la couleur et l'audio. Meilleur exemple : l'AE2009 avec le player d'Offset et le code a Roudoudou sur le meme screen!
Arf, oui, donc en fait tu doit "recharger dans l'asic" pour la mise à jour, et non dire "prend les datas là dans la Ram". Donc en gros y'a un temps de transfert ce qui explique qu'on aime bien utiliser plusieurs slots de Sprites hard pour un seul...?
Mais bon dans ce cas en se plaçant sur une base de seulement 8 slots utilisés...c'est jouable comme pour un C64 ? Sachant que certains sprites parfois peuvent ne pas vraiment être animés mais juste déplacés ?
Pour des Schmup par exemple, y'a pas toujours de l'animation de partout. Juste du déplacement bien souvent.
Reste qu'alors oui, il faut jongler entre moulte techniques et bricolages, lol. Et bonjour la galère en synchronisation.
comme tu l'indiques avec les sprites, oui les shoot en sont un bon exemple.
attention cependant, la copie est qq chose d autorise c est pas la mort non plus. meme avec la copie c est qd meme plus rapide qu en soft se taper le sprite a la main.. mais avec l avantage que le sprite a sa propre palette et pas forcement le meme mode graphique que le background..
Par contre ça pompe pas un poil plus de mémoire en hard qu'en soft ?
Et le problème je pense c'est quand on cumule les 2 techniques : sprites Hards et soft, puisqu'on double en fait les routines de gestion, non ?
Enfin, bon. Faut pas être trop gourmand non plus dans l'absolue je pense.
Vouloir caser 28 monstres "Hards et softs" de 32x64pix à l'écran, euh...mwaip.
Disont que si avec le multiplexage des Sprites Hards tu peux caler +1 ou +2 monstres complets (genre 2 ou 3 sprites Hards 16x16 chacun) à l'écran, c'est déjà énorme en fait. Non ?
Et pour des monstres en 1 seul sprite hard, bin y'a sans doute moyen d'en caler justement pas mal en plus si les levels/design/gameplay sont bien faits/adaptés.
Genre Schmup vertical, 1 vague vertical de 4 vaisseaux ne prendraient en fait que 1 seul ou 2 sprites Hards multiplexés ?
Tu as un lien pour le fumeux AE2009 dont tu m'as parlé ?
A noter qu'un jeu n'est pas obligé de fonctionner en 50Hz.. dans ce cas, mixer soft et hard est interressant. Mais disons qu'en soft tu dois t'occuper de restaurer le fond d'ecran etc et que t'as pas cette contrainte en hard
C'est clair que si Fano peut réussir a acaler 2 vagues horizontales d'énemis simultanées pour 2x moins de sprites...c'est plus que largemt interessant. LE seul truc c'est que ces vagues ne soient pas au même "Scanline"... Et pour les vagues en diagonales y'a sans doute moyen de biaiser cela afin que les vagues puissent en fait se croiser. C'est même théoriquement simple.
Quand aux vagues "verticales, bin là c'est l'orgie potentielle donc.
Bref on tient un bon filon potentiel.
Bien sur je ne prétent pas que ça fera un moteur de jeux fluide et rapide, mais au moins le jeux sera magnifique, lol... Genre bin quand même : 32 couleurs à l'écran quoi... Des sprites en Mode 1... Etc...
LE problème c'est que le moteur de Fano est déjà bien avancé et assez ambitieux. (mmmh, pas totalement au point non plus si j'ai bone mémoire, lol) Et il n'avait sans doute pas prévus cette technique donc il risque de devoir refaire un max de trucs sans doute..
Après ce qui est bien dans un Schmup, c'est que on peut bien faire des Monstres en 1 seul sprite Hard 16x16. Et en Horizontale bin le pseudo Mode0 passe trés trés bien aussi.
Mais pour le coup du "pas obligé d'être en 50Hz"...euh. Fano avait fait des essais et c'était moyen quand même en 25Hz... ça reste l'éternel problème, ne pas vouloir trop en demander à la machine quoi.
Sinon je pense toujours au concept d'un jeux 6128+ mixant cartouche et D7. L'intéret selon moi est que tu peux gagner de la Ram en stockant certains Datas (genre des tuiles de sprites et des tuiles de décors, sons et musique peut être ?) dans la cartouche, en Rom. Donc faire un "accés disc" en cours de jeux. Ou plutôt un accés Rom. ça prend certes du temps machine aussi : transférer la Rom en Ram ? ou alors c'est comme du Bank Switching et tu utilises la Rom à la place de la Ram ? Surtout si y'a un compactage...
En fait l'intéret selon moi (je me trompe probablement) c'est qu'alors les tuiles non utilisées dans le lvel, bin elle ne sont pas en Ram. Tu peux donc faire des levels avec théoriquement plus de monstres ou de styles de décors (mais pas en même temps), ne chargeant avec la D7 que le Level Design et le moteur de jeux...
Sachant qu'entre 2 vagues de monstres (cas d'un Schmup) bin tu as bien un peu de temps libre pour les transferts non ? Et en ménageant bien l'ensemble, tu peux t laisser de la place pour les rotations de tuiles donc.
Le problème, c'est qu'il faut avoir une cartouche customisé en Eprom amovible... Et avoir de quoi Graver l'Eprom.
Enfin, bin il faut un loadeur adapté au jeux sur une partie de la Cartouche.
Qui prendrait facilement 48Ko je pense. Voire 64Ko ? Voire moins ? MAis qu'il faudrait néanmoins programmer.
ça ferait un truc genre un logo Amstrad (+ un sample "AAAAmSTraaaad", à la séga ?). Qui demanderai d'insérer la D7 du jeux, puis de presser une touche... Et voilà.
Après, un tel loader serait générique je pense...le reste de la Rom serait en fonction du jeux.
Mais une fois de plus, je rêve trop ?
Post Edition : Back to the topic : Oui sur C64 ilssemblent utiliser cette technique pour des scrolling multi, non ? Genre tu as un superbe scrolling horizontale Multi à la Shadow of the Beast... Bin comment tu cales les gros arbres qui te casse tout ça ? Réponse ? En multiplexant du Sprite Hard...
Euh, pas facile non plus, mais pourquoi pas.
Idm si tu veux un effet genre une lune dans ton décors, qui reste fixe (donnant une impression de profondeur) alors que ton décors scroll. Bin 2 Sprites Hards Mode 0 alignés horizontalement (32x16 mais en fait 64x16...)multiplexés permettent logiquement de faire un bon gros truc carré de 64x64...Si tu arrives a le caler sur 4 lines.
Mais là il faut je pense bien gérer la "rotation" des slots de Sprites hards.
Disont que on se souvient tous de la démo Shadow of the beast sur Amstrad. Et son superbe parallax. http://www.youtube.com/watch?v=6_RbO0Vm-AA Mais y'a pas les arbres, juste un petit panneau par contre... Je sais pas si il tilise du Plus (je ne pense pas) ni si il utilise 128Ko de Ram... Mais en faisant moins de parralax et plus de Sprites Multiplexés, faut voir ce que ça peut donner.
Si le Sprite Hard se multiplexe facilement sur Amstrad Plus bien sur...lol. C'est pas gagné je pense.
Dernière édition par MacDeath26 le 03 Sep 2009, 18:31, édité 6 fois.
Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
Sacré sujet qui prend un peu les routes sinueuses.Le gros obstacle à un genre de 'multiplexage' des sprites , c'est que l'ASIC a surement été conçu sur le zinc d'un pub anglais après l'ingestion massive de cervoise tiède par deux ingénieurs stagiaires qui voulaient faire une bonne blague au père Sugar (faut la faire sortir la frustration ), donc comme le dis justement norecess il faut les updater à chaque fois au lieu de changer le pointeur (surement comme c'est le cas avec le C64).
Sinon une fois passée la déception, c'est un composant qui est sympa, ne serait que pour les 4K couleurs, PRI , SPLT et les AY lists (je ne parle pas de l'IM2 et des int DMA buggués ).Il est vrai aussi que les sprites Hard sont réelement un plus même si ils ne sont pas à la hauteur de ceux des autres machines.
Plus sérieusement, c'est sur que si on pouvait updater les sprites au moins à la même vitesse qu'il sont affichés, sachant que tu devrais au moins travailler avec un jeu double, donc 8 sprites soit une largeur maximale de 128 pixels mode 1 ou 64 mode 0 (soit 16 caractère ) pour pouvoir préparer la ligne suivantes de sprites pendant qu'une est affichée et que tu as 1024 nops (16 lignes*64 nops par ligne) pour updater tes 8 sprites de ligne suivante.
Sinon, j'avais déjà pensé , comme surement beaucoup d'autres avant moi , pour un jeu de type Space Invaders utiliser les sprites repliqués car le type de jeu s'y prête à merveille.Sinon, la contrainte c'est que les sprites repliqués de la sorte sont identiques mais pas au même endroit.
Je suis en train de re-écrire et d'expérimenter des pans entiers du code de Wildfire mais le gestionnaire de sprites est bien assez performant et souple pour y toucher (et j'en suis fier ) .Par contre, c'est vrai que dans certains cas ça peut être interessant, j'y avait pensé pour simuler des méga lazer verticaux par exemple.APrès c'est effectivement assez délicat car ça repose sur PRI et ça peut entrer en conflit avec d'autres techniques.
Quand au fait de tourner en 50Hz, je recherche effectivement la performance mais un jeu, c'est pas une démo et y'a beaucoup d'autres choses à gérer.Si c'est pour tourner à 50Hz mais sacrifier le gestionnaire de scripts par exemple, qui est indispensable pour donner de la consistance au gameplay, ben autant faire une démo (sans dénigrer, les démo sont l'occasion de trucs de oufs mais malheureusement souvent peu applicables dans le cadre de jeux (j'attend toujours un jeu en rupture ligne à ligne )).
Si il y aussi une idée qui me semble ne pas avoir été utilisée avec l'ASIC c'est justement l'usage des couleurs RGB pour travailler des effets de transparence, je suis persuadé qu'il y a quelque chose à explorer de ce coté là (comme certaines démos le font d'ailleurs sur old) et un concept sympa, voir original, à en tirer.
En tous cas, on en serait pas là si l'ASIC avait été conçu intelligement (et les 16 couleurs codées sur 8 bits, hein ) , là au lieu de se prendre la tête, on aurait de très beau parallaxes sur au moins deux plans incrustés , ah ça fait du bien rêver...
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
A savoir que la position des sprites hards sont fonction des compteurs CRTC. Dupliquer les sprites hard peux ne prendre aucun temps machine. Exemple type dans la preview de delirium tremens (a matter sur un vrai CPC+) afin de voir un ecran resolution mode 1 en 31 couleurs complet (pas totalement complet dans la preview). Ast n'a pas non plus inventé le principe de deplacer les sprites en court de balayage, la première demo le faisant etant certainement "it was so nice before the crash of the mir station (Eliot)". Le seul soucis au final des sprites hard est que l'on ne peux pas changer leur contenu assez rapidement. L'indexation des adresse d'offset des sprites hard aurait été judicieux... Mais cela n'est pas possible (pas vraiment) donc il faut faire avec. Cela dit pour un shoot, il est tout a fait possible d'utiliser ces differentes techniques pour faire apparaitre à l'écran plus de sprites hard qu'il n'y en a dans l'asic dans la mesure ou ceux ci ont les memes gfx et que leur position est differente (x ou y peux importe).
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 81 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