Demomaking

Voila je suis éblouis par le génie des gars capable de coder une demo de 64ko qui contient beaucoup de textures, de la musique de qualité et qui dure 15 minutes par dessus.
Quand je vois que mon simple programme en OpenGL qui affiche 2 deux simples lignes prends deja plus de 120ko je me dis comment est ce possible ?
Si il y a des demomakers dans la salle j'espère qu'ils pourront m'éclaircir sur ces trucs et astuces qui font que les démos sont si petites et renferment tant de chose :)
Merci d'avance !

...Rassure moi... Tu ne compile quand même pas en mode debug ?????

Arg si !
Je me suis jamais penché sur la question Debug ou release quelle différence ?
mais la on dévie du sujet je crois non ?

Enfin bon en effet en release c est moins gros je me suis renseigné sur la différence.
Cependant une simple rotation de cube prends déja 40ko....

Peut être que tes demo makers utilisent des dll que tu n'a pas pris en compte dans les 64Ko

prenons cette demo :

http://www.scene.org/file.php?file=/demos/groups/farb-rausch/fr08_final.zip&fileinfo

Il n'y a q'un exécutable. (Forcément par la suite, elle s'appuit sur des dll OpenGL ou DirectX de l'OS mais rien de plus, ou autres dll créent à l'occasion pour cette démo)

C'est vrai que c'est étrange une démo aussi longue sur 64Ko. Mais déjà dans une démo tout est précalculé...Ca simplifie grandement le code...
En fait quand je cré quelquechose , je pense en premier à ce que ce sera et peut être à la fin je regarde la taille de l'exe :lol:

PS: Une version DEBUG contien des informations utiles au débuggage qui sont inutile ( et donc supprimé ) pour une version finale ( release ) d'où le changement de taille.

il l'expliquent en partie sur leur site : http://www.theproduct.de/.

il ne stocke aucune données brutes. tout est généré au début de la démo pendant le petit temps de chargement. et puis au final l'exécutable est packé avec upx.

effectivement il ne stockent aucune donnée, elles sont toute crée au depart et si tu regarde bien la quasi totalitée des trucs que tu voient sont descriptible mathematiquement, il ne reste plus qu'a les assembler entre eux pour donner l'impression d'un truc super complexe.
par exemple la fameuse cafetiere qu'on voit dans beaucoup d'exemple (et qui est même une primitive de la glu !!! ) et descriptible mathematiquement avec des surfaces courbes...

il y a une autre methode qui consiste a crée des objet en utilisant les fonction aleatoire mais en forcant le seed de la fonction donc le resultat est le même d'une execution a l'autre !!!

autrement pour les texture ce sont en fait des textures procedurales ( le plus souvent juste des assemblages de points de couleurs proches ) et d'ailleurs la plus part des textures sont des textures de beton ou autre...

enfin je decrit la des techniques simples mais il en existe d'autre comme par exemple de stoquer des texture en tres basse resolution et de les agrandire avec des technique comme l'interpolation.

sinon pour reduire la taille du code il n'y a pas de mystere... la plus part du code est fait en assembleur.

voila @+

Merci bafman j'y vois plus clair en ce qui concerne les méthodes.
Cependant quand tu dis que pour réduire la taille de l'exe y a pas de miracle , la plus part du code c est de l'asm, je me pose des questions sur le comment ?
Etant donné que ces démos utilisent des library graphiques comme Direct3D ou OpenGL, donc des fonctions de haut niveau donc pas d'asm.
Enfin je le vois comme ça.
Un autre point aussi : la musique !
Sacré bonne qualité la musique, comment ils stockent ça dans 64k ?

ça me fait quand meme halluciné, les gars arrivent à générer des textures de briques mathématiquement 8O
Quelqun aurait un exemple concret en open source ? :D

pour la musique y'a les mods ou d'autres formats (comme le .spc le format de la SNES) qui donnent une bonne qualité en tres peu d'espace
mais c toujours le meme principe que pour les graphics (creer les elements complexes de la demo avec des elements bcp + simples et donc qui occupent bcp + d'espace)

pour la musique il utilisent de la modulation de frequence de base...
en gros tu prend plusieurs channels et tu leurs envoie des fonctions mathematique genre (je presise bien "genre") cos sin et autre, appres il te rest juste a determiner la frequence que tu veut => faible pour des son graves => forte pour des sons aigues.
encore une fois ce n'est qu'un exemple, j'ai vu une demo ou il y avait de la voie donc stockages d'info plus complexes...
sinon pour generer une texture de brique ce n'est pas dur il suffit de crée une texture rouge, de tracer un trait au centre de la hauteur et 2 trait dans les demi largeure, un au premier tier, le deuxieme au deuxieme tiers, ensuite la repetition de texture fait le reste, tu passe par dessus un algo pour bruiter (ajouter du "bruit") la texture et voila...

Qand je dit qu'il generent des truc mathematiquement je veut dire qu'il utilise des fonctione mathematique mais le reste c'est souvent de l'algorithmique asser simple dans le principe.

ça doit etre vachement interressant tout ça :)
Personne a des liens vers des démos dans ce genre avec des sources ?

dans le meme genre de compression assez hallucinante, tu peux telecharger un fps: kkrieger sur http://www.theprodukkt.com/ . Ils utilisent aussi des generation de textures et sons.