Honra em honra e parte por parte. Algo assim, nós o mergulharemos no fascinante mundo da demoscene. Hoje falaremos sobre um trabalho específico no campo da codificação de tamanho. O fato é que alguns lançamentos não apenas tiveram um status de culto em círculos estreitos - eles influenciaram direta e claramente a mente das pessoas, forçando-as a aprender o IDA Pro, observar o código e penetrar em todos os mínimos detalhes. Era simplesmente incompreensível e muito interessante como essa mágica funciona.Esta é uma cruz do Grupo de Membros da Fila - introdução de 128 bytes para PC a partir da distante 1996:
Aqui está um vídeo do trabalho:Em suma, como os avôs lutaram ... Após o sucesso do Enlight'95 na conferência FIDO DEMO.DESIGN , foi anunciado um concurso virtual para a criação de um trabalho de 128 bytes para o PC. Ele andou por vários meses, os organizadores coletaram os resultados, votaram e determinaram os vencedores. Todo o arquivo de lançamento com Demo design'96 está disponível no Pouet para revisão. O vencedor foi um cruzamento do Mad Max / Queue Members Group . O grupo QMG é de Samara, na época os caras eram estudantes de uma das universidades técnicas, e o próprio Mad Max era o líder de toda a equipe.O concurso "abalou" as mentes jovens de todo o país que os organizadores do Enlight'96 imprimiram uma impressão de camisetas com uma impressão cruzada de lixo nas costas. Aqui estão algumas fotos do arquivo:
E uma filmagem de um vídeo sobre o Enlight'96:
em março de 2020, o grupo = R MDA = (que oficialmente represento aqui) implementou com sucesso um projeto para preservação digital deste trabalho histórico. Começamos criando um vídeo ... Sim, um vídeo banal, que foi posteriormente enviado ao YouTube. Antes, por 25 anos, a versão em vídeo do cross não existia, e para assisti-lo era necessário o poderoso kung fu DosBox, que nem todo mundo possui.Em seguida, reunimos em um único arquivo todos os materiais adicionais, incluindo a cruz do código-fonte. Infelizmente, o autor não publicou o código-fonte na época; além disso, de suas palavras, as últimas alterações no trabalho foram feitas no editor HEX. Assim, o código-fonte abaixo é o contrário do original com nossos comentários:; 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
É claro que, no processo de reverter o código para a fonte, nosso programador x86 principal teve a idéia de otimização. Foi assim que o cross2 acabou - são necessários 1 byte a mais (127 em vez de 126), mas tudo o que foi otimizado é gasto em texto e som. Alteramos a cor para verde para que você não confunda visualmente estes trabalhos:Não há nenhum objetivo em zombar da herança histórica aqui, apenas qualquer codificação de tamanho pode ser otimizada em vários bytes ao longo do tempo. O tempo passou muito bem, quase 30 anos, e a otimização acabou sendo significativa - 20 bytes (quase 16% do código). Nosso trabalho tem um byte a mais que o original (13 bytes de texto foram adicionados ao código, 6 bytes de código para saída, 2 bytes por som = 21, menos 1 byte na diferença de tamanho).Na verdade tudo! A fonte cross2 pode ser encontrada no arquivo do Pouet e compará-la visualmente com o original. Muito obrigado a Peter [sapo] Sobolev e Mike [Mad Max] Shirobokov pelos conselhos e materiais durante o desenvolvimento deste projeto.--- EOF ---#FF - E um byte inteiro não é suficiente ... | Piloto)# 00 - O MBM ... | Convite para Revisão Online 2020# 01 - IBMP ... | O que são introduções?# 02 - O MBM ... | A cruz das mudanças# 03 - IBMP ... | 2B ou não 2B# 04 - IBMP ... | Tomamos BC pelos chifres# 05 - ICBM ... | Anime# 06 - IBMP ... | Canalde entretenimento do avô em meteorologia no telegrama:teleg.run/borndedHá um bate-papo ao lado do canal. Nele, você pode tentar levantar questões para o demosceno, montador, pixel art, música do rastreador e outros aspectos dos processos. Você pode ser respondido ou enviado para outros chats mais temáticos.Então eles venceram - então nós vencemos!