Hugi Size Coding Competition #30
category: code [glöplog]
bitl, have you submitted an entry? I haven't received it!
Quote:
bitl, have you submitted an entry? I haven't received it!
yes, I sent to cdvolko (at) gmail (dot) com. Look in spam.
Adok, please, check your spam folder again, I have sent updated code ;)
Got it! :)
It's the last day for entry submission now - and things are getting exciting. Don't forget to submit your entry!
Submission deadline is over and you can now download all the entries and their source code at the website - https://hugi.scene.org/compo/hcompo.htm. The next week is for discussion of the entries, in case you think an entry does not match the specification perfectly and should get a penalty. Please post to this forum at pouet.net.
My review ;)
To be honest, only rrrola fulfilled all the conditions. Which he himself formulated, instead Adok ;)
In any case, his version is the most authentic.
On the other hand, if we compare it with the visual part of the original from Adok, then only the Sniper's intro also leaves some of the squares not erased. May be author believed that this was part of the conditions? (also, why is the size indicated in the table as 145 bytes, while the Sniper's com-file size is 150 bytes?)
My version is far from the original if you compare the speed and step of the animation, as well as the thickness of the black border (which erases the previous square).
I did what I thought was best. Because when discussing the conditions with Adok, we agreed that it is not necessary to repeat all the ugly nuances, but the main thing is to convey the essence of the effect.
It seems to me that it is impossible to clearly determine the winner here, given the initially ambiguous rules. In any case, thanks to Adok, I had something to do for a couple of days.
And as a bonus: 128-byte version with sound:
This Base64, you can decode it to a file here: https://emn178.github.io/online-tools/base64_decode_file.html
Thanx to all participants ;)
To be honest, only rrrola fulfilled all the conditions. Which he himself formulated, instead Adok ;)
In any case, his version is the most authentic.
On the other hand, if we compare it with the visual part of the original from Adok, then only the Sniper's intro also leaves some of the squares not erased. May be author believed that this was part of the conditions? (also, why is the size indicated in the table as 145 bytes, while the Sniper's com-file size is 150 bytes?)
My version is far from the original if you compare the speed and step of the animation, as well as the thickness of the black border (which erases the previous square).
I did what I thought was best. Because when discussing the conditions with Adok, we agreed that it is not necessary to repeat all the ugly nuances, but the main thing is to convey the essence of the effect.
It seems to me that it is impossible to clearly determine the winner here, given the initially ambiguous rules. In any case, thanks to Adok, I had something to do for a couple of days.
And as a bonus: 128-byte version with sound:
Code:
xC9DsRZRU1D32+L5sBPNELgQEP7DivN19bA/ujED7vq6EwBfXVsD3XUJ993lQDLgA/hDgPsUfgL33VNVV7gAAovL0ekr+WnJQAEr+Yvri8vzqoHHQAEr+01184rD0OACw0tf/sx12VtKdbiD7HL79LowA7CQ7qzu7uRgSHWhzSA=This Base64, you can decode it to a file here: https://emn178.github.io/online-tools/base64_decode_file.html
Thanx to all participants ;)
Hi guys, I too was able to spend a little time on an entry, enjoying the reminiscing of previous times. As usual, without spending hours and hours on it, though I may have spent more time that I should, I get it to what I think can be the smallest, then have a look at other entries and slap my forehead with a thought of, "why didn't I think of that?"
I tried the BIOS setting of the palette technique, but couldn't get it as small as bitl did. I tried a few other things, too, but without exact rules was hesitate on keeping them. :-)
Anyway, quite impressive guys. I am always impressed with what you come up with.
As for the 145 entry, though my entry.com was 150, the reverting back to screen mode 3 was not part of the rules, and with Adok's permission, that bit of code was not included in my entry's official size.
Thank again for the memories. If there is another compo, I will surely try to participate, though hopefully there is a more detailed rule set. However I completely understand why there weren't any this time.
Thanks again,
Ben (Sniper)
I tried the BIOS setting of the palette technique, but couldn't get it as small as bitl did. I tried a few other things, too, but without exact rules was hesitate on keeping them. :-)
Anyway, quite impressive guys. I am always impressed with what you come up with.
As for the 145 entry, though my entry.com was 150, the reverting back to screen mode 3 was not part of the rules, and with Adok's permission, that bit of code was not included in my entry's official size.
Thank again for the memories. If there is another compo, I will surely try to participate, though hopefully there is a more detailed rule set. However I completely understand why there weren't any this time.
Thanks again,
Ben (Sniper)
Let me add my congratulations to Bitl and Rrrola as the clear winners. I
leave it to them to duke it out as to who actually came in first because
of any penalty assignments.
The old Hugi Coding Compos often had validation test programs that went a
long way to enforcing the rules. Screen images were verified
pixel-by-pixel. If randomness was involved, the RNG was provided along
with its starting seed.
When I first ran Adok's Squares program on a real DOS machine, it gave
very weird results. I suggested to Adok that maybe something simpler,
like displaying squares of the default palette colors might be better.
Eventually I realized his program needed to be run under DOSBox. (The
main problem was the colors were completely wrong because the color
selection register was not reset to zero.)
Hugi Compo #27 - "The Resurrection" was popular in part because it
balanced small code with a compression algorithm used to display a
self-contained ASNI graphic image. Maybe a compo that displays a
self-contained ASCII message would be of interest. (Maybe Genesis from
the Old Testament, if that's not too controversial.)
leave it to them to duke it out as to who actually came in first because
of any penalty assignments.
The old Hugi Coding Compos often had validation test programs that went a
long way to enforcing the rules. Screen images were verified
pixel-by-pixel. If randomness was involved, the RNG was provided along
with its starting seed.
When I first ran Adok's Squares program on a real DOS machine, it gave
very weird results. I suggested to Adok that maybe something simpler,
like displaying squares of the default palette colors might be better.
Eventually I realized his program needed to be run under DOSBox. (The
main problem was the colors were completely wrong because the color
selection register was not reset to zero.)
Hugi Compo #27 - "The Resurrection" was popular in part because it
balanced small code with a compression algorithm used to display a
self-contained ASNI graphic image. Maybe a compo that displays a
self-contained ASCII message would be of interest. (Maybe Genesis from
the Old Testament, if that's not too controversial.)
OK, tonight the discussion of the compo will end. Unless someone makes a last-minute complaint, there will be no penalties, so the ranking will remain the same. It has been a very nice compo and I have some ideas for future compos, in addition to what Boreal proposed. So probably this will not have been the last Hugi Size Coding Competition.
in fact I've already filed a complaint against myself :) Rrrola's code is better. Moreover, if he made some inaccuracies (like me), his intro would fit in 100 bytes.
PS: advice for future compo: no need to provide any code. An example for a task can be a GIF animation. Or a static image.
PS: advice for future compo: no need to provide any code. An example for a task can be a GIF animation. Or a static image.
I think bitl should be the winner because his entry is smaller. ;)
I've had an evening to play with different rules after the deadline and came up with a 96-byte version (8 squares instead of 9, 32x32 instead of 20x20, 256 frames instead of 180). The main savings are from basing everything on 256-step cycles.
I feel that an outer pixel loop should save a few more bytes (compared to the square loop), but didn't try it.
I've had an evening to play with different rules after the deadline and came up with a 96-byte version (8 squares instead of 9, 32x32 instead of 20x20, 256 frames instead of 180). The main savings are from basing everything on 256-step cycles.
I feel that an outer pixel loop should save a few more bytes (compared to the square loop), but didn't try it.
Code:
org 100h ; assume cx=0xff ah=0 si=0x100 bl=0
; init from program bytes, data will be at A000
mov di,0xa000
push di
rep movsb ; cx=0
pop es
mov al,13h ; set video mode
pal:
imul dx,bx,127
int 10h
mov ax,1010h ; set palette color: bl=index, dh=R=index*127/256 ch=G=0 cl=B=0
inc bl
jns pal ; bx=0x80
main:
mov si,es
mov cl,8 ; 8 squares
square_loop:
lodsw
imul di,ax,85
inc di ; di = next address of top left pixel (LCG pseudorandom)
dec byte[si] ; decrease size: new position when 0
jnz skipreset
mov [si-2],di
skipreset:
lodsb ; al=size
nega:
neg al ; 0..127,128..255 -> 0..127,128..1
jl nega
; draw a 32x32 black square with (al/8)x(al/8) red square in the center
y:
x:
pusha ; we need to push ax and bx
hv: ; if |y-r|>size or |x-r|>size, draw black
negb:
neg bl
jl negb
cmp bl,al
jb colored
salc ; al=0
colored:
shr bx,8 ; now test bh
jnz hv
stosb
popa
inc di
sub bh,8
jno x
add di,320-32
sub bl,8
jno y
loop square_loop
mov dx,3dah
wait_end:
in al,dx
test al,8
jnz wait_end
wait_start:
in al,dx
test al,8
jz wait_start
in al,60h ; ESC?
dec al
jne main
ret
Quote:
I've had an evening to play with different rules after the deadline and came up with a 96-byte version
wow, that's really cool)
may I ask? Is there a good reason why you are using full code for VSYNC? It seems that the stripped-down version still fulfills its function of limiting speed. I'm asking without mocking :) Maybe I don't understand something.
Code:
mov dx,3dah
wait_start:
in al,dx
test al,8
jz wait_startBut in visual, in this case, nothing will definitely change.
I'm only using the full vsync test because it was like that in Adok's prototype. The effect is simple and computers are fast, so the drawing might finish before the vertical retrace ends? (but that's a bit of a stretch...)
In my intros I use your version with jz, or nothing at all when there's no space left.
In my intros I use your version with jz, or nothing at all when there's no space left.
Quote:
I'm only using the full vsync test because it was like that in Adok's prototype.
Yeah. This is another reason to give me penaltie, because I cut VSync and used "halt" instead.
However, since Adok doesn’t give prizes, then who cares? ;)
Hi All,
Totally missed this Compo :(
Just registered in Pounet.
Hope to participate in future ones.
Thanks,
Mathi.
Totally missed this Compo :(
Just registered in Pounet.
Hope to participate in future ones.
Thanks,
Mathi.
