Inscription : 13 Jan 2010, 14:25 Message(s) : 2270
En lisant ton post je pensai moi aussi à Blood, etc. Rien est impossible, ça sera juste au niveau d'un CPC, avec les contraintes que cela représente. Tant que le plaisir de jeu et intact, même "allégé", c'est le principal.
Concernant ce que tu proposes pour le scroll, il me semble qu'on en a justement parlé précédemment. (à moins que ça soit sur le topic Gfx) Enfin, l'idée plus ou moins la.
De toute façon il y a assez peu de scrollings, est c'est pas du smooth au pixel du tout..
En gros que ça scroll abruptement d'un demi écran suffit amplement.
Mais pour un truc comme la scène du scummbar, y'a en fait limite pas besoin de faire un scroll, on peu faire un passage à l'ecran suivant, de même pour pas mal de scènes intérieur en fait..chez la dame voodoo non ?)
Et au final assez peu d'écrans ont un scrolling/font plus d'un ecran de large. quoique...
Mais en gros même un scrolling à la Gryzor, qui fait sursauter d'un demi écran à chaque fois, ça peut largement être bien.
Citer :
Blood, Iron Lord et Defender of the crown
Blood avait en fait assez peu de choses en plus sur 16bit... les voix digitalisées en fait...car trés gourmand donc c'est sur, un Atari avec ses 512K et D7 en 720K ça aide...
Arf, un poil plus d'animations notament pour l'intérieur du vaisseaux, l'espèce de poisson/navette (sais plus leur noms) qui apparaissait.
Iron lord : c'est complètement du transfert au pixel depuis la version 16 bit Atari (peut être PC EGA-CGA d'ailleurs si y'en a eut une) quoique les palettes mode1 eurent put être légèrement mieux choisies.
BAT, Night Hunter, Zombi et Hurlement...Fer&Flammes le maitre "absolu/des ames..."
UBI soft à montré que ces jeux là trés typés 16 bitpouvaient être trés bien fait sur un Amstrad, même si ça en jette moins niveaux couleurs (transfert mode 1) ou animation... Et si on se tape parfois pleins de chargements...
LE Scumm semblant avoir été conçu dans une optique multiplateforme/multijeux, c'est clair que c'est pas toujours optimisé pour telle ou telle machine.
Mais concrètement un Monkey Island doit être plus simple qu'un Zak/maniacmansion : bien moins d'actions (9 seulement puisque on va prendre la dernière version pour le gameplay) ou de personnages.
C'est juste boucoup plus lourd niveau Graphismes et animes...mais de ce côté là les marges de simplification sont assez large.
Bon courage Megachur, j'éspère que mes transferts mode1 te conviennent... logiquement Toto devrait s'occuper du transfert en format CPC non ? à moins que Fano...
Inscription : 12 Juin 2008, 20:29 Message(s) : 1709
Xifos a écrit :
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...
oui bien sûr... si on fait le scroll au crtc il faudra un rupture pour pas que l'inventaire et les verbes des actions scrolls en même temps... ou alors, les mettre en noir, scroller avec le CRTC (afficher les bandes de décors) puis une fois fini, les réafficher ... et hop plus besoin de rupture... (qui a besoin de voir l'inventaire pendant que ça scroll ?) faudra juste réactualiser les coordonnées des box (x,y, xmax, ymax) pour qu'on puisse continuer à cliquer dessus... bon que des idées donc... en attendant, je pourrai toujours faire un ldir bourrin qui va bien pour que ça marche dans un premier temps comme le code original en c sur pc ou amiga ou st pour la RAMivore, j'y travaille... c'est pour cela que ça prend du temps en fait en ce moment sur la partie des scripts...des chargements de ressources, etc... il faut réfléchir avant de convertir/coder et c'est long ...
mais plus c'est long... et plus c'est bon !!! VooDoooo
Inscription : 12 Juin 2008, 20:29 Message(s) : 1709
MacDeath26 a écrit :
Bon courage Megachur, j'éspère que mes transferts mode1 te conviennent... logiquement Toto devrait s'occuper du transfert en format CPC non ? à moins que Fano...
Merci ! Oui j'ai regardé les transferts mode 1 -> cela va être bon...
par contre, comme évoqué il me faudra à chaque fois (ou même des fois plusieurs quand c'est du multi-écrans) un screen de 17 ko .scr et le .pal associé !!!
TotO m'a dit que c'était Fano qui avait tous les outils de conversion dispo... Fano, si tu nous lis !
D'ailleurs, on peut commencer qu'à mettre au format cpc que les premiers screens affichés (logo lucasart, écran de début, la jetée, le port, le scumm bar, etc...) cela sera déjà très bien pour un début puis dès que cela aura avancé les autres !!!
Inscription : 12 Juin 2008, 20:29 Message(s) : 1709
fano a écrit :
Megachur a écrit :
TotO m'a dit que c'était Fano qui avait tous les outils de conversion dispo... Fano, si tu nous lis !
Pas de souci , dis moi vers quel format tu voudrais convertir , au pire si c'est pas dans mon toolkit j'ajouterai
en fait tout simplement les bmps ou pngs en screen ocp de 17ko mais il faut découper certaines grandes images pour qu'elles ne fassent que 320 octets de large !
Euh, petite question bien que je me doute que ça n'est peut être pas encore le bon moment... Comment comptais-tu t'y prendre pour la gestion du Scrolling ?
Enfin en gros tu veux faire scroller de combien à chaque fois ? et quand esque ça actionne le scrolling ?
en effet... (je parle en résolution mode1...pour le mode2, diviser par 2 les nombres de pixels, sachant que ça fait la même surface, enfin ça vous savez...)
Certains écrans font 320pix de large ou moins, donc là y'a logiquement pas de problèmes : y'a pas de scrolling !
Certains écrans sont des multiples de 320...voire de 80.
Ainsi on a des tableauxde 640 de large par exemple soient 2x320... y'a aussi du 3x320... du 480 aussi (320x1.5...)
ceux ci peuvent ne pas trop poser de problèmes en fait. il suffit de penser en blocks de 80pix...soient en 1/4 d'écran.
Si tu est sur l'un des bords/extrémités du tableau, ça scroll plus donc tu peux te balader vers le bout. par contre si tu t'approche de l'autre côté, je pensait que lancer un "freeze"+ scroll de 1/4 d'écran... au moment ou tu arrive au dernier 1/4 d'écran (block de 80 pix) en gros tu arrive au dernier1/4 de l'écran, au moment d'entrer dedans, ça freeze puis scroll... ainsi tu peux toujours fouiller les 2/4 du milieux de l'écran actuel...
Que dans la version originale, le Scummbar par exemple il scroll pas par écrans complets quand tu arrive au rideau ?? Bin je pense que ça peut poser des problèmes ça. Esque les sprites bougent pendant le scrolling (bougent dans le décors en plus de scroller avec lui...) ?
Mais alors y'a des tableau avec des mesures bizares, genre euh...408pix de large (la tête de singe géante...)... comment ça gère le scroll dans ce cas ? esque c'est pas jsute pour une cinématique ? ça serait pas plus simple de carément virer les 8 pixels "en trop" ?
ou 1008pix (le ponton quai du scummbar....arf...)
Mais en gros moi je pensais a un scroll à la manière de GreenBerets... mais dans les 2 sens, lol, voire en plus rapide ?
Citer :
comme évoqué il me faudra à chaque fois (ou même des fois plusieurs quand c'est du multi-écrans) un screen de 17 ko .scr et le .pal associé !!!
Esque ça veut dire que théoriquement, quand on passe a un autre écran complet (dans le cas des décors larges) on peu faire des changements de palette d'un écran à l'autre d'un me^me décors ? bon en mode1 c'est sûr que la marge de manoeuvre n'est pas exploitable, mais en mode0...sur les super dioramas en 3 écrans, il doit bien y avoir moyen de se ménager des changements de couleur en douceur (qui ne se verront pas) en se ménageant une encre ou deux sur la totalité du décors ? avantage alors de faire des à-coups par quarts d'écrans...
Citer :
mais il faut découper certaines grandes images pour qu'elles ne fassent que 320 octets de large
on est en mode1... 1 octet = 4 pixels... donc 320octets = 1280pixels ?... donc 160 cases ? divisé par la hauteur ?
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
Inscription : 12 Juin 2008, 20:29 Message(s) : 1709
MacDeath26 a écrit :
Euh, petite question bien que je me doute que ça n'est peut être pas encore le bon moment... Comment comptais-tu t'y prendre pour la gestion du Scrolling ?
Enfin en gros tu veux faire scroller de combien à chaque fois ? et quand esque ça actionne le scrolling ?
en effet... (je parle en résolution mode1...pour le mode2, diviser par 2 les nombres de pixels, sachant que ça fait la même surface, enfin ça vous savez...)
Certains écrans font 320pix de large ou moins, donc là y'a logiquement pas de problèmes : y'a pas de scrolling !
Certains écrans sont des multiples de 320...voire de 80.
Ainsi on a des tableauxde 640 de large par exemple soient 2x320... y'a aussi du 3x320... du 480 aussi (320x1.5...)
ceux ci peuvent ne pas trop poser de problèmes en fait. il suffit de penser en blocks de 80pix...soient en 1/4 d'écran.
Si tu est sur l'un des bords/extrémités du tableau, ça scroll plus donc tu peux te balader vers le bout. par contre si tu t'approche de l'autre côté, je pensait que lancer un "freeze"+ scroll de 1/4 d'écran... au moment ou tu arrive au dernier 1/4 d'écran (block de 80 pix) en gros tu arrive au dernier1/4 de l'écran, au moment d'entrer dedans, ça freeze puis scroll... ainsi tu peux toujours fouiller les 2/4 du milieux de l'écran actuel...
Que dans la version originale, le Scummbar par exemple il scroll pas par écrans complets quand tu arrive au rideau ?? Bin je pense que ça peut poser des problèmes ça. Esque les sprites bougent pendant le scrolling (bougent dans le décors en plus de scroller avec lui...) ?
Mais alors y'a des tableau avec des mesures bizares, genre euh...408pix de large (la tête de singe géante...)... comment ça gère le scroll dans ce cas ? esque c'est pas jsute pour une cinématique ? ça serait pas plus simple de carément virer les 8 pixels "en trop" ?
ou 1008pix (le ponton quai du scummbar....arf...)
Mais en gros moi je pensais a un scroll à la manière de GreenBerets... mais dans les 2 sens, lol, voire en plus rapide ?
Citer :
comme évoqué il me faudra à chaque fois (ou même des fois plusieurs quand c'est du multi-écrans) un screen de 17 ko .scr et le .pal associé !!!
Esque ça veut dire que théoriquement, quand on passe a un autre écran complet (dans le cas des décors larges) on peu faire des changements de palette d'un écran à l'autre d'un me^me décors ? bon en mode1 c'est sûr que la marge de manoeuvre n'est pas exploitable, mais en mode0...sur les super dioramas en 3 écrans, il doit bien y avoir moyen de se ménager des changements de couleur en douceur (qui ne se verront pas) en se ménageant une encre ou deux sur la totalité du décors ? avantage alors de faire des à-coups par quarts d'écrans...
Citer :
mais il faut découper certaines grandes images pour qu'elles ne fassent que 320 octets de large
on est en mode1... 1 octet = 4 pixels... donc 320octets = 1280pixels ?... donc 160 cases ? divisé par la hauteur ?
En fait, on peut imaginer plusieurs types de scrolls :
- soit le scrolling original -> je bouge l'écran par octet = scroll au caractère comme disent les anciens (ce qui peut être fait avec le CRTC) -> mais attention, cela veut dire continuité dans les écrans au niveau couleur !!! - soit un scrolling par tranche... moche mais efficace, à la vas-y que je te fais un ldir comme dirait un codeur z80 !!!
ce qui est sûr -> il faudra conserver les mêmes couleurs pour le sprite principal pour les écrans (d'où l'intérêt du mode 0 par rapport au mode 1 je pense) sinon cela ferra moche ! -> le scrolling par octet semble le plus facile et moins moche qu'un scroll par tranche... -> comme je le disais, pendant le scroll, on peut ne pas afficher les verbes et l'inventaire pour utiliser un scroll 'smouss de chez CRTC inside of CPC !!!
bon, pour le reste, autre solution, je mets l'écran en noir... j'affiche le nouveau décors, le sprite et hop on remets les couleurs ?!!! facile non ?
Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
Megachur a écrit :
-> comme je le disais, pendant le scroll, on peut ne pas afficher les verbes et l'inventaire pour utiliser un scroll 'smouss de chez CRTC inside of CPC !!!
Je pense qu'effectivement c'est une bonne solution car ça permet de faire un scroll Hard (R12&13) sans avoir à faire de rupture qui peut être consommatrice en mémoire supplémentaire. Pour être honnête , je ne pense pas que les splits raster d'un écran sur l'autre seraient une bonne idée.Une palette globale par scène (qui inclue évidemment des couleurs fixes pour le personnage et certains objets) je trouve ça déjà pas mal.
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
[quote="MacDeath26"] - soit le scrolling original -> je bouge l'écran par octet = scroll au caractère comme disent les anciens (ce qui peut être fait avec le CRTC)
Si c'est à l'octet c'est pas au caractère Au caractère c'est au WORD (2 octets) ce que fait effectivement le CRTC.
Bin c'est sûr que pour les solutions techniques, je n'ai pas trop mon mot à dire... Donc faisez comme vous le sentez... Il y a assez de contrainte de mémoire (scripts, chié de sprites, textes et effets, voir le décors en lui même...ouille...) donc le confort des graphiste, on voit ça en dernier lol...
un scrolling smooth...bin sur 16bit c'était pas trés fluide à la base il est vrai. Après je sais plus trop comment il gérait le traveling... en gros a partir de quand il l'enclanche. Il me semble que ça variait en fonction des décors, ou des cinématiques.
Voir la map que j'ai mis en fichier joint (version VGA...) En gros :
3x320 pix...soient 12 quarts de 80pix...
sur le bord gauche (4 premières cases), on a de la verdure, une baie ensoleillée avec sable et ciel azur, mer elle même azure...
Si on passe en vision du milieux (centré sur les cadavres empalés...) bin déjà y'a plus la mer, et y'a plus de verdure du tout. La fôret devient sombre et glauque.
quand à l'extrémité à droite, l'ambiance devient mystérieuse, magique et violette... Or entre ses 2 ambiances (gauche toute et droite toute) trés différentes, on passe par 1 écran complet donc plusieurs séquences de scrolling si on fait scroller par exemple par batches de 80 ou 160pixels...
et à bien y regarder, seuls les 3 premières "cases" à gauche utilisent du vert et encore la 3ème case du base n'en utilise quasiment pas, lol...
Donc ces 2 couleurs (admettons qu'on utilise seulement 2 verts...) bin on a ensuite 5 quarts d'écran sans vert...ni violet vif...et même avec finalement assez peu de couleurs (boucoup de noir, et du bleu violassé...gris...) ce qui peut laisser une "fenètre" afin de caser un "changement de palette" pour préparer soit au retour au vert (si on se déplace d'un quart vers la gauche, soit en violet vif si on vas vers la droite... Les violets vifs (roses, un peu) étant eux même utilisés que sur les 4 dernières cases...
car vu le mode de déplacement en point and click, on ne peut pas forcément faire un scroll smooth et continue d'un bout à l'autre... on arrive au bord/déclencheur de scroll... et ça avance d'un "cran" et attend qu'on re-clique pour re-avancer...non ?
Disont que on peut admettr que cliquer sur le bord de l'écran enclanche une mini cinématique, donc Guybrush vas aller se placer en début d'un nouvel écran pendant que tout ça scroll vite fait (il me semble que c'est comme ça que ça se passe dans le scummbar...).
Bon, pour les sprites qui gardent obligatoirement la même palette, ça je m'en doute. Mais guybrush prendrait disons...opf...7-8 couleurs maxi me semble t'il. Sachant que Noir et Blanc sont forcément casables sur la map..communes) et le gris aussi peut être.
ça fait qu'on peut imaginer donc que un scrolling par a-coup genre ce qu'il y a dans GreenBeret (après je ne sais pas comment c'est fait je vous l'accorde) avec le sprite qui se freeze pendant que ça défile... bin on doit bien trouver un moyen de changer quelques encres (un paire) et ainsi corriger un poil la palette pour l'autre extrémité du décors...
Après esque changer une encre oblige par exemple à ...effacer tout l'écran ? comment on fait les effet de rotations de couleurs alors ?
ça utilise le même slot d'encre, c'est juste qu'on change la couleur assignée à cette encre un peu come pour un raster, parceque à un intant T bin cette encre est de fait inusitée dans le décors (et les sprites) sur plus d'un écran.
Ensuite, esque un scrolling horizontale (quelqu'il soit) peut garder un raster horizontal ?
on pourrait alors fonctioner avec un pseudo "système d'attributs" sur la map... euh...disont que dans mon esprit ça se rapproche d'une contrainte par attribut, bien que ça n'en est pas du tout lol...
en sachant qu'on doit garder genre 1 écran complet + 1 quart (dans le cas ou on fait défiler par "sauts/à coups de 1/4 d'écran) d'écart pour les changements d'encre entre la droite et la gauche du décors, qui à aucun moment ne se rencontrent...
euh, vous me comprenez ?
Je vais taché de faire une convertion de cette map (vite fait) qui illustrera mieux ma logique....
Oh bien sûr si techniquement c'est impossible, je m'incline... et surtout si c'est trop gourmand en mémoire... Car oui ça sera bien la mémoire qui risque de poser des problèmes, surtout pour ces décors de 3x320pix de large (voire plus)...
Et surtout grapiller des couleurs de la sorte n'est pas toujours trés explitable en palette CPC old...mais sur PLUS..arf je sais on y est pas encore...) et il est vrai qu'on est pas obligé de respecter les teintes exactes de la version VGA...
Citer :
Pour être honnête , je ne pense pas que les splits raster d'un écran sur l'autre seraient une bonne idée.Une palette globale par scène (qui inclue évidemment des couleurs fixes pour le personnage et certains objets) je trouve ça déjà pas mal.
En même temps (je parle toujours d'un point de vue graphismes) il y a pas mal de décors avec un horizon... ou un haut d'écran ou aucun sprite principal ne va... Donc un raster en mileu d'écran par exemple (à peu presque) permet souvent de changer 1-2 couleurs qui n'est alors plus présente du tout... Cas par exemple des plages avec un superbe ciel...
couleurs en fait réservées aux décors seulement d'ailleurs. Mais il est vrai que les rasters c'est chiant sur un CPC old, surtout si...on fait du scroll non ?
Arf, comment il faisait sur crypt of trogan ? idéalement il faudrait le même genre de truc sauf qu'on met un coup de scrolling quand on arrive au dernier quart d'écran et non en bout. Après euh... c'est vrai que stryker/trogan a moins de lourdeur autre (sprites assez simples et petits) et surtout basé sur des tuiles qui se répètent souvent...mais c'est aussi un jeux d'action non ?
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
Inscription : 12 Juin 2008, 20:29 Message(s) : 1709
bon, j'arrive à lire l'index des différents objets et à arriver au moment où on va charger la room 10 (la première room "logo" ) et exécuter les scripts !
le seul pb est qu'il va falloir que je découpe le fichier global par room (en extrayant également les gfxs) car sinon on charge plus de &ffff d'un coup en mémoire et c'est un peu lourd pour le cpc 64 ko !!! y'a une bonne réflexion sur le sujet et surtout une bonne partie de code !
Inscription : 12 Juin 2008, 20:29 Message(s) : 1709
bon c'est le bouzin tout ce code inutile... mais j'avance (tant pis pour l'optimisation)... bon voilà en détail (ce qui n'est d'ailleurs pas du tout documenter sur les différents sites de hack de scumm...)
en fait, pour rappel dans le fichier index, on trouve taille index uint32 (4 bytes argh!!!) + "RO" (room offset) + uint16 nombre de room (exemple &63,&00 pour monkey1 amiga fr) puis : 1 byte = file disk number + uint32 = file offset (cela ne semble pas être utilisé, peut-être je pense l'emplacement sur le disk quand c'était pas des fichiers mais directement des tracks/secteurs ?)
ensuite un fichier disk commence par une entête taille fichier uint32 + "LE" (= Lucas Entertainment) puis un file offset pour trouver facilement les rooms taille offset uint32 + "FO" (File Offset) + uint16 (nombre de fichiers) + la liste des offset file uint32 puis pour chaque fichier room taille offset uint32 + "LF" (Lucas File attention les chevilles ) + pleins de bordels room, scripts, objets, costumes, décors images et j'en passe bref un gros bouzin tout bo (genre wad de doom) qui fait une taille pas possible pour certaines rooms (>&ffff)... bon heureusement, je pense pouvoir découper tout cela (c'est en cours) et ne charger que ce qu'on a besoin (quitte à faire des microchargement si nécessaire on verra après pour l'optim)... mais bon, déjà que le code d'origine n'est pas évident à comprendre, cela rajoute un peu de spécifique !!! bref je m'éclate
voilà...voilà !!!
si ça avance bien, dans deux semaines, on devrait voir apparaître d'abord des carrés blancs pour les costumes (= sprites) puis les textes !!! !
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 73 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