Bonjour,
quelqu'un a t'il été à la microalchimie et aurait des nouvelles / informations à donner à propos de vampire?
Merci
Olivier
Rajah (./2) :Eh oui, à partir du moment où la machine a un CPU compatible, et où les programmes utilisent proprement l'OS (pas d'accès direct au hardware), tout marche nickel.
Bizarre de voir le GEM tourner sans faille sur du matos Amiga,
Rajah (./2) :A ce jour les seuls modes graphiques disponibles sur Vampire sont fournis par mon driver SAGA.SYS pour fVDI. Il supporte un nombre limité de résolutions 4/3, 16/9 et 16/10. Seuls les modes 16-bit 65536 couleurs sont supportés pour l'instant. La raison : ce driver est une adaptation de l'exemple de driver 16-bit pour Falcon fourni par fVDI. Et j'ai eu la flemme de m'atteler aux autres modes.
Les modes vidéos proposés sont assez larges, résolutions étendues (ici écran 16/9 en TC16) comme celles d'origine.
Rajah (./2) :Sur FireBee, le driver graphique a été optimisé par Didier Méquignon. Quant à NVDI, je ne sais pas s'il accélère l'affichage sur cette machine.
Sinon, petit narcissisme du quotidien, j'ai demandé un essai de mon portage de Xenon2 sous GEM : c'est lent. La FireBee est plus rapide. Mais je crois que cela pourrait être plus rapide avec une optimisation du driver VDI vis-à-vis de la vidéo de la Vampire (nommé SAGA), ou de l'utilisation de NVDI ?
Rajah (./2) :La carte Vampire V2 est équipée de 128 Mo de FastRAM qui est très rapide. EmuTOS et FreeMiNT l'utilisent de manière optimale.
Quid de la présence de la Fast/TT-RAM ?
Rajah (./2) :Le 68080 est très performant pour exécuter les instructions 68000. Dans le cas d'un jeu, l'affichage consomme beaucoup de CPU, donc l'optimisation du driver graphique est de première importance. Donc il y a fort à parier que les lenteurs viennent du driver fVDI. Quoi qu'il en soit, pour optimiser un programme, il faut utiliser un profiler pour déterminer les fonctions qui rament. Sinon on fait des suppositions à l'aveuglette.
Mon code est en GFA-68000 et VDI purs, donc c'est pas un gage de rapidité.
Rajah (./2) :Le 68080 émule un 68040 (et aussi les instructions des autres processeurs, autant que possible). A ma connaissance il n'existe pas de compilateur qui utilise les nouvelles instructions spécifiques au 68080. Certains programmes Amiga ont été manuellement patchés en assembleur pour exploiter les instructions spécifiques 68080 (principalement AMMX).
Doom recompilé semble-t-il pour 68080 dépotait, plus rapide que FireBee (moins que la version Jaguar cependant).
Tophe38 (./3) :Franchement, EmuTOS marche bien. Tous les bugs rapportés sont méticuleusement étudiés et corrigés.
Alors, ok, il faudrait que je jette un coup d’œil à Emutos, car, la dernière fois que j'avais regardé ça, je n'avais pas trouvé ça utilisable (plantage quasi constant).
Rajah (./5) :Sachant que cette probabilité est quasi-nulle (contrairement à ce qui se passe côté Amiga), quand même.
obligatoire pour ne pas être embêté si Atari réclame ses droits sur le TOS.
Rajah (./5) :Pour configurer la résolution avec mon driver fVDI, il faut manuellement éditer le fichier FVDI.SYS avec un éditeur de texte. Je ne connais pas ce menu.
Concernant la vidéo, la liste des modes rapidement proposés au boot était assez large, ça m'a donné la fausse impression que l'éventail de résolutions incluait les modes ST.
OL (./15) :Tu parles de la fonction vro_cpyfm() de la VDI interne d'EmuTOS, ou du driver fVDI en couleurs qu'on voit dans la vidéo ?
le Vro_cpyfm() de Emutos est particulièrement lent car il applique le masque même pour la copie donc il fait le boulot 2 fois!
BlankVector (./17) :OL (./15) :Tu parles de la fonction vro_cpyfm() de la VDI interne d'EmuTOS, ou du driver fVDI en couleurs qu'on voit dans la vidéo ?
le Vro_cpyfm() de Emutos est particulièrement lent car il applique le masque même pour la copie donc il fait le boulot 2 fois!
The VDI driver was so far optimized with some handwritten 68K ASM.
The driver is not yet optimized with AMMX. (this is todo)
The V4 68080 CPU and Cache controller also boosts the speed somewhat.