|
| |
Released At :
Show me your (vector)balls
Credits :
SIDs used in this release :
Download :
Look for downloads on external sites:
Pokefinder.org
User Comment
Submitted by ChristopherJam on 5 August 2015
| Bah. A few days of applying some fairly obvious optimisations to the loader and I'm down from 42 seconds to 29. Should have done that years ago.. |
User Comment
Submitted by Dr.j on 13 August 2013
| looking awesome ! great coding here |
User Comment
Submitted by ChristopherJam on 13 August 2013
@USC: Jam Ball 1 would be my entry to Bitbreaker's compo, cf Compotime: Show me your (vector)balls. The event and entries don't have CSDB pages yet, but there are download links in one of the comments.
@Oswald: Thanks! I do half the work of depacking within the display area; most of the rest of the raster time is doing phase one of the depack and writing intermediate results into the display code. And yup, same charset all the way :) |
User Comment
Submitted by Oswald on 13 August 2013
| the display method is extremely kewl, so you manage to depack the char pointers each 5 rasterline? same charset all the way? suprisingly small visible errors! |
User Comment
Submitted by Urban Space Cowboy on 13 August 2013
| If this is Jam Ball 2, what was Jam Ball 1? |
User Comment
Submitted by Yogibear on 13 August 2013
User Comment
Submitted by The Syndrom on 12 August 2013
User Comment
Submitted by Burglar on 12 August 2013
| thats pretty fucking smooth! really good job! |
User Comment
Submitted by ChristopherJam on 12 August 2013
@algorithm: One 253 entry charset for the entire animation, no flipping.
No space for the video matrix either, the entire display area is refetching the first 40 bytes of zero page every five raster lines. |
User Comment
Submitted by ChristopherJam on 12 August 2013
I'd not actually seen Bitbreaker's original before now! I do need to credit him for the animation data for this one, but I'm not sure what category to put him in. Graphics, perhaps?
Mine is 50fps, but his is realtime calculated and doesn't sparkle at the poles; I'd be hard pressed to compare them.
It's really not possible to crunch it much smaller, though I'm happy to provide an intermediate file to anyone who wants to have a go. As it is, even post decrunch I'm fitting 77824 tile indices into 57525 bytes, the last 45k of which is basically random. I could do with writing or linking in a better loader, mind.
[Onyx:~/c64/2013/vectorballs_compo/vq] pucrunch d2.prg |wc
Only programs from 0x0258 to 0xffff can be compressed
(the input file is from 0x0200 to 0xff69)
eta: after my own crunch is applied:
[Onyx:~/c64/alz/alz64] pucrunch jam\ ball\ 2.prg 2>>/dev/null | wc
318 2379 60654 |
User Comment
Submitted by algorithm on 12 August 2013
| Ahh. The good old VQ :-) Even though the result has some lossiness, it still looks great. Without looking at the code, i am assuming that you are having approximately a charset every 10 frames? I guess you may be taking into account the frames and using char flipping left/right/up/down? |
User Comment
Submitted by TheRyk on 12 August 2013
Just opened two VICE Windows to find out which of the Amiga 2013 balls looks best. Though I shun Amiga anyway and am not gonna lick anyone's balls, it's hard to tell.
Yours seems to have the higher refresh/framerate. Bitbreaker's not only spins/rotates but also moves with distance effect.
Fick, Daul und wurstig Although Katy Perry's hot, I slightly prefer Bitbreaker's ball. :o)
Good coding study, anyway.
PS: Loader? Really not possible to crunch it within 202 blocks?
PPS: You're not the first one trapped by that damn grey dot issue. |
User Comment
Submitted by ChristopherJam on 12 August 2013
Ah! How embarrassing. I guess I should have replaced my $d020 writes with $d022 writes when I wanted to ditch my timing debug without messing with cycle counts.
Oh well, something to watch out for in future releases I guess.
/n00b |
User Comment
Submitted by JackAsser on 12 August 2013
@CJam: Shows on newer breadboxes (c64c). Also correctly emulated in VICE if you run x64sc and choose that VIC-chip. You know, those gray ghost dots when setting a color register. The first pixel will become gray regardless of color chosen after a write to a color register. In essence you're writing to $d020 in the top border but always black. This results in a flickering gray dots moving around here and there.
But it doesn't really matter because it's an awesome release non the less of course! :D |
User Comment
Submitted by ChristopherJam on 12 August 2013
Thanks guys.
@JackAsser Grey dots? I see no grey dots on my old breadbox... |
User Comment
Submitted by Oswald on 12 August 2013
User Comment
Submitted by JackAsser on 12 August 2013
Nice! :D
But then we have the issue of NOT testing in x64_sc (which emulates the gray dots correctly)... :P |
User Comment
Submitted by Frantic on 12 August 2013
|
|
|
 | Search CSDb |
|
| Navigate | |
|
| Detailed Info | |
|
| Fun Stuff | |
· Goofs
· Hidden Parts
· Trivia
|
|
| Forum | |
|
| Support CSDb | |
|
 |  |
|
