| |
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....
|
| |
HCL
Registered: Feb 2003
Posts: 716 |
I think we will see a VQ-ed version, one-framed. Now how to set up CSAM to do the job again!? :P |
| |
Perplex
Registered: Feb 2009
Posts: 254 |
The animation won't look very good when played back at 50+ Hz, though. It rotates much too fast for that. I suggest the remaining cycles are to be used for interpolating new frames inbetween the provided keyframes. ;-) |
| |
HCL
Registered: Feb 2003
Posts: 716 |
@Perplex: Agree, very good idea. My idea is no longer to make it as fast as possible, as Cruzer already made it one-framed, with one hell of a margin as well :P. Instead i'm going for the most beautiful speed, do it with NUFLI anti-aliasing perhaps in interlace to get more color depth. I'm going for teh votes, not for the speed :). |
| |
Bitbreaker
Registered: Oct 2002
Posts: 500 |
to achieve better votes, one should place some boobs beneath the ball. |
| |
algorithm
Registered: May 2002
Posts: 702 |
@Perplex. Yes, the additional cycles can use the interleaved method of displaying frame 1 as frame 1, frame 2 as frame 1 and 2 interleaved, frame 3 as frame 3 which in turn would double the time it takes for a whole animation transition (and make it appear smoother)
@hcl. CSAM is not that much suited for outline or line based source (although with some tinkering, charmaps can be extracted and processed further. I do have an unreleased version that has an additional mean-removal before the VQ which works well for preserving edges more efficiently. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
not many things looks uglyer than playing animations like that, mayba 8x8 plasmas with +4 pixel x/y shift flicker. |
| |
algorithm
Registered: May 2002
Posts: 702 |
At 50fps it would not look that bad. Interpolating frames via the software approach would not work via pre-generated codebooks via VQ methods hence why i suggested the interleave method (although interpolated frames do not necessarily require to be placed in the codebook at all - just the closest fit to the existing codebook data) but would still require the 256 bytes (16x16) of charlookup data |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
Quote:not many things looks uglyer than playing animations like that, mayba 8x8 plasmas with +4 pixel x/y shift flicker.
using lossy compression and playing it back like that? =P |
| |
HCL
Registered: Feb 2003
Posts: 716 |
Ok, posted a first version.. Just to put some pressure on the rest of you :). |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Thanks! Had actually kinda lost the motivation and started on something else already. :) |
| Previous - 1 | ... | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | ... | 18 - Next |
