[AXE] la façon la plus rapide de dessiner des pixels en axe

Vous vous êtes souvent demander comment dessiner des pixels d'une façon particulièrement rapide Voici la solution :

on sait que l’écran est composer de 96x64 pixels et que par définition, l’écran est composée de 64 ligne de 12 octets chacun ( car un octets est égale a 8 bits et bx12=96 )

nous allons donc nous en servir

Pour cette technique, nous allons récupérer le numéro de l'octets en fonction de la position X et Y du pixels que l'on veut dessiner.

1) Nous allons récupéré le numéro de la ligne, on sait que une ligne est égale a 12 octets donc on ajuste a prendre Yx12 pour récupéré le premier octets de la ligne Y, ensuite nous allons récupéré le numéro de l'octets X en faisant tout simplement X/8.

On a donc le code :

Code:

:(Yx12)+(X/8)+L6->P

(on stocke le résultat obtenu dans la variable P. )

2)Il faut maintenant trouver le numéro du bit a allumer dans les 8 bit d'un octets, et la rien de plus simple il suffit de faire :

Code:

{A^8+GDB0}

:O :O mais d'ou vient de GDB0 ??? :O :O.

c'est enfaîte le numéro du bit a dessiner contenue dans une chaîne hexadécimal qui est celle ci

Code:

:[80402010080040201]->GDB0

cette chaîne s'explique facilement car en binaire elle donne :

Code:

-10000000
-01000000
-00100000
-00010000
-00001000
-00000100
-00000010
-00000001

3)Maintenant que l'on a tout sa, il suffit de les ajouter ensemble avec un "or" et des faire un petit dispgraph :

Code:


:.TEST
:[8040201008040201]->GDB0
:clrdraw
:0->A
:0->B
:B*12+(A/8)+L6->P
:{A^8+GDB0} or {P}->{P}
:repeat getkey
:dispgraph
:End


Et en version optimiser :

Spoiler:

Purée c'était ça le pow qui manquait

T'as oublié de dire que c'est Runer112 qui t'a dit ça |-D

oui et non car la technique e la base c'est moi qui l'ai trouvee c'est juste une grosse optimisation de runer112

Bah non, la technique à la base c'est moi qui l'ai trouvée, avec le pow. Toi t'as juste fait un truc qui marche pas

x) stop rage !
sinon excellent tutoriel par contre je ne compte pas l'utiliser pour le moment :/

c'est pas facile a mettre en oeuvre mais c'est tres utile

D'ailleurs je me demande si je devrais pas essayer de suivre cette technique avec l'ASM tiens, pour voir ce que ça donne. Je vous tiens au courant

en tout cas c'est tres rapide

oui très rapide mais trop compliqué pour moi pour le moment x)

mais non c'est juste de la manipulation d'octets

c'est bien ce que je dis... en fais je vais passer pour un faible mais je ne connais pas très bien les octet avec les calculatrice (les seuls octets que je connaissent c'est ceux du poids x) )

aaaaaah le faible

bah justement lis le tuto comprend le a fond et c'est bon

C'est pas si compliqué que ça franchement, et ça permet de faire de grosses optimisations puisque tu peux parfois te passer de code en mettant un peu plus de data. Ça vaut vraiment le coup que tu passes un peu de temps à comprendre. Demande à nikitouzz, lui qui a vu mon code de KoFiX, quel était le pourcentage de data et le pourcentage de code sur le total [Vous devez être inscrit et connecté pour voir cette image]
Et c'est quand même beaucoup plus facile à piger que les fonctions anonymes

exactement hayleia

ok bas dans ses cas là je vais m'y mettre

Alors vous tous je vous jure... j'ai fait une enorme erreur et personne ne me la dit, vous savez quoi je vous laisse la chercher

X/8 ?

Pour valider une reponse, copier le code final corriger ici.

Code:

:{Y*4*3+(X/2/2/2)+L6->r1} or {X and 7+GDB1}->{r1}

Aussi, j'ai regardé le code ASM du Pxl-On de l'Axe, bah c'est exactement la même technique, sauf que comme en ASM c'est toujours plus optimisé, ton astuce ne sert à rien.

j'ai calculer avec themachine02 le nombre de fps et ca ressembalit as du 2-3 fois plus rapide donc si mon code sert a quelque chose et si tu regarde les programme de runer112 il utilise que ca. donc meme si le code asm semble etre le meme ca va plus vite et sur ce point la j'en suis sur et l'erreur n'est pas la matref

je comprend pas pourtant l'erreur est enorme et mon code ne marche pas du tout je vous poste la reponse avec l'explications :

Code:


:.TEST
:[8040201008040201]->GDB0
:clrdraw
:0->A
:0->B
:B*12+(A/8)+L6->P
:{B*12+(A/8) And 7+GDB0} or {P}->{P}    c'est ici l'erreur car ca ne veut absolument rien dire cette ligne... il faut la remplacer par : {A^8+GDB0} or {B*12+(A/8)}->{P}

:repeat getkey
:dispgraph
:End


Mais t'es nul c'est exactement ce que j'ai dit pour l'erreur --' ton P il sert à rien là. Et c'est impossible que ça aille plus vite, l'ASM ça peut être que plus rapide (à moins que Quigibo utilise des divisions, mais ça m'étonnerait). Je vais (ré)essayer de le faire en ASM pis on verra.

c'est plutot la routine pour recuperer les machin derriere GDB0 le p je peut le laisser ca changera rien du tout. Et c'est pas impossible puisque qu'on a fait des test et que les resultat sont la.

je le refait : pour une boucle de 1000*1000 j'ai :

ma methode : 30.17
pxl-on : 47 seconde

Bah utilises ma ligne à la place des deux tiennes et tu verras que t'as pas besoin de P.

Alors si l'Axe est plus lent c'est parce qu'il calcule le pixel à afficher avec du bitshift plutôt qu'aller le chercher dans une data. Je vais essayer comme ça et ça donnera Best. Pxl-On. Ever.

J'ai certes pas besoin de P mais c'est pour aider a comprend il y a pas P dans la version optimisé il me semble.