TRANSYLVANIA by 6502MAN et JESTER

[jester]

56 décors, 35 samples audio, 10 thèmes musicaux, 35 sprites, plus de 500ko de données... je commence à saturer. Heureusement on en voit le bout et la phase de beta-test ne va pas tarder.
Philippe croule sous le travail, et moi c'est guère mieux... on avance donc moins vite.

Mais peu de machine de cette époque (86) ont eu des jeux avec une bande audio disposant d'autant de samples réalistes, surtout sur 8 bits ! Le synthé vocal d'Exelvision/Ti avait un sacré potentiel... dommage qu'il ait été plus que sous-exploité.

[Fabrice Montupet]

EXL135 va fonctionner à haute cadence... comme jamais!

[jester]

Ce fut d'ailleurs un gros challenge du jeu: éviter les accès disques inutiles et optimiser les chargements/sauvegardes de partie... car c'est vite ce qui énerve l'utilisateur.

Une dernière passe encore avant la phase de beta-test... il y a qqs petits bugs résiduels, mais 99% du jeu est opérationnel et stable.

[DataPro]

D'une certaine manière, je suis bien ennuyé de ne pas pouvoir tester le jeu sur une vraie machine...

[6502man]

Jester a fait un très gros travail d'optimisation, notamment sur la partie des acces disks

En ce moment je suis très pris par le boulot donc j'ai un peu de mal a avancer, mais Jester a pris le relais pour tenir les délais

[Fabrice Montupet]

Les lecteurs BASF AG 6164 et Panasonic JU-363 qui équipent la grande majorité des EXL135 ont une mécanique relativement bruyante. Le coffrage de l'EXL 135, identique en taille et en look à celui de l'EXL 100, donne à cet ensemble une belle impression d'unité et d'élégance; il en découle cependant un désagrément sonore: son surdimensionnement par rapport au contenu, la qualité très discutable du plastique utilisé provoquent résonances et vibrations à chaque activité disque. C'est donc particulièrement bien vu d'avoir pensé à minimiser les accès disque.

[jester]

D'ailleurs je teste avec mon exel135 qui est horriblement bruyant !
Mais ça gratte encore pas mal, chaque scène réclame au moins 1 accès disque (le décor)... mais dans l'ensemble ce n'est pas vraiment pire qu'un jeu Sierra On Line de l'époque AGI Engine.

En ce moment je me bats contre un petit soucis, une erreur 127... c'est-à-dire plus assez de mémoire... Oups ! Saloperie de Basic #*+&#!

[Fabrice Montupet]

