Inscription : 12 Juin 2008, 20:29 Message(s) : 1726
Pour moi qui suit codeur, je ne vois pas de problème pour le code (point_of_click, scrolling, gestion de mémoire sur un 128ko, etc).
Par contre,
1) Ripper tout les graphismes (sprites+décors), les convertir au cpc... ça, ça devrait prendre bcp de temps.
Vu le peu d'animation, à voir si on ne peut pas utiliser le mode 5 (mode 1 ou 0 avec changement de couleur par ligne comme expliqué dans un autre thread)...même si ça nous gache du temps machine, cela pourra peut-être amélioré le rendu gfx !
2) Reste également à récupérer toute la map des éléments/personnage qu'on peut activer sur le décors et toutes les interactions possibles -> l'idéal serait de récupérer et de ne refaire que la partie codel (il y a peut-être des docs avec l'émulateur des jeux lucasart scrumm je crois ?) Une autre piste serait d'avoir les sources 68000 (d'amiga par exemple) que l'on convertirait en z80 pour être au plus proche du jeu original !
Si quelqu'un à des infos sur les points 1) et 2) on pourra passer à la partie team bulding et développement assez facilement !
qui n'en veut ?
P.S : je peux déjà proposer une routine FDC de lecture ultra rapide pour les chargements !
The SCUMM virtual machine is made up of a number of sub engines working together. Strictly, the term SCUMM only refers to the scripting language itself. The official term for the virtual machine as a whole is SPUTM --- but getting people to change is probably a lost cause.
Here are all the engines used by the SCUMM virtual machine.
SPUTM The 'real' name for the engine, SCUMM Presentation Utility (TM). SCUMM The actual scripting language. IMUSE The MIDI control system, allowing dynamic music. SMUSH A movie compression format and player. INSANE The event management system used in V7+ games. MMUCAS The memory allocation system used in The Curse of Monkey Island. V8 only.
Si on fait une conversion, en plus, cela ouvrirait la porte à plein d'autres jeux : Some of the adventures ScummVM supports include Adventure Soft's Simon the Sorcerer 1 and 2; Revolution's Beneath A Steel Sky and Broken Sword I & II; Flight of the Amazon Queen; Wyrmkeep's Inherit the Earth; Coktel Vision's Gobliiins; Westwood Studios' The Legend of Kyrandia and games based on LucasArts' SCUMM (Script Creation Utility for Maniac Mansion) system such as Monkey Island, Day of the Tentacle, Sam and Max and more. You can find a thorough list with details on which games are supported and how well on the compatibility page. ScummVM is continually improving, so check back often. ou bien http://wiki.scummvm.org/index.php/Datafiles pour la liste plus complète
attention, le scumm c'est moteur créé sur c64 pour maniac mansion et qui a été porté sur des bécanes plus puissantes pour tous les jeux d'aventures lucas (le dernier l'utilisant doit être monkey island 3). maniac mansion et zak mac kraken existant sur c64, eux sont portables. c'est là ou l'on regrette que lucas n'ait pas bossé sur cpc/spectrum autrement que par des portages genre us gold. scumm gère tout apparemment, y compris les musiques. porter scumm en z80 ne serait-il pas la 1ère chose à tester ?
scummvm c'est à la base un émulateur de la machine virtuelle scumm qui entre-temps a appris à gérer d'autres jeux non-scumm (simon sorcerer, les titres coktail de gobliiins à woodruff en passant par bargon attack, du delphine software et même des point'n'click de série B où souvent les auteurs ont eux-mêmes communiqués leurs sources à l'équipe) en offrant des optimisations sur les titres en midi, des philtres graphiques ... bref c'est devenu une énorme machine de guerre qui gère même parfaitement des titres assez poussés bien loin du scumm comme discworld 2 ou les 2 1ers chevaliers de baphomet. et scummvm consomme pas mal.
Inscription : 13 Jan 2010, 14:25 Message(s) : 2282
Je ne voulais pas aborder le sujet, mais puisqu'on y est ...
SCUMM (Script Creation Utility for Maniac Mansion) est le coeur même de nombreux point&clicks signés Lucas Arts.
Ce script décrit tout le déroulement du jeux et ses interactions, ainsi que la gestions des ressources (graphismes, sons, textes, objets, etc)
Ainsi, une fois le moteur porté pour une CPU (le 68000 par exemple), il reste à chaque équipe de développement à coder les lib graphiques, les banques sons, etc. propres aux machines "compatibles". (Mac, Amiga, Atari)
Plus le jeu est récent, et plus la version du script est élevé, et donc enrichi en fonctionnalités et lourd à gérer :
- 1987 / v1.x : Maniac Mansion - 1988 / v2.x : Zak McKracken, ... - 1989 / v3.x : Indiana Jones & The Last Crusade, ... - 1990 / v4.x : The Secret of Monkey Island, ... - 1991 / v5.x : Monkey Island 2: LeChuck's Revenge, ... - 1997 / v8.x : The Curse of Monkey Island !
Du coup, il est évident de devoir commencer par porter SCUMM pour Z80. Et à vrai dire, je n'ai jamais rien trouvé de tout cuit !
En suite, l'autre gros du travail consiste évidemment à convertir tous les graphismes et animations possibles au format CPC / CPC+. Quand on regarde la version PC et Amiga de MI2, on voit bien qu'il y a un allégement niveaux effets spéciaux (orages dans le cimetière, etc) ; Il est donc possible d'adapter le script pour réduire ce qui n'est pas gérable sur une machine moins puissante ... Tant qu'à faire, sans dénaturer le jeu. Quand je regarde le longplay sur youtube, je me dis qu'il doit falloir des années à une seule personne pour tout convertir ; a moins d'utiliser une "moulinette" pour automatiser le plus gros du travail.
Finalement vient le travail du musicien, qui doit recomposer et recréer toutes les musiques et bruitages nécessaire pour le jeu. A moins de créer un moteur MIDI (et encore ?), pas de salut possible ...
Evidemment, le codeur devra créer de nouvelles routines d'affichages pour gérer décors (plusieurs plans ?), animations, et sprites ...
De la, j'ai certainement oublié de décrire 90% du travail à réaliser ... Je dirais donc juste : GOOD LUCK !
Inscription : 20 Août 2007, 18:21 Message(s) : 5103
PJA de Demoniak qui demande qu'a être utiliser ... une modification du code pour utiliser le mode 0/cpc+ ne devais pas être bien difficile ... Hey Demoniak ?
Inscription : 13 Jan 2010, 14:25 Message(s) : 2282
Certainement très bien pour faire un nouveau jeu ; Mais dans le cas d'un portage, ça serait 10x plus de boulot que porter SCUMM à mon avis.
EDIT :
Quitte à porter "SCUMM" sur Z80, peut-être serait-il plus intéressant de créer un compilateur pour ce "langage" plutôt que l'interpréter, afin de gagner en performances ?
Inscription : 12 Juin 2008, 20:29 Message(s) : 1726
oui, le portage de SCUMM permettrait de ne pas avoir à tout réécrire au niveau script/interaction perso/objet, etc... et de ne se concentrer que sur le customing cpc -> gfx, musique et adaptation spécifique moteur gfx si nécessaire
On sait par ailleurs désormais que du code c est portable sur cpc, donc on peut partir de la version c puis après progressivement optimiser le bousin... Quand on voit la version amiga, du bon c compiler sauce 68000... qui saccade quand ça scroll (quand on connait les possibilités de la machine ) cela n'a rien enlevé à l'aventure !!!
Bon, je propose qu'on passe donc au team bulding ?
Leader, Co-Leader (en gros ceux qui organisent le bousin) graphiste, codeur, musicos designer, testers, etc...
Je propose en producteur exclusif, le roi de la bidouille et du hack -> HERMOL avec support de son forum pour les échanges et puis bien sur Google avec Google Code pour stocker tout le bouzin des sources et du dév faut bien que Google nous aide, non ? Vu que c'est le plus gros...
Inscription : 12 Juin 2008, 20:29 Message(s) : 1726
Euh, oui, euh... sinon faudrait juste se donner quand même une limite -> genre 2012 pour sortir le bousin au plus tard... sinon on est parti pour 10 ans !
Inscription : 13 Jan 2010, 14:25 Message(s) : 2282
Pour faire avancer le schmilblick ...
Playfield : 20x18 (Mode 0) --------------------- Affichage en double buffering / Sprites softwares : - Une table pour le décors d'arrière plan - Une table pour les éléments du premier plan (à afficher avec masquage si nécessaire) - Une table pour les paths/collisions/éloignement (0=collision ; 1-7= éloignement) - Gestion de l'affichage des dialogues (sprites hards à la volée ?)
GUI : 40x7 (Mode 1) ---------------- La première zone indique les actions (40x1) La seconde zone affiche les interactions (40x6)
Utiliser uniquement les sprites hard pour l'interface : - 1 sprite en mode 1 pour le pointeur - 15 sprites en mode 0 pour les objets (3 lignes de 2/3 sur 5 colonnes de 4/5 d'objets)
Avec cela, on peut avoir un affichage semblable aux moke-ups et gérer convenablement le jeu :
EDIT : Maintenant, j'ai un peut oublié les perso dans l'histoire ... 32 couleurs en mode 0 c'est pas possible ?
Je pense que respecter exactement le mockup pour l'interface serait un gaspillage...
Indiana Jones 3 par exemple était entièrement texte pour l'inventaire si j'ai bonne mémoire. Et vue que pour Monkey2 ils ont simplifié les action (de pleinpleins a seulement 9...) et ils ont appliqué cette optimisation aux version ré-éditées d'ailleurs...
Monkey 1 avait aussi la vieille interface d'Indy 3...
ça c'est la version EGA je suppose..?
Bref, passer en mode "texte seulement" pour l'interface/inventaire permet déjà de virer une chiée de Datas, car plus de sprites Hards si lourds...et un truc en simple mode1 ce qui suffit largement.
Sinon bin 2 bandes horizontales (et non 2 colonnes...) donc les actions en mode1 (sur toute la largeur de l'écran) puis les inventaire en simple Mode0 encore...avec juste une autre palette que celle du tableau peut être.
Pour les effet de profondeur des sprites, c'est du "scriptage" des "tableaux"...
les lieux sont en fait plus ou moins une seule grosse image de plusieurs écrans parfois (genre quand ça scroll... latéralement) et assez peinture car pas vraiment de tuilage répétées mais ça peut tout de même se compresser... L'image que j'ai mis par exemple, le ciel possède quand même des coins "tuilés"... Et pas mal d'endroit de l'image sont plus ou moins des cases de 8x8 que l'on doit bien retrouver parfois non ? (le planché ou certaines textures ?)
Concernant le scriptage, ça doit marcher comme Baldures gate... A la couche de fond et celle des sprites, on ajoute une couche logique qui définit les zones ou les Sprites peuvent être (le sol) mais aussi quel sprite ou ensemble de sprites utiliser.
Après bin la profondeur c'est comme pour un jeux de course de voiture, les sprites on toute une gamme de tailles différentes.
Genre normal, petit et trés petit, ça peut suffir... 4 tailles différentes peut être ? sachant que comme ça devient de plus en plus petit, ça tient alors de moins en moins de place mais devient vite difficile a modéliser en Mode0 notament...
Il convient alors juste de designer les tableaux en conséquence...
Pour les effets de premier plan que les Sprites passent derrière...bin idem, il faut être soigneux dans le design des tableau (c'est comme un travail de meteur en scène donc...) et les sprites Hards servent justement à ça, ça serait même plus utile et pratique que de mettre les sprites Hards pour l'inventaire, lol...
Indy 3, un bon exemple justement de l'interface en texte seulement, avec séparation horizontale des actions et de l'inventaire...
Raison toute pragmatique : passer l'interface en 9 actions permet d'utiliser les touches F1 à F9 en raccourcis clavier (donc pas de pointeur dans cette zone, il sera réservé aux écran de jeux) Et la place sauvée de la sorte permettra de caller plus de sprites softs pour les animation justement dans la zone des tableaux.
Quand à l'inventaire, moi je serai pour justement utiliser une séléction par les flèches (clavier) notament, avec surbrillance.
Car le problème de faire un "écran" de 5x3 sprites hards, c'est que chaque fois que tu fouilles ton inventaire (qui contient souvent une chiée d'objets, dans ces jeux là si j'ai bonne mémoiire) bin vu que les sprites Hards servent d'écran complet (de tuiles) c'est super chaud de recharger à chaque décalage dans l'inventaire les 15 sprites... surtout que ça utilise alors une routine "soft" de conversion en format sprite Hard me semble t'il. Tu as tes graphismes (pour chaque objets), puis tu dois en soft calculer ce que doit donner la fenètre d'inventaire, puis convertir en 15 sprites, puis charger ces 15 sprites...euh...
L'inventaire ne doit pas prendre autant de ressources, car on est souvent amené à le faire défiler souvent.
Dernière édition par MacDeath26 le 22 Juil 2010, 18:26, édité 1 fois.
Inscription : 13 Jan 2010, 14:25 Message(s) : 2282
C'est vrai que c'est tout de suite plus jolie en mode texte ... Après, soit tu veux faire un portage fidèle, soit tu fait vite fait un portage comme à l'époque. "speccy". (sachant que tu n'as pas suffisamment de sprites hard pour gérer les animations) D'ailleurs, les sprites hard ne servent que pour l'OSD dans RD+ si je m'abuse ?
Si c'est possible, l'idée serait d'utiliser les sprites hard pour les dialogue dans le playfield, puis les reprogrammer pour afficher l'inventaire ensuite. Du coup je ne vois pas ou est le gâchis ? C'est même plutôt judicieux si c'est réalisable, car on ne vient pas amputer la palette du décore et l'on n'a pas besoin de maskage pour détourer le texte en sur-impresssion.
Si c'est possible, l'idée serait d'utiliser les sprites hard pour les dialogue dans le playfield, puis les reprogrammer pour afficher l'inventaire en suite)
Oui, la gestion des dialogues j'y pensait aussi... Philactères (bulles de BD donc) ou une zone de type bande noire ? avec affichage du portrait ?
C'est pas simple non plus.
mais là l'usage que tu préconises des Sprites Hards me semble encore bien trop lourde... LEs sprites Hards sur CPC+ c'est lourd en Data bruts... et long a changer/charger dans l'Asic...vraiment. Et c'est pas trop un truc en mode texte non plus.
Et l'idée n'est pas de dire tiens on fait du spectrum... Mais juste d'être réaliste. Un Amstrad CPC c'est bien, surtout un Plus, mais c'est vraiment pas un PC 486 VGA... Or moi, j'avais Monkey Island 2 sur mon 486 compaq VGA avec de la mémoire en pagaille, un diskdure, la souris et tout et tout... Que en 1989-91, sur mon PC EGA avec D7 et 512K de Ram, je jouait à Monkey 1 et Indy3...qui avaient justement la version texte de l'inventaire.
En gros je pense que la version3 du SCUMM peut passer, juste en réduisant le nombre d'actions, mais ensuite ça serait se faire chier pour rien de vouloir un super système complètement windows like avec pleins de zolis icones graphiques...
Bref se contenter des Sprites Hards en tant que effets spéciaux, pointeur, tuiles de premier plan... C'est largement suffisant. PAr exemple pour les dialogues... Afficher des bulles de texte dans le playfield peut sembler assez euh...lourd. Donc un sprite hard "portrait" pour indiquer qui parle...ça peut le faire non ?
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 29 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
!
Hey Demoniak ?
faut bien que Google nous aide, non ? Vu que c'est le plus gros... 
