REDUCTOR 5.3 ____________ (C) TOM&JERRY Encore une nouvelle version du compilateur REDUCTOR. Celle-ci utilise encore une methode de compactage en deux temps differente, censee repondre aux defauts de REDUCTOR et, dans une moindre mesure, de REDUCTOR 2. En effet, REDUCTOR 4 dans aucun cas ne rallonge le fichier ecran du fait de sa methode de compilation. Le programme commence par rechercher dans l'ecran non compile un code qui n'apparait pas dans cet ecran. S'il n'en trouve pas, le compactage est annule. (ce qui est rare !!!) Ensuite, le programme compacte l'ecran sous la forme suivante, quand il trouve une suite d'au moins 3 octets. le programme compacte la suite sous cette forme : 1er octet : code de reconnaissance 2eme octet : valeur de l'octet 3eme octet : nombre de fois ou il faut poker la valeur de l'octet Quand REDUCTOR 4 rencontre un code de reconnaissance lors de la compilation (ce qui est peu probable car il cherche d'abord un code qui n'est pas dans l'ecran) il le compacte selon la methode citee ci dessus. Cette fois ci, il semble que l'on ne peut faire mieux en matiere de compactage, car en principe,il n'y a pas de perte d'octets du fait de la methode de compilation. De plus, Reductor 4 integre desormais dans le fichier genere le decompacteur. L'adresse de depart de ce dernier correspond a celle de l'implantation de l'ecran compacte. Cette adresse est redefinisable, il est donc possible de loger dans la memoire PLUSIEURS IMAGES ECRANS !!! (Attention, les ecrans ne doivent pas se chevaucher dans la memoire, sinon plantage !). La version 4.2 de Reductor dispose en plus d'une option de chargement du code genere EN MEMOIRE ECRAN !!! C'est tres pratique quand un jeu a plusieurs ecrans a charger, il est ainsi possible de charger un ecran compacte APRES avoir charge le jeu principal. Le programme vous donne l'adresse de chargement et d'execution de l'ecran. Il est a noter que le decompacteur integre,quand cette option est choisie, est transfere en &be80.Il est donc fortement deconseille d'implanter un chargeur a cette adresse. Toujours plus fort: Reductor, dans sa version 4.3 integre la possibilite de faire des presentations speciales d'ecrans, grace a une option de decompactage en &6000. Il suffit d'avoir integre dans le chargeur du jeu une des presentations proposees. ( Pour l'instant, il y a la presentation en volets, en deroulement, mais d'autres ne sauraient tarder).Une demonstration est prevue dans chaque chargeur. Reductor 5.1 permet lui, grace a 2 nouvelles routines de recherche et de compactage de compacter TOUS les ecrans 17ko, images digitalisees ou programmes charges en memoire ecran. Si un Bip retentit lors de la recherche de l'octet de reconnaissance, ne vous affolez pas, le CPC vous indique simplement qu'il passe a la recherche de l'octet dont la frequence d'apparition sur l'ecran est la plus faible.(cela peut prendre de 1 a 3 minutes...) Ces modifications sont transparentes quant a l'utilisation des ecrans compactes. La version 5.2 comporte en plus un test du compactage ecran.En effet, quand il n'y a pas d'octet de reconnaissance, il peut y avoir avec le codage des decompactages errones en fin de fichier, ex : Les 3 derniers octets du fichier code sont FF FF 01 ou FF est l'octet de codage. Lors du decompactage,les octets FF FF seront 'effaces' par le decodage, en consequence, le dernier octet du fichier ne sera pas FF mais 01, d'ou probleme. Ce phenomene ne se produit que sur les derniers octets de l'ecran.Quand il s'agit d'un dessin, cela ne se voit pas, mais s'il s'agit d'une portion de programme, la, cela peut poser des problemes. Le test incorpore dans la version 5.2 va donc verifier si l'ecran decompacte est bien semblable a l'ecran originel.S'il ne l'est pas, il vous le signale, il ne faut pas utiliser l'option decompactage en memoire.(dur,dur !!) Cette fois, il devrait s'agir de l'ultime version de REDUCTOR, la 5.3. Qu'est ce qu'elle a de nouveau ???€Une nouvelle routine de recherche du meilleur octet de compactage (2eme recherche), plus rapide (la 1ere durait toujours 1 min 4 sec, celle-ci prend toujours moins de temps.). Mais ce n'est pas tout.Il est desormais possible de redefinir l'adresse d'implantation du decompacteur lors d'un decompactage ecran.A quoi ca sert ?? Par exemple, si vous essayez de deplomber (OH !!!) un jeu edite par GREMLIN sous ùCPM, la protection de ce jeu fait que le loader du jeu charge le programme dans presque toute la memoire, en pratique de &100 a &c000.Le decompacteur en &be80 est donc a proscrire, car il risque d'ecraser des donnees necessaires au logiciel. La solution, implanter le decompacteur en dessous de &100. De plus, un petit detail qui a quand meme son importance, le systeme de calcul de la longueur disk de l'ecran compacte tient desormais compte du HEADER, vous ne vous retrouverez donc pas avec un fichier de 9ko alors que cette saloperie de CPC vous a dit qu'il n'en faisait que 8 !!!