Honor in honor and part by part. Something like this we will immerse you in the fascinating world of demoscene. Today we’ll talk about specific work in the field of sizecoding. The fact is that some releases not only had a cult status in narrow circles - they directly and clearly influenced the minds of people, forcing them to learn IDA Pro, watch the code, and penetrate into all the smallest details. It was simply incomprehensible and very interesting how such magic works.This is a cross by Queue Members Group - 128 bytes intro for PC from the distant 1996:
Here is a video of the work:In a nutshell, how the grandfathers fought ... After the success of Enlight'95 in the FIDO-conference DEMO.DESIGN , a virtual contest was announced for the creation of 128-byte work for the PC. He walked for several months, the organizers collected the results, voted and determined the winners. The entire release archive with Demo design'96 is available on Pouet for review. The winner was a cross from Mad Max / Queue Members Group . The QMG group is from Samara, at that time the guys were students of one of the technical universities, and Mad Max himself was the leader of the whole team.The contest so “rocked” young minds all over the country that the organizers of Enlight'96 printed a print of t-shirts with a cross dump printout on their backs. Here are some archive photos:
And a shot from a video about Enlight'96:
In March 2020, the group = R MDA = (which I officially represent here) successfully implemented a project for digital preservation of this historical work. We started by creating a video ... Yes, a banal video, which was subsequently uploaded to YouTube. Previously, over the course of 25 years, a video version of cross did not exist, and to watch it required the powerful DosBox kung fu, which not everyone owns.Next, we have collected in a single archive all additional materials, including the source code cross. Unfortunately, the author did not publish the source code at the time, moreover, from his words, the latest changes to the work were made at all in the HEX editor. Accordingly, the source code below is our reverse of the original with our comments:; 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
It's clear that in the process of reversing the code to the source, our key x86 programmer got the idea for optimization. This is how cross2 turned out - it takes up 1 byte more (127 instead of 126), but everything that was optimized was spent on text and sound. We changed the color to green so that you do not visually confuse these works:There is no purpose in mocking the historical heritage here, just any sizecoding can be optimized over several bytes over time. Time passed pretty well, almost 30 years, and optimization turned out to be significant - 20 bytes (almost 16% of the code). Our work is one byte longer than the original (13 bytes of text were added to the code, 6 bytes of code for output, 2 bytes per sound = 21, minus 1 byte in size difference).Actually everything! Source cross2 can be found in the archive at the Pouet and visually compare it with the original. Many thanks to Peter [frog] Sobolev and Mike [Mad Max] Shirobokov for advice and materials during the development of this project.--- EOF ---#FF - And a whole byte is not enough ... | Pilot)# 00 - The MBM ... | Invitation to Revision Online 2020# 01 - IBMP ... | What are intro?# 02 - The MBM ... | The Cross of Changes# 03 - IBMP ... | 2B or not 2B# 04 - IBMP ... | We take BC by the horns# 05 - ICBM ... | Anime# 06 - IBMP ... | MeteorismsGrandfather’s Entertainment Channel in Telegram:teleg.run/borndedThere is a chat next to the channel. In it, you can try to raise questions for the demoscene, assembler, pixel art, tracker music and other aspects of the processes. You can be answered or sent to other, more thematic chats.So they won - so we win!