| |
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....
|
| |
Bitbreaker
Registered: Oct 2002
Posts: 500 |
Quoting HCL
Bitbreaker's ball was fast, ok, but you have also had two compos to optimize it ;). Besides i still think that span-filling is slower if you realtime-calc the vectors, hmm. that requires a proof i suppose :P ..and you *are* having double buffers, so it would be a piece of cake to do it bug-free then!?
What you mean with bug free? without tearing? In fact the tearing is not too heavy on the real machine. I might vsync but loose a few frames by that. Redoing the clearing to make it happen linewise and not columnwise would help, to make the synching happening within a tighter range.
As for realtime calced vectors i'd need ~$33e for just the filling and calculations coming along with that, if i remember correctly.
Also i had to do many things on that filler from scratch or can we take that as a hook for some serious drahma please? :-P |
| |
PopMilo
Registered: Mar 2004
Posts: 145 |
Thanks!
Thank you Bitbreaker for making this compo, thank you all who showed how to code this thingy...
My take on this - we need more of these small, focused competitions! |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
An eorfiller with double buffers can be tear free without losing any frames by only changing $d016 in the IRQ, but any plotter that spends most of its time writing the the final bitmap requires triple buffers for the same effect - and if you've unrolled code dedicated to each buffer, that eats memory fast.
@HCL, the looped clear+fill costs me an extra few thousand cycles per frame, but it frees up memory for more unrolled speedcode fragments, which saves me more time than I lose to the loops.
As it is I'd hoped to spend an evening tuning how much memory I allocate to each of the clear, fill, and edge routines to optimise cycles, but like you I misread the deadline!
The speedcode uses a mix of inlined and JSRs for incrementing the column pointer, with inlines on the more commonly used cases towards the ends of the routines, but JSRs to save RAM on the less used cases. Again, the distribution's probably not all that optimal.
I draw lines left to right or right to left depending whether the slope is up or down; this way I only have positive slopes in my slope table. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
darn. i find myself working on the damned packer now, because i think a both faster AND shorter version (than the ones shown) is within reach. damn urge to code useless crap it is =) |
| |
The Syndrom
Registered: Aug 2005
Posts: 56 |
apart from the animation-approach I even think Shadows very nice version can be improved, if you split the charsets into 4 or 8 to gain full resolution. You'd still need some kind of preprocessor to sort/match the charsets to the 128 frames. |
| |
Shadow
Account closed
Registered: Apr 2002
Posts: 355 |
Actually, by just using a custom-charset instead of the standard C64 one, I think I could get something that looks considerably better (especially given the very fast rotation speed at 50 fps).
Hmm... maybe I will give it a try just for fun! |
| |
algorithm
Registered: May 2002
Posts: 702 |
Having it look good at 50fps would require either more of a smoother transition between each frame (256 frames+) or some type of interpolation.
Notice frame by frame how some frames are near identical or/and with char flipping can be reused. |
| |
Shadow
Account closed
Registered: Apr 2002
Posts: 355 |
Quote:Actually, by just using a custom-charset instead of the standard C64 one, I think I could get something that looks considerably better
I hereby retract the statement above. It looked like crap! I would proably need more intelligence in the charset analyzer, the "as-few-bits-diff-as-possible"-method didn't cut it at all. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 500 |
dear animators,
here's my petscii attempt
and ugly attempt (charset with 256 individual chars for all frames) |
| |
PopMilo
Registered: Mar 2004
Posts: 145 |
@Bitbreaker: Good enough to totally distract me on workplace!
Looks decent on larger surfaces... Not bad at all. |
| Previous - 1 | ... | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 - Next |
