| |
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....
|
| |
Martin Piper
Registered: Nov 2007
Posts: 634 |
Using lossless delta animation each frame was down to about 300 bytes. With the number of frames that meant too much memory. :( |
| |
The Human Code Machine
Registered: Sep 2005
Posts: 110 |
There are only 128 frames which will be repeated twice and this should fit into the memory! |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
Quote:Using lossless delta animation each frame was down to about 300 bytes. With the number of frames that meant too much memory. :(
damn, no need to try myself then :) funny enough, i somehow got distracted and caught myself tweaking some old line drawer of mine =P |
| |
HCL
Registered: Feb 2003
Posts: 716 |
Haha.. quite funny this. Someone sets up a goal, a bunch of guys aims their weapons, and in the end, hit targets of a great variation more or less far from the goal :D. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 500 |
it is said that there is an entry from Metalvotze that is worth waiting for. So i'll upload all entries + results as soon as it's done. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 500 |
Quote: Haha.. quite funny this. Someone sets up a goal, a bunch of guys aims their weapons, and in the end, hit targets of a great variation more or less far from the goal :D.
They are getting old and loose eyesight! :-) |
| |
Bitbreaker
Registered: Oct 2002
Posts: 500 |
Finally, there's the results, and thanks to Metalvotze, none of the serious competitors will be last :-)
So here come the results (executables):
place handle frames
god bitbreaker $24f
----------------------------
1. christopherjam $25f
2. axis $29c
3. cruzer $29e
4. hcl $2a4
5. drago $dead
As you see, i decided to be out of compo :-) Congrats to ChristopherJam pushing the eor-filler that hard to nearly reach my result and a big thanks to all that participated! Now it is time to discuss and boast in detail i guess? :-) Now show me your inballievable code! |
| |
Axis/Oxyron
Registered: Apr 2007
Posts: 91 |
Congrats to Christopher. Great work dude!
After taking a look into the code of all entries I have to say: "We are all bloody uncreative".
The code looks something like 90% identical (eor filler mostly unrolled and slopetable lines) with only small changes in the details like how the stored data is converted to slope spans.
I really hoped that someone comes up with a nice innovation. Like special code for flat lines gathering multiple pixels per store or some tricks to avoid the eor per linepixel.
I guess this has to wait until the next compo. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 500 |
So that is how it is done in my case:
All coordinates are shifted 4 pixels to the right, so that only 15 columns have to be treated (thanks to THCM for that hint) also all faces are resorted so that they are drawn from right to left, thus the left edge of all faces never will come into contact with edges from other faces, and ora'ing with already present content in the buffer can be omitted on left side.
The use of slope tables seem to be common practice, so not much to tell here. Funny enough one comes a long with rather small tables here, but the input data is bloated up by that process. To save bytes the format of data.bin was adopted quite a bit.
Stuff has been aligned to convenient places so that most of all the jump pointers can be easily calculated with 2 cycle illegal opcodes. Also a lot of code is squeezed into the zeropage and from $ff9c on, so that both code segments can be accessed via normal branches (address wraparound).
Here's the source have fun digging through it. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
Thanks, guys!
And yes, I was hoping to get away from using an eorfiller too, but my span fill attempts either took up way too much ram with tables, or were too slow, despite presorting the polys from left to right so I never needed to mask the right hand sides.
All of my slopes are taken from a single 384 byte table, but the offsets into it are all precomputed and my memory usage is pretty dire. I'm damn impressed that bitbreaker managed to get the best time in only 133 blocks!
Each edge is stored as two bytes for the address to jump into an eorfill routine, the low byte of a base pointer into the eorbuffer, and an offset into the slope table.
The eorfill routines plot up to 32 pixels, each taking its Y value from basepointer+slope[x*4+offset]. They plot two pixels at a time if the slope is low enough.
I too shifted four pixels left and four pixels up, so I only use 15x15 chars.
If I knew I could have gotten away with a single charset for display, that would have saved me a few kb to unroll some of the loops further.
Very impressed with the cleanness of some of the other entries. |
| Previous - 1 | ... | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 - Next |
