Forum › Autour de l’Amiga › Amiga OS 4 – MorphOS – UAE – AROS › [UAE] WinUAE 6.0 (02/07/2025) › Répondre à : [UAE] WinUAE 6.0 (02/07/2025)

- Level 25
- Messages : 15375
WinUAE 6.0 beta 10 (23/02/2025)
https://eab.abime.net/showpost.php?p=1732957&postcount=120
Cette mise à jour inclut la plupart des optimisations prévues en mode non-ce. Tant que le mode d’affichage est normal, les performances devraient être assez bonnes même lorsque toutes les lignes changent à chaque image. Les optimisations ont encore besoin d’être optimisées (la plupart du code n’est pas optimisé car cela rend les tests et les corrections beaucoup plus faciles. Une optimisation trop précoce est rarement une bonne idée). Une partie de ces optimisations peut également être utilisée dans les modes CE mais je ne suis pas encore sûr que cela en vaille la peine car l’émulation du chipset basée sur le cycle ne peut pas être contournée comme elle peut l’être dans les modes non-ce, l’amélioration totale des performances peut être assez faible.
– Ajout d’un autre mode bitplane optimisé : si les paramètres de la ligne (DDF/DIW/BPLCON,FMODE etc. Sauf BPLCON1) n’ont pas changé mais que le contenu ou les couleurs ont changé depuis le champ précédent : dessinez la ligne directement depuis la mémoire vive (en contournant l’émulation DMA) en utilisant le mode rapide basé sur la ligne car il est garanti que c’est sans danger pour cette ligne. Pour l’instant, il ne prend en charge que les modes de plan de bits normaux (pas de HAM ni de DPF, etc., mais ces modes seront implémentés ultérieurement). Utilise actuellement un code de conversion planaire/chunky très naïf. (Un code basé sur le SSE serait bienvenu). Cela devrait améliorer les performances lorsque la plupart des affichages en mode natif changent continuellement. Maintenant, toutes les configurations non exactes au cycle devraient être aussi rapides ou plus rapides que les anciennes versions. ATTENTION : Les programmes qui ont des DDFSTRT « non alignés » ne sont pas encore corrects et auront des lignes avec un décalage horizontal mélangées avec des lignes avec un décalage horizontal correct. Le défilement sous-pixel n’est pas encore totalement supporté.
– Réinitialisation de l’état de la ligne stockée (redessiner tout l’écran) lorsqu’un changement de configuration est détecté.
– Optimisation de la logique de cycle de correspondance horizontale câblée (PAL/NTSC). Activer la logique de correspondance horizontale du mode programmé uniquement si au moins un registre de mode programmé horizontal est mis à jour, ne pas l’activer inutilement si seul le registre vertical est mis à jour. Cela devrait accélérer les modes à cycle exact.
– Le blitter immédiat dans les modes les plus rapides possibles n’était pas aussi rapide qu’auparavant. Il n’est toujours pas aussi rapide qu’auparavant car ce changement peut réduire la vitesse de l’émulation CPU pure, ce qui nécessitera des ajustements ultérieurs. Cela n’a rien à voir avec la réécriture de l’émulation de l’affichage. Par exemple, AIBB EllipseTest.
– Si Picasso96 SetSwitch() est appelé pour demander le passage en mode natif mais que le mode est déjà natif : ne rien faire et ne pas créer de message de log inutile. (Cela arrive lorsque l’on déplace des écrans en mode natif avec Picasso96 chargé, ce qui provoque des changements de configuration inutiles et des réinitialisations de l’état des lignes stockées).