Ca donne des idées apres avoir vu le super Rick Dangerous 128+ J'ignore si un Toki sur un Plus est faisable. En attendant j''ai fait quelques essais sur le niveau 1. Qu'en pensez vous ?
Heu y a eu quand meme une version NES, une version Lynx et une version C64 de sortie. De plus il me semle qu'une version GX4000 étaité prévue. C'est que dans l'absolue ça doit etre peut etre faisable quand meme nan ? Peut etre au detriment de certains niveaux et de certaines posibilités... enfin bref j'en sais rien...
Dernière édition par NiNxPe le 09 Jan 2010, 21:45, édité 1 fois.
Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
Hou , ne vas pas si vite en besogne lol
Y'a de l'idée et graphiquement ça donne bien.Par contre, il nécéssiterait une étude approfondie auparavant car c'est vrai que c'est un gros morcif à convertir et on y perdrait au passage. On peut très bien imaginer un système de double buffering au vu de taille des sprites et garder les sprites hards pour les projectiles et autres bonuses.
Après , faudrait trouver du temps pour travailler là dessus et je dois avouer que j'en manque un peu (je vais demander une année de détachement pour pouvoir bosser sur tout ce qui me fait envie )
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
Plusieurs raisons possible a cela : --trop gourmand, le résultat aurai été merdique. --trop gros, la cartouche en 128Ko est forcément trop petite (le cas le plus probable) --le format "PLUS" fut hélas trop limité à 64Ko car mister sugar a été radin sur la RAM. --la GX a fait faillite...euh...admettons.
Après, le fait de faire ça en cartouche/rom ça permet notament de compenser le fait que les levels, bin y'a vite un max de tuiles et de choses... Et se baser sur une version 128+ déjà ça me semble hélas nécessaire aussi.
Comme je l'ai déjà dit, les sprites sont gros, donc en hard : pas trop possible, et en soft : gourmand en CPU voire mémoire...
Designer du graphisme au format CPC+ genre Mode0 sur un PC, c'est forcément facile (enfin euh...c'est quand même du boulot) et ça peut rendre super bien c'est clair (et là ton job est superbe). Mais quand on doit se plier a des contraintes d'un moteur de jeux, ça devient vite plus spartiate.
Y'a qu'a voir final fight. On dira ce qu'on voudra, bin c'est pas super top niveau jouabilité et feeling, mais oui, les sprites et graphismes sont du bon portage sur CPC mode0...
Après je ne dit pas que c'est pas une raison pour pas tenter le coup bien sûr...héhéhé.
Perso, je suis persuader que idéalement, il nous faudrait un format hélas 6128+... Donc en fait mélanger à la fois une cartouche, 128Ko de Ram, ET le lecteur de D7. C'est selon moi le seul moyen de faire des Méga-games...
Datas bruts : cartouche. Moteur du jeux : en Ram notament, mais tous les levels et autres chiottes, bin sur la D7 quoi.
Ce genre de formule hybride serait dl'idéal selon moi.
Mais hélas, le format cartouche en plus de 128Ko c'est pas encore ça (mais je pense que cette année on devrait y arriver...) Et les méchanisme du mixage ROM+D7...bin euh...pareil, y'a du boulot pour en tirer bien progfit.
Bien sur, pour du jeux d'action c'est pas necessaire, 512Ko de cartouche peuvent bien suffir. Reste que les 128Ko de RAM, vu que l'Amstrad Plus doit tout de même boucoup faire de chose en SOFT, bin c'est necessaire (adieux la GX pour des trucs bien léchés, mais euh, ça reste faisible quand même...)
Mais pour des jeux genre RPG (Pirates, Might and magic...) bin là on devrait pouvoir avoir du résultat impressionnant et presque digne de 16 bit en mixant Cartocuhes et D7...
Toki : C'est avant tout un Gryzor like avec un peu de mario.
Tir multidirectionnel (ce qui est vite assez lourd niveau sprites, car y'a 8 directions...), saut sur la tete des monstres.. Scrolling multidirectionnel aussi... Et des Boss assez énormes tout de même... (ouille)
Si on veut être fidèle à l'arcade, bin les sprites sont gros...larges en fait. Grizor, le sprite typique est rectangulaire, Toki c'est carré tout de même.
Bien sûr on peu faire comme sur Atari ST : écran plus petit, donc le tout plus petit quoi. Mais euh...le format Spectrum en 256x192...c'est moyen quoi. Il suffit de voire Black Tiger et Strider. Sprites assez gros, mais écran tellement petit que le moindre saut te met hors de l'écran, donc actionne le scrolling, donc rame du cul.
Un écran grand, c'est lourd, mais alors tu n'actionnes pas un scrolling multidirectionnel au moindre saut.
Sinon a ce propos, je sais pas sur quelle base tu as fait ton portage graphique, mais se baser sur la Version Atari ST me semble judicieux car elle fut exécuté avec un écran réduit justement passque même l'Atari ST avait du mal avec un tel jeux (de par le manque de soutien Hardware pour les sprites et ce genre de truc...)
Et en général, l'Atari ST est plus facilement "compatible" graphiquement avec un Amstrad de par la résolution standards sur la même échelle (320x200...16 couleurs...) Et pour le son aussi d'ailleurs... Quand je dit que l'Atari ST est presque un CPC en 16 bit...
En tout cas il me semble qu'un Black Tiger serait sans doute plus aisé à faire car moin le côté tirs multidirectionnels...ça allège tout de suite niveau spritage..et les sprites sont plus petits aussi...)
Inscription : 20 Août 2007, 18:21 Message(s) : 5003
le projet m'intéresse bien, y'a du potentiel Si t'arrive a rendre les tiles et les sprites de toki & ennemies en 16 couleurs je suis prêt a te monté ca ! Parcontre l'intérêt , c'est de faire quelques chose de diffèrent ( par la création de nouveau niveaux ) et pas simplement de faire une adaptation 1:1
Mh... J'avais commencé à refaire les musiques de la veersion amiga sous starkos, contactez moi si jamais le projet prend forme (on peut aussi prendre la version ST mais je la trouve pas géniale)
Perso, le format 256x256 (mode1 eet équivalents mode0) me semble assez adapté pour les conversions arcades. C'est du full screen vertical à peu presque carré de surcroit me semble t'il. Idéal en tout cas pour les jeux de platform multidirectionnels (scrools vertic et horiz)
Par contre ça fait un peu plus que du 320x200 niveau nombre de pixels si je ne m'abuse donc peutr ête un poil lourd pour le CPU ? 256*256 = 65536pix 320x200 = 64000pix... opf peut être qu'en grapillant 2 lignes (une en haut et en bas) donc 256x240 = 61440pix...on arrive à un bon compromis...
les speccy ports étaient souvent en 256x192=49152pix... Mais avec aussi un hud faisant facilement 1/4 de la hauteur de l'écran, voir 1/3 si vertical. soit un écran tout petit.
et il me semble que faire une fenètre de jeux aussi petite c'est mal, déjà passque minuscule mais aussi passque si tes sprites sont "relativement" gros, bin au moindre saut ça oblige le jeux a scroller verticalement. Voire strider par exemple. au moindre saut tu sort de l'écran et ça chie niveau scrolling, alors qu'avec un écran plus grand, bin franchement y'aurait bien moins de scrollings à activer.
à voir donc.
Fano me dit souvent que 256pix (en mode 1, 128 en mode 0) c'est une optimisation niveau code et tout et tout.
ça marche aussi en vertical ?
y'a t'il des jeux qui utilisent cette résolution ?
sinon superbe le remake, trés cartoon, j'adore.
Pour Black Tiger : moi j'avais fait des essais graphiques en mode 1 donc en vue de corriger la version existante. Après le moteur me semble irrécupérable donc mieux vaut partir sur du neuf c'est clair. Repomper le moteur de Satan par exemple, qui fut au final la véritable adaptation de BlackTiger...sur cpc.
En gros je pensais au départ ce jeux en Mode1 avec des sprites Plus. Genre 2 sprites hards l'un sur l'autre en pseudo mode0...ça fait un pavé carré équivalent de 32x32. largement assez pour faire de beau sprites.
Certe le mélange Mode1 et Mode0 peut faire tache, voir Rick dangerous sur C64 notament (beurk) néanmoins là, les sprites en mode0 ont pleins de couleurs, donc possibilité d'antialiaser assez pour avoir un résultat sympa.
Mais bon, faire le décors en 4 couleurs, ça limite vachement boucoup trop plein au final. En gros je me suis apperçu que pour un portage relativement fidèle à l'arcade, il manque simplement 1 couleurs (voire 2 idéalement) au mode1 pour la fenètre de jeux. Pour le HUD, les rasters sont largement utilisables) Et un jeux plateforme comme ça, l'usage de rasters dans la fenètre de jeux (trojan crypt) bin c'est super limité en fait.
Après bin les sprites Hards, c'est lourd et lent à animer. Donc déjà on ne peut pas avoir des animes fluides, pleines de frames, même tourner le perso dans l'autre sens c'est problématique car y'a pas l'option dans la bank de sprites hards. Animer le personnage du joueur pompe alors plus de slots de sprites que nécessaire et les 16 sprites sont vite trop peu nombreux. Mais pour les bonus, les tirs ou certains petis ennemis c'est nickel bien sûr.
en parlant d'animation : les feuilles de sprites de toki là... Il me semble que économiser un poil plus de frames serait plus réaliste tout de même. Sauf bien sur si on vise une version Cartouche avec plus de 128Ko de Rom... Ou alors une version CPC6256+...
Ou alors une version mixte : un bon vieux 6128+ utilisant à la fois D7 et cartouche 128Ko, et avec de la RAM en plus par rapport à la GX4000 ou 464+ histoire de se donner de la marge.
Sinon moi je pensait à un sprite de Toki mixte. Le corps serait en soft, mais la tete en Hard. Vu que la tête ne subit pas trop de modifs (le casque bien sur, lol) pourquoi pas...
Les sprites Mixtes me semblent un truc a tester en général d'ailleurs.
Mais dans l'ensemble, même si là c'est juste des essais graphiques... Bin utiliser ça tel quel est un gaspillage de bits. la tête peut largement utiliser les mêmes tuiles en position basse ou debout.
Y'a trop de frames pour la marche. Et faire le sprites dans les 2 sens (gauche ou droite) bin une routine pour inverser en soft est plus plausible aussi (voir rick dangerous) vu la taille des sprites. Autant pour les sprites genre une arme dans une main et un bouclier dans l'autre, ça m'a toujours énervé (black tiger qui arrive a changer de main son bouclier, ou a le mettre dans sa poche quand il monte un poteau, lol), autant quand y'a une arme a 2 mains ou pas d'arme, le sprite estp lus facilement réversible.
mais on n'en est pas encore là je suppose...lol.
Ast et son Mario : il a besoin de quoi ? il me semble qu'il cherchait surtout des types pour le son et la musique ?
Après c'est clair que ce genre de jeux serait bien plus commodes à faire sur amstrad+ car sprites plus petits et moins animés. Wonderboy2 serait un bon modèle de jeux alors.
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 14 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