Concours de demo en 4kb de sources

Posté par  (site web personnel) . Modéré par Fabien Penso.
Étiquettes :
0
7
fév.
2003
Démo
Le canal IRC #demoscene de freenode organise un concours de demo 4kb, mais qui a cette fois la particularité d'etre limité en taille au niveau des sources.
Pour avoir quelquechose d'equitable, il a été defini que le programme devait être écrit en C ou en C++, et utiliser SDL ou OpenGL (sans bibliothèques additionnelles). Les fichiers de données sont interdit, et le programme doit pouvoir compiler et tourner sous Linux, Windows, et MacOSX. On va bien s'amuser. Que ceux qui aiment coder comme des porcs se rejouissent, ce concours est fait pour eux. J'espere que vous connaissez parfaitement le préprocesseur C et toutes ses subtilités, vous en aurez besoin.

Aller plus loin

  • # Re: Concours de demo en 4kb de sources

    Posté par  (site web personnel, Mastodon) . Évalué à 10.

    Cela rappelle les demo contests sur st et amiga.
    es catégories étaient 4ko (la plus dure), 40ko (la plus courante) et 64ko (la plus "confortable"). Mais cette taille tenait à la fois les binaires et les données (graphisme, musique, polices,...), souvent compressées.
    la plupart des morceaux dans http://www.chiptune.com(...) viennent de ce genre de concours.

    Là, par contre, cela va être très interressant.

  • # Re: Concours de demo en 4kb de sources

    Posté par  . Évalué à 7.

    qui a cette fois la particularité d'etre limité en taille au niveau des sources.

    <troll>
    Allez, tous a vos claviers les h4k3rs:
    - pas de commentaires
    - noms de variables avec une lettre, voire 2 maxi
    - evitez les retours chariots

    Ca va donner ;)
    </troll>

    • [^] # Re: Concours de demo en 4kb de sources

      Posté par  (site web personnel) . Évalué à 10.

      la taille finale des sources est calculé par un script perl qui vire les retours charriot et les espaces.
      ma prod, quasiment fini, comporte pas loin de 60 #define, d'une ou deux lettres.
      c'est la qu'on regrette que le C n'accepte pas les accents, les caracteres speciaux, etc en tant que nom de globale/variable :)

      • [^] # Re: Concours de demo en 4kb de sources

        Posté par  . Évalué à -1.

        ma prod, quasiment fini, comporte pas loin de 60 #define, d'une ou deux lettres.

        Ma parole, c'est intelligent comme exercice de programmation, ça... Heureusement que les demo contests sont là pour dénicher les génies de l'informatique.

    • [^] # Re: Concours de demo en 4kb de sources

      Posté par  (site web personnel, Mastodon) . Évalué à 10.

      Je pense qu'il faut mieux le faire propre, et se faire un chtit prog qui diminue fortement la taille du code, justement en renommant les variables, vire les commentaires, etc.

      • [^] # Re: Concours de demo en 4kb de sources

        Posté par  (site web personnel, Mastodon) . Évalué à -7.

        T fou toi ?
        C po hack fer d vars si compr

      • [^] # Re: Concours de demo en 4kb de sources

        Posté par  (site web personnel) . Évalué à 2.

        faut ecrire un parser C quoi :)
        honnetement, le faire direct a la main est plus rapide.
        Ce que j'ai fait, c'est une sorte de squelette propre, que j'ai reduit au maximum, et apres on utilise ca pour faire les effets dedans.
        Apres, si tu veux faire un truc automatique, bonne chance :)

        • [^] # Re: Concours de demo en 4kb de sources

          Posté par  . Évalué à 1.

          Un parser C, comme tu y vas. Globalement il faut faire un reconnaisseur de la grammaire du C, c'est vrai (merci Flex!). Une fois ceci fait, il ne faut pas grand chose de plus. On doit pouvoir se passer de Bison, mais c'est vraiment violenter Flex. Enfin ca doit se faire sans grosses douleurs.

          Cela dit c'est vrai que sur 4k, tu n'en a pas pour des heures à le faire à la main :)

          • [^] # Re: Concours de demo en 4kb de sources

            Posté par  . Évalué à 3.

            Il y a beaucoup plus simple: utiliser des noms de variables qui commencent tous par "variable_", et faire le remplacement a grand coup de grep/sed. Ca devrait etre moins complique qu'un parseur C...

            • [^] # Re: Concours de demo en 4kb de sources

              Posté par  . Évalué à 3.

              oui mais ca ne change pas grand chose sur le nom explicite de la variable sauf si tu considère que la suite du nom a une caractéristique particulière (ex unicité des deux caractères suivants le "_"). Ca fait juste perdre du temps à taper "variable_" à chaque fois.

              • [^] # Re: Concours de demo en 4kb de sources

                Posté par  . Évalué à 3.

                J'ai du mal m'expliquer...

                
