A.D.A. Amiga Demoscene Archive

(Not about.. ehh.. "fashion"...)

Short version: I like rubber vectors and I intend to make the largest rubbercube ever on A500. I also hope someone else tries to beat me to it.

Long version:
I *really* like rubber vectors, especially on A500 where it's non-trivial to make a big one. (With higher performance / more RAM the fun kinda goes out of it).

While I'm not usually one to aim for breaking old records this one intrigues me (I'm getting a bit long in the tooth so "old-man-crossword-puzzles" are starting to seem fun I guess..).
I'm aiming for a simple 2 bitplane cube, as large as possible at 50 FPS, which would work in an intro or small dentro (i.e. if anything is stored on disk it would have to be very small amounts of data). That said: it'd be cool to see *any* clever new approach to rubbering on A500.

I reached out to selected german, finnish and swedish coders for some good-spirited competition a while back but so far the results have been disappointing. Maybe this post can change that a bit (after all: the relative interest in OCS has grown significantly). :)

I've also done a bit of digging to find the best & biggest around. If anyone knows of other prods with impressive rubber vectors then please shout!


Digital Innovation had one coded by Icronite. While it's big and pretty good looking they're lying a bit in the description (it's 240x180 in 2bpls, rather than 256x256 in 3). There's also a bit of stuff loaded from disk but whatever.. :)


In Point Blank Blazer did a neat one and didn't really lie that much (it's 208x196 rather than 200x200). All the exploding cubes we have to watch while the precalc is running might get a bit tedious though. :)


Rubberdemo from Major Asshole was a big fake of course (also, I *think*, running the effect at 25 FPS).


And just for reference Funky Pixels had a neat one at 256x256, but obviously that's AGA so it doesn't count.


So, I have some ideas of my own and will release before the end of the year (hopefully much before). I'll buy a beer for anyone who does a nice rubber, and a case for anyone who beats me at my own game. ;) (case to be replaced by some other drink if you happen to suffer from gout or tea-totalling).

Ooh, a challenge! :-D

Neat :)

So I have never coded one so forgive my ignorance but how much space would it take to generate a bunch of lines and select one per scanline using the copper? (you will likely not need all permutations but a defined set depending on how you will show the object/cube)

For a totally naive implementation (buffer of frames rather than buffer of scanlines) you obviously get bottlenecked by the amount of chip ram before any other size / performance limit.
As you say, when using a buffer of scanlines it'll all depend on "how the cube rotates" so it's more or less all under your control. :)

Yeah I just wonder how far that it will take you and how much memory usage would be?

Writing an offline tool for this and calculating the mem cost and such and do a rotating cube shouldn't be that hard. It might also be possible to rotate the cube in a "memory efficient" way :)

Also (thinking loud really) compressing these lines are of course very easy (basic RLE) but I wonder how much CPU it would take to decompress them?

It might be possible to be smart here and have a cache of decompressed lines and decompressing a bunch each frame to balance CPU vs. Memory cost.

A simple (because it wouldn't need to be complex) decompression scheme should absolutely be doable. The issue might then become either your precalc & compression time or how much you want to put on disk.

Overall I think the solution will be in a combination of tricks and tweaks, which is the reason why I like this one! :) (also, trying not to talk about my own plans here... ;-D )

Yeah :) As I'm too lazy to do anything I'm fine with giving away my ideas ;)

So how have the other ones been implemented in general?

A lot of the smaller /older ones are probably pure naive implementations with a circular buffer of frames. Rendering one new frame + compositing the rubbered cube at 50 FPS.

The larger ones are all based on some compression scheme (obviously, there's not much chip to go around so you'd want to pack it + also be able to utilize your 512k fakefast). Precalcing done either at some point earlier in the prod (a bit more challenging to keep the prod interesting), at startup, or reading the stuff from disk.
People seem to have precalced anything from just spans to more "cube state" (like the twisting patterns / "which scanlines to select"-info) to the entire rubber cube animation. :)

Alright. Makes senes.

By coincidence this is already on my lists of effects to code while on holiday, which starts in 3 days, sooo.... Challenge Accepted! :-) On the downside this probably means I'll have to cut the effect from my demo, unless you don't mind waiting until next year to see my version :-/

Well. There is nothing stopping you from using it in the demo right? Even if you release the effect here when you actually put it in the demo there is more that can be done (look a bit different, sync with music, wipe in, out, etc) so I wouldn't worry to much about that.

Yeah, what emoon said. The people who are most likely to scream "recycling!!!!" are usually clueless and will always find something to bitch about anyway. :)


Then again, this problem might be void. If someone else happens to make a much cooler rubber vector than what you have... will you still include yours in the demo months later? ;)

Probably not, but then I'm assuming mine will be the best! :P Joking aside, if we're just showing stuff here, and my idea actually works, I can remove the decoration and just have an exe with no name/group brandings.

I'll be making "an actual production" (although a small one) out of mine. While I wouldn't impose that restriction on anyone going for free beer (and fame) it would be really cool to see a number of tiny rubtros. (always some fun in coming up with a fake group, if nothing else).

I had a few hours to myself today and knocked up a rough version of my rubber. It appears that in max size mode it won't quite fit into my demo unless I cut the audio budget, so using it in a small rubtro is looking like the best option for me now as well ;-)

I'm in on the rubtro idea!

It could be great fun if we released our intros simultaneously, so that nobody has the advantage of knowing what others have come up with. :)

I was already contemplating what to bring to Gerp, and now there's an obvious answer. How about a rubtro shootout at the Gerp demo compo? ;)

(Or a separate rubtro compo, if there are enough entries)

Excellent idea with a battle at Gerp (actually, it was what I wanted to suggest today as well).

This is a cool idea :) Are there some more restrictions to this than it should be A500 (512k chip + 512k fakefast) and 50 FPS?

Gerp would be great!!! :-) As of tomorrow I'll have no access to amiga hardware for the next 4 weeks unless I happen to find an oldschool amiga scener in Japan, lol I'll be back the week before the party so I'll have time to clean up any glitches that show up on the real deal.

emoon: Nothing else that I can think of really. :)
Of course, the "amount of twisting" (twist-to-height-ratio or "size of history buffer" if you will) is a defining factor and something you'd want as high as possible but that goes without saying. Otherwise you could have a large cube, make one split in the middle and call it rubber.
I believe Blazer's cube from Point Blank beats everything else on A500 hands down when it comes to this quality.

But yeah, as a baseline 50 FPS on a standard (512k+512k) OCS machine is where it should be at.


Paradroid: Sounds good!

Sounds good!

Also when judging the quality should not only go on size but also appearance imo (like you say 1 split could 'technically' count as a rubber cube while it really isn't)

Absolutely! When it comes to the "cases of beer"-challenge I'll of course rationalize the hell out of who gets the award from me. ;) As for what goes down at Gerp I'll happily leave that in the competent hands of the organizers and attendees there. :)

Slummy: Gerp organizers would love to host the compo. If you want us to, send us an email at gerp/at/demoose.se and we'll add it to the website and run it with the rest of the compos

2 weeks left until showdown!
I'm somewhat behind schedule due to lack of time + some re-engineering of the algorithm, but I'll have a release. :)

So far I have mainly been brainstorming, writing notes and working out details "on paper". As for the code, only the support code and some basic stuff is there yet. The real bulk of the coding is starting... NOW! :-D

I finished the code for mine ages ago, although I've yet to test it on real hardware. I'll be back home next week and will no doubt try to get a few more pixels added to the width and height... or shrink it down due to it only working in winuae, lol

Paradroid, I hope my song fits the memory-budget. Cheers and have a blast at GARP! :)

Also, several people have been asking whether the showdown at Gerp will be the conclusion ( == "if they can't make it for Gerp then they can't make it all").

This is of course not the case. :)
While several of us are aiming to release there I'll still happily admit defeat (and buy some beer) for anyone who (according to me) beats my own implementation at a later point during the year.

When coding cube effects like this, I often find that having a physical cube in your hand that you can rotate and write notes on is an indispensable tool.

It could be fun to give a mini-seminar at Gerp: "Origami for cube coders: how to fold your own paper cube". ;)