A l'époque, quand je jouais à des jeux d'aventure ou AD&D sur mon Apple II, le lecteur Disk ][ ne cessait pas de faire du boucan de tous les diables! Mais après avoir passé quelques années à utiliser un malheureux lecteur de K7 pour seule unité de stockage, utiliser un lecteur de disquette était magique! :') De fait, ce bruit... je l'adorais! Aujourd'hui, il m'amuse Mais c'est par pure nostalgie.

[jester]

A priori les sauvegardes/restaurations marchent, plus de problème mémoire, dernières grosses boulettes corrigées... j'ai terminé le jeu plusieurs fois... Philippe essaie de faire une dernière passe + teste Exeltel pour moi et si ça roule le package BetaTest sera prêt pour la fin de semaine.
Ensuite, Il y aura sans doute qqs trucs à modifier ça et la en fonction des retours...

[jester]

Version Beta livrée.

Mais le plus gros bug n'a pas été corrigé : trouver des gens possédant un exeltel + exeldisk + exelmémoire + exelbasic plus... on a pas osé utiliser l'exeldrums

Mais je ne veux plus jamais entendre parler de Basic sur cette machine... jamais !
La gestion mémoire des chaines de caractère est une catastrophe sous exelbasic, et la version + semble merder dés lors qu'il n'y a pas une bonne quantité de VRAM dispo (sans faire d'erreur mémoire, ce serait trop facile).
Idem pour les instructions d'E/S sur disque (PRINT #, INPUT #)... d'une lenteur rare... donc si d'autres fous avaient par hasard l'envie d'attaquer un gros projet avec une base en exelbasic... mieux vaut éviter cette erreur fatale !
On a pu ramener le temps de sauvegarde d'une partie à qq secondes, mais je vous raconte pas les ruses de sioux !
Par contre le temps de chargement du jeu est très long (>1mn pour lire moins de 10ko de données )... alors qu'en LM ça prendrait 5s !!!
That's life !

[Daniel]

Quand tu utilises des chaînes de caractères en Basic, il y a une allocation dynamique de mémoire. Pour toute affectation d'une valeur à une variable chaîne, une nouvelle zone de mémoire est allouée et si la variable a déjà été utilisée son ancien contenu est "abandonné". La place libérée reste provisoirement inutilisée. Au bout d'un certain temps l'espace chaîne est saturé, le Basic lance alors une réorganisation. Cette réorganisation est très longue s'il y a beaucoup de chaînes (plusieurs secondes). Pendant la réorganisation le programme est bloqué et on ne peut plus rien faire. Si on tente de l'interrompre à ce moment-là, il y a un très gros risque de détruire le programme en mémoire.

Même les meilleurs Basic (y compris Microsoft) ont ce défaut. A l'époque héroïque où je programmais encore en Basic, je rusais en n'affectant jamais plusieurs fois une valeur à une variable chaîne. Par exemple, en Basic Microsoft, je n'écrivais pas :

Code : Tout sélectionner

M$ = "Hello"
.....
M$ = "World"

Mais

Code : Tout sélectionner

M$ = "Hello"
.....
MID$(M$, 1, 5) = "World"

Avec cette ruse, il n'y a pas de réallocation de mémoire, ni de réorganisation de l'espace chaîne, on gagne un temps considérable, ou plus exactement on en perd moins. Ceci dit, écrire un jeu en Basic est toujours une mauvaise idée, surtout sur une machine aux capacités limitées. En assembleur on gagne sur tous les tableaux, et avec un peu d'expérience ce n'est pas plus difficile ni plus long.

[Markerror]

Version Beta livrée.

Idem pour les instructions d'E/S sur disque (PRINT #, INPUT #)... d'une lenteur rare... donc si d'autres fous avaient par hasard l'envie d'attaquer un gros projet avec une base en exelbasic... mieux vaut éviter cette erreur fatale !

Et encore, c'est de l'ExelBasic+, c'est déjà mieux que celui de base .

Pour les jeux d'aventure, l'assembleur finalement n'est pas un mauvais choix. Passé la création des bases (analyseur syntaxique, gestion des ordres de base style prendre/poser et définition d'une structure de données assez polyvalente pour gérer des actions avec un objet dans un lieu précis), ce n'est pas plus compliqué que de bricoler en Basic.

[6502man]

L'Assembleur est de toutes façons supérieur a tout les niveaux et je préfère aussi

Mais dans ce cas précis, j'avais fait le pari de convertir un jeu d'aventure existant sur une autre machine 8 bits vers l'exel et comme j'aime bien le style des jeux d'aventures graphiques commandes textes, et que je voulait adapté un jeu APPLE II, du coup ca c'est fait en BASIC.

Au final c’est une bonne expérience et ca permet de découvrir d'autres choses des machines,et surtout on peut faire de bon jeu sur EXELVISION.

[jester]

Il faut dire aussi que si on était resté sur le plan de départ de Philippe: TEXTE + GRAPHIQUE, nous n'aurions pas rencontré de gros soucis en Basic... mais comme j'ai eu l'idée lumineuse de coller des sons un peu partout et un peu de musique (histoire d'exploiter le synthé vocal), on a vite surchargé le Basic avec ce genre de déco.
Et puis le programme Basic d'origine que Philippe a traduit n'était pas un véritable interpréteur de jeu... les 9/10 sont codés en dur... on est loin d'un AGI ou SCI engine de Sierra !

Mais ce qui est certain: il aurait été très facile d'adapter une grande partie de la production de jeu d'aventure de cette époque sur l'Exl100/Exeltel + exeldisk !

[Fabrice Montupet]

Hélas très peu de temps devant moi ce soir Mais à peine rentré du boulot, j'ai réussi à trouver quelques instants pour générer la disquette de Transylvania reçu ce jour et de l’exécuter sur un Exeltel VS + Exelmémoire 16ko + Exeldisk. Le jeu est d'une grande qualité et je félicite Phil et Fabrice pour le travail accompli. L'intro est superbe, l'ambiance du jeu très réussie, des décors sont du jamais vu sur Exelvision, les effets sonores saisissants! . Demain, j'aurais du temps pour jouer/tester le jeu, je ne vous cache pas que j'ai hâte!
Voila mes premières impressions sur Transylvania, je tenais à vous les faire partager