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

2013-06-26 09:48

Axis/Oxyron
Account closed

Registered: Apr 2007
Posts: 91

My implementation is a pretty straight forward eor filler with slopetable lines.

Completely unrolled speedcode for clear and fill that only accesses the bytes that get touched in at least one frame of the animation.
I shifted the coordinates -3 in x. My prototype reported the least amount of touched bytes in that position.
My address generation in the lineroutine is optimized down to 1 inc-zp every 16 pixels, because all the #$80 fiddling is encoded into my slopetables.
The rest is just classic code-optimization of the lineinit.
I just realized, I could have saved a lot with storing the line speedcode with multiple widths. So I dont need to patch and restore an rts into the linecode.

2013-06-26 10:16

ChristopherJam

Registered: Aug 2004
Posts: 1409

Sadly I only thought of including the $80 fiddling into the slope tables this morning, but I did have multiple speedcode fragments rather than doing RTS patching. All my fragments just JMP back into the main loop in zero page.

2013-06-26 11:39

Shadow
Account closed

Registered: Apr 2002
Posts: 355

Aw damnit, I missed the deadline with my joke entry.
Oh well, here it is anyway:

http://ag1976.com/tmp/amiga_petscii.prg

50 fps baby, oh yeah! :D

2013-06-26 11:58

chatGPZ

Registered: Dec 2001
Posts: 11391

so, as if anyone cares, ofcourse i tried anyway :)

in: 263168 bytes (128 file(s)) out: 69281 bytes (1 file(s)-128 frame(s)) left: 26.33%

so that'd *almost* fit, using plain delta+RLE on the bitmaps. using screen+charset properly might actually make it fit, but since my little packer doesnt do that automatically i couldnt be arsed to test =P

oh, and it runs so fast that it looks totally crap, making the whole animation attempt somewhat pointless =) was interesting to get some figures for code- and data size of both attempts though, cheers =)

2013-06-26 12:12

Shadow
Account closed

Registered: Apr 2002
Posts: 355

Groepaz: Yeah, I noticed that on my PETSCII animated version as well - the animation is really not well suited for 50fps display, it just turns into a pink blur... Running VICE at 50% speed actually makes it look better!

2013-06-26 14:17

BYB

Registered: Jan 2011
Posts: 20

Where to download? I would like to see all the other versions too. Actually i only saw the petscii one, really nice work and idea. :) Ah, i found the competition entries up there :)

2013-06-26 14:29

Shadow
Account closed

Registered: Apr 2002
Posts: 355

Bitbreaker posted a link to the executables in the same post with the results (#134)

2013-06-26 18:09

HCL

Registered: Feb 2003
Posts: 728

Big congratulations to ChristopherJam who is the true winner of this compo, and also the only entry with correct double buffering!! No wonder you had memory problems if you managed to do that.

Omg, i ended up on last position :(. This definitely ends my era as a 1337 coder.. but i still claim that i once was.

..So here comes a few excuses. I wasted ~2 weeks on a huffman-packed animation of the line-buffer, which turned out alot slower than i expected. Well, at least i *tried* something else than an eor-filler, but later went back to implement something like Cruzer's hard-liner from 2004. I didn't really get any further than Cruzer did back then i suppose, or rather i didn't even get there probably :P. From the benchmarks it looks like Me+Cruzer+Axis implemented almost exactly the same thing.

I really would have wanted to go further from here, but there was no more time, and also my energy was starting to drain. I still have most of the zeropage unused, and the data.bin is untouched, but shifted 4 pixels like the rest of you also did. The last optimization that gained me some $18 frames or so was to unroll the vertex read-loop for one face, and thus also duplicating the line-init (via macro) to operate on various vertex combos. Gained more than i expected.

Ok, time to check out the other entries to see if there is something interesting.. Should be for a lamer like me :P.

2013-06-26 20:16

Cruzer

Registered: Dec 2001
Posts: 1048

Gongrats to Birbreaker and ChristopherJam, truly impressed. Guess it's back to the drawing board. Great to see that the filled vector standard has reached a new level compared to the 1992 style that rules for many years.

2013-06-26 20:27

HCL

Registered: Feb 2003
Posts: 728

Cruzer's implementation looks really clean and almost unoptimized. I bet you could gain some easy frames here and there..

Axis's ball is crapped on places.. I call for a ~$10 frames penalty ;). Well, it's probably just an easy bug fix, but it looks sloppy.. 3 bytes per vertex was kinda innovative, don't you think?

CJam, WTF? Looped clear + eor-fill, and still you beat us with margin. Ok, some zp-code there, and lots of precalced data, but i'm still like WTF?! Gotta learn the lesson :P.

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

I don't know if this applies to some of your lines, but i draw the lines backwards.. Then i don't need to find an address to put the RTS and then restore it. The line always finishes on the right place with RTS, and i just have to find out where to start. WTF, i did the worst result, i shouldn't come with tips and trix.. i should try to learn instead, it's just hard to change roles :P.