Logicielsmoto.com

Arf les lignes noires coutent... Mais il se passerait quoi si on ne les affichait que pour les lignes où un sprite plein apparait ?


Quitte à faire ca, que penses tu d'homogénifier le passage par les global_location1/2 ? En gros ces routines protègent U, et en interne le chargent avec location_1 puis _2. Ce sera homogène au niveau des paramètres d'appel : les global en entrée, et seul D et possiblement X seront trashés, ce qui laisse Y et U dispo. Bon X et U seraient plus pratiques dans la mesure où Y est plus couteux, mais on peut faire avec.

_________________
Good morning, that's a nice Tnetennba

Il y a deux masques de lignes noires (qui ne se chevauchent pas) :
- un pour les tiles (toutes les lignes mais à l'exterieur de la zone background)
- un pour les sprites (intérieur de la zone background une ligne sur deux)

J'ai fait la modif rapidement pour ajouter le DP dans ces deux routines + dans le décor.
Gain attendu : >2000 cycles par boucle principale ... si je ne me suis pas trompé

Dans le main_engine.asm, si tu commentes les lignes :

Tu n'affichera pas le masque de sprite (une ligne noire sur deux)

si tu commentes les lignes :

Tu n'affichera pas le masque des tiles

ça vaut le coup de compiler sans ces lignes de code, car on comprend mieux la mécanique implémentée.

En effet, c'est intéressant comme expérience

Je vois qu'on fait pas mal de "LDU <glb_screen_location_2" un peu partout dans le code, par exemple ici aussi:Je me dis que l'on gagnerait pas mal d'octets à bouger ce LDU dans la routine pointée par X (les routines d'affichage). Si tu arrives à mettre un PSHS U et un PULS U,PC dans ces routines et migrer le LDU <glb_screen_location_2 dedans, il serait intéressant de voir si cela ne réduirait pas la taille de certaines boucles, voire de l'empreinte mémoire globale.

Plus globalement parlant, il me semble que certains compilo C (CMOC je crois) passent les paramètres de fonction par des global en 1ere page. Cela épargne les registres et leur accès est quand même assez rapide. C'est vrai que sur 8bits, ca me semble une convention qui a du sens. Cela revient à considérer les entrées direct-page comme des registres secondaires. GCC6809 a une option pour cela me semble-t-il.

_________________
Good morning, that's a nice Tnetennba

Je l'avais retiré des sprites compilés justement pour une question de taille en mémoire (on a 948 sprite/tile compilés dans le projet avec le LDU <glb_screen_location_1).
Pour le LDU <glb_screen_location_2 on en trouve une douzaine dans le code je crois.

Après si le remettre dedans permet d'aller plus vite pourquoi pas,

J'ai cru comprendre qu'on utilisait 26 banques de ram. Il en reste combien de libre ?

Sinon j'ai réussi à éviter le PSHS X,U lors de l'appel des routine d'affichage en échangeant le role de X et Y (Y n'est pas modifié). Du coup c'est rigolo, car le remplissage des buffer de haute priorité se fait par un beau PSHU B,X,Y (et la dernière valeur déduite de Y par la suite).Du coup ca tourne un chouia plus vite avec l'organisation des routines de rendues actuelles, et ca économise des octets.

_________________
Good morning, that's a nice Tnetennba

cool !

Il reste 4 pages entieres de libre (28,29,30,31) de quoi caser les anims de sonic pour la spirale et les objets manquants si tout va bien.

une petite optim au passage:est équivalent à qui est plus compact et rapide. D'une façon générale les TFR entre registre d'adresse (6 cycles) sont avantageusement remplacés par un LEA (4 cycles pour un simple transfert).

_________________
Good morning, that's a nice Tnetennba

J'ai pris un peu de retard ce soir car je voulais étudier encore qq pistes, la suite demain.

J'ai trouvé une solution pour ajouter l'utilsation de S dans les pshu des routines des masquage (lignes noire) :
Par chance j'ai la couleur noire à l'index D ;-)

Lorsqu'on dessine ces lignes de masquage, on monte d'abord la page video non visible (de travail) en $A000
on va set les registres d,x,y,s et dp à #$dddd (couleur noire)
on fait nos pshu ...
l'irq est appellé, s est à $dddd, tous les registres sont donc sauvegardés dans cet écran "invisible", seuls cc, pc et u ontdes valeurs différentes de $dd
Ils produisent donc avec des points de couleur dans notre page de travail video
Mais ces points sont dans une zone de masquage justement (bas de page) donc ça ne perturbe pas nos graphismes.
Il suffit, une fois que la boucle principale est terminée, de repositionner à noir ces 10 pixels (5 octets), ce qui sera peu couteux.
Juste après on bascule la page invisible à visible : aucun artefact.

En résumé on utilise #$dddd comme stack system lors de l'appel IRQ (juste l'appel, car en début d'irq je repositionne déjà S dans un buffer )

fin de l'implémentation ce soir ...