int var_test_arret = 0;
                
void* var_mon_gros_pointeur = NULL;

                devient

                
int v1 = 0;
                
void* v2 = 0;

                avec sed s/var_test_arret/v1/g | sed s/var_mon_gros_pointeur/v2/g.

                Et je constitue le filtre complet set avec grep, uniq, et un peu de sh. Ca me fait perdre du
                temps a taper "var_" devant toutes les variables, mais c'est pas la mort, y'a bien des libs
                ou tout commence par "gtk_" ...

          • [^] # Re: Concours de demo en 4kb de sources

            Posté par  . Évalué à 0.

            On doit pouvoir se passer de Bison, mais c'est vraiment violenter Flex

            Heu, oui, a la base flex est un analyseur lexical, pas grammatical... C'est-a-dire qu'il separe les mots-clefs, les identificateurs, les nombres mais a priori ne reconnait pas l'ordre des mots.

  • # Re: Concours de demo en 4kb de sources

    Posté par  (site web personnel) . Évalué à 4.

    Tin Jylam t'es relou !
    La scène est morte en 88 je te rappelle !

    Ca sert à rien de vouloir la déterrer !

    Qques liens pour completer:
    http://www.lnxscene.org/(...)
    http://unixscene.kameli.net/(...)
    http://www.pouet.net/(...) =)
    http://www.ojuice.net/(...)

  • # Re: Concours de demo en 4kb de sources

    Posté par  . Évalué à 0.

    Ma solution:

    D'abord on écrit une démo de ~30ko.

    Ensuite, on la compresse avec bz2 -> demo.bz2.

    Ensuite on crée un main.c. Dedans, on copie le contenu de demo.bz2 dans une variable. Ensuite, on utilise zlib pour décompresser le contenu de la variable et on lance le programme obtenu.

    C'est de la triche mais ça doit etre possible.

    PS: si on ne peut pas utiliser zlib, réécrire l'algorithme de décompression des archive bz2, ça prend combien de ko ?

    PPS: c'est pour déconner, j'imagine que ça ne doit pas ^etre possible tout ça...

    • [^] # Re: Concours de demo en 4kb de sources

      Posté par  (site web personnel, Mastodon) . Évalué à 1.

      Y'a écrit «Les fichiers de données sont interdit» . Mais bon, ça devrait peut être marcher. Et en utilisant aussi les espaces du source pour compresser, soyons fous !

      personnellement, j'y crois pas, mais celui qui y arrive aura droit à une noix (noack?) d'honneur!

      • [^] # Re: Concours de demo en 4kb de sources

        Posté par  . Évalué à 1.

        Ben en fait l'idée c'est justement de copier/coller le contenu du bz2 directement dans une variable. A la fin, on a plus qu'un seul fichier source contenant le code de décompression ET le contenu de l'archive à décompresser.

        Evidemment, comme le dit quelqu'un dans le commentaire just en-dessous, ce n'est pas classe de tricher. Surtout dans ce genre de concours où on ne devient pas milliardaire en gagnant.

    • [^] # Re: Concours de demo en 4kb de sources

      Posté par  (site web personnel) . Évalué à 5.

      Si je me rappelle bien, sur HP48, RFP était composé de 2 programmes: le décompresseur faisait à peu près 700 octets, et le compresseur environ 2K, mais comme le compresseur était lui-même compressé et utilisait de décompresseur avant de s'éxécuter vraiment on arrivait à un total d'à peine plus de 2K. Les fichiers textes se compressaient plutôt bien, et concrêtement, et il me semble que j'arrivais à produire des fichiers compressés représentant à peu près 40% de l'original. C'est certes moins bien qu'un vrai bon vieux bzip2 avec lequel on peut souvent descendre à 20%, mais c'est déjà pas mal. Sur un fichier de 8K par exemple, tu peux imaginer tomber à 3,3K et il te reste 0,7K pour loger le décompresseur.

      A part ça AMHA ce genre de technique n'est pas hyper fair play ni élégante. Contourner le règlement c'est toujours possible mais là n'est pas le but. D'un autre côté la plupart des démos vraiment petites utilisent de manière non modérée toute la panopile de compressions et d'astuces qui sont à leur disposition. Donc...

      Pour info, RFP est dispo ici: http://www.hpcalc.org/details.php?id=2369(...)
      Et le "code source" est dispo dans la mesure où c'est un programme en assembleur, donc du coup pas besoin de déssassembler pour remonter au source 8-) Sinon, l'assembleur HP48 c'est pas ce qu'on fait de plus lisible, ça a beau être du Motorola (ie beaucoup plus sympa qu'Intel) les registres de 64 bits découpés en quartets couplés à un mode d'adressage datant de l'époque de Néanderthal (traduire -> il faut charger à la mimine les registres d'adresse avec des adresses calculées/contenues au préalable dans les registres de calcul, qui ne sont évidemment pas les mêmes, ce serait trop simple) ça a tendance à rendre le code un poil compliqué.

      • [^] # Re: Concours de demo en 4kb de sources

        Posté par  (site web personnel) . Évalué à 1.

        A part ça AMHA ce genre de technique n'est pas hyper fair play ni élégante. Contourner le règlement c'est toujours possible mais là n'est pas le but. D'un autre côté la plupart des démos vraiment petites utilisent de manière non modérée toute la panopile de compressions et d'astuces qui sont à leur disposition. Donc...

        Je rapelle seulement que la c'est une compo qui a comme limitation la taille des SOURCES. donc les compressions, a part pour des eventuelles data contenues dans les sources, ca sert a rien.
        D'autre part, contourner les regles, c'est bien, si les regles sont assez carrées.
        Exemple : interdit d'utiliser des datas exterieures. Rien n'empeche de mettre les datas dans le source C. C'est une chose comme une autre, mais bon, c'est comme ca qu'on peut inclures qques images ...

    • [^] # Re: Concours de demo en 4kb de sources

      Posté par  (site web personnel) . Évalué à 3.

      1/ zlib interdite (aucune librairie autorisée sauf SDL ou OGL)
      2/ le code de decompression de bzip2, je doute tres fortement qu'il tienne en 4k DE SOURCE.
      3/ Apres, MEME si tu y arrivais, tu te retrouverais avec ... les sources de ta demo en C. de la, rien a faire, faut compiler. et comme tu ne sais meme pas sur quelle plateforme tu te trouves et que tu n'as pas le droit d'utiliser de programme externe (car pas portable), ca sert a rien.
      4/ si tu pensait a compresser la demo deja compilée, pas possible, il faut que ca soit portable.


      en theorie, on a pensé a tout dans les regles. apres, y'a ptet une faille, mais va falloir la trouver :)

      • [^] # Re: Concours de demo en 4kb de sources

        Posté par  . Évalué à 0.

        hmm... je te proposerais bien d'inclure le code de gcc dans la démo mais je doute qu 4ko suffisent :)

      • [^] # Re: Concours de demo en 4kb de sources

        Posté par  . Évalué à 2.

        en theorie, on a pensé a tout dans les regles. apres, y'a ptet une faille, mais va falloir la trouver :)
        J'avais pensé à faire un énorme tableau de data codé avec une chaine contenant uniquement des espaces et des tabulations (chacun représentant un bit, 0 ou 1), mais bon comme la taille du source avant comptage par perl est aussi limitée... beh tant pis :(

        A part ça:
        cat source.c | perl -pe 's/\s//g' | wc -c

        Excessive use of cat detected :)

    • [^] # Re: Concours de demo en 4kb de sources

      Posté par  . Évalué à 2.

      Hum, on parle d'un limite de 4K au niveau du code source pas au niveau du binaire c'est ce qui change dans cette limitation.

      quand a l'utilisation de la Zlib ou autre elle est assez courante, et pas besoin de d'emmerder avec bz2 ou autre tu a l'excelent UPX qui fait le boulo bien mieux ( compression de l'ordre d'un rapport de 0.3-0.4 sur les executables decompresseur en moin de 300 octets et decompression plus rapide que l'eclaire ).
      C'est pas specialement de la triche dans les autres compos vue que presque tous le monde fait pareil, apres c'est a celui qui optimise le mieux son code pour la compression ou qui utilisera le plus de texture et des sample procedureaux.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.