Je suis (discrètement) votre discussion depuis le début.
Je ne peux qu'approuver l'efficacité avec laquelle le sujet est traité. En dehors de la seule faisabilité technique, c'est clair que vous avez pris en main les bons morceaux pour commencer.
Inscription : 12 Juin 2008, 20:29 Message(s) : 1726
La suite du découpage de fichier au sabre "Pirate" :
j'ai utilisé SCUMMRev5_Build130 ouvert le fichier du premier disk DISK01.LEC (attention c'est la version amiga fr pour l'instant que j'utilise -> je passerai à la version pc quand je serai un peu plus avancé pour voir si ce que j'ai fait est compatible avec d'autres versions ce qui ne devrait plus trop tarder !!!) mais ce que je dis est valable pour les autres version bien sûr !
bref, pour l'utilitaire dont je parle plus loin, il vaut mieux se baser sur la version pc EGA disk par exemple... fr serait un plus
ensuite j'ai découpé le fichier et je n'ai récupéré que ce qui est hors graphique, sons, etc. (on peut aussi le voir à l'inverse je n'ai récupéré que ce qui est intéressant (cf liste des items à conserver à faire avec RO, LS, etc. ))
cela m'a permis de réduire la premier room (&0a) de 61ko à 16ko... ce qui me va bien car tout doit rentrer dans un bank de 17ko
là, j'en suis donc à coder les opcodes (oulala y'en a un paquet) ce qui va faire exécuter des trucs à l'écran (ouaaaahhhhhhh !!!! )
Bon, donc je crois que je vais avoir besoin d'un petit utilitaire sur cmd dos pc pour faire un découp des fichiers rooms...
Voici un ptit cahier des charges à ce sujet pour un autre codeur fano, Demonial, ? :
1) tout d'abord, on passe en paramètre le fichier disk (ex : DISK01.LEC) ensuite il faut faire un xor &69 sur tous les datas après il faut interpréter le fichier comme cela :
4 octets longueur fichier 2 octets (doivent être égal à "LE")
SECTION "FO" (on ne va rien en faire...si ce n'est s'en servir pour aller au différente SECTION "LF") 4 octets longueur 2 octets = "FO" 32 bits d'offset jusqu'à fin longueur
pour chaque SECTION "LF" 4 octets longueur 2 octets = "LF" 2 octets = numéro de la room (très important )
puis on va trouver 1 SECTION "RO" 4 octets longueur 2 octets = "RO"
puis on va trouver à l'intérieur divers éléments qu'il faut sauvegarder (cf MK1_AMFR_INDEX.asm) dans un répertoire "data\room\[numero de room]" comme cela : NUM_OFFSET_TYPE.extract où NUM = un numéro de 01 à xx qu'on incrément à chaque object OFFSET = offset par rapport au début de la section "RO" TYPE = les deux caractères qu'on trouve après la 4 octets de la longueur de l'objet
Nota : chaque élément commence par sa longueur sur 4 octets, ensuite deux octets pour le type
la SECTION "LF" contient ensuite des scripts 4 octets longueur 2 octets = "SC" qu'il faut sauvegarder à la suite avec les mêmes règles de nommage qu'au-dessus
puis les sons ou les costumes ou d'autres éléments à traiter de la même façon !!!
et on boucle tant que pas fin fichier "LE"
Voilà à la fin, on va a obtenir plein de fichiers dans data\room\numéro de room...
cela permettra ensuite d'appliquer des règles automatiques pour le calcul des offsets... en effet, les objets de type "OI" - Object Image vont être enlever car les images seront charger séparément (comprendre dans une autre bank mémoire de 17ko) idem pour les costumes en fait, tous les trucs spécifiques à la plateforme finalement (son, image, costumes=sprites) que je traiterais à la façon cpc...
2) il faudra également produire un fichier "idem 3_0S.asm mais que pour les scripts de la room en question" (cf tout en bas pour l'exemple) en recalculant l'offset à partir du début de la room comme je vais charger tout ça en bank, l'idéal serait donc d'ajouter également &4000 à l'offset
je pense également qu'il faudra le faire pour les costumes et d'autres éléments, à voir !
ce qui donnerait par exemple:
premier script de la room &0A : ancien offset &00007121 relatif au début du fichier ROOM Nota : en fait l'offset dans le fichier est &0000716D mais il faut enlever les différents trucs avant : &0000716D - 6 (LE) - &3e (FO) - 8 (LF) = &7121
donc il est bien relatif au début de (RO) et on peut le recalculer facilement en faisant : &7121 - les longueurs des trucs qu'on doit pas garder (cf liste des types qu'on garde pas) et on obtient le nouveau offset relatif à RO qu'il faudra mettre dans un .asm pour modifier l'index !
Ensuite, il faudra vérifier que data qu'on garde de la ROom + les SCripts font pas plus de 17ko ! donc va falloir tester toutes les rooms si c'est avéré, il faudra donc séparer room (RO) et script (SC) et du coup revoir les offsets des SC relatif au début de la bank (=&4000)...
au final pour l'exemple de la room &OA
NOMSECTION.numéro room
les deux fichiers serait : RO.0A SC.OA (si avéré)
il faudrait mettre un check si > à &4000 de long !!!
3) également, l'idéal serait au final de produire le fichier MK1_AMFR_INDEX.asm directement !!! on pourrait même mettre en commentaire les fichiers son, image, etc...en gros ce qui ne sera pas dans une liste de type autorisé !
soit l'asm soit le fichier (ou les deux si on sépare RO et SC) en binaire directement...
facile non ?
fichier mis pour exemple : 3_0S.asm db &0A dw &038e,&0000 ; db &21,&71,&00,&00 ici j'ai changé l'offset d'origine &00007121 par le nouveau &0000038e (-> c'est un 32bits à l'origine mais je pense bien le changer en 16 bits après pour économiser de la place mémoire)
pour l'instant l'offset est toujours relatif au début du fichier de la room mais, comme indiqué, je pense qu'il faudra mettre les scripts à part (à vérifier selon la taille data RO + data SC) Egalement, le +&4000 est fait dans le code pour se retrouver au bonne endroit pour l'instant...
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
Inscription : 13 Jan 2010, 14:25 Message(s) : 2282
Super boulot ; Respect !
Pour info, les effets graphiques sont allégés d'une version à l'autre. Il est donc fort possible que les scripts de la version CGA soient les plus "simples". Par exemple, sur PC VGA, lorsque Guybrush profane la tombe, il y a des éclairs dans le ciel qui rythme chaque coup de pelle, et l'ambiance sonore qui va avec. Sur Amiga, il n'y a déjà plus les éclairs ...
Pour les banks, elles font bien 16k et non 17 ? (d'ou vient cette curiosité des screens de 17k à ce sujet ... 1k=1000 au lieu de 1024 ?)
Il est vrai que dans le temps on avait souvent une confusion entre les Kilo 1000 et kilo 1024... ça a été rêglé car maintenant on différencie entre Kilo et Kibi.
Wikipedia :
Citer :
Traditionnellement, lorsqu'ils sont appliqués aux octets, les préfixes « kilo », « méga », « giga », etc., ne représentent pas un multiple de 103 = 1 000, mais un multiple de 210 = 1 024. Cependant cette tradition viole les normes en vigueur pour les autres unités, y compris le bit, et n'est même pas appliquée uniformément aux octets, notamment dans la mesure de la capacité des disques durs. Une nouvelle norme a donc été créée pour noter les multiples de 210 = 1 024 : les « kibi », « mébi », « gibi », etc.
De même la confusion était assez pénible car souvent 1Byte = 8 bits... Euh pas vraiment, mais sur les vieux ordis 8bits, peut être...
The SI prefixes kilo, mega, giga, tera, etc., stay the same as for all the SI units, based on power of 10. In this case: 1 kilooctet (ko) = 10p3 octets = 1,000 octets 1 megaoctet (Mo) = 10p6 octets = 1,000 ko = 1,000,000 octets 1 gigaoctet (Go) = 10p9 octets = 1,000 Mo = 1,000,000,000 octets 1 teraoctet (To) = 10p12 octets = 1,000 Go = 1,000,000,000,000 octets 1 petaoctet (Po) = 10p15 octets = 1,000 To = 1,000,000,000,000,000 octets
"p" pour puissance...
Mais en rétro-Amstrad, on continue de dire Ko comme avant non ?
Sinon bravo à Mégachur qui avance coûte que coûte, et bon courage pour la suite. On es avec toi !
PS @ Fano : arf merd, je me plante décidément toujours...
Dernière édition par MacDeath26 le 29 Août 2010, 18:32, édité 2 fois.
Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
TotO a écrit :
Pour les banks, elles font bien 16k et non 17 ?
C'est bien 16K , 16384 octets, comme la mémoire écran par défaut d'ailleurs.Depuis la normalisation fin 90 , 1Ko fait 1000 octets (quelle drôle d'idée , t'as déjà vu 1000 divisible par la taille d'une page ou d'un secteur ?) mais perso j'utilise toujours l'ancienne valeur car fondée sur l'agencement "naturel" de la mémoire. Ceux sont les Japonais qui avaient tout compris car il exprimaient la taille des cartouches en bits ce qui ne prête à aucune confusion
Sinon Megachur , si tu peux me mettre les fichiers .LEC je vais regarder pour commencer à faire la moulinette
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
Inscription : 12 Juin 2008, 20:29 Message(s) : 1726
Bon, déjà 3 opcodes de codés...qui ont l'air de marcher en + !!!
par contre, je butte sur un truc à la con :
sachant que hl = var et _bitVars est défini comme cela : byte *_bitVars; la valeur est : _bitVars = (byte *)calloc(_numBitVariables >> 3, 1); et _numBitVariables = 4096
Ca devrait être correct , à tester tout de même car je ne suis pas spécialiste en C. Si tu en as encore quelques uns, en décontractant du soir ça peut être sympa
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
Inscription : 12 Juin 2008, 20:29 Message(s) : 1726
je viens d'en traduire un autre comme cela (j'ai vu ta réponse après ):
Code :
bc = var de est réservé ... j'avais pas dit (pas tapé !!!)
;; _bitVars[var >> 3] |= (1 << (var & 7)); ld a,c and 7 ld l,a or a ld a,1 jr z,writeVar_1_multiply_end writeVar_1_multiply add a,a dec l jr nz,writeVar_1_multiply writeVar_1_multiply_end
srl b rr c srl b rr c srl b rr c ld hl,_bitVars add hl,bc ; go to _bitVars[var] byte right place or (hl) ld (hl),a
si je compare les deux codes... je me suis trompé sur l'interprétation du 1 << décalage alors que c'est 1 la valeur du décalage en fait à gauche !!! tant mieux le code ne sera que mieux -> juste un add a,a au lieu de ce gros bouzin !!! oulala je fatigue moi !
Inscription : 12 Juin 2008, 20:29 Message(s) : 1726
j'ai juste changer un peu ton code fano (tu n'avais pas pensé au and (hl) et de plus une fois fait le and (hl) pas besoin de faire un or a car cela mets à jour les flags :
ld bc,_bitVars add hl,bc ; go to _bitVars[var] size(byte) right place and (hl) ret z ; a = 0 ld a,1 ret euhhh...la fin aurait pu être correcte mais en fait c'est hl qu'il faut que je renvoie exactement : and (hl) jr z,readVar_return_false ld hl,false ret readVar_return_false ld hl,true ret
hummm ! le z80 va digérer tout cela maintenant !!!
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 33 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
)
