bon alors je veux faire comme les grands et je me mets à l'assembleur...
Seulement mon besoin d'assembleur est pour des affichages à l'écran... En effet j'ai une grosse série de points à afficher et j'aimerai optimiser les affichages successifs de points.
Je ne demande pas le code en assembleur je vais tâcher de me débrouiller . Seulement dans le cours d'assembleur que j'ai, je n'ai trouvé que le moyen de placer des points sur un écran defini en MCGA et c'est du 300x200 manifestement. Ca ne m'intéresse pas.
J'aimerai donc savoir (si c'est dans le domaine du non-secret) dans quelle plage d'adresse mémoire sont placés les deux buffers d'écran (qu'on "switche" avec FlipBuffer()) lorsque la fonction OpenScreen() est utilisée. Comment évolue cette plage d'adresse lorsqu'on change la résolution? Tout ceci dans l'optique de placer en assembleur les points (donc les couleurs) directement dans le buffer d'écran.
Retourne l'adresse mémoire du buffer de dessin. Cela peut correspondre directement à la mémoire vidéo si la sortie est ScreenOutput() ou SpriteOutput() et permet des manipulations binaires rapides. Si 'AdresseMemoire' est 0 alors l'accès direct en mémoire n'est pas possible. Cette commande est à l'usage des programmeurs avancés. Pour obtenir plus d'informations sur le tampon, les commandes suivantes peuvent être utilisées : DrawingBufferPixelFormat() and DrawingBufferPitch().
Ta question est très clair ainsi que la réponse de comtois ...
Toutefois juste pour te permettre de te diriger mieux dans cette approche voici quelques idées / commentaires :
- l'usage du DrawingBuffer() est très efficace oui.
- l'usage de l'assembleur pas nécessairement plus intéressant pour autant (mais il y a des mais bien sur).
Le + simple est de commencer par remplacer un simple Plot(x, y, Couleur) par un PokeL(Adresse, Couleur).
Dans ce cas le calcul de l'adresse par une formule basée sur DrawingBuffer() et DrawingBufferPitch().
Par contre en se basant sur le DrawingBufferPixelFormat() il faut faire attention à ce que l'écriture du code de couleur n'est pas fait de la même manière en fonction du mode de l'écran (8/16/32 bits, en codage RCB ou BVR selon les cas).
Une fois établie la règle de calcul de l'adresse, si ton code fonctionne avec un PokeL tu pourras facilement 'régresser' en assembleur. Une bonne approche pour cela consiste à utiliser le compilateur en générant le listing assembleur (pbcompiler nomprog.pb / COMMENTED).
L'optimisation restante est parfois assez ardue, car le compilateur PB est très efficace à lui seul. Ce qui reste derrière comme possibilités consiste à trouver de quelle manière jouer sur les registres pour faire mieux. Et là en général on ne gagne pas grand chose.
La partie la plus 'coûteuse' du code généré par le compilateur ne réside la plupart du temps pas dans les instructions de calcul mais plutôt dans les instructions de transfert en mémoire. Ce qui n'est pas un défaut du compilateur mais une simple question de performances du PC (CPU + mémoire + carte graphique).
Sur mon PC une simple boucle qui dessine des pixels (couleur incrémentée de 1 pour chaque pixel suivant) sur l'écran donne des résultats comme suit :
- en utilisant un Plot() environ 3M pixels / s
- en utilisant un PokeL() environ 6M pixels / s
- en utilisant un code ASM standard environ 14M pixels/ s
- en utilisant un code ASM optimisé environ 20M pixels / s
Ces résultats montrent le gain possible mais l'effort est souvent assez rude.
Donc, comme tu le demandes, je ne mets pas de code, mais n'hésites pas ....
Slts
Mon avatar reproduit l'image de 4x1.8m présentée au 'Salon international du meuble de Paris' en janvier 2004, dans l'exposition 'Shades' réunisant 22 créateurs autour de Matt Sindall. L'original est un stratifié en 150 dpi.
Le mieux quand on veux pas de code c'est les listings en pseudo code ou plus simplement des algos ^^. Ca me rappelle que j'ai des choses à tester en assembleur, et ce sujet en fait partie ^^
Merci pour les deux réponses, je connaissai déjà le principe mais l'idée de passer par pokel ne me serait pas venu
. Seulement dans le cours d'assembleur que j'ai, je n'ai trouvé que le moyen de placer des points sur un écran defini en MCGA et c'est du 300x200 manifestement. Ca ne m'intéresse pas.