faites bruler l'image de votre RAM en Grammer

comme certains ont réagi étrangement en voyant mon nouvel avatar de RAM-qui-brûle, je poste mon code source...

Code:

:.0:Return
:ClrDraw
:ClrPart
:Rect(48,20,10,24,1
:Rect(20,40,15,60,1
:For G,23,80
:Rect('G,37,G,57
:G+4→G
:End
:Text(45,9," R.A.M.
:PartType(2,"RLU,D
:Lbl "FEU→F
:FuncF
:Repeat getKey=15
:AddPart(20,56
:End
:Func0F
:Stop
:.FEU
:Fill(23,1,0,6,3,40
:RunPart
:DispGraph
:End

:D futur pro du grammer persalteas

beau code tu ne peut pas l'optimiser ? il m'a l'air bien lourd ?

La vache ... Syntaxe bizarre le Grammer, surtout pour les automates...

Lourd ? C'est compacté comme du thon en boite, ce code...

je peux gagner des octets dans le nom de la subroutine, c'est tout...
Ah et je peux enlever le "Return", mais y'aura une erreur si Grammer est pas installé.

deja compacter O_o

et comme le dit si bioen matrefeytontias la syntaxe est rudement bizarre

a quoi sert toute les fonctions tu pourrais mettre la traduction a coter sil te plait ? x)

oui x) mais sur ton code sa te prends deux seconde

edit : ton lien est pas bon...

remplacé.

bon,a lors, traduction...

:.0:Return indique que c'est un programme Grammer
:ClrDraw efface l'écran
:ClrPart efface le buffer spécifique aux particules
:Rect(48,20,10,24,1 trace un rectangle noir
:Rect(20,40,15,60,1 trace un autre rectangle noir
:For G,23,80
:Rect('G,37,G,57 trace les lignes des pattes de la RAM
:G+4→G
:End
:Text(45,9," R.A.M.
:PartType(2,"RLU,D programme le comportement que les pixels allumés du buffer-fumée devront adopter
:Lbl "FEU→F crée un pointeur vers la subroutine FEU
:FuncF allume un interrupteur vers la subroutine FEU
:Repeat getKey=15
:AddPart(20,56 ajoute une particule au buffer
:End
:Func0F éteint l'interrupteur
:Stop termine le programme
:.FEU label FEU
:Fill(23,1,0,6,3,40 fait bruler le rectangle noir sur une certaine zone de l'écran
:RunPart met a jour le buffer spécifique des particules
:DispGraph affiche les buffers sur l'écran
:End

Ouais en fait t'es un gros flemmard qui fout rien et refourgue tout aux natives ça a l'air bien ce langage dis donc, c'est corse nan ?

merci c'est toi qui a redigee le tuto ?

la syntaxe ne me rentre toujours pas dans la tete sa parait tellement illogique par rapport a l'axe...

C'est un concours ?

Mais c'est quoi ce clash organisé, là ?

Vous vous êtes concertés ?

Je trouve que c'est plutôt un avantage, d'arriver a faire de beaux trucs sans se fatiguer... Sinon autant faire de l'assembleur pur.

Et je vous assure que la syntaxe est pas difficile a comprendre, j'utilise un interrupteur, c'est tout... Kinder m'a dit que ça existait en Axe mais qu'il avait pas eu le temps de le mettre dans le tuto.

Persaeltas, si tu relis la suite des messages tu verras que j'était avec toi

Persaeltas

la deuxième fois


Sinon, à quand une adaptation pour le site du zér0 ?

Quand j'aurai ce foutu concours.

Maimaimais c'est pas un clash O.O au contraire, c'est bien qu'on puisse tout faire faire pas des natives, ça fait haut niveau.

Un langage de haut niveau est bien un langage simple on est d'accord ? (du moins plus simple que ceux de bas niveau)

Ça dépend, mais en général oui (toujours est-il plus compréhensible)

Oui, il est plus loin de l'ordinatuer et de son langage de base (binaire ou héxa)

les langages de haut niveau bas niveau ont tous desqualiter differente et des defaut differente cependant on est tous d'accord de dire que unnlangage de bas niveau offre plus de possibiliter de programmation

Oui, je suis d'accord.

Pareil. Preuve : Ti-Basic et ASM. Ou même, essayez de faire un gestionnaire de périphérique externes pour Linux en python, qu'on rigole (chose impossible sans l'ASM ou le C--)

le c-- ??? sa existe ???

en attendant quelqu'un pourrais m'expliquer comment de l'intepreter pourrais allez aussi vite que du compile ?

tout simplement car l'axe est optimisé pour le poid: il a tedence à avoir des routines plus lentes si celà permet d'économiser quelques octets.
En revanche le grammer, même si quelques micro-econdes sont perdus pour l'interprétation, les routines sont au contraire optimisé pour une vitesse optimale, coute à prendre plus de place en mémoire, mais celà reste accéptable car c'est juste l'aplication qui est plus lourde et pas le programme en soit qui lui est plutôt léger vu qu'il ne stoque pas les routines. Par contre on ne peut pas se passer de l'aplication pour lancer les programmes.

merci sandro mais la n'etait pas ma question

je voulais savoir comment l'applications traitai le programme pour qu'il aille plus vite que l'axe alors qu'il est interpreter ligne par ligne