[Axe/Basic] Laser en fonction de l'angle

[Wistaro]

Dommage...

[mdr1]

Euh, désolé de te contredire, Persalteas, mais il y a un moyen de faire un code bien plus rapide. Le premier point tout à fait aberrant est de calculer sin(A) et cos(A) deux fois de suite alors que la valeur ne change pas ; il suffit de stocker ces valeurs dans des variables. Déjà, tu vas gagner pas mal de vitesse.

Mais surtout, tu devrais utiliser le pré-calculé pour ne pas sans cesse refaire des calculs inutiles. Normalement, c'est exactement ce qui se passe en Axe, en tout cas, en assembleur, on fait généralement comme ceci : inclure directement du pré-calculé. Le code devient (avec d'autres optimisations au passage) :

Code: Select all

ClrDraw
AxesOff
Degree
.2->Xmax
Ans->Ymax
-Ans->Xmin
Ans->Ymin
361->B
seq(sin(X),X,1,B->L1
seq(cos(X),X,1,B->L2
0
While 1
Ans+1-B(Ans=B
Line(0,0,L1(Ans),L2(Ans
Text(0,0,Ans
Line(0,0,L1(Ans),L1(Ans),0
End

Mon programme fait 139 octets et voici le résultat :



Bien évidemment, ça reste plus lent qu'en Axe. Mais le fait d'afficher 3 lignes au lieu d'une ne triple absolument pas le temps demandé, hein. Quand à faire cela en Asm ne permettrait que de gagner très peu de vitesse, mais surtout quelques dizaines d'octets (soit pas beaucoup), car pour ce programme, ce sont les routines toutes faites Asm utilisées par l'Axe qui sont le facteur limitant. Mais notez que ce programme n'est pas du tout plus difficile à faire en Asm qu'en Axe.

Persalteas, tu nous le fais en Grammer ?

[Persalteas]

Ah ! Je savais bien que c'était possible !

L'idée était en effet le pré-calculé, dans le temps j'avais fait un jeu du pisseur avec des valeurs enregistrées, et ça allait beaucoup plus vite que ce que je viens de trouver !

Merci beaucoup

*Persalteas s'incline encore plus bas

[mdr1]

Je n'ai rien dit, j'ai regardé le code Axe, ce serait nettement plus optimisé en Asm en taille comme en vitesse.

[Persalteas]

Sans vouloir être un troll, voici comment Xeda l'a fait en Grammer:

Code: Select all

:.0:Return
:0→A→E
:Repeat 0
:ClrDraw
:GetInc(A
:Text('ºA and 255
:62+sin(A
:/ 2→B
:94+cos(A
:/ 2→C
:Rect('47,31,C,B
:Rect('48,31,C+1,B
:Rect('47,32,C,B+1
:DispGraph
:End


112 octets

[Hayleia]

112 octets parce que toutes les routines sont dans l'application. Matref sait le faire aussi en peu d'octets, il a juste à tout mettre dans une app et utiliser son Axiome PageSwap, et bim.
Ça sert à rien de comparer la taille d'un programme en Basic et celle d'un programme en Axe, et pareil pour la comparaison Grammer/Axe.

[mdr1]

112 octets parce que toutes les routines sont dans l'application. Matref sait le faire aussi en peu d'octets, il a juste à tout mettre dans une app et utiliser son Axiome PageSwap, et bim.
Ça sert à rien de comparer la taille d'un programme en Basic et celle d'un programme en Axe, et pareil pour la comparaison Grammer/Axe.

Bien sûr que si que ça sert de comparer, on présente souvent la page d'application Grammer nécessaire pour exécuter des programmes Grammer comme un inconvénient, il est donc juste de montrer que les programmes sont d'un autre côté bien plus légers et qu'avec pas mal de programmes, la balance penche bien vite du bon côté.

[Persalteas]

Oui - par cette affirmation de "112 octets" je souhaitais dire que c'était un code relativement court et simple, en nombre de lignes à penser si tu veux.
Evidemment que les routines, ça compte pas.

J'aurais du compter en nombre de lignes, excuse-moi.

[mdr1]

Non, le nombre de lignes ne veut absolument rien dire, parfois, en Axe, on va avoir des lignes immenses et impossibles à comprendre tandis qu'en asm, chaque ligne sera toujours une instruction élémentaire triviale. Dans ce cas, je vais vous faire des programme ti basic sur une seule ligne...

[Hayleia]

112 octets parce que toutes les routines sont dans l'application. Matref sait le faire aussi en peu d'octets, il a juste à tout mettre dans une app et utiliser son Axiome PageSwap, et bim.
Ça sert à rien de comparer la taille d'un programme en Basic et celle d'un programme en Axe, et pareil pour la comparaison Grammer/Axe.

Bien sûr que si que ça sert de comparer, on présente souvent la page d'application Grammer nécessaire pour exécuter des programmes Grammer comme un inconvénient, il est donc juste de montrer que les programmes sont d'un autre côté bien plus légers et qu'avec pas mal de programmes, la balance penche bien vite du bon côté.

Bof, "avec pas mal de programmes" tu passes à une SE et tu t'en fous d'économiser de la place (c'est ce que j'ai fait en tout cas )
À la limite, j'accepte ton argument pour le Grammer. Mais est-ce que tu crois qu'on peut coder assez de programmes pour rattraper les 49152 octets de DCS ?

Oui - par cette affirmation de "112 octets" je souhaitais dire que c'était un code relativement court et simple, en nombre de lignes à penser si tu veux.
Evidemment que les routines, ça compte pas.

J'aurais du compter en nombre de lignes, excuse-moi.

En nombres de lignes ça compte pas vraiment non plus si on se met à vouloir comparer avec l'ASM aussi, là le nombre de lignes risque d'être plus gros aussi
(ce qui revient à ce que mdr1 a dit dans son ninja post)
Et oui, c'est simple à penser mais ça devient vite moche et long si on l'optimise pour la vitesse et c'est ce que Matref a fait