Il est spécifiquement conçu pour ceux qui souhaitent réaliser des intros 4k (voire 1k), et ne fonctionne que pour x86_64. Pour des tailles supérieures, je doute que ses avantages contrebalancent ses limitations.
Distribué sous GPL 3, il est écrit en python et disponible sur [http://www.alrj.org/projects/bold/]. Toute suggestion, amélioration, critique ou remarque est la bienvenue.
La partie "runtime", qui peut être incluse dans le binaire final, est écrite en assembleur et bénéficie d'une exception à la GPL, un peu comme le runtime de GCC.
Les principales caractéristiques de Bold sont les suivantes :
- En-têtes ELF limités au strict minimum
- Structures internes (particulièrement la table DYNAMIC) réduites à leur plus simple expression.
- Résolution des symboles externes par hash, pour ne pas embarquer dans le binaire les noms de fonctions à rallonge (OpenGL est parfois champion pour ça)
- Réordonner les différentes sections jusqu'à trouver l'arrangement qui compresse le mieux
- Porter la chose pour x86, en 32 bits
# Intéressant
Posté par Damien Thébault . Évalué à 10.
(On a déjà vu des projets comme gold proposer des linkers alternatifs pour certaines fonctionnalités, ici c'est une autre direction)
D'ailleurs, il y a quelques posts de Flameeyes (qui poste notamment sur Planet Gentoo), qui sont intéressants à lire:
http://blog.flameeyes.eu/2008/04/11/about-gold-and-speed ("sub-string collapsing" ?)
http://blog.flameeyes.eu/2006/09/22/sometimes-i-think-im-was(...) (-fvisibility)
Sinon j'ai quelques questions :
Quelle est la méthode utilisée pour compresser et décompresser le code? J'imagine que le décompresseur doit être intégré au début de l'exécutable, suivi de l'exécutable réel compressé?
Quel est l'algorithme utilisé, lzma/xz (XZ Embedded?), bz2, gz? J'imagine que d'un côté c'est bien de pouvoir beaucoup compresser, mais en 4k il n 'y a pas beaucoup de place pour avoir un décompresseur trop complexe.
[^] # Re: Intéressant
Posté par Amand Tihon (site web personnel) . Évalué à 10.
Je ne me suis pas penché sur le problème du "sub-string collapsing" parce qu'en général, quand le binaire est limité en taille de cette manière, peu de bibliothèques sont utilisées (SDL et GL suffisent souvent). Les noms des bibliothèques étant les seules entrées de la strtab, les collisions sont virtuellement inexistantes.
En ce qui concerne la compression, bold ne fait rien lui-même. La solution retenue et communément acceptée est d'utiliser un dropper, une petite ligne de script shell insérée avant le fichier compressé.
#!/bin/sh
a=/tmp/I;tail -n+3 $0|zcat>$a;chmod +x $a;$a;rm $a;exit
[binaire compressé]
De cette manière, le décompresseur est très court. Ceux qui veulent jouer la sécurité peuvent se baser sur gzip, mais lzma commence à être de plus en plus présent et même à faire partie des paquets "obligatoires" des grandes distributions (j'ai déjà recensé debian, opensuse, mandriva, slackware, gentoo, arch, fedora, ubuntu). bzip2, lui, est rarement efficace sur des petits fichiers.
Il y a des gens qui retirent même le shebang du dropper, mais en pratique, je constate que ça pose quand même pas mal de problèmes.
# Scène démo
Posté par Frédéric Massot (site web personnel) . Évalué à 10.
On parle de démo, d'intro et de la scène démo :
- Les démos sur Wikipédia : http://fr.wikipedia.org/wiki/Demomaking
- La scène sur Wikipédia : http://fr.wikipedia.org/wiki/Sc%C3%A8ne_d%C3%A9mo
- La vidéo de Second Reality, une démo mythique : http://www.youtube.com/watch?v=8G_aUxbbqWU
[^] # Re: Scène démo
Posté par Kerro . Évalué à 6.
Précisions: cette démo fonctionnait sans problème sur un 486DX2-66 (moins de 30 millions d'instructions par seconde) sur du matériel non accéléré (pas de vidéo accélérée, pas de carte son élaborée, et je crois pas d'utilisation de coprocesseur arithmétique) et sur 2 Mo de mémoire.
A l'époque, c'était vraiment une tuerie.
[^] # Re: Scène démo
Posté par Amand Tihon (site web personnel) . Évalué à 6.
Il en existe même une version pour Commodore 64, assez incroyable : [http://www.youtube.com/watch?v=zVPW40ygds4] !
Par la suite, on a également vu apparaître une version "live", Real Reality: [http://www.youtube.com/watch?v=-Da6e-BjhWM].
[^] # Re: Scène démo
Posté par Kerro . Évalué à 2.
C'est vrai que c'était typique de l'époque. Tout comme les mecs qui pondaient un tracker en deux jours (les gars de Triton je me souviens, du genre "ouais bon ben les trackers existants ne me vont pas, j'en code un". Hop, deux jours plus tard c'est fait) ou ceux qui voulaient utiliser le mode protégé plus facilement (hop, je fais une bibliothèque, ça a donné heu... je ne me souviens plus du nom, mais utilisé par tous le monde ensuite).
[^] # Re: Scène démo
Posté par Kerro . Évalué à 6.
C'était Tran qui avait créé PMODE (DOS extender http://en.wikipedia.org/wiki/PMODE ). J'ai retrouvé sa trace car je me suis toujours souvenu de sa superbe démo Timeless (http://www.pouet.net/prod.php?which=2878 ) qui n'a rien de techniquement terrible, mais que je trouve vraiment chouette. Pour un codeur, il se débrouille très bien en graphisme et musique (tout est de lui).
Et, tadaaaam, Timeless est portée sous Linux ! Et Windows, et d'autres plateformes. C'est vrai que ce type avait l'habitude de fournir son code, ce qui n'était pas courant à l'époque.
[^] # Re: Scène démo
Posté par goofy . Évalué à 4.
J'ai un peux lâcher l'affaire depuis la fin des études…
[^] # Re: Scène démo
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Aujourd'hui la moindre équipe de dev de jeu est composé d'une quinzaine de personne, sans compter les graphistes et autres musiciens.
De plus les systèmes d'aujourd'hui sont infiniement plus complexe qu'à l'époque et avec l'utilisation du HW 3d tous les rendus se ressemblent.
Bref, il n'y a plus vraiment de place pour briller avec une démo.
Mais je suis sûr que l'on pourra me montrer quelques contre exemple.
"La première sécurité est la liberté"
[^] # Re: Scène démo
Posté par dinomasque . Évalué à 2.
Les compétitions de démos de 64Ko voire 8ko ou même 4ko sont stupéfiantes.
BeOS le faisait il y a 20 ans !
[^] # Re: Scène démo
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Il utilise quoi comme téchnique ? Les shaders ou cela reste du pure ASM x86 ?
"La première sécurité est la liberté"
[^] # Re: Scène démo
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Faut quand même satisfaire l'ordinateur, eh !
C'est pas parce qu'il y a moins de mouvements de bit qu'il faut "travailler moins" là !
[^] # Re: Scène démo
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Scène démo
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
Relis à haute voix le message à qui tu répondais, le tien, le mien.
[^] # Re: Scène démo
Posté par Frédéric Massot (site web personnel) . Évalué à 2.
Il y a des démos sous Linux, mais pas les dates : http://www.scene.org/search.php?search=linux&x=0&y=0
[^] # Re: Scène démo
Posté par Pierre Bourdon . Évalué à 2.
# .
Posté par Troy McClure (site web personnel) . Évalué à 4.
Pourquoi ce choix, est-ce parce que le x86-64 est plus dense que le x86-32 ou bien est ce que c'est juste un choix arbitraire ?
[^] # Re: .
Posté par Amand Tihon (site web personnel) . Évalué à 10.
Toute la logique du link est strictement identique en 32 et 64 bits, "seules" les structures de données diffèrent. Il n'est pas du tout exclu que bold supporte un jour le x86-32, voire même d'autres architectures (là je m'avance peut-être un peu, encore que...).
Certaines parties on un peu été codées à la Rache® et demanderont une réorganisation pour pouvoir gérer le 32 bits facilement.
Bon, je dois aussi admettre que l'esprit de la Demo, c'est un peu de faire ce que personne n'a fait avant et les intros pour x86_64 sont rares :)
¹) Comme je n'utilise pas du tout la libc, il faut faire appel aux syscalls, qui ne sont pas couverts par la couche de compatibilité 32 bits offerte par Linux. Cela dit, le runtime de bold n'en utilise qu'un : SYS_exit.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.