Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in 
CSDb User Forums


Forums > C64 Coding > Compotime: Show me your (vector)balls
2013-05-24 11:28
Bitbreaker

Registered: Oct 2002
Posts: 448
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-07-02 06:36
Bitbreaker

Registered: Oct 2002
Posts: 448
*sigh*

$14a for $100 rendered frames, just as with the vectorball where it is also $100 rendered frames.
2013-07-02 07:56
Oswald

Registered: Apr 2002
Posts: 4724
well, then its pretty much killing the eor filler method, and you even have dither for free :)
2013-07-02 11:26
ChristopherJam

Registered: Aug 2004
Posts: 1165
Hey, eor filler has dither for free if you fill from left to right instead of top to bottom (eg final part of Effluvium).
2013-07-02 12:52
Oswald

Registered: Apr 2002
Posts: 4724
how do you fill from left to right?

I remember my very first naive filler was trying doing something like that with tables, so if a byte b4 filling looked like:


00110000

then feed it into a table and you get:

00111111

fill left to right ;)
2013-07-02 13:02
JackAsser

Registered: Jun 2002
Posts: 1824
Quote: well, then its pretty much killing the eor filler method, and you even have dither for free :)

EOR-fill dithering is free in the fill-phase but require "thick" vertical lines when drawing the lines.
2013-07-02 13:36
ChristopherJam

Registered: Aug 2004
Posts: 1165
@Oswald, it requires two lda:eor:sta sequences for each row, once to set the right-hand pixels for the bytes, one for the left hand. I guess that's what @JackAsser means by 'thick lines'?

Eg, for an edge that starts 43 MCM pixels into a row, flipping from solid 0x00 to solid 0xff

lda#$03:eor row+10:sta row+10
lda#$fc:eor row+11:sta row+11


(assuming contiguous bytes for each row of the eorbuffer; I can't actually remember whether effluvium had a fullscreen eorbuffer or if I just did one row at a time)
2013-07-02 14:03
Oswald

Registered: Apr 2002
Posts: 4724
I dont get it but two runs is more expensive, than span filling or the eor filling method. What jackasser means.. I guess its easyer to see how graham did it in natural wonders, it takes a lot to explain :)
2013-07-02 21:20
HCL

Registered: Feb 2003
Posts: 694
$14a sounds too fast for an eor-filler where ~$a0 is spent on the eor-shit.. (if i got the calculations right :P). But i think that "glenz" might be the thing that could keep the eor-filler alive. Drawing many lines *should* be faster with the eor-filler since nothing else than the line itself needs to be in fast registers, then multicolor also gives a benefit. So perhaps it turns out that both Bitbreaker and Cruzer found their corner cases where their mad implementations are just superior to anything else ;).
2013-07-03 07:30
Bitbreaker

Registered: Oct 2002
Posts: 448
@HCL: no doubt, at glenz my routines would suck hard, that is where eor has its true benefit :-)
2013-09-20 12:05
PopMilo

Registered: Mar 2004
Posts: 145
Quote: Would be possible, but it might still look crap, and actually i don't bother much pushing those frames through my various converters :-) With one charset each 16 frames it still looks kind of crap :-)

@Bitbreaker: Any chance on 'lending' any of those converters ? :)

Would like to test char-based animation on another type of graphic...
Previous - 1 | ... | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 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
Codey/Second Dimension
Remdy/Dentifrice
Fabs/HokutoForce/ONS
Quetzal/Chrome
Ze Smasher/F4CG
Compyx/Focus
Mibri/ATL^MSL^PRX
Impetigo/Crescent
Lord Crucifier/SCS*TRC
Jason Page/MSL
zscs
cba
Guests online: 54
Top Demos
1 Coma Light 13  (9.6)
2 Comaland 100%  (9.6)
3 Edge of Disgrace  (9.6)
4 Uncensored  (9.6)
5 Unboxed  (9.6)
6 Lunatico  (9.5)
7 Memento Mori  (9.5)
8 Christmas Megademo  (9.5)
9 Wonderland XII  (9.5)
10 The Shores of Reflec..  (9.5)
Top onefile Demos
1 Copper Booze  (9.8)
2 Daah, Those Acid Pil..  (9.5)
3 To Norah  (9.5)
4 Dawnfall V1.1  (9.5)
5 Lovecats  (9.5)
6 Elite Code Mechanics  (9.4)
7 Square Booze  (9.4)
8 Quadrants  (9.4)
9 For Your Sprites Only  (9.4)
10 Tribute to Ben - Las..  (9.4)
Top Groups
1 Booze Design  (9.4)
2 Oxyron  (9.4)
3 Censor Design  (9.4)
4 PriorArt  (9.3)
5 Crest  (9.3)
Top Musicians
1 Rob Hubbard  (9.8)
2 Jeroen Tel  (9.6)
3 Linus  (9.5)
4 Drax  (9.5)
5 Reyn Ouwehand  (9.5)

Home - Disclaimer
Copyright © No Name 2001-2021
Page generated in: 0.069 sec.