| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
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....
|
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
I can also provide oneway encrypted datajunk i created when fiddling around with crunchers like doynax :-) |
| |
Burglar
Registered: Dec 2004
Posts: 1105 |
so this will result in many compo fillers ;)
nice idea, too bad I wouldnt know where to start writing a superfast filler :/ |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Too short deadline for me I'm afraid, but I'll release a version later that beats you all. :) |
| |
Mixer
Registered: Apr 2008
Posts: 455 |
Make the ball actually round, while you're all at it :) |
| |
Skate
Registered: Jul 2003
Posts: 495 |
Do you mind if i use SuperCPU? :D
I'm so busy these days but I'd really like to attend that compo. No promises but i may join the fun. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Decided to give it a shot anyway, and I already got my first unoptimized version up'n'running. First question - why is it bigger than in your original demo? Wasn't this supposed to be a compo about making a faster version of the exact same ball? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11391 |
the original demo isnt an animation player :) |
| |
HCL
Registered: Feb 2003
Posts: 728 |
Hmm.. also got an unoptimized version running.. 7-8 frames at worst, but then the lines and fill/clear code are looped. Never mind.. the setup feels a bit strange though.. I wonder if those $5000 bytes of animation will rule out optimizations that would be possible if it was real-time.. because just as Cruzer said, i thought we were competing against the original, which was in real-time :P. Very strange this.. :) |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
Well, i have also done an animation version of this ball, with the same filling algorithm as used in the realtime version. The reason to take animated data is to make things compareable and faster. Also i said it already many times: you may change the data to your needs, as long as it produces the same output. I really don't say this for no reason, i changed the data.bin heavily for my purposes. And hey, you can use all mem, so don't complain about those $5000 bytes, it is just what our merry musicians would usually waste, right? :-P |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
Quote: the original demo isnt an animation player :)
I don't think it's so much bigger than in the realtime version, at least when being in the front and at its largest zoom. Also, it still fits into a 16x16 with safety margin, i don't see how this brings trouble :-) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 18 - Next |
