| |
Bitbreaker
Registered: Oct 2002
Posts: 500 |
Compotime: Show me your (vector)balls
After several comments arised that such an amiga-ball can be filled faster, i now want to call out a filler-compo for our coders.
Requirements:
The vector must be rendered in hires, background is white, foreground is dark red.
There's a raster-irq running that splits the screen at $2d and $f2 to set the background and border color to white and black, as seen in the screenshot. Means, there is a charline free in the bottom, that is where the benchmark results are displayed with the system charset. Displaying the result with screencodes is enough for us coders, but hex or decimal values are okay too.
The animation will be precalculated to see the power of your filler only. Therefore a data.bin is provided that contains all animationsteps for all faces with culling etc. already done.
The data structure may be altered to your needs, but not the animation itself, obvious isn't it?
The structure of data.bin is as follows:
byte x1 | $80
byte y1
byte x2
byte y2
byte x3
byte y3
byte x4 (optional, depending on if we have a triangle or quad)
byte y4 (optional, depending on if we have a triangle or quad)
As you can see faces can have 3 or 4 vertices, the first vertice is marked with bit 7 set, to be able to determine if a face consists of 3 or 4 vertices and to have a break out point for a finished frame, which is marked with the value $ff. If there's further questions about the data-format, don't hesitate to contact Bitbreaker
The filling must happen fullframe and fullsize, means, no interlacing or other cheap tricks with reducing resolution.
A counter for benchmarking must be implemented to count the frames until 256 frames have been displayed, it must be made visible in the bottom line.
The lowest value achieved counts (as there might be some jitter), for that, each entry must run in an endless loop.
The whole mem can be used, but every free byte of mem gives extra kudos.
Deadline is June 25th 0:00.
If the deadline is extended, a severe drama is expected, if not, you are out. Also i'll participate with an own entry, make a drama about it! :-)
Entries must be handed in to Bitbreaker and must not be released beforehand. They all will then released after the deadline, for maximum thrill and drama :-)
Each entry must be executeable with run.
SO DO YOU HAVE THE BALLS? |
|
... 166 posts hidden. Click here to view all posts....
|
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
How about using half sized chars (8x4 px)? The animation should still fit in memory with 128 frames and 15x30 cells without the corners. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 500 |
Quote: How about using half sized chars (8x4 px)? The animation should still fit in memory with 128 frames and 15x30 cells without the corners.
Would be possible, but it might still look crap, and actually i don't bother much pushing those frames through my various converters :-) With one charset each 16 frames it still looks kind of crap :-) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11136 |
i doubt anyone would have noticed the crap even in the one charset version =) it moves so fast, you cant really make it worse by making the charset a bit inaccurate =D (still, i would aim for non-lossy compression.... lossy is crap by definition =P) |
| |
Oswald
Registered: Apr 2002
Posts: 5025 |
interesting, now either everyone was wrong with the eor fillers so far, or bitbreaker found a corner case for span fillers. I didnt thought I will see this moving this fast though and that includes hcl's version :) |
| |
Axis/Oxyron
Registered: Apr 2007
Posts: 91 |
It is ofcourse an extreme combination of corner cases.
Hires leads to the fact that the eor fillers cant use their profit of drawing the lines only in half the resolution.
An object without any shared edges helps the span filler to avoid drawing the edges twice and avoids a lot of masking and oring at the edges.
Also the structure of the object is pretty optimal for span fillers.
So, the same fillers with different data would lead to total different results.
With a low poly object in lores I am sure Cruzer will run circles around all of us. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 500 |
Quoting Axis/OxyronIt is ofcourse an extreme combination of corner cases.
Hires leads to the fact that the eor fillers cant use their profit of drawing the lines only in half the resolution.
An object without any shared edges helps the span filler to avoid drawing the edges twice and avoids a lot of masking and oring at the edges.
Also the structure of the object is pretty optimal for span fillers.
So, the same fillers with different data would lead to total different results.
With a low poly object in lores I am sure Cruzer will run circles around all of us.
No one wants lowres anymore nowadays :-) Also i am not sure if the span filler performs worse on low poly stuff. Of course edges are shared then (what is expensive in the yet implementation, as it implies some overhead per line and face), but bigger areas that i can fill with 5 cycles per 8 pixel get filled pretty fast therefore. |
| |
Oswald
Registered: Apr 2002
Posts: 5025 |
nobody? :) I love early / mid 90's style pc/amiga LUT effects, which is usually not possible in hires.
It would be interesting to see how your span filler performs on a cube compared to eor fillers. as you say it's indeed superior when looking at larger areas (5cycles vs 8 or more). one could ofcourse buffer the edges to avoid calculating them twice, but that has some overhead aswell, so one has probably go through all the pain and code it entirelly to see wether it worths it. span fillers loose out on the edges to eor fillers (the preparations to jump into correct speedcode span & masking the edges), its hard to guess which would win. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 500 |
A cube at around same size is done in $14a frames, including different patterns per face, and without using slopetables but calculating the slopes on the fly. If anyone has the need to try i can provide the data used for that testcase. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11136 |
Quote:nobody? :) I love early / mid 90's style pc/amiga LUT effects, which is usually not possible in hires.
just do it i say :) |
| |
Oswald
Registered: Apr 2002
Posts: 5025 |
Quote: A cube at around same size is done in $14a frames, including different patterns per face, and without using slopetables but calculating the slopes on the fly. If anyone has the need to try i can provide the data used for that testcase.
$14a for 128 rotation phases? thats ~2,5 frame per phase, a nicely optimized eorfill version should be 2 or a bit more. |
| Previous - 1 | ... | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 - Next |
