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/.

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
added on the 2023-08-20 15:05:59 by あどく あどく
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" ;)
added on the 2023-08-22 10:48:13 by hfr hfr
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:
added on the 2023-08-23 13:28:45 by sol_hsa sol_hsa
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.
added on the 2023-08-23 14:44:09 by あどく あどく
What’s the penalty?
added on the 2023-08-23 17:22:12 by evilpaul evilpaul
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?
added on the 2023-08-23 17:51:43 by bitl bitl
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.
added on the 2023-08-23 18:51:16 by あどく あどく
sounds like a rather uninspiring task. Best to set a goal (eg mandelbrot zoomer) in least amount of bytes
added on the 2023-08-23 20:56:22 by Navis Navis
(eg mandelbrot zoomer)

booooring.... ;)
added on the 2023-08-23 21:05:24 by bitl bitl
Loose specifications and arbitrary penalties. Right. Got it.

But Sol is still the winner so far, right?
added on the 2023-08-23 21:15:14 by evilpaul evilpaul
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.
added on the 2023-08-24 08:04:41 by あどく あどく
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.
added on the 2023-08-24 10:13:00 by iq iq
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.
added on the 2023-08-24 11:45:06 by noname noname
Submit your new code to cdvolko (at) gmail (dot) com

gmail will block emails with attachments containing .com files, even if it's in a zip.
added on the 2023-08-24 13:12:30 by bitl bitl
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?
added on the 2023-08-24 15:03:18 by BoyC BoyC
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.

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.
added on the 2023-08-24 16:24:18 by bitl bitl
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.
added on the 2023-08-27 17:08:10 by あどく あどく
The first entry has arrived.
added on the 2023-09-04 06:53:42 by あどく あどく
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.
added on the 2023-09-07 15:12:17 by あどく あどく
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.
added on the 2023-09-20 06:46:50 by あどく あどく
Could it be better if the instructions were spelled out? Something like this:

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.

BB Image
added on the 2023-09-23 00:48:55 by rrrola rrrola
*... and start the animation again.
added on the 2023-09-23 00:53:53 by rrrola rrrola
Thank you for spelling out the rules!
added on the 2023-09-23 08:51:12 by あどく あどく
Three days to go!
added on the 2023-09-27 06:53:03 by あどく あどく