state of the art/9 fingers routine

[blindfold]

Hi.

The question is about "state of the art" and "9 fingers" demos by spaceballs

Does someone know anything about routines used to draw those anims? All I would like to do is to make an disc data interpreter to simply port the demo onto the other platforms (like my GBA/DS/PSP). I suppose all data after decrunching is some list of vericles, ew.plus some filter flags.

[Photon]

Excuse me if you already know about Amiga blindfold

The Amiga had bitplanes, unlike todays graphics cards that have full true color pixel buffers. Probably they did this (haven't disassembled the code) by capturing filmed material and frame by frame manually draw the outline, saving the vertices describing a single polygon in a single bitplane.

When replaying it they load, say, 10 seconds (500 frames @ full framerate, might be less) of vertices. All the routine does is draw 1 polygon in 1 bitplane each frame. Each frame image (1-bit-depth pixels) is put in a cyclic buffer of let's say 5 images.

To get the "strobe" effect where the current image is laid over the buffered current image, they simply put 5 or so bitplanes on top of each other and determine the palette, so that the backmost image has the lowest color value and each layer (bitmap) adds color and the current image is the brightest.

Any patterns like circles are done in the same way, as overlays, but then you have to sacrifice the depth of the strobe effect since OCS Amigas only have 6 bitplanes max.

On modern PC graphics cards you have alpha channels, but I'm uncertain whether any or all types support RGB Alpha.

Don't know enough about GBA/DS/PSP's graphics capabilities, but you have to make a routine with layers that combine into a range of colors. If they support block image transfers with 'RGB add' you can of course make that effect by drawing the outlines into a buffer and adding them (ORing could work) onto the RGB video buffer.

If the console supports indexed color (palettes) it's even easier - draw outlines with color 128, 64, 32, 16, 8, 4, 2, 1 and OR them onto the RGB video buffer. The palette then decides how the colors combine into more intense colors.

[blindfold]

I thought there are lists of polygons, or at least some tables per frame, but I get idea of putting bitplanes to get the right colors.

Can't they modify pallete (to all white) to get strobe effects?

As to full framerate, I think they interpolate between keyframes, this saves memory/lengthen movie because od smaller data.

GBA/DS have similar graphic capibilities to use indexed palettes - no alpha channels - just color index 0 as fully transparent (alpha channel like opacity is achieved in different way if not just true or false via special effects) PSP is a different story.

Well, actually what I'm interested in is the way the demo holds those vertex tables. I know nothing about Amiga debugging etc so this is a stopline, writing a SOTA/9F Runner is not so hard for me, however.

[Photon]

On Amiga you can draw a complete outline without dividing it into tris or quads. You use the XOR function in case lines cross, like when transforming.

Framerate doesn't need to be full (50) to make it look smooth. That is because there aren't any distinct objects moving across the screen, more like a changing outline.

Color0=transparent is default for many game system, like sprites. But the non-0 pixels would OVERLAP instead of COMBINING into more and more intense colors. Alpha channel is usually 8-bit; a 256-level opacity layer. That would not give the desired effect with glowing colors.

Vertex lists are probably just a list of 16-bit screen coordinates for each frame, not necessarily the same number of vertices in each frame. It's only necessary when doing transforms from a girl to a star or something.

c=number of coords in outline
n=duration of transform in number of frames
src[]=list of coords for source shape
dst[]=list of coords for destination shape

i=from 1 to n
j=from 1 to c
coord[c].x=src[c].x+(dst[c].x-src[c].x)*i/n
coord[c].y=src[c].y+(dst[c].y-src[c].y)*i/n
next j
next i

So the demo loads 110K of vertices, enough to animate while loading next chunk. Probably some pointer table pointing to the coord list for each frame, too.

[blindfold]

Thank you for info. Too bad I totally suck at debugging. I even do not know how to start, but I think I will first make some OpenGL renderer (cause it is easier). The worst thing is that I think the data is compressed, somehow.
In other words:
1. I can make a viewer for OpenGL (PC/Windows at first)
2. I don't know how to lay my hand on the data from the demo.


The plan is easy:
To make an demo interpreter to run the original demo with original data for various platforms. Of course at first I can use already prepared data.

This isn't a hot tomato. I have really full hands loaded already with work and wet socks. If somebody is willing to help - please do.

[blindfold]

EDIT: I thought about using already dumped memory from WinUAE, but I'm not sure it is loaded all at once.

[Photon]

Oh, I thought you wanted to know how to duplicate the effect itself, not necessarily to run the same data

Code for different parts would probably differ a little bit, but the same principle.

And you can hear the disk loading in sections, so it is not loaded all at once. You could probably read all the tracks with a utility, since they are normal tracks. It might be crunched though. Ask Galahad how he would extract the data, I never learned how to crack stuff.

[blindfold]

Hi. Not much progress so far... Except I have managed to learn one more system (DS), so I think if the engine will come, it will be released on: Windows (native OpenGL), GameboyAdvance, NintendoDS (native 3d). Later I will add support to PSP - I haven't programmed that one in my company :/, nobody wants this baby.
God I suck on debugging...

Here is my guess:

The vector animations in State of the Art where hand drawn in 1 bitblane. Frame pr frame. They probobly made a program that display each 1 bitplane raw image in the backround. The animator then outline every area wich has the bit set.
The "animated lines" are then stored to disk. To recreate the image the blitter is used to draw the lines. Then the blitter is used to fill the bitplane. The blitter filler works like this. Scan from left to rigth. if a bit is set start filling. on the next bit which it set stop the filling... next bit continue filling... etc.
In 9 fingers I think lonestarr wrote a Bitmap to vector routine similar to the one you have in macromedia Flash today.
.
To disassemble in winuae simply press the pg. up button. Probobly the code will be hard to read for a non amiga coder because there is alot of hardware calls to do the blitting.

[Doc Mindie]

the lads in Spaceballs had a trick or two up their sleeves...... using old techniques in new ways to make it look incredibly difficult.

State of the Art is a wonderful example of that, I think

[StingRay]

basically, sota is just an animplayer, animdatas were stored and during runtime the gfx datas are calculated using simple interpolation. then a linedrawer is used to draw the outlines and finally, blitter fills it. very simple actually, nothing magic about it. the main work was to generate the anim data I suppose, the actual demo code is very simple.

[Doc Mindie]

Which is what I said

"Using OLD tricks in a NEW way to MAKE IT LOOK difficult"

[oRBIT]

The animations are not hand-drawn AFAIK, they were converted from digitized graphics with a utility the spaceballs-dudes made. I think they even sold the converter later to a software company..
I've read about this along time ago..

[blindfold]

Thank you very much. I will try to debug/try to read the data then, just after I push some f*cking DS commercial crap to publisher.