Démos Graph 90—à vos pinceaux !
Posté le 08/08/2024 23:55
Tout à l'heure sur la shout avec
Mb88 on repassait sur l'idée de faire des démos (voir
scène démo si vous ne connaissez pas). Essentiellement, c'est des programmes minuscules (aussi petits que possible) qui font des trucs graphiques stylés.
Sur Graph 90, on ne peut pas trop faire ça parce que de toute façon un add-in doit faire 28 ko rien que pour mettre l'en-tête du g3a avec les icônes... donc vous imaginez que les démos de 4 ko c'est pas la peine d'y penser. ^^"
Du coup j'ai écrit un petit programme, "Prizm Demos Loader" (PDL) qui permet essentiellement de charger des binaires purs de petite taille pour les exécuter :
Prizm Demos Loader
Comme le bare metal c'est quand même un peu chiant, le chargeur fournit à la démo :
- Un pointeur VRAM et un pointeur vers la fonction d'affichage (dupdate) ;
- Une variable qui compte automatiquement le temps écoulé en millisecondes.
Avec le loader il y a aussi une démo d'exemple toute bête qui fait une sorte de fondu de couleurs pendant 4 secondes . Quand on le compile ça donne un fichier
.pdl qui est juste un binaire pur (124 octets, plutôt optimisé !) et qu'on peut lancer dans l'add-in de chargement.
Voilà c'est très primitif encore mais c'est pour lancer un peu le mouvement. Si vous avez des commentaires ou pensez qu'on devrait s'y prendre différemment, allez-y. Je serais intéressé pour faire une mini-compétition de démos, genre 1 ko comme clin d’œil à la 1kBCJ, s'il y a des preneurs !
Télécharger pour tester :
PrizmDemos.g3a
exdemo.pdl
Copier les deux fichiers sur la calto, lancer l'add-in "PrizmDemos", sélectionner "example.pdl" (EXE)
Fichier joint
Citer : Posté le 12/08/2024 14:53 | #
1ko je pense que c'est faisable, mais assez dur aussi... Après faut voir le temps qu'on se donne, pour 24/48h ça me semble la valeur raisonable
PS : J'avais aussi commencé a faire un pong en assembleur, et à la moitié env. il fait déja 300o donc ouais c'est assez bas
Caltos : G35+EII, G90+E (briquée
Citer : Posté le 12/08/2024 14:54 | #
ça laisse que la place pour 500 instructions, c'est peu, surtout qu'on code en C.
Citer : Posté le 12/08/2024 14:54 | #
4 ko me va aussi, après tout c'est vrai qu'on n'a pas beaucoup d'expérience ici pour la plupart (moi non plus) donc peut-être qu'il faut commencer par une taille plus confortable pour laquelle on peut coder en C et minimiser "vaguement" (le temps d'apprendre à faire des dessins jolis) et plus tard réduire.
Citer : Posté le 12/08/2024 15:19 | #
Mb88, il y a 5 min : C'est trop cool https://en.wikipedia.org/wiki/Bh%C4%81skara_I%27s_sine_approximation_formula
Mb88, il y a 31 s : J'ai vite fait réussi à bricoler une fonction sin avec https://haste.breizh.pm/egunelitot.py
https://haste.breizh.pm/egunelitot.py :
org_x = x%(2*pi)
x %= pi
v = (16*x*(pi-x))/(5*pi**2-4*x*(pi-x))
if org_x > pi: v = -v
return v
Pour les démos ça peut être pratique
Citer : Posté le 12/08/2024 15:30 | #
Des fonctions cosinus et sinus en degrés avec :
x += 90
org_x = x%360
x %= 180
v = (4*x*(180-x))/(40500-x*(180-x))
if org_x > 180: v = -v
return v
def fakesin(x):
org_x = x%360
x %= 180
v = (4*x*(180-x))/(40500-x*(180-x))
if org_x > 180: v = -v
return v
Citer : Posté le 12/08/2024 18:20 | # |
Fichier joint
Merci Mb88, tes 2 fonctions sont hyper intéressantes.
Je me suis permis de te les piquer ainsi que tes opérations en FP.
Je voulais voir ce qu'on peut faire raisonnablement sans trop d'optimisation dans un espace reduit.
J'ai repris mon effet démo CubeFire que beaucoup avaient apprécié et je l'ai amené à 1604octets.
Y'a certainement moyen de le compacter encore plus car là c'est du hyper rapide.
Je vous mets tout dans l'archive jointe (le .c, le Makefile et le PDL pour tester).
Citer : Posté le 12/08/2024 18:22 | #
Trop cool ! Content que mes fonctions de fp te sont utiles, c'est aussi pourquoi je publie mon code parfois sous la unlicense.
J'essaye, ça a l'air cool. Moi aussi j'ai commencé à coder une démo.
Citer : Posté le 12/08/2024 18:23 | #
Si tout le monde a commencé peut-être qu'on peut se donner une deadline et vérifier qu'on est tous d'accord sur les règles ? Histoire qu'on ait un cadre. Perso j'ai pas commencé, je dirais pas non à un peu plus que deux jours
Citer : Posté le 12/08/2024 18:24 | #
Moi aussi, j'ai vraiment pas grand chose pour le moment
Caltos : G35+EII, G90+E (briquée
Citer : Posté le 12/08/2024 18:28 | # |
Fichier joint
On peut gagner un peu en déclarant cos(x)=sin(x+90).
Je passe de 1604octets à 1452octets, ce qui est non négligeable.
* https://en.wikipedia.org/wiki/Bh%C4%81skara_I%27s_sine_approximation_formula.
*/
fixed_t sine(fixed_t d) {
fixed_t v;
fixed_t org_d = d%TO_FIXED(360);
while(org_d < TO_FIXED(0)) org_d += TO_FIXED(360);
d = org_d;
d %= TO_FIXED(180);
v = DIV(MUL(MUL(TO_FIXED(4), d), (TO_FIXED(180)-d)),
(TO_FIXED(40500)-MUL(d, (TO_FIXED(180)-d))));
if(org_d > TO_FIXED(180)) v = -v;
return v;
}
fixed_t cosine(fixed_t d) {
return sine( d + TO_FIXED(90) );
}
Dans le ZIP la totale
Citer : Posté le 12/08/2024 18:34 | #
C'est vrai, mais pour les perfs c'est mieux de l'inline
J'ai testé c'est trop cool
Citer : Posté le 12/08/2024 18:49 | #
De mon côté c'était juste pour faire un peu mumuse.
Je suis pas trop dispo pour coder en ce moment.
Je suis dans les travaux dans ma maison.
Mais par contre, je regarderai avec beaucoup d'attention vos réalisations.
1Ko, c'est quand même chaud patate. Certainement jouable en faisant
tout enbeaucoup d'assembleur, mais du coup ça va vraiment limiter le nombre de participants.2Ko ou 4Ko semblent plus raisonnables pour une première approche, à la vue de ma première expérience.
Sachant qu'il y a des trucs qu'on paye très cher, par exemple utiliser un float...
Citer : Posté le 12/08/2024 18:51 | #
Moi je suis pour 4Ko, comme je l'ai dit précédemment pour pouvoir faire une démo avec un minimum de contenu.
Citer : Posté le 12/08/2024 18:53 | #
1Ko c'est parfaitement possible en C avec -Os je pense. Mais après ça me gène pas de faire 4Ko
Caltos : G35+EII, G90+E (briquée
Citer : Posté le 12/08/2024 18:59 | #
Le cube de sly fait déjà 1.5 Ko alors que c'est juste un cube avec des flammes : pas de texte etc. Et on a peu d'expérience en demoscene ici, comme lephé l'a dit précédemment, donc je pense que c'est bien de se laisser un peu de marge pour pouvoir faire des demos un peu sympa.
Citer : Posté le 12/08/2024 19:04 | #
Pour le fun, je vais quand même essayer de descendre la taille de la démo du cube, en restant en C, sans assembleur pour voir ce que cela peut donner.
Citer : Posté le 12/08/2024 22:23 | # |
Fichier joint
992. Notez que j'ai passé -Oz à -O2 ça marche beaucoup mieux.
Le reste des optis est hétérogène, certaines ont marché, d'autre non (e.g. Blur j'ai rien gagné).
Je voulais descendre sous 1 ko, j'ai arrêté mais on peut sans doute faire mieux encore.
Citer : Posté le 12/08/2024 23:53 | # |
Fichier joint
796. Juste après avoir posté j'ai vu des optimisations faciles sur sine(), du coup j'ai continué...
Parmi les grosses optis, virer le tableau palette et calculer les couleurs à la volée dans Render(). Les couleurs sont drôles également parce que toutes les couleurs ont une composante égale à u/2, des 1 à gauche de cette composante, et des 0 à droite, donc on peut toute les exprimer comme des décalages d'une valeur commune.
Dans l'archive précédente j'ai pas mal gagné en optimisant Bresenham pour n'avoir qu'un seul cas en échangeant x et y. Cette opti a été facilitée par l'inlining de Pixel() (sans le test de bornes, qui est superflu) ce qui a donné beaucoup de simplifications. À la fin du calcul les directions horizontales et verticales ne sont qu'une suggestion, tout ce que ça change c'est deux variables à échanger au début, et à la place de x/y y'a juste un pointeur qui se balade dans la VRAM.
Sur l'initialisation, deux choses. Le cube contient que des 0.75 et des -0.75, donc j'ai tout initialisé avec un bitmask. Ça passait bien une fois que j'ai viré rx/ry/rz de la structure (en combinant RotateVertex() et ProjectVertex(), dans lesquels d'ailleurs ont peut simplifier le calcul de divisor()) parce que du coup y'a pile 4 int par sommet, soit un total de 32 int, donc 32 bits dans le masque. Le code de cette initialisation ne prend finalement que 32 octets.
Pour l'initialisation des lignes, aucun intérêt à le faire en code, il suffit de fournir la constante. Mais sur un octet stocker des nombres entre 0 et 7 et les faire multiplier par 16 octets (la taille d'un sommet) lors de l'accès à Cube[i] est dommage. On peut prémultiplier dans le tableau ce qui évite une multiplication dans le code.
Beaucoup de choses à faire dans sine(). Pas d'angles négatifs. La réduction d'arguments peut juste retirer 180 en boucle, pas besoin de modulo. Compter si on retire 180 un nombre pair ou impair de fois (avec une variable "swap" alternant entre -1 et 1) permet de savoir s'il faut mettre un signe négatif sur le résultat final, ce que je fais avec un xor (quand x=1 ou -1, ^x et *x sont identiques à 1 bit près). La multiplication par 4 n'a pas besoin d'être en point fixe.
12 octets ont été gagnés en utilisant les flags cherchés par Fcalva, en l'occurrence -mbranch-cost=255 -mzdcbranch -fcode-hoisting -fexpensive-optimizations.
Voilà je crois que j'ai tout dit.
Citer : Posté le 13/08/2024 16:50 | #
Le lanceur segfault quand j'ai lancé une démo et que j'essaye d'en lancer une autre après. L'erreur n'est pas la même à chaque fois.
Ps : est ce que ce serait possible d'avoir une touche qui permet de tuer la démo en cours d'exécution ?
Citer : Posté le 13/08/2024 17:11 | #
Oui j'ai remarqué aussi, merci. Il faut que je vide le cache d'instructions entre deux appels, je vais modifier ça. Et oui je vais aussi programmer pour qu'EXIT arrête la démo automatiquement. Je fais ça dans l'heure un truc comme ça.
Citer : Posté le 13/08/2024 17:37 | #
Ok, cool !