| |
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....
|
| |
HCL
Registered: Feb 2003
Posts: 728 |
..No it's not a looped line, it's a 1992 standard unrolled bresenham:lda #
ora LineBuf,y
sta LineBuf,y
txa
sbc ydiff
bcs *+7
iny
adc xdiff
bcc *-3
tax
The lines are up to 30 pixels long (dx or dy), so you need some more space than you mentioned..
One optimization i can give away is to skip the "ora" in the code above, which i thought would be possible for quite a few lines. Would be easy to store as a single bit in the animation (the last unused bit per vertex-pair), though my measurements showed it's just ~20% of the lines that it applies to -> no go.
Also have not come up with any better way to store the vertexes, that doesn't eat up more precious memory :P. |
| |
Oswald
Registered: Apr 2002
Posts: 5095 |
sorry, I meant unrolling even the slope calcs into ldy #'s :)
why looping on calculating the slope? for such lines use log div, for the rest the non looping bresenham. but you should know that :) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
I was considering cheating horrendously by storing for the top and bottom of each character-aligned 8 pixel wide slice of each polygon a y-value and an index into a table of edge patterns (short lists of y offset/bitmask pairs), but given that there are over 10,000 such slices over the 120 frames, I don't think I'll have the memory for that approach; even 4 bit y deltas plus 12 bit pattern indices don't leave me enough space for the ~3800 pattern definitions required
Back to the drawing board. |
| |
Oswald
Registered: Apr 2002
Posts: 5095 |
Quote: I was considering cheating horrendously by storing for the top and bottom of each character-aligned 8 pixel wide slice of each polygon a y-value and an index into a table of edge patterns (short lists of y offset/bitmask pairs), but given that there are over 10,000 such slices over the 120 frames, I don't think I'll have the memory for that approach; even 4 bit y deltas plus 12 bit pattern indices don't leave me enough space for the ~3800 pattern definitions required
Back to the drawing board.
damn i dont understand a word :) |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Yup, as you correctly guessed I started out with the hardliner concept. And I'm only at about 2.5 frames so far, but hey, it's just about beating BitBreaker. :)
I haven't done any specialized line routines yet, so the pixels are just being drawn one by one. But I have some plans similar to Oswald's (I think) about drawing multiple pixels in one sta, as well as omitting the eor for the lines that don't share any bytes with other lines. Why are you guys using ora btw?
But optimizations like that are of cuz only worth it if they aren't eaten up by increased administration costs, which are already a huge part of it with a lot of small lines, so I have also worked on getting them reduced. I'm still using BitBreaker's original data, but if I reorganized them so the lines wouldn't have to start from scratch each time in guessing stuff like which of the 4 main directions it's pointing, whether it's flat, etc. it would help a lot. |
| |
Sorex
Account closed
Registered: Nov 2003
Posts: 43 |
Quoting Bitbreakerany blocky animation will be deteced within no time and a serious drama will be generated upon it, be sure about that! :-)
I'm not good at this stuff at all so I'm not planning to compete.
And I don't know if speedy fillers use tricks like 8 pixel fills to speed up things so is that counted as a blocky animation aswell then even when it actually "draws" it at each frame?
Or is only 1 pixel fill allowed? |
| |
HCL
Registered: Feb 2003
Posts: 728 |
@Oswald: yeah, that's what i did, i even had a precalced div table.. but just finding the values in the table ate up the benefit of the faster line. Though the bresenham is faster on flat lines, plus that the steap lines are quite short.
@Cruzer: of course it is EOR, not ORA. So, do you have any mem left for further development? |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
@HCL: About $2a00 free + various holes in the data/code. And it might be possible to gain some more by packing the coords, but of cuz only if the freed up data can be used for optimizing the whole thing more than the depacking takes. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
@Cruzer, are you already down to 46,500 cycles? (I'm assuming 19656-43*25=18581 cycles available per frame; should really be less once the raster IRQ is factored in)
I think I've only just worked out a way to get that low, and I've less than $1e00 bytes remaining :-/ All my grandiose plans for getting below 2 frames turned out to need at least 70k of ram, unless you count VQ :p |
| |
Kisiel
Account closed
Registered: Jul 2003
Posts: 56 |
so maybe is good idea to use memory expansion, like 1541U aka REU ?
VICE have this so it's not a problem. |
| Previous - 1 | ... | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | ... | 18 - Next |
