Another size optimizing compo! This time the aim is to reduce a 3D-Starfield routine by size.
3D starfields should be wellknown from amiga-demos in the early 90ies.
Since the aim should not be reached by cutting down system compatibility to gain some extra bytes, a source is provided which does all system-init, doublebuffering and screenclearing for you. You just have to add your own optimized code at the given place. More precisely this are two places - one init-routine, which is called once and can be used by you to calculate tables etc. and the main-routine. The main routine is getting a pointer to the bitplane it has to drawn on in A0.
Deadline was: saturday, june 28, 1997 at 21.00 CET.
btw thanks a lot to Morbid for providing then Init-Source ! :)
This time 12 people took part in the compo - and unlike at the SQRT-compo there are nearly
no contributions with equal length.
Sounds like easy judgeing, but this time I had problems of another kind. 3 of the 10 contributions didnt take care of all rules. Two of them didnt do proper perspective - I didnt disqualify them, since they werent very close of winning. The problem was Axis contribution. He sent me one with 62 bytes using some nice tricks, but it had a repeating pattern. The stars repeated every 256 steps. He simply cycled the Z-values instead of generating new, individual random-positions. I told it to him and he later replied , that he fixed it needing another 6 bytes. But I didnt get his new routine till today. So I will assume that his routine is 68 Bytes.
You thought that was it ? Well, me too ! But on the day after the first (earlier) deadline
I got another contribution by Raylight , which matched all the rules and had
a length of only 60 bytes. Since it was in time for the later, original deadline I decided
to let in contribute anyways. So we have a new winner!
*1 not doing real perspective transformation.
*2 not doing real perspective transformation, stars are only in 256x256 range.
So - and you thought 64 bytes (my original contribution, which was finished before I got any others contribution) is the minimum ? It isnt ! After getting Axis contribution I saw he was using a quite nice trick to shorten the amount of bytes used for perspective transformation. I substituted my perspective-code with his and managed to shorten Axis perspective transformation code by even another 4 bytes. Ending up with a 60 bytes routine ! Using another Trick I even made it to 58 bytes, without violating any of the rules - I cycled the random-numbers. Check out the code for more info :) Graham later told me, that this was, what Axis originally wanted to do in his routine.
The routine is now down to even 54 bytes..
|How does it work ?|
Explaining every single routine is a bit too time consuming. I will just publish some routines
at this page. Download a package with all contributions here.
The winning 60 byte-routine by Raylight: (no doubt, this guy is using GoldED for his sources. :) )
The winning 64 byte-routine by Azure:
This is Axis 62 byte routine, which was disqualified. Check it out anyways, since it is quite interesting.
This is Azures (some ideas by Axis) 54 byte routine, which didnt take part in the compo: