Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
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-05-30 17:42
Bitbreaker

Registered: Oct 2002
Posts: 508
I do double buffering what looks white okay on the real machine, anything less will look rather ugly i'd say :-) vblank would be overkill and we'd also loose granularity when comparing the results.
2013-05-31 21:26
ChristopherJam

Registered: Aug 2004
Posts: 1409
A few of the polygons near the edge of the sphere are inside out, likely a bug in the backface removal. May we reject these?
2013-05-31 22:22
Cruzer

Registered: Dec 2001
Posts: 1048
@Bitbreaker: Agree, thanks for clearing it up.

@ChristopherJam: How on earth did you detect that? And I vote against removing them, since the compo is about rendering the given animation fastest, not about making the prettiest vectorball.
2013-06-01 03:25
ChristopherJam

Registered: Aug 2004
Posts: 1409
@Cruzer It's more that some plot routines either crash or don't set any pixels at all if the ordering is clockwise instead of counterclockwise.

e.g. if you assume the highest point is the start of a chain running down the right hand side to the lowest point, and the end of a chain running up the left hand side, you can use each chain to make a set of masks

left mask
00111
01111
01111
11111

right mask
11100
11110
11111
11000

left AND right:
00100
01110
01111
11000

If the left and right are the wrong way around, left AND right will produce all zeros, as the right mask will become 0 before the left mask becomes 1

So, even a routine that uses all the data might fail to plot CW polys, so we at least need a ruling as to whether we need to to flip CW polys to make them visible.
2013-06-01 07:44
Bitbreaker

Registered: Oct 2002
Posts: 508
I'd say optimize them away, as they can't be too many and will not change the result much speedwise and optically (except when crashing the machine :-) ) As for me they didn't cause any trouble, but i also sorted out some faces that will never been shown, like some of them are also at zero height if i remember right :-)
Now i am just pondering what i shall do with my $1800 free bytes, add music? 8-)
2013-06-01 07:48
ChristopherJam

Registered: Aug 2004
Posts: 1409
Sweet, thanks. As you say, there were only a few, and they were basically slivers anyway.

Yup, the zero area polygons are already gone :D
2013-06-06 04:43
Cruzer

Registered: Dec 2001
Posts: 1048
Quoting Bitbreaker
Now i am just pondering what i shall do with my $1800 free bytes, add music? 8-)
Is it oneframed yet? Otherwise free bytes can always be used for optimizations. :)
2013-06-06 06:36
Bitbreaker

Registered: Oct 2002
Posts: 508
Quote: Quoting Bitbreaker
Now i am just pondering what i shall do with my $1800 free bytes, add music? 8-)
Is it oneframed yet? Otherwise free bytes can always be used for optimizations. :)


It is doublebuffered, fast and fully functional, and it is $1a00 free bytes meanwhile :-) However the biggest free block is somewhat around $800 bytes, the rest is spread all over. So far i can't see any possibility to improve speed by more memory usage. To do so, i'd need a few more pages of zeropage :-) Code unrolling will make things slower, so will do the introduction of lookup tables. I really wasted big amounts of mem for aligned and interleaved stuff though.
2013-06-06 06:47
Hein

Registered: Apr 2004
Posts: 954
Quote: It is doublebuffered, fast and fully functional, and it is $1a00 free bytes meanwhile :-) However the biggest free block is somewhat around $800 bytes, the rest is spread all over. So far i can't see any possibility to improve speed by more memory usage. To do so, i'd need a few more pages of zeropage :-) Code unrolling will make things slower, so will do the introduction of lookup tables. I really wasted big amounts of mem for aligned and interleaved stuff though.

what cruzer is trying to say is that he's almost having it oneframed. :)
2013-06-06 07:03
Bitbreaker

Registered: Oct 2002
Posts: 508
aka animated? ;-)
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | ... | 18 - Next
RefreshSubscribe 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
Scarzix/Offence
redcrab/G★P
Guests online: 73
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Coma Light 13  (9.6)
4 Edge of Disgrace  (9.6)
5 Mojo  (9.6)
6 Uncensored  (9.6)
7 The Demo Coder  (9.6)
8 Comaland 100%  (9.6)
9 What Is The Matrix 2  (9.6)
10 Wonderland XIV  (9.5)
Top onefile Demos
1 Layers  (9.7)
2 Cubic Dream  (9.6)
3 Party Elk 2  (9.6)
4 Copper Booze  (9.6)
5 Dawnfall V1.1  (9.5)
6 Rainbow Connection  (9.5)
7 Morph  (9.5)
8 Libertongo  (9.5)
9 Onscreen 5k  (9.5)
10 It's More Fun to Com..  (9.5)
Top Groups
1 Booze Design  (9.3)
2 Oxyron  (9.3)
3 Performers  (9.3)
4 Triad  (9.3)
5 Censor Design  (9.3)
Top Graphicians
1 Mirage  (9.8)
2 Archmage  (9.7)
3 Hend  (9.6)
4 Pal  (9.6)
5 Carrion  (9.6)

Home - Disclaimer
Copyright © No Name 2001-2025
Page generated in: 0.056 sec.