Hugi Size Coding Competition #30
category: code [glöplog]
Hi there,
I've recently coded a mediocre 256-byte intro. It is currently 238 bytes in size. I think it would be an interesting challenge to see how much it can be optimized. Therefore, I hereby announce Hugi Size Coding Competition #30. Take this code and optimize it as much as possible. Submit your new code to cdvolko (at) gmail (dot) com. You can always send me preliminary versions of your code and submit new versions until the deadline. The deadline is October 1st, 2023. I'll keep a table with the current statistics at https://hugi.scene.org/compo/.
I've recently coded a mediocre 256-byte intro. It is currently 238 bytes in size. I think it would be an interesting challenge to see how much it can be optimized. Therefore, I hereby announce Hugi Size Coding Competition #30. Take this code and optimize it as much as possible. Submit your new code to cdvolko (at) gmail (dot) com. You can always send me preliminary versions of your code and submit new versions until the deadline. The deadline is October 1st, 2023. I'll keep a table with the current statistics at https://hugi.scene.org/compo/.
Code:
;squares
;by adok/hugi
.286
code segment
assume cs:code,ds:code
org 100h
program:
push 0a000h
pop es
mov al,13h
int 10h
mov dx,3c9h
mov cx,11
xor ax,ax
pal:
push ax
out dx,al
xor al,al
out dx,al
out dx,al
pop ax
add al,6
loop pal
xor ax,ax
push ax
mov si,offset rec0
mov cl,9*4
init:
mov al,byte ptr [si]
and al,7
inc ax
mov byte ptr [si],al
inc si
loop init
start:
mov si,offset rec0
mainloop:
xor ax,ax
lodsb
mov bl,20
mul bx
push ax
xor ax,ax
lodsb
mov bh,25
mul bx
xchg ax,dx
pop ax
add ax,dx
push ax
mov dx,03DAh
wait_end:
in al,dx
test al,8
jnz wait_end
wait_start:
in al,dx
test al,8
jz wait_start
pop ax
push ax
mov di,ax
mov cl,20
xor ax,ax
emptysquare:
push cx
mov cl,20
;push ax
;mov al,12
rep stosb
;pop ax
pop cx
add di,320 - 20
loop emptysquare
xor ax,ax
mov al,byte ptr [si]
mov dx,10
sub dx,ax
xchg ax,dx
mov bx,321
mul bx
xchg ax,dx
pop di
add di,dx
lodsb
mov cx,ax
shl cx,1
square:
push cx
mov cx,ax
shl cx,1
;push ax
;mov al,12
rep stosb
;pop ax
add di,320
sub di,ax
sub di,ax
pop cx
loop square
xor ax,ax
in al,60h
dec ax
je ende
mov al,byte ptr [si]
or al,al
je decrease
mov al,byte ptr [si - 1]
inc al
mov byte ptr [si - 1],al
cmp al,10
jne cont
xor al,al
mov byte ptr [si],al
jmp cont
decrease:
mov al,byte ptr [si - 1]
dec ax
mov byte ptr [si - 1],al
or al,al
jne cont
xor al,al
inc ax
mov byte ptr [si],al
cont:
pop ax
inc ax
push ax
cmp al,10
jne next
xor ax,ax
push ax
pop ax
int 1ah
sub dl,5
and dl,7
mov byte ptr [si - 2],dl
xor ax,ax
int 1ah
and dl,15
mov byte ptr [si - 3],dl
next:
inc si
cmp si,offset enddata
jne backjump
jmp start
backjump:
jmp mainloop
ende:
pop ax
ret
; variables
rec0:
x0 db ?
y0 db ?
size0 db ?
dir0 db ?
rec1:
x1 db ?
y1 db ?
size1 db ?
dir1 db ?
rec2:
x2 db ?
y2 db ?
size2 db ?
dir2 db ?
rec3:
x3 db ?
y3 db ?
size3 db ?
dir3 db ?
rec4:
x4 db ?
y4 db ?
size4 db ?
dir4 db ?
rec5:
x5 db ?
y5 db ?
size5 db ?
dir5 db ?
rec6:
x6 db ?
y6 db ?
size6 db ?
dir6 db ?
rec7:
x7 db ?
y7 db ?
size7 db ?
dir7 db ?
rec8:
x8 db ?
y8 db ?
size8 db ?
dir8 db ?
enddata:
code ends
end program
I think it could appeal to more people to implement along a well defined rule-set rather than starting from your (rather questionable) implementation.
Now it unfortunately sounds more like "optimize my shitcode until deadline" ;)
Now it unfortunately sounds more like "optimize my shitcode until deadline" ;)
As it stands, what's the criteria of changes that can be made? Without specification the optimizations can take shortcuts and reduce mathematical accuracy, etc.
In which case here's my entry:
In which case here's my entry:
Code:
ret
I'd say that the output should be exactly the same. In previous compos we added a penalty to the size of an entry if the output was different.
Perhaps it's a bit more difficult than that this time because of the random number component, but without randomization, the output should be the same.
Perhaps it's a bit more difficult than that this time because of the random number component, but without randomization, the output should be the same.
What’s the penalty?
Adok, what is the main target? Optimize the proposed code, or recreate the given visual effect? In any case, you can optimize so that nothing remains of the original code (and program logic), but visually it will be the same.
Should I recreate the ugly artifact that occurs when the black border intersects with the red square?
Should I recreate the ugly artifact that occurs when the black border intersects with the red square?
The penalty is not defined yet. We will discuss about it in case it is necessary.
Your task is to write code that produces the same output. This also means that ugly things have to be reproduced. But I am aware that this is controversial so I might make an exception and also accept entries that look alike except the ugly side effects.
Your task is to write code that produces the same output. This also means that ugly things have to be reproduced. But I am aware that this is controversial so I might make an exception and also accept entries that look alike except the ugly side effects.
sounds like a rather uninspiring task. Best to set a goal (eg mandelbrot zoomer) in least amount of bytes
Quote:
(eg mandelbrot zoomer)
booooring.... ;)
Loose specifications and arbitrary penalties. Right. Got it.
But Sol is still the winner so far, right?
But Sol is still the winner so far, right?
OK, I've realized that my idea has been bad because of the artifacts that occur in the original program, which should not be there. But if anybody submits an entry for the compo that does the same thing as the original program, I'll gladly accept it until the deadline. There are no prizes so it's all just for the fun of it.
I think having to produce the exact same output is fine. But I'd find the challenge more interesting and fun if the starting point was some high level C code or pseudocode, rather than an ASM version that has already gone through several transformation and optimizations. Because from whatever higher level idea you started, this particular code has already fallen deep in some particular local minima (in "size optimization space"), so participants have a lot less creative room to explore in the space, where other better global minima most likely exist.
Long way to say - I feel you already optimized too much and what's left to do is not fun nor very creative.
Long way to say - I feel you already optimized too much and what's left to do is not fun nor very creative.
Reminds me of the c't puzzle competition which my colleague solved during compile-time using C++ templates (which was so complex that it bombed the MSVC compiler, but got a detailed extra-mention in the magazine afterwards). The resulting program just returned the correct answer whereas everyone else optimized for runtime-speed.
Quote:
Submit your new code to cdvolko (at) gmail (dot) com
Note:
gmail will block emails with attachments containing .com files, even if it's in a zip.
While I get where Adok is coming from with this, it doesn't feel too inspiring to try to bit-hunt someone else's code/effect.
Here's a hot take: the Function 2023 256 byte compo is in just over 2 weeks of time. Why not release something new there?
Here's a hot take: the Function 2023 256 byte compo is in just over 2 weeks of time. Why not release something new there?
Quote:
While I get where Adok is coming from with this, it doesn't feel too inspiring to try to bit-hunt someone else's code/effect.
Probably someone will be interested in optimizing someone else's code. The proposed initial code is probably not very successful, but since the main goal is to recreate the visual part, then everything is not so terrible :) Makes sense.
Quote:
Here's a hot take: the Function 2023 256 byte compo is in just over 2 weeks of time. Why not release something new there?
why not both? :) Adok's compo has deadline is October 1st, 2023.
If Gmail blocks .com files, then just send me the .asm source file.
I've got some positive feedback on the compo idea via email.
I've got some positive feedback on the compo idea via email.
The first entry has arrived.
Meanwhile we have three entries. One of them is much smaller than the other two and I was very excited when I received it. That was what I had been looking for! Competition is open till October 1st and you can send me an updated entry any time.
Ten days to go and we have a total of three entries so far. If you want to participate there is still time to submit your entry.
Could it be better if the instructions were spelled out? Something like this:
Quote:
Make an intro with black background and nine animated squares. The intro runs in mode 13h (320x200 pixels, 256 colors), waits for the vertical retrace (70 frames per second), and ends when the ESC key is pressed.
Center each square at a random position on the screen. Every time a square animation ends (= at frame 180), pick a new random position for the square and start the animation animation.
The animation has the following keyframes:
- start - frame 0: black (#000000), side length 0 pixels
- middle - frame 90: red (#F00000), side length 20 pixels
- end - frame 180: black (#000000), side length 0 pixels
The colors and side lengths of the squares are linearly interpolated between keyframes.
The animation frame of each square is random at the start of the intro.
You don't have to be precise. Bigger deviations from the spec will be penalized more.
*... and start the animation again.
Thank you for spelling out the rules!
Three days to go!
done