| |
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....
|
| |
algorithm
Registered: May 2002
Posts: 705 |
@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: 5095 |
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: 705 |
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: 11391 |
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: 728 |
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. :) |
| |
HCL
Registered: Feb 2003
Posts: 728 |
Well, if i had it one-framed already, i would also start on something else ;). ..or stable 2-framed also for that matter.. I didn't do anything magic there at all so if anyone has just something better than 1992-standard, you will probably beat me. But we're supposed to beat Bitbreaker right, so just had to come up with something.
No matter how i think around this, it boils down to something very similar to Cruzer's "hard-line" from YKTR. Feels lame to implement that, since that is probably where Cruzer starts, and optimizes more from there :P.. But since there is an average of ~90 short lines per frame, it is very important to keep a low overhead on the line drawing. I tried a faster line routine with pre-calced div-values but it ended up slower anyway by just fetching those values from the tables (!). |
| |
Oswald
Registered: Apr 2002
Posts: 5095 |
I have similar feelings. I would precalc all possible lines, including the 'trick' of setting many pixels by one sta. each line would be as long as the longest of the used angle, put rts as needed. also precalc shifted versions. then through ZP setup you can access the whole 16x16 matrix. You can save half of the zp setup by using the 7th bit in Y. store the animation as jumptables already into the speedcodes. Then unroll the filler. then realize you're out of mem :)
I did not start on this since I think cruzer and others would do the same. And as counterintuitive as it is, maybe its true that Bitbreakers raster fill method is better for this. |
| |
HCL
Registered: Feb 2003
Posts: 728 |
@Oswald: Damn, seems you're a bit ahead of me in the details of the hard-line, but i figured most of it :). Yeah, it's some hell of a job to set up all that, and i'm afraid if i do it i will make other things slower so i don't gain anything in the end(?).. Perhaps i will try anyway, i think there is just enough memory, but then again perhaps i'm refusing to see some part of it all..
That's sort of why i posted this one. It's just plain and simple, and it does the job not too badly. It is a tiny bit faster than Bitbreaker's original, so if i did the realtime calculations perhaps it would end up on par.. so what did i prove then? |
| |
Oswald
Registered: Apr 2002
Posts: 5095 |
cool :) so if a plain lineroutine is faster, then unrolling will do even more.
did some estimates. just by looking at the screenshot lets say one line is max 24 pixels.
ldy #$00 ;can be skipped sometimes or replaced by iny/dey
lda (),y
ora mask,x ;save the set up of 8 masks when shifting horizontally
sta (),y
makes 9 bytes. 24 pixel radius needs about 74 angles (half of 360 is enough)
24*9*74= 15984 = 16k. pretty good! it would be smaller as near vertical lines doesnt set all 24 pixels, also trough table juggling its still possible to set more than one pixel by one lda ora sta AND shifting horizontally, but only worths it at near horizontal lines.
storing jump addies instead of coords is not possible tho, as it would blow up the anim data (p1->p2, p2->p3, p3->p4, instead of p1->p2->p3->p4) |
| Previous - 1 | ... | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | ... | 18 - Next |
