Oh, il ne fut pas dit que AsT a inventé le principe (qui existait déjà sur C64) juste qu'il en avait vagument parlé avec Hermol...
Donc il semblerai que c'est une technique pas forcément facile ni pratique, de par le fait que l'on duplique bêtement le sprite, donc il doit être identique niveau animation.
Et si c'est comme pour C64 bin on ne peut dupliquer du sprite sur la même Line.
Bref niveau jeux, ça reste faisable sporadiquement : Pour toute ligne Verticale : --un mur de flammes par exemple... --une vague verticale de "vaisseaux" par vraiment/trop animés. --des jeux de plateformes sur plusieurs niveaux/hauteurs, genre des monstres à la Mario, pas trop animés et ne changeant pas vraiment de plateforme. --Pour des bonus et objets à Ramasser ça peut faire aussi je pense. sporadiquement. --Jeux à la Robocop 2...des Plateformes par exemples, que l'on retrouve sur plusieurs étages, ou des Scie circulaires, pièges divers...
Sachant que la magnification en Y permet de plus facilement couvrir de la surface Verticale aussi. C'est que en X2 bin ça fait du 32pix de hauteur... 2x moins de sprite à multiplexer donc, notament pour l'effet de vague verticale.
Pour les méga lazers verticaux dont parle Fano notament... Si on peut claquer du Sprite Hard là dedans, bin vu le design d'un tel laser, la magnification verticale en plus peut trés bien le faire.
Mais cette technique devrait être employé si ça permet de caler au moins 2 monstres en plus je pense. idéalement plus. Ces 2 monstres peuvent faire la différences entre un écran vide et un écran plein, lol.
Sinon intégrer une telle possibilité "sporadique" (à voir avec les scripts des levels donc) ça prend peut êtrre plus de place, vu que c'est en plus du reste, ou alors c'est juste un évenement particulier pour tel ou tel monstre spécifique ? Genre c'est un twik dans le Script du level, ou c'est une grosse outine à intégrer au moteur ?
Ensuite techniquement : le fait que ça ne soit pas sur la même scanline, concrètement ça limite comment ? -Pas de pixels de tels sprites sur une même ligne Y ? -Peut on simplement décaler de 1 pixel en Y ?
Logiquement, le "décalage" de 1 pixel peut se concevoir peut être. (Mais je ne le pense pas.)
Car dans l'article du C64Wiki que j'ai mis, bin ils parlent de plusieurs techniques. e ne pense pas qu'elles soient toutes applicables à l'Amstrad, mais alors les quelles le sont plus ou moins ?
Donc oui, la copie simple du même sprite mais à une hateur différente, chose qui semble faisible sur Amstrad alors.
Mais sinon la méthode de Green Bérets, en faisant une rotation des Slots de sprites, ça ne semble pas trop faisable sur Amstrad ? Ou alors en usant du fait qu'on à le double de slots de sprites sur CPC ? Genre on affiche 8 sprites pendant qu'on charge les 8 suivants, puis on affiche les 8 suivants pendant qu'on charge les 8 premiers...etc. Il me semble qu'on peut effectivement charger des sprites pendant que d'autres s'affichent.
Reste à voir au niveau temps machine, ressource mémoire, etc... Bonjour la synchronisation, lol.
"Hélas" oui, le HardWare de l'Asic/Plus n'est pas comme le C64, et ne peut pas forcément tout faire pareil. Esque par contre il permettrait des choses que le C64 ne peut pas justement ?
Bon, déjà avoir plus de sprites (même si plus petits) avec beaucoup plus de couleurs, c'est déjà bien quoi. Après heureusement que le 6128+ possède 128Ko... D'accord les Graphismes ça fait pas tout, mais ça compte quand même un peu, lol.
Sinon on parlais d'un Doom like sur CPC dans un autre topic. Sans parler de faire un moteur complet, mais une modélisation d'une plaque pseudo 3D par exemple, utilisant alors les espèce de zooms granuleux. la multiplexion de sprite peut être utile pour un effet démo alors, non ? ça serait autre chose que de "mettre plus de boules dans des bandes rastrisées"...
Bon sinon une autre question, toujours sur ces sprites Hards : Esqu'on peut les distordre ? Genre les afficher en diagonal par exemple ? (ou en ZigZag...) l'idée serait d'implémanter la valeur X de coordonée en cour d'affichage du sprite Genre Ligne 1 à X, ligne 2 a X+1, etc... ou alors ligne 1 à X, Ligne 2 à X, ligne 3 à X+1...etc... euh...en théorie, mais le Hardware le permet t'il ?
Autre truc dans le genre : peut on Modifier la magnificatio en cour d'affichage, donc des valeurs de magnifications différentes pour chaque rasterline ?
Quand on magnifie en Verticale (Genre Yx2...)bin euh, 1 pixel = 2 pixels en hauteur. Esque ça peut se distordre aussi ? ou c'est indivisible !
Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
Pour répondre bêtement, tu prends une ligne, tu comptes le nombre de sprites qu'elle croise (parties transparentes comprises), et voilà tu as le nombre de sprites par scanline
Sinon, le principe peut être effectivement applicable pour un jeu de plateforme.Par exemple, une classe d'enemis réserve 3 sprites et le code permet de les dupliquer toutes les 16 lignes.Comme je disais précédemment , le gros défaut c'est que tous tes sprites seront identiques ET dans le même sens à moins d'utiliser le double de sprites.L'avantage, c'est qu'en utilisant 6 sprites, tu peux avoir 30 enemis à l'écran en respectant la contrainte de 3 enemis maxi par bloc de 16 lignes
Citer :
Genre on affiche 8 sprites pendant qu'on charge les 8 suivants, puis on affiche les 8 suivants pendant qu'on charge les 8 premiers...etc.
Comme je l'ai dit plus haut, ça coince au niveau de notre grand ami et enemi, celui qui nous fait vivre mais qui nous tue aussi : le TEMPS ! Avec une magnification en Y à 1, ça fait 1024 nops, en optimisant tu update grand max 1,5 sprite pendant ce temps là, et encore...
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
Inscription : 28 Août 2008, 23:41 Message(s) : 258
Ca part un peu dans tous les sens votre thread.
Pour gérer des animations dans les sprites, il suffit de gérer ça en flipping pour pouvoir partager le temps de transfert sur plusieurs frame, étant donné qu'une animation de personnage ne peut de toute façon pas se faire au frame sous peine de risque épileptiques.
Si on change la position X d'un sprite hard alors qu'il est affiché, alors il est réaffiché, ce qui coupe le sprite Je me rappelle plus ce qui se passe si lorsqu'on est sur la ligne 10 et que le sprite est affiché ligne 10, on lui dit que le sprite est affiché ligne 9. Je crois me souvenir que offset me disait qu'on se retrouve en ligne 11 avec la ligne 3 du sprite et non plus la ligne 2
Pour le multiplexage des sprites, ça date au moins de 1987. La difficulté des moteurs sur C64 consistait à permuter les sprites lorsqu'ils se croisaient dans l'axe vertical. Il existe des méthodes pour faire ça.
Comme dit à moult reprises, l'Asic n'a pas de ram "sprite" libre pour les vectoriser. Contrairement au C64 également, il n'est pas possible de les prioriser. On a jamais réussi à retrouver les ingénieurs de l'asic. (peut-être des échappés de l'asile...) Ce qui implique que si on veut gérer un effet de profondeur avec un zoom avec un sprite qui passe devant ou derrière l'autre, et bien il faut inverser la position des deux sprites (et leur contenu si il est différent) ou en utiliser d'autres. Ce qui implique d'avoir de bonnes méthodes de tri.
Enfin, il est possible de tricher je suppose sur le contenu du sprite en limitant le nombre de couleurs à 4, sur le même principe que le dual playfield du jeu génocide. Utiliser 2 bits pour un dessin et 2 autres bits pour un 2eme dessin dans le même sprite, et changer la palette pour afficher l'un ou l'autre des dessins. Mais bon, c'est un peu moche quand même et ça implique que les sprites ne se croisent pas et que la palette soit changée.
Inscription : 15 Oct 2007, 02:49 Message(s) : 402 Localisation : Les Sucres en Morceaux
Par contre, si tu triches avec les encres, ne pouvant pas attribuer de couleur "transparente", tu te retrouves limité, car les 2 sprites "mixés" doivent alors avoir le même contour. Je me trompe ?
Bon, pour ce qui est du fait que les Sprites Multiplexés sont identiques (animés pareil voir synchrones...).
Bien sur c'est moyen pour faire des orcs se ruant sur toi et te tailladant à la Hache...
Après je pense qu'il y a moyen de biaiser la monotonie en utilisant la transparance. Tu double ainsiles Sprites Hards par un sprite Soft servant de coloriage pour certaines zones. Euh...ça implique de caler un nombre respectable de sprites softs par contre (ouille). Mais ça romp la monotonie, et il vas de soit qu'il y a un certain travail graphique : que le style du jeux permette cela quoi.
Mais il me semble que pour un Pseudo Wonder Boy 2 in Monster land c'est largement faisible (jeux qui mériterai un pseudo Remake, au moins reprendre le concept d'un Mario avec épée et achat d'équipements...). LEs sprites /monstres ne sont bien sur pas énormes quoi.
Sinon si tu as un peu de Sprites de libres... Disont par exemple un monstre en 2 sprites (16x32 donc...par exemple). Qui serait animé en 3 frames (faut pas être gourmand, lol...). ça fait un total de 6 sprites.
Ces 6 sprites sont chargés... Bin tu peux alors faire des monstres au mouvement asynchrone sur plusieurs niveaux, certains étant synchrones, d'autres non...
Ceux sur le même niveau sont forcément asynchrones (soient 3 monstres donc), mais peuvent être synchrones avec certains d'un autre niveaux Y.
Euh, par synchrone/asynchrone, je parle en fonction de la Frame d'animation bien sûr.
Mais dans l'ensemble ça implique des mouvements automatiques, pré-calculés ou sans trop d'adaptation au déplacement du Joueur.
Car sinon ça risque d'impliquer des Frames supplémentaires d'animation. Dans Gryzor par exemple, voire Green berets, bin la plupart des méchants se contentent de traverser l'écran en restant sur leur niveau d'origine.
Sinon pour des jeux genre Jet Set Willy...c'est tellement automatisé que y'a bien moyen de faire de superbes écrans avec cette technique.
Mais euh... Mario Bros "old" par exemple. Les monstres genre champigons carnivores.
Exemple :
L'animation bin c'est genre 2 images max (euh, plus ?) Et il font face à l'écran donc n'ont pas de sens Gauche Droite. C'est l'exemple typique du Sprite facile à multiplexer je pense.
Bien sur dans l'image d'exemple, ils sont sur la même ligne, lol. Mais en les rendant asynchrones, et en ajoutant des plateformes sur d'autres hauteurs avec des Multiplexés, bin tu peux avec seulement 2 Sprites Hards ne faire genre 8 à l'écran. LE gain étant aussi que ça te laisse du temps pour charger d'autres sprites sur les nombreux slots libres.
Mais bon,il faut reconnaitre que le type de jeux nécessitant boucoup de sprites, qui en plus sont rarement animés en moult frames, bin ça reste le Schmup, et là bin y'a vraiment de quoi faire. Surtout qu'un Schm'up Amstrad, y'a pas trop besoin de caler exclusivement des monstres en 64x64 pixels...
Star Sabre est un bon Exemple que ce qu'un Schmup sur Plus peut donner. Et le Format Plus n'a pas eut le temps d'avoir de véritables Schmups sinon (Mystical, lol...quoi d'autre ? ah bin vi, Star Sabre...).
Les patterns de vagues d'enemis d'un bon schmup, c'est varié Mais il n'est pas rare d'avoir des vagues veticales,que ça soit pour un Schmup Vertical ou Horizontal.
Bin là on tient peut être la technique pour faire de bons coups de boosts en nombre de sprites. Il faut juste bien intégrer cette possibilité et les contraintes induites dans le Level Design alors.
Mais bon, on ne peut pas faire des jeux modernes sur de vieilles machines de toute manière. Si les jeux d'avant étaient ce qu'ils étaient, c'est passque les machines d'époque étaient limitées. Les vieilles Bornes d'arcades n'étaient pas tant plus puissantes qu'un CPC : Genre tu avait un Z80 pour les Graphx/animation, et un Z80 pour le son, lol... LE reste était en Rom et en Hard c'est clair, mais ça restait finalement limité en fait. Bien sur les Bornes d'arcade ont vite évoluée et on a eut des méga ros sprites pour de superbes jeux de baston (Double Dragons like, mais surtout AD&D Tower of Doom par exemple) Bin un CPC ne peut pas faire ça. Par contre pour des jeux de plateformes de type AlexKid ou MArio...bin c'est trés faisible quoi.
La C64 en avait de trés bons. Le CPC old pas trop. L'Amstrad Plus aucun. (Pang ? Robocop 2 ? mwaip...)
Toutefois un jeux de plateforme n'est finalement pas si gourmand en nombre de sprites, si ? Quoique si tu fait du sprite relativement gros mais surtout bien animé genre Black Tiger...
Dernière édition par MacDeath26 le 04 Sep 2009, 15:36, édité 1 fois.
PS. Arretez de vous prendre la tete avec la technique.. faites les jeux simplement.. surtout dans un contexte de jeu, c'est vraiment pas grave que ca tourne en 20Hz voir 15Hz.. le Z80 peut encaisser bien des chsoes sur plusieurs frames, la technique ne fait pas tout !
En même temps ici c'est la section Coding, donc Technique soft...
Citer :
Ghost'n'Goblins etait a 50Hz ! Un super gameplay difficile au possible.. que te faut-il de plus ?
Oui en effet, et tu as oublié la superbe musique... Après euh... ghost'N'goblins n'affichait que 4 couleurs pour le décors et 4 couleurs pour les sprites... (comme ghouls'N'ghost d'ailleurs, qui lui était en full screen d'ailleurs, mais aux graphismes moins bon notament pour Arthur)
Mais on n'avait pas droit aux coup de l'armure qui se casse donc 2 Points de vie (ce qui explique la trop grosse difficulté...). Perso j'ai jamais dépassé le level2.
D'ailleurs cette série (Ghost/ghouls) m'a toujours laissé un goût de "peut mieux faire" ou de "dommage...".
Genre l'idéal aurait été un mélange des 2.
Et on ne peut pas comparer ça a des jeux "à la Mario".
Quoiqu'il en soit, il faut réserver cette technique (Sprite Multiplexing) pour les jeux De type plateforme/run and gun/Sh'M'up, à condition d'avoir des levels à forte teneur en plateformes sur plusieurs niveaux, des vagues d'enemis de type Sh'm'up (jeux à la Robocop, Midnight Résistance...), etc.
Et là bin oui si ça ne pénalise pas trop en matière de ressources machine, bin ça peut vraiment bien charger les levels en Adversaires, au moins pour certaines séquences..
Mais encore faut il que le jeux soit fluide, rapide et jouable quoi...lol.
Inscription : 29 Août 2007, 12:04 Message(s) : 1989 Localisation : seine et marne 77
Citer :
Mais bon, on ne peut pas faire des jeux modernes sur de vieilles machines de toute manière. Si les jeux d'avant étaient ce qu'ils étaient, c'est passque les machines d'époque étaient limitées. Les vieilles Bornes d'arcades n'étaient pas tant plus puissantes qu'un CPC : Genre tu avait un Z80 pour les Graphx/animation, et un Z80 pour le son, lol... LE reste était en Rom et en Hard c'est clair, mais ça restait finalement limité en fait.
Hum hum.... La différence entre un CPC qui utilise un z80 et une machine d'arcade qui utilise DES z80s ?
Ah mais elle est de taille mon ami. Sans avoir besoin de parler de "programmation", faut distinguer au moins 2 points.
Le z80 du CPC doit être programmé, et il s'occupe de tout affichage graphique, son, etc (géré en software).
Le ou les z80 d'une machine d'arcade (voir le 68000 ou n'importe quel autre processeur), ne sont pas utilisés pour celà. Les processeurs présents dans les machines d'arcade sont là pour faire du pilotage de fonctions hardware.
Exemple : La carte CPS1 de Final Fight utilise 64ko de RAM dynamique. Les boules non quand on sait que le CPC dispose de 128ko pas vrai ?
concrètement les puces custom, graphiques ou sonores sont super puissantes, pour preuve, le 68000 utilisé pour piloter la carte de FF est infiniment moins costaud que les puces CPS1-A et CPS-1 B......
Les 64ko servent juste à contenir les commandes d'affichages des décors, sprites, et les commandes sons qui vont être envoyées au z80 qui lui même pilote la puce son.
Une simple borne équipée de 2 ou 3 z80 est plus balaise qu'un amiga 500 à titre de comparaison.....
Citer :
Bien sur les Bornes d'arcade ont vite évoluée et on a eut des méga gros sprites pour de superbes jeux de baston (Double Dragons like, mais surtout AD&D Tower of Doom par exemple). Bin un CPC ne peut pas faire ça. Par contre pour des jeux de plateformes de type AlexKid ou MArio...bin c'est trés faisible quoi.
les machines d'arcades en particulier celle de capcom, affiche en mode planar comme l'amiga, mais en utilisant des tuiles, bien plus pratique. les sprites de DDTOD (tower of doom), sont composé de 200 ou 300 images, si ce n'est plus par personnage. En fait, tout dépend du jeu pour le nombre de sprites, surtout sur CPC. final fight très gros sprites, mais peu, double dragon 2 gros sprites et bonne animation, mais lente.
_________________ SPS Community Expert (SPS CE) / SPS France
Ah ça, Tower of Doom et Shadow over Mystaria sont énormes !!!
Et oui tout le custom Hard des bornes d'arcades (ou consoles, voire c64...lol...) et la grosse chié de ROM fait vite une énorme différence que l'Asic d'un 6128PLUS ne parvient pas vraiment à combler.
Déjà si un 6128 pouvait utiliser les +64ko de ram pour le son et les graphiques sans empiéter sur les 64ko du z80...ça serait un régal (un peu comme pour un MSX).
Inscription : 13 Jan 2010, 14:25 Message(s) : 2270
Le "sprite multiplexing" est un concept tellement précis et contraignant, qu'il faudrait faire un jeu "taillé pour" et non l'inverse. Une sorte de Lemmings où je ne sais quoi ... Enfin, quelque chose d'unique qui bleuffera forcément sur notre bécane !
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 67 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