Inscription : 13 Jan 2010, 14:25 Message(s) : 2270
C'est vrai qu'à la base, l'idée est de faire Monkey2 pour CPC+. Maintenant, vu qu'il faut reculer pour mieux sauter, il est plutôt normal de commencer par Monkey 1. Mais il ne faut pas oublier que c'est l'objectif final !
Les raisons sont forcément d'ordre logiques et techniques, et je laissera Megachur s'exprimer à ce sujet, si besoin est.
Je vais donc étudier au mieux Monkey1 puis ouvrir un thread concernant le cahier des charges pour une version CPC.
Je compte sur Megachur pour me faire parvenir toutes infos techniques relatives au moteur, afin ne pas avoir les yeux plus gros que le ventre tout en restant ambitieux.
Inscription : 12 Juin 2008, 20:29 Message(s) : 1709
bon, la conversion du code avance doucement...
En fait, hormis les opcodes/script, y'a pas tellement de code à convertir finalement sur la masse des sources... cependant deux trucs m'occupe beaucoup : 1) faire le tri dans le code pour savoir ce qui est important à convertir et surtout exclure (soit parce que ça correspond pas à la version de monkey 1, soit parce que c'est inutile sur cpc) ! De plus, une partie du code sert juste à initialiser ou réinitialiser le moteur... et la plus part du temps on est en one shoot sur ce projet car on exécutera un jeu par exe... de plus certaines structures prennent énormément de place en mémoire... donc il faut bien les simplifier un peu...c'est là qu'on voit que les codeurs d'aujourd'hui ne font plus attention à ce genre d'optim ! 2) et faire attention au fonction qui appelle une autre fonction, qui appelle une autre fonction et au final la dernière fait juste un return(function4())... surtout qu'avec le code dont on a pas besoin autant appeler directement function4()...
Sinon également, scummvm charge tout en mémoire (toutes les rooms, gfxs, etc...) donc sur certaines fonctions, il faudra que j'adapte certaines choses dans le code pour que ça marche...
Comme vu avec TotO, l'écran de 320x200 en 4 couleurs sera divisé ainsi dans un premier temps : - Playfield : 320x144 (40x18 caractères) - Current action : 320x8 (40x1 caractères) - Interface : 320x48 (40x6 caractères)
je vais d'abord faire tourner le moteur sur les scripts/opcodes. ne pas trop me soucier des sprites (afficher des carrés blancs s'il faut), mais surtout afficher les dialogues pour voir si le moteur marche bien...ensuite on verra pour le reste !
Suggestion pour tout le monde : attendez que le moteur soit porté integralement par Megachur, pour ensuite seulement commencer à planifier quoique ce soit.
Bon, les "skins" des décors sont quasiment tous transcrits au format "320x200x4" non pas CGA mais bien mode 1 par moi même...
vu que je sux en coding, je ne peux que faire en format PC modern... on m'a dit que le PNG c'est déjà bien...
et honnètement, c'est déjà plus beau (en théorie) que sur du CGA (avec 2 palette fixes et seulement le noir de customizable...muyarf...)
Surtout que j'ai "forcé" pour trouver un panel de palettes variées...
Selon moi, le gros problème sera le côté...128K-16K de réellement dispo à l'instant T...
et 3,3mghz au lieux de 8-12mghz...
Ah si Sugar avait sortis un 6256 au lieux d'un 6128...
Sur 16 bit, on est à 32Ko l'écran/VRAM minimum (320x200x16...voire plus... VGA =64K, non ?) et ça fait déjà 5 D7 facile... D'accord nous on est en 16K par écran... sauf que euh...on n'est pas à la moitié en RAM total mais au 1/4 512 / 4 = 128... ?
Donc euh... faut espérer que la gestion de base (Textes et autres) prenne pas trop, et surtout les Sprites et scrolls...
Et bon, on vas déjà voir avec une chiée de loadings...
Mais en 3 D7 en 720Ko c'est logiquement trés jouable.. arf faudra pas trop y aller sur le son, non ?
Sachant que euh... on peut raidsonnablement diviser par 2 les frames d'anims, non ?
Sinon dans le cas de monkey 1... il me semble que le tableau le plus "gros" fait 1008x144... voir le fichier joint... Après j pense que y'a pas trop de scripts dans ce tableau, à voir...
Donc entre le scroll, le fait que euh... c'est pas trop géré par tuiles répétables (à voir...)... on est à 3.15 écrans en largeur... 16K x3... 48K dans les dents... en comptant large car en fait c'est des écrans (Datas) de 320x144...le reste c'est du texte... Mais y'a aussi les sprites, qui sont vites gros en, surface non ? (Soft oblige...) Scripts et sons aussi à terme... Arf...
Bof, sur 128k (6128 bien sûr...) ça devrait aller... à voir... Moi j'y jouait sur disk dur avec mon PC EGA 12Mghz et 640Ko de Ram... ça aide..version VGA quand même à la base... 64K par écran...lol même si le EGA transférait ça à l'arrache...en 32K...beurk...)
Et tant qu'a faire, si ça load, autant compacter...on est plus à 2-10 secondes près...
Mais graphiquement ça sera toujours mieux que sur un bon vieux PC XT 8mghz en 512Ko CGA...quoique...
Juste euh... prévoir de bien gérer les doubles lecteurs... (3" et 3"1/2...un de chaque minimum, non ?)
Le scumm sur C64... c'était Zakmac...maniac mansion aussi... Monkey 1 est 2 générations au dessus..voire 2et demi ou 3... (loom et indy3...entre temps...).mais si on fait abstraction des loadings... le CPC peut largement gérer niveau graphismes pures...
Bon courage aux codeurs de la part d'un porteur graphics de la Alphatest version CGA-Mode1... Si dieux le veux...
Ah oui, dde mémoire, sur un PC (donc full soft niveau sprites et scrolls...) ça ramait du cul sur un 8mghz pourtant 512K + CGA... Donc euh... pas gagné sur CPC...pour avoir une superbe jouabilitée... et même sur Amstrad PLUS...lol...
Reste la question piège : vas t'on implémenter la souris Amstrad ??? Bon déjà si on table sur les actions modernisées donc 9 actions max... c'est déjà une optimisation, permettant les raccourcis claviers (touches F1-F9...)
Enfin on s'en branle que ça soit fluide, faut juste que ça soit expressif un peu mais surtout jouable (donc que ça marche...) dur dur...
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
Inscription : 13 Jan 2010, 14:25 Message(s) : 2270
A 2h30, il vaut mieux dormir que de déballer toutes les fractions de pensées restantes de la journée en vrac sur un forum sensé être "constructif" ...
--- Haaaaa, refaire le CPC ... S'il était à 8MHz, s'il avait eu un lecteur 3.5", s'il avait eu une palette un peut plus importante, et si le CPC+ avait été 16bit ... Bingo !!! Le CPC idéal n'est rien d'autre qu'un Atari STf. point. A mon avis, il est plus vite fait et plus cool de partir de ce dernier et voir pour lui carrer la ROM BASIC et Parados dans le fion. ---
Pour revenir à tes remarques sur les limitations, il faut voir que le jeu est sorti en 1990, et pourtant il tourne sur des vieilles bécanes CGA datant d'avant le CPC !!! Le jeu complet se lance sur un 8088XT (8bit) à 4,7MHz avec 512Ko de RAM. (rien ne dit qu'il ne fonctionnerai pas sur une machine avec 256Ko, je n'ai juste pas trouvé moins)
De plus, le jeu étant donc sorti en 1990, il a probablement été codé en C. Le fait de passer le tout en assembleur permet la aussi des gains non négligeables aussi bien niveaux performances que mémoire. Et après, comme tu le remarque, il y a aussi des optimisations au niveaux des animations afin de gagner en fluidité. Mais on en est pas encore là ...
Sachant que les décors sont des écrans fixes appelés à scroller occasionnellement, c'est ce qui permet de pouvoir rester en 320x200 sur CPC ... Mais le scroll se fera comme sur PC "old", au caractère. C'est pourquoi, il serait peut-être intéressant de stocker les décors sous forme de "map". (a vérif)
Coté son, ne crois pas que ça prend de la place ... 4Ko de RAM est suffisant pour jouer une musique et autant pour en stocker plusieurs compressées. Du coup, réserver une banque de 16K pour le son, c'est royale.
Je n'aborde pas la partie "controles" pour le moment, c'est encore sujet à dérive du topic.
Inscription : 12 Juin 2008, 20:29 Message(s) : 1709
norecess a écrit :
Suggestion pour tout le monde : attendez que le moteur soit porté integralement par Megachur, pour ensuite seulement commencer à planifier quoique ce soit.
Car je pense que c'est toujours impossible
bon, puisque tu insistes -> et moi je pense que c'est impossible que tu sortes une nouvelle démo sur cpc old !
Inscription : 12 Juin 2008, 20:29 Message(s) : 1709
Pour les contrôles : je pense qu'à minima il y aura curseurs et joystick !
pour la souris : par contre, il faudra que je trouve des infos pour savoir comment coder le driver (si quelqu'un sait déjà le faire on gagnera du temps ?) !
pour les chargements : on verra mais ma routine de chargement est déjà très rapide...de plus gérer deux lecteurs ne pose aucun pb ! on pourra même lire des tracks plutôt que des secteurs pour aller encore plus vite ! Targhan pourra peut-être m'aider un peu si besoin ?!? Cf Midline process et son chargement, affichage + music en même temps !!! De plus, on peut se permettre de faire un micro-loading à chaque changement de room si nécessaire (ça pénalisera quand même pas trop pour un jeu d'aventure). ce serait juste dommage de couper la musique en fait ! Et c'est vrai qu'à certains endroits on a 4 ou 5 possibilités de déplacement, difficile de tout précharger !!!
pour le scroll : effectivement, je pense qu'on les ferra avec le CRTC au caractère (de manière plus fluide qu'un PC ou même la version amiga qui n'utilise pas du tout les chipsets de la machine ) On ordonnancera les données des décors en fonction de l'affichage pour effectivement un tile caractère (par bande de 1 octet) et une bonne idée !
pour la mémoire : ce qui prendra de la place c'est effectivement les costumes et les textes... j'optimise directement cela pour l'instant pour ne pas être trop gourmand (pas comme le code original de scummvm en c++ qui gaspile à fond du cpu et de la mém mais c'est vrai que sur un pc à 3,02Ghz avec 2 giga on le voit même pas !) je pense même faire une routine d'allocation mémoire ce qui permettra de voir si on dépasse la mémoire possible (en fait j'en ai déjà une mais j'hésite à l'activer pour ne pas pénaliser les performances ... peut-être sera-t-il intéressant de l'activer et si on dépasse pas la limite de mémoire fixée : la desactiver si pb de peformance ...)
déjà généralement on peut coder cela calc_diff = diff * 60 / 1000 et ensuite on codera également en essayant de réduire la division... calc_diff = diff * 3 / 50 puis après VAR(VAR_TIMER) = calc_diff et VAR(VAR_TIMER_TOTAL) += calc_diff
Je vais probablement me faire passer à tabac, mais je suis un peu inquiet quant à la capacité du CPC à faire tourner Monkey 1. J' y ai rejoué pour voir sur Steem (toujours aussi drôle même si je le connais par coeur). Hé bien le ST avait du mal (notamment dans le SCUMM Bar) , j'ai du pousser le 68000 (virtuel) à 16 mhz pour que ça soit agréable. Certes je l'avais fait sur 386 25 mhz à l'époque (avec 4 MO de ram). Il est également vrai que si c'est du C avec des trucs style variable2 =variable1 * 60 / 1000, compilé tel quel en motorola (je parle toujours de la version ST), bon ça peut expliquer la lenteur, et je suis d'accord qu'une réécriture du moteur en ASM avec optimisation peut rendre l'adaptation possible sur CPC, mais quel boulot !
D'ailleurs ça me rappelle quand j'étais à Port Royal, avec Carla, elle venait d'en embrocher deux puis elle me dit... Oups je m'égare !
Heu, à part ça si je puis me permettre une suggestion, je virerais tout ce qui est scrolling pour me contenter d'écrans 16 k [EDIT : écrans de moins de 16 k en enlevant l'interface et la barre de texte ] (compressés sur disk) à charger, et de soigner les sprites. Pas pour des mauvaises raisons genre les capacités du cpc à scroller (je sais qu'il peut très bien le faire aux registres 12/13), mais dans le but d'économiser au max la mémoire. Parce que c'est ça qui m'inquiéte le plus : la ram ! 128 dont 64 à aller chercher en jonglant avec les banks ! D'ailleurs, est il prévu d'utiliser deux pages écrans en flip ?
Autre chose : la version ST n'a que rarement de la musique, pas tout le temps comme les versions PC qu'ils avaient améliorés après (VGA et CDROM). Et elle demande très souvent de changer de disquette !
Pour terminer, je tiens à vous dire que je trouve votre tentative d'adaptation remarquable et ça serait un beau coup qu'il y ait une version CPC et CPC+ de Monkey1. Même si j'ai bien peur que ma dernière phrase (qui est sincère) ne m'évite pas le lynchage ! Je n'essaierai même pas de m'échapper avec le coup du singe à trois têtes...
Inscription : 12 Juin 2008, 20:29 Message(s) : 1709
@Xifos :
Bonjour et bienvenue pour échanger sur le projet !
non, je ne pense pas que cela soit fou (ou encore impossible comme dirait et répeterait NoRecess )...
en fait, même, si on regarde des jeux comme capitaine blood, defender of the crown, iron lord, bat (1 ou 2 ?) et j'en passe qui ont fait l'objet d'une conversion sur cpc... Je pense qu'elles ne sont pas si mal que ça pour des jeux d'aventures/actions... même si Iron lord charge souvent et lentement !!! LucasArt qui est une boîte américaine n'a tout simplement pas investi sur le cpc (contrairement au c64 par exemple)... Je pense d'ailleurs qu'à l'époque (et même maintenant), si on pouvait disposer des sources originales (même en asm) cela nous ferrait gagner bcp de temps plutôt que de convertir le c++ de scummvm en z80 !!!
c'est un projet ambitieux mais pas irréalisable !!! là j'en suis à l'exécution des scripts après le codage du clavier (viendra ensuite celle des opcodes)... et on va vite voir si c'est réaliste...de faire tourner cela à 4Mhz... c'est plus le temps qui nous manque à tous je crois, que l'envie de faire ce type de conversion sur notre cher cpc !!! si en plus on retrouve le filling de l'original ... quelle joie de jouer à ce jeu sur cpc !!!
Je viens de le reterminer sur ST (Steem) "Je n'en reviens pas de ta virilité" "Et moi je n'en reviens pas de ta fragilité !" Enfin bref !
J'ai repensé à cette histoire de scrolling. Me demande si on peut pas faire une routine qui va charger les écrans par bandes de 16x144 pixels (16xhauteur écran de jeu). Donc tenter quand même un scrolling en chargeant une bande supplémentaire et en scrollant au CRTC, mais faut donc une rupture... Mais le SCUMM en lui même j'ai peur que ça soit RAMivore...
Sinon les conversions de Blood, Iron Lord et Defender of the crown étaient superbes, oui. Bonne continuation ! (smiley de pirate) (et arrête d'embêter mon rat)
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 49 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