Page 7 sur 8

Re: TRANSYLVANIA conversion AMSTRAD CPC

Publié : 07 déc. 2014 10:19
par Xavier
j'ai protégé le fichier TRANS.BAS sur la disquette
Jester, te prend pas la tête...
Le listing de la pièce jointe me semble bon.
Par contre, la gestion de la mémoire sur CPC, me semble assez rigoureuse et le segment de RAM supérieur à 64k semble plutôt exotique!
Pour l'instant, je réduis la taille du basic avant d'attaquer la partie graphique en assembleur.

Re: TRANSYLVANIA conversion AMSTRAD CPC

Publié : 18 déc. 2014 19:42
par Xavier
Salut,
La conversion d'un jeu déjà existant, n'est pas chose simple.
Et avant, de se lancer dans une telle réalisation, il faut posséder quelques base techniques sur la machine d'accueil.
Et c'est là que l'on se heurte aux limitations techniques et matérielles qui ont rebuté les programmeurs de l'époque!
C'est là que l'on s'aperçoit que le travail est périlleux.
Le projet de conversion a été pensé à l'inverse de la logique de conversion!
Il ne faut pas se dire :"Peut-on faire mieux?" ou "Peut-on faire plus beau?"

Mais, "Peut-on le faire fonctionner sur cette machine?"
A priori, oui.
J'ai adapté le programme basic sur CPC, avec seulement les textes, mais au prix de galipettes acrobatiques en programmation!
Le programme Basic Exel (28k) charge correctement, mais les 10k de données variables bloquait l'exécution du programme.
Donc, passage des données texte (8k environ) en mode assembleur, en mémoire haute.
Avant même de penser graphisme ou son, la partie mémoire Basic bloque certaines banques mémoire... et la suite de la programmation sera très périlleuse.
Chercher les bons codes, les astuces et les outils pour adapter les codes Exel n'aboutira qu'a des problèmes de mémoire, et d'incompatibilité.
Il s'agit donc ici de réinventer le programme aussi fidèlement que l'original.
Donc, pour le moment, créer une version fonctionnelle du jeu est une priorité, les fioritures et autres exotismes seront ajouté en fin de projet.
Je pense pouvoir sortir quelque-chose de tout ça, mais la priorité est de placer le décor avant de fignoler les détailles.

A suivre.

Re: TRANSYLVANIA conversion AMSTRAD CPC

