# 02 - Et un octet entier ne suffit pas ... | La croix des changements

Honneur d'honneur et partie par partie. Quelque chose comme ça, nous vous plongerons dans le monde fascinant de la demoscene. Aujourd'hui, nous parlerons de travaux spécifiques dans le domaine du codage de taille. Le fait est que certaines versions n'avaient pas seulement un statut culte dans des cercles étroits - elles ont directement et clairement influencé l'esprit des gens, les forçant à apprendre IDA Pro, à regarder le code et à pénétrer dans les moindres détails. C'était tout simplement incompréhensible et très intéressant de voir comment une telle magie fonctionne.

Ceci est une croix par Queue Members Group - 128 octets d'intro pour PC de la lointaine 1996:

image

Voici une vidéo du travail:



En bref, comment les grands-pères se sont battus ... Après le succès d' Enlight'95 à la conférence FIDO DEMO.DESIGN , un concours virtuel a été annoncé pour la création d'un travail de 128 octets pour le PC. Il a marché pendant plusieurs mois, les organisateurs ont collecté les résultats, voté et déterminé les gagnants. L'ensemble des archives des versions avec Demo design'96 est disponible sur Pouet pour révision. Le gagnant était un croisement du Mad Max / Queue Members Group . Le groupe QMG est originaire de Samara, à l'époque les gars étaient étudiants dans l'une des universités techniques, et Mad Max lui-même était le leader de toute l'équipe.

Le concours a tellement «ébranlé» les jeunes esprits dans tout le pays que les organisateurs d'Enlight'96 ont imprimé une impression de t-shirts avec une impression de vidage croisé sur le dos. Voici quelques photos d'archives:

image

image

image

Et un plan d'une vidéo sur Enlight'96:

image

En mars 2020, le groupe = R MDA = (que je représente officiellement ici) a mis en œuvre avec succès un projet de conservation numérique de cette œuvre historique. Nous avons commencé par créer une vidéo ... Oui, une vidéo banale, qui a ensuite été téléchargée sur YouTube. Auparavant, au cours de 25 ans, une version vidéo de cross n'existait pas, et pour la regarder, il fallait le puissant DosBox kung fu, que tout le monde ne possède pas.

Ensuite, nous avons rassemblé dans une seule archive tous les documents supplémentaires, y compris le code source croisé. Malheureusement, l'auteur n'a pas publié le code source à l'époque, de plus, d'après ses paroles, les dernières modifications apportées au travail ont été apportées à l'éditeur HEX. En conséquence, le code source ci-dessous est notre inverse de l'original avec nos commentaires:

; NASM or FASM

        org 100h

        mov bx,es
        add bh,10h              ; bx = cs + 1000h
        mov es,bx               ; es = segment behind 64k of our code (extra video buffer)
        mov ds,bx               ; ds = es

        xor ax,ax
        mov cx,ax
        dec cx                  ; cx = -1
        rep stosb               ; clear extra video buffer
        dec ax                  ; ax = -1
        mov di,0A2D0h           ; set pointer to pixel at 130,80 (col,row)
        mov cl,80
        rep stosw               ; fill 80*2 = 160 pixels by 0FFh color (draw horizontal line)

        mov bx,19A0h            ; set pointer to pixel at 20,160 (col,row)
v:      mov [bx],ax             ; draw vertical line...
        add bx,320
        ja v                    ; ...until bottom

        mov ax,13h
        int 10h                 ; set 320x200 (256 colors) graphical video mode

        mov dx,3C8h
        xor al,al
        out dx,al               ; start palette set from 0 color
        inc dx
        mov cx,0C0h*3
        rep outsb               ; set first 0C0h (192) colors to black
p:
        out dx,al               ; red component
        outsb                   ; green = 0
        outsb                   ; blue = 0
        inc ax                  ; increase color (1, 2, 3..63)
        cmp al,64
        jb p                    ; set colors 0C0h..0FFh to red gradient (from dark to saturated)

        mov ch,0A0h
        mov ds,cx               ; ds = 0A000h = vedeo segment

l:      ; bx = pixel pointer, dx = pixel pointer delta value (initial values doesn't matter)
        cmp bh,0FAh
        jae s                   ; jump if current pixel is out of screen
        mov al,[bx]             ; else get color of pixel
        cmp al,0C0h
        jb s                    ; jump if pixel color is out of red gradient range (0C0h..0FFh)

        ; flame effect
        dec ax                  ; else decrase color by 1 (make it darker)
        mov [bx+1],al
        mov [bx-1],al
        mov [bx+320],al         ; di = 320
        mov [bx-320],al         ; and fill pixels around the current by new color

        mov si,-640             ; position delta: 2 lines up
        test dh,80h
        jnz n                   ; jump if dx is negative (poor pseudorandom boolean check)
        add si,2                ; wind effect
n:      mov [bx+si],al          ; add pixel 2 lines higher than current pixel considering possible wind
s:
        ; restore cross
        mov al,[es:bx]          ; get color from extra video buffer
        or [bx],al              ; replace pixel on screen by 0FFh is al = 0FFh (slow cross redraw)
        add bx,dx               ; increase pixel pointer by (pseudorandom) delta value
        inc dx                  ; increase delta value

        or bx,bx
        jnz l                   ; loop until full screen will be processed

        in al,60h               ; read keyboard scan code
        cmp al,1
        jnz l                   ; repeat if Esc key is not pressed

        mov al,3
        int 10h                 ; set text video mode

        ret                     ; return to DOS


Il est clair que dans le processus d'inversion du code vers la source, notre programmeur clé x86 a eu l'idée d'optimiser. C'est ainsi que cross2 s'est avéré - il prend 1 octet de plus (127 au lieu de 126), mais tout ce qui a été optimisé a été dépensé en texte et en son. Nous avons changé la couleur en vert afin que vous ne confondiez pas visuellement ces œuvres:



Il ne sert à rien de se moquer du patrimoine historique ici, juste n'importe quel codage de taille peut être optimisé sur plusieurs octets au fil du temps. Le temps a plutôt bien passé, près de 30 ans, et l'optimisation s'est avérée importante - 20 octets (près de 16% du code). Notre travail est un octet de plus que l'original (13 octets de texte ont été ajoutés au code, 6 octets de code pour la sortie, 2 octets par son = 21, moins 1 octet de différence de taille).

En fait tout! La source cross2 se trouve dans les archives du Pouet et la compare visuellement à l'original. Un grand merci à Peter [grenouille] Sobolev et Mike [Mad Max] Shirobokov pour leurs conseils et leur matériel durant le développement de ce projet.

--- EOF ---

#FF - Et un octet entier ne suffit pas ... | Pilote)
# 00 - Le MBM ... | Invitation à la révision en ligne 2020
# 01 - IBMP ... | Qu'est-ce que l'intro?
# 02 - Le MBM ... | La croix des changements
# 03 - IBMP ... | 2B ou non 2B
# 04 - IBMP ... | On prend BC par les cornes
# 05 - ICBM ... | Anime
# 06 - IBMP ... |

Chaîne de divertissement de Meteorisms Grandfather dans Telegram:teleg.run/bornded

Il y a un chat à côté de la chaîne. Dans celui-ci, vous pouvez essayer de soulever des questions pour la demoscene, l'assembleur, le pixel art, la musique tracker et d'autres aspects des processus. Vous pouvez recevoir une réponse ou être envoyé vers d'autres chats plus thématiques.

Alors ils ont gagné - alors nous gagnons!

All Articles