C'est astucieux . Il sera important d'indiquer cela dans les commentaires du code pour relecture plus tard.

_________________
Good morning, that's a nice Tnetennba

ça y est j'ai appliqué :
- tes dernières modifications
- la corrections des \ en /
- l'optim s et dp sur l'affichage des masques
- l'optim dp sur l'affichage du background

J'ai commit l'ensemble du code sur le repo, voici les fichiers modifiés :



Je n'ai pas conservé le .fd du point de départ des optims pour pouvoir comparer mais on doit pas être loin des 10% de gain !!! incroyable.

Au passage j'ai noté un plantage, mais qui n'est pas du fait des optims.
Quand le personnage tombe dans le trou après le passage secret, je fais un réinit assez sommaire pour que le perso revienne au début.
Si on se déplace à droite jusqu'en bas de la première pente puis on revient en arrière ça plante. J'ai du oublier de réinit quelque chose ...

Cool .. oui il peut y avoir des bugs indépendant des optims. Il me semble en avoir isolé un dans l'affichage: on trouve 2 pixels en trop en dessus ou au dessous de Sonic



Ce bug me semble avoir été toujours là. En listant le code j'ai été surpris de trouver des LDA #$11, soit 17 pour la hauteur des sprites/tiles. Or ne font elles pas 16 plutôt ? Enfin ca n'a peut-être rien à voir car ces deux pixels pourraient être aussi des masques AND/OR générés qui sont mal placés car j'ai trouvé quelques incongruités dans certains sprites compilés (STD consécutifs avec les mêmes valeurs d'offset par rapport à U, ce qui est à minimal inutile, ou un bug de génération).

Sinon j'ai fait un profil de ce qu'il se passe durant le chargement du fichier SD:
https://www.cjoint.com/doc/22_11/LKejvD ... emmap.html

C'est instructif: 31% du temps est dans la ROM de SDDrive à lire les octets bits à bits (en $E3DA), mais plus intéressant, 18% du temps sert à sauter les 256 octets inutilisés par secteur SD (en $E40D). Je présume que tu charge le lecteur SD piste par piste avec les API du moniteur comme un grosse diskette, non ? On peut faire beaucoup plus rapide en streamant les octets en flux continu. C'est beaucoup plus rapide, et comme il n'y a pas les 256 octets de remplissage la taille du fichier *.SD serait divisé par 2. Donc un temps de chargement facilement 18% plus rapide on a plus besoin de lire les 256 octets de remplissage).

A noter: on passe aussi pas mal de temps (18% en $4054) à recopier les données du buffer secteur vers la ram. Cette partie pourrait être plus rapide avec des PSHU D probablement, mais ca n'est pas le mieux à faire.

Enfin: 13% du temps semble être passé dans la décompression.

Ce que je suggères ici (pour plus tard) pour avoir un chargement rapide en mode SD est donc: Passer la carte SD en mode flux. Récupérer les octets un a un depuis la carte SD, et les envoyer directos dans la routine de décompression. Ca devrait aller super plus vite tout en réduisant la taille du fichier SD dont 50% des données sont juste du padding.

_________________
Good morning, that's a nice Tnetennba

Après le git pull, j'ai un problème de compilation:
Que se passe-t-il ?

_________________
Good morning, that's a nice Tnetennba

Les points blancs et rouges ne sont pas des bugs mais l'affichage des "capteurs de collision" de terrain qui apparaissent en mode debug.
Il y a également un point blanc en haut a gauche qui devient rouge quand on change de "plan" (loopings)

Le mode debug s'active en effectuant un define sur debug dans le fichier properties :


ou si tu as déclaré un equate "debug" dans le code ;-) => ce qui doit être ton cas.

ça active l'appel suivant dans le main :



désolé si tu as passé du temps la dessus ... je ne t'ai pas prévenu.

Pour la version sd, c'est le même code que pour la version fd, j'utilise les routines moniteur de lecture disquette et c'est le code de sddrive qui "prend la main" sur les appels et joue son propre code.

Ceci dit je n'y avait pas pensé ... je pourrais faire un loader spécifique à sddrive qui boot direct sur sonic (ou tout autre jeu produit par notre builder)
Ainsi pas de menu sddrive et je suis libre d'accéder à la sd avec mes propres routines non liées à l'abstraction de la disquette ... oh oh oh
ça c'est une nouvelle fonctionnalité à implémenter dans la V2 du builder ;-)
Evidement ça veut dire une sd par jeu (ou un menu spécifique "maison")

Le principe actuel (chargement identique à celui de la disquette) est de charger les données lues (compressées zx0) dans un buffer et de jouer la décompression buffer => zone de destination RAM.
Evidement, avec un loader sd custom on pourrait décompresser en effectuant un "stream" depuis la sd j'imagine.

un problème de refresh eclipse ... il manque des fichiers dans mon commit ... sorry
J'ai commit les fichiers manquants et les voici en pj