Publié : 19 déc. 2014 09:44
par jester
La version Exel n'est qu'une adaptation du code original... tu devrais peut être partir non pas de cette version mais de la version Apple II (c'était bien cela ta source Philippe ?).
Ensuite si on a réussi à faire une adaptation pour Exelvision, je pense que c'est les doigts dans le nez sur CPC... la machine est quand même beaucoup plus souple, avec une architecture classique, et énormément de documentation. Après je ne connais pas l'Amstrad CPC, mais il y a eu des jeux bien supérieur à Transylvania.

Si l'adaptation réclame beaucoup trop de travail, je dirais que ce jeu n'en vaut pas la peine... il y a des jeux d'aventures 1000 fois mieux que ce vieux machin totalement ringard... qui trouvait son intérêt sur Exelvision car ce type de jeu, et dans cette forme, n'avait jamais été réalisé (et même imaginé) avec une belle éclate sur la partie sonore. Après le jeu en lui même :cry:

Re: TRANSYLVANIA conversion AMSTRAD CPC

Publié : 19 déc. 2014 10:40
par Xavier
Salut Jester,
Ensuite si on a réussi à faire une adaptation pour Exelvision, je pense que c'est les doigts dans le nez sur CPC...
:D
Je n'ai que deux narines !
J'en suis qu'au mode "découverte"... Comme je l'indiquais dans un poste précédemment envoyé, je passe du Zx81 à l'Amstrad.
Parcours chronologiquement logique, car je suis effectivement passé du ZX81 au beau CPC 464...
Mais, pour le Basic et les jeux.
Donc, après avoir bien décapé le ZX81, il était naturel de passer au CPC.
Donc retour vers le passé, et reprise de la programmation ou je l'avais laissée, c'est à dire Basic commande RUN"
Sur ma période récente sur le ZX81, j'ai réappris l'assembleur Z80 et le hard.
Donc, j'essai d'appliquer mes connaissances nouvellement apprises avec l'Amstrad.
Mais, en effet, contrairement au ZX81, je n'ai pas à réinventer le système, car cette machine est abondamment documentée et c'est un réel plaisir de pratiquement tout trouver sur le net! (superbe travail d'archivage et de conservation, en passant!)
Donc, les exemples sont disponibles, et l'aide accessible.
Toutefois, je suis encore très "jeune" pour imiter les grand nom de la programmation de l'époque...
Je suis au niveau bricolage "Hebdogiciel", amateur... et concrétiser rien qu'une idée ... est laborieux.
Après je ne connais pas l'Amstrad CPC, mais il y a eu des jeux bien supérieur à Transylvania.
Effectivement, mais je ne suis pas magicien... et faire du copier/coller sans rien y comprendre, n'est pas productif.
Et c'est là que l'on s'aperçoit de la qualité des logiciels Amstrad produit à l'époque!
Si l'adaptation réclame beaucoup trop de travail, je dirais que ce jeu n'en vaut pas la peine...

Trop tard! :D
J'en suis à 38,345% de la conversion.
Mais, c'est un exercice passionnant qui réclame pas mal de compétences.
On apprend en reproduisant, puis plus tard, cela servira pour d'autres.
Il faut dire que je dois repenser le programme et recréer pratiquement tout avec des routines "bricolées"...
Le plus simple aurai été de scripter le jeu avec un logiciel spécialisé.
Mais, ce serait moins drôle...

Re: TRANSYLVANIA conversion AMSTRAD CPC

Publié : 19 déc. 2014 20:30
par 6502man
Oui la version qui m'a servi de conversion est celle de l'Apple II (Basic + ASM).

En fait la partie Basic de la version Exelvision a un avantage par rapport à celle de l'Apple II, des bugs ont été corrigés et le code réorganisé pour certaines parties.
Et aussi tous les textes passé en données au lieu d'être codé en dur dans le programme sur la version Apple II.
Mais il y a eu un peu de gymnastique obligatoire par la limitation du nombre de caractères par ligne de l'ExelBasic (128), car la version Apple II avait des lignes de 255 caractères (il me semble).

Si tu as besoin d'explications je peux t'aider (tant que la mémoire est là) :wink:

Re: TRANSYLVANIA conversion AMSTRAD CPC

Publié : 20 déc. 2014 06:57
par Xavier
Merci Philippe et Jester,
En proposant mon aide, je pensais pas avoir à commencer le projet!
Mais, il faut bien commencer par quelque chose.
Le basic est relativement proche de celui de l'Excel, et n'a pas eu de changements majeurs.
Seule les routines ASM, sont à refaire (son graphisme).
En l'état, le programme, n'est pas encore exploitable.
Je dois faire la routine graphique avec l'utilitaire de conversion pour créer et afficher les décors.
La musique et le son seront présent dans la présentation... dans le jeu... c'est moins sûr.
Pour le moment, je dois réaliser et déboguer le programme basic de base afin d'y voir plus claire.
Donc, pour le moment, je jette la base du programme qui constituera les fondations du jeu.
Pour la partie basic, pas de problème...
Mais..
Si tu as besoin d'explications je peux t'aider (tant que la mémoire est là)
Oui, sur les appels ASM et les arguments des CALLs, surtout pour la partie "MEDIA" qui fait appel à la partie graphique!
Nous passons du vectoriel au BITMAP, donc nous nous retrouvons avec des décors et des objets qui ne pourront pas être traités de la même façon! car la taille des objets est différente à celle des décors. Et là, j'ai envie de revenir au vectoriel contrairement au décors qui seront en BITMAP.
Donc, j'ai besoin de savoir sur quel fichier les routines renvoient les indexes (fichiers OBJ?).
Mais, pour le moment, je fais la routine d'affichage des décores... taille fixe... environ 40 décors à stoker en mémoire.
Les objets, on verra après.
Merci à tous pour votre aide...
Même si cette aventure ne sera pas un "Best Of" pour l'année 2015... le projet aura le mérite d'exister...
:D

Re: TRANSYLVANIA conversion AMSTRAD CPC

Publié : 20 déc. 2014 10:31
par jester
Le problème du vectoriel est la vitesse d'affichage... avec un très bon codage ça passerait... sinon c'est insuportable.
La majorité des objets étant petit: un BITMAP compressé est parfait.
Pour les gros objets se posent le problème de la vitesse de dessin.
Et en plus ce la demande d'embarquer 2 codes différents: l'un pour décompresser/afficher les BITMAP, l'autre pour décompresser/dessiner le vectoriel.

Sur Exel on compressait les images en privilégiant la vitesse de décompression et la minimisation de l'espace mémoire pour décompresser... mais le taux de compression était assez bon: les images compressées étaient petites.

Re: TRANSYLVANIA conversion AMSTRAD CPC

Publié : 20 déc. 2014 18:50
par 6502man
Xavier a écrit :Oui, sur les appels ASM et les arguments des CALLs, surtout pour la partie "MEDIA"
Pour la routine MEDIA(F,NN,R)
F= fonction ( 82:affiche décors _ 79:affiche objet _ 83:joue voix _ 77:joue music )
NN= numéro de l'objet à charger
R= boucle la musique ou la voix

voila ;)

Re: TRANSYLVANIA conversion AMSTRAD CPC

Publié : 20 déc. 2014 19:41
par Xavier
Pour la routine MEDIA(F,NN,R)
F= fonction ( 82:affiche décors _ 79:affiche objet _ 83:joue voix _ 77:joue music )
NN= numéro de l'objet à charger
R= boucle la musique ou la voix
Merci pour l'info!

Le problème du vectoriel est la vitesse d'affichage... avec un très bon codage ça passerait... sinon c'est insupportable.
... pour des milliers de lignes, est un remplissage de grandes surfaces... mais pour quelques lignes...ça restera supportable.
Je vais tester le vectoriel avant le bitmap, car je n'ai pas les images ...
Je regarde pour l'affichage graphique...

Re: TRANSYLVANIA conversion AMSTRAD CPC

Publié : 22 déc. 2014 17:43
par Xavier
Salut,
Je vais faire un bref bilan du travail effectué, pour rendre compte des avancements du projet... et donner l'opportunité aux contributeurs précédents d'y participer et valoriser le travail déjà fait.

Donc,
* Conversion du programme Basic (programme Exel de base), en le faisant maigrir des variables Basic REP$ et COM$, avec migration en Bank haute et ASM.
* Création de la routine ASM pour l'affichage des textes.
* Création de la routine ASM pour l'affichage des éléments vectoriels pour l'affichage des objets (décors en bitmap).

Eléments vectoriels:
La version Exel étant basée sur des éléments bitmap, il faut donc remonter à la version Apple2 pour avoir les données.
Avec les fichiers DUMPés récupérés, il est donc possible de les traiter avec une petite routine assembleur.
Mais, certaines fonctions n'étant pas documentées, il reste des "erreurs" de tracés...
screen vecoriel sur CPC
screen vecoriel sur CPC
trans_vect.jpg (36.56 Kio) Consulté 4365 fois
Il semble y avoir des informations en trop!

En effet, les DATAs de dessin vectoriel semble utiliser des "TAGs" de fonction, permettent des animations et autre joyeusetés.
Ma routine de lecture en &8000, Datas en &9000:

Code : Tout sélectionner

;#F0#     EXIT
;#F1# &20 bit5		%0|0|1|0|0|0|0|0 ; ND (1By) [20]
;#F2# &40 bit6		%0|1|0|0|0|0|0|0 ; ND (1By) [41,42,43]
;#F3# &60 bit6+bit5	%0|1|1|0|0|0|0|0 ; ND (2By) [60]
;#F4# &80 bit7		%1|0|0|0|0|0|0|0 ; MOVE TO / ABSOLUTE
;#F5# &A0 bit7+bit5	%1|0|1|0|0|0|0|0 ; LINE TO / ABSOLUTE
;#F6# &C0 bit7+bit6	%1|1|0|0|0|0|0|0 ; ? LINE TO / ABSOLUTE
;#F7# &E0 bit7+bit6+bit5	%1|1|1|0|0|0|0|0 ; FILL

Write "VTRACE.BIN"
org &8000

	LD de,0 ; X coord.
	LD hl,-100 ; Y coord.

	CALL &BBC9

	LD hl,&9000
Loop
	XOR a
	LD(TagDE+2),a ; Reset A > X up to 256

	LD a,(hl)
	CP &00
	RET Z
	AND &E0 ; get 111xxxxx
	RLCA	; Rot 11xxxxx1
	RLCA	; Rot 1xxxxx11
	RLCA	; Rot xxxxx111
	CP 1
	JR z,tag20
	CP 2
	JR z,tag40
	CP 3
	JR z,tag60
	CP 4
	JR z,tag80 ; +BIT 0 RES
	CP 5
	JR z,tagA0 ; +BIT 0 RES
	CP 6
	JR z,tagC0 ; +BIT 0 RES
	;; F7: tagE0
	JR tagE0 ; +BIT 0 RES

;; Dist..


;#F1#;; ????
tag20
	INC hl
	JR loop

;#F2#;; ????
tag40 	LD a,(hl)
	CP &40
	JR nz,tag41
	JR Tag4X
tag41
	CP &41
	JR nz,tag42
	JR Tag4X
tag42
	CP &42 		
	JR nz,Tag4X
tag43
	;; &43 or BIT0 from RES 0,a
Tag4X
	INC hl
	JR end_loop

;#F3#;; ????
tag60
	INC hl
	INC hl
	JR loop

;#F4#;; MOVE TO ; ABSOLUTE
tag80 	CALL Get_A; tag81 + 256 offset
	JR init_plot

;#F5#;; LINE TO ; ABSOLUTE
tagA0 	CALL Get_A; tagA1 + 256 offset
	CP &A0
	JR nz,tagA2
	JR init_line
tagA2	
	JR init_line

;#F7#;; LINE TO ; ABSOLUTE
tagC0	CALL Get_A
	JR init_line

;#F6#;; FILL
tagE0 	CALL Get_A; tagE1 + 256 offset
	CP &E0
	JR nz,tagE2
	JR init_plot
tagE2
	JR init_plot

end_loop
	JR loop

init_line
	LD a,&F6
	JR int_launch
init_plot
	LD a,&EA
int_launch
	LD (callarg+1),a
	CALL get_coo
	CALL line1
	JR end_loop
get_coo
	INC hl
	LD a,(hl)
	LD (TagDE+1),a ; X coord.
	INC hl
	LD a,(hl)
	XOR &FF
	LD (TagHL+1),a ; Y coord.
	INC hl
	RET
line1
	PUSH hl
TagHL
	LD hl,&00FF
	RL l
	RL h
TagDE
	LD de,&0000
	RL e
	RL d
callarg
	CALL &BB00
	POP hl
	RET
Get_A
	LD a,(hl)
	BIT 0,a ; Test if X>256 from 81,A1,E1...
	JR Z,Ret_1
	ex af,af'
	LD a,1
	LD(TagDE+2),a
	ex af,af'
Ret_1	
	RES 0,a
	RET

J'ai créé deux disquettes CPC pour visualiser les décors et les objets du jeu.
trace.zip
Disquettes tracé Objet/Décors
(51.96 Kio) Téléchargé 128 fois
lancez la démo en tapant : RUN"DEMO pour les deux disquettes.
On peut s'apercevoir que le programme ASM ci-dessus est perfectible, et qu'un certain nombre d'information passent mal...
Surtout pour les objets...
Il reste encore du travail sur ces Objets, car ils seront utilisés lors du jeu.
Pour ce qui est du décor, ils seront redessinés en s'inspirant des tracés obtenu.
Pour le moment en mode 1, le jeu pourra être converti en mode 0 pour la partie décor, et mode 1 pour la partie texte, mais les routines de splitting trouvées, ne me semble pas stable.
Il est donc prioritaire de décortiquer les bases du jeu avant de parler cosmétique!
A plus, pour un version plus aboutie de ce traceur vectoriel.
Par contre, si quelqu'un a une idée, ou trouve l'utilité des fonctions non documentée....
Ce projet est participatif, et je n'ai pas la prétention de coller mon pseudo sur cette portage, car beaucoup de travail a déjà été fait par les différent contributeurs de ce forum!
Au fait, on a perdu Baptiste ?

[EDIT]
J'ai l'impression de faire mon 'Defcard' avec ce message pourri !
[EDIT]

Re: TRANSYLVANIA conversion AMSTRAD CPC

Publié : 22 déc. 2014 19:01
par defcard
J'ai l'impression de faire mon 'Defcard' avec ce message pourri !
[edit modo: Heu comment dire... même si le message d'un membre te semble déplacé, tu peux lui répondre, lui demander des explications voire lui demander des excuses, mais en aucun cas avec un déferlement d'insultes comme tu viens de le faire. Je te rappelle qu'on est en public et que je ne tolèrerai pas un autre écart de ce genre.]

Re: TRANSYLVANIA conversion AMSTRAD CPC

Publié : 22 déc. 2014 20:08
par Xavier
:shock:
Pas de censure pour les insultes!
:oops:
Si Defcard veux donner une critique sur cette phrase, il le peut.
Du moment, que ce n'est pas sur le projet...
Ou dans le cas d'une censure de messages privés, il serait de bon aloie de copier ce message dans un pli privé.
Walà...
Mais, bon, j'ai pourri son message, alors c'est de bonne guerre.
J'envoie un message privé pour lui apprendre comment on insulte les gents.
:D

Re: TRANSYLVANIA conversion AMSTRAD CPC

Publié : 22 déc. 2014 20:42
par 6502man
Concernant les DATAS vectoriel, sur Apple II il y avait une différenciation entre les coordonnées horizontales <255 et >255 c'est à dires que si la coordonnées est <255 le TAG avait une valeur 128 et si >255 un TAG de 129 idem pour les TAG 160 et 161 ....
ATTENTION c'est de mémoire donc il faut vérifier mais ca devrais être ca .

Sinon tu as aussi des TAGS pour les remplissages des formes (ce qui doit correspondre aux points affiché sur ta version) !!!
et aussi pour la forme et couleurs de remplissage il me semble ...

Re: TRANSYLVANIA conversion AMSTRAD CPC

Publié : 22 déc. 2014 21:04
par Xavier
Salut,
Oui, c'est vu lors de la programmation ASM:
Dans cette partie de programme ( :shock: :shock: )
Get_A
LD a,(hl)
BIT 0,a ; Test if X>256 from 81,A1,E1...
JR Z,Ret_1
ex af,af'
LD a,1
LD(TagDE+2),a
ex af,af'
a=DATA VECTEUR
BIT 0,a ; Test if X>256 from 81,A1,E1...
On teste le BIT0 pour le tag donc 81,A1 et E1 ont une taille de a+256
Donc la taille n'est plus de AA mais de 1AA => inscrit en écriture dynamique dans LD hl,01AA pour les coordonnées X.
???
D'ailleurs, le B1, c'est peut-être les Y...
Mais je n'ai...
Zut, effectivement j'ai des 82,A2 et E2 !
Donc, je fais pareil pour le bit1, donc tout ce qui fini par "2"
Merci, je n'y avais pas pensé pour les Y ...

Re: TRANSYLVANIA conversion AMSTRAD CPC

Publié : 22 déc. 2014 22:43
par 6502man
De mémoire les Y ne dépasse pas 256 :roll:

Mais peut être l'inversion vidéo du tracé :wink: