[CSDb] - User Forums - Compotime: Show me your (vector)balls

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > Compotime: Show me your (vector)balls

2013-05-24 11:28

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....

2013-06-14 06:39

HCL

Registered: Feb 2003
Posts: 716

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 (!).

2013-06-14 06:52

Oswald

Registered: Apr 2002
Posts: 5017

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.

2013-06-14 07:09

HCL

Registered: Feb 2003
Posts: 716

@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?

2013-06-14 08:37

Oswald

Registered: Apr 2002
Posts: 5017

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)

2013-06-14 12:30

HCL

Registered: Feb 2003
Posts: 716

..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.

2013-06-14 13:14

Oswald

Registered: Apr 2002
Posts: 5017

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 :)

2013-06-14 15:34

ChristopherJam

Registered: Aug 2004
Posts: 1378

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.

2013-06-14 15:45

Oswald

Registered: Apr 2002
Posts: 5017

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 :)

2013-06-14 15:51

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.

2013-06-14 20:42

Sorex
Account closed

Registered: Nov 2003
Posts: 43

Quoting Bitbreaker

any 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?

Previous - 1 | ... | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | ... | 18 - Next

Refresh

Subscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search for in
All times are CET.

Search CSDb

Advanced

Users Online

iceout/Avatar/HF
csabanw
Frostbyte/Artline De..
Guests online: 124

Top Demos

1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 No Bounds  (9.6)
7 Uncensored  (9.6)
8 The Ghost  (9.6)
9 Wonderland XIV  (9.6)
10 Bromance  (9.6)

Top onefile Demos

1 It's More Fun to Com..  (9.8)
2 Party Elk 2  (9.7)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.5)
5 Rainbow Connection  (9.5)
6 TRSAC, Gabber & Pebe..  (9.5)
7 Onscreen 5k  (9.5)
8 Wafer Demo  (9.5)
9 Dawnfall V1.1  (9.5)
10 Quadrants  (9.5)

Top Groups

1 Oxyron  (9.3)
2 Nostalgia  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)

Top Diskmag Editors

1 Jazzcat  (9.4)
2 Magic  (9.4)
3 hedning  (9.2)
4 Newscopy  (9.1)
5 Elwix  (9.1)

Page generated in: 0.431 sec.