Not logged in, Join Here! or Log In Below:  
 
News Articles Search    
 


Submitted by A.S.HAINES, posted on December 12, 2001




Image Description, by A.S.HAINES



This is a composition of screenshots from the 'Flu' demo, for the Codecraft#2 8k competition. There were six entries in this category, and it won. I should mention that this was some time ago; Codecraft#3 finished earlier this year.

However, since very few of you will be aware even of the type of computers existence, I doubt many of you will have seen it. For what it is worth, the computer used was a RiscPC equipped with a StrongARM processor running at 202.4 Mhz. ARM chips have a very elegant RISC architecture and are pleasant to program in machine code. There are now several manufacturers of ARM based computers. If you are interested in learning more, search for RiscOS (and perhaps ARM). If you are not, please don't flame..

The demo had five graphical sections, clockwise from the top: Coloured metablobs. As far as I know, this hasn't been done before, but I can't follow the PC demo scene so it may be a rediscovery. In any event, it turns out to be quite easy to do using a two pass algorithm. In the first pass I simply set up 3 pairs of metablobs in separate channels. In the second pass these channels are summed then processed to find the brightness, and the proportions used to give the colour.

The rippling reflection part takes up a large proportion of the file; the compressed moon picture alone is over 3kb. (This section was added when the competition rules were changed with the maximum size going from 4 to 8kb.) If the reflections look a bit blocky, this is because interpolation was used to keep the speed up.

The 'Fish' section was written by Alain Brobecker, a very skillful French mathematician. In his words this is "a rotozoom with edges as quadratic splines and an RGB trainee". (I believe the fish tile was by MC Escher.)

The yellow thing is meant to be the front panel of a computer (Coder graphics), which slowly burns away in a 512 translucent particle fire effect. (The 'Phoebe' was a yellow computer which was canned before launch).

Finally, for completeness, "Flu Flash" was a quick animated logo. I'm afraid it didn't convert to JPEG particularly well.

Perhaps it is not surprising with the concept of "fluid" that some of these pictures don't look as good as they do in action. Nevertheless, I hope you like it even if this is not a typical pic of the day entry. No first person? No shooting? What was I thinking? :-)

Yours,
Tony


[prev]
Image of the Day Gallery
www.flipcode.com

[next]

 
Message Center / Reader Comments: ( To Participate in the Discussion, Join the Community )
 
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
 
Hiro Protagonist

December 12, 2001, 02:48 PM

Interesting. How'd you get the screenshots?

 
Ron Frazier

December 12, 2001, 02:49 PM

the fish is really cool. It almost looks holographic. Is there any chance there might be a StrongArm emulator out there that we could run an executable on?

 
dom

December 12, 2001, 03:41 PM

Beautiful. Really, really nice.
:)

 
Lion V

December 12, 2001, 04:33 PM

Funky

 
ector

December 12, 2001, 04:35 PM

btw.. colored metaballs have been done before, even in 3d using the marching cubes algorithm...

 
Bunnz

December 12, 2001, 04:36 PM

Cool!

Looks nice!

Have fun!
Bunnz
Visit: Bunnz Productions

 
Dr.Mosh

December 12, 2001, 05:08 PM

Mmmh, nice idea for the metaballs :)
*runs off to try*

 
Liquidex

December 12, 2001, 05:58 PM

Kickass demo, yo.

 
Ekul

December 12, 2001, 06:00 PM

3d colorblending metaballs was first seen in the demo "jakoob" by fudge at the gathering 1997

 
zaxe

December 12, 2001, 06:00 PM

good work, i always like funky strange alien hardware :) about the blobs, doing them in 3D is quite normal in the pc demoscene right now, but your variant still looks cool.

 
mattie

December 12, 2001, 09:23 PM

i totally agree! :)

 
Stefan Karlsson

December 12, 2001, 09:51 PM

i try again:
RGB
GBG
BRR

 
blackbot20

December 12, 2001, 11:12 PM

love the metaballs, i'll bet it looks very cool animated.

 
Frans Bouma

December 13, 2001, 03:46 AM

Why would you use splines for the rotozoom effect? Just fiddle around with the delta's a bit (like adding a sine value per line) and the rotozoomer gets a 'rubber' effect instantly :D

 
EGreg

December 13, 2001, 07:12 AM

Yay! Nice.

-Greg

 
DEVLiN

December 13, 2001, 07:40 AM

Couldn't agree with you more... it's quite cold here in GBG ;)

 
Loris

December 13, 2001, 08:26 AM

Thankyou all for your comments.
I emailed this IOTD from a temporary account and unfortunately the email return address is wrong (I don't know if I'll be able to access it now). Please send any email to:
a.s.haines@bham.ac.uk

The screenshots were taken using a program entered in the 2k tool category of Codecraft#2 ("ScreenGrab" by CasmA and neBula)
I should have given the website...
http://www.dnd.utwente.nl/topix/codecraft/
**Please note that none of these programs will run on a PC**

I certainly agree that the Fish display is cool (animated, it looks amazing). Hopefully Alain will be able to comment on his work here because I don't pretend to fully understand it (sorry Frans).
While ARM emulators exist, to get the demo to run you'd need a full RiscPC emulator. Also ARM chips are quite powerful so it would probably be dog-slow. The source is on the web-site so you can look at it if you want. Alain has a stand-alone Fish demo on his own website which is in some ways superior (No lossy compression on the Fish tile).
Re the coloured metablobs, thank you Ector and Ekul for pointing me towards this demo. As I said I can't follow the PC scene, but I'm not suprised its been done before. Metaballs (3D entities) have been done on the RiscPC as well, but not by me. (RiscPCs tend not to use graphics cards and do everything in software. That said a graphics card for the platform now exists). Personally I'm not completely sold on 3D (not for its own sake, anyway). It is certainly fun in many games but I like platformers. ;-)

Finally, as an aside perhaps I should mention something of interest you can't see in the graphics. To get all this stuff to fit in 8k I had to compress not just the data but also the code. All ARM instructions are 32 bits wide. The code was packed using a sort of scrolling dictionary of the last 256 instructions, where non-matching nibbles from the best match are replaced to give the next instruction. To depack, the initial 'dictionary' is the depacking code to give it something to start with. This works quite well, and indeed a stand-alone utility performing this on arbritrary code was entered (by Pervect/Topix) in the 2k utility competition.
This might be of interest to Gameboy Advance programmers.

Yours,
Tony

 
Stefan Karlsson

December 13, 2001, 10:25 AM

ja, tänk på mej som går på lindholmen, JÄVLAR vad det e kallt där ute =) och ja, det var faktiskt meningen att läsas så som du gjorde, grattis;)

 
EGreg

December 13, 2001, 02:28 PM

Yay.I like the meatballs, are they animated in the demo?

-Greg

 
StAn

December 15, 2001, 05:45 PM

Your code compression method is interesting, but I don't see how the "nibbles" to be changed from the best matching 32bit word can be stored efficiently...
As I see it, one byte is used to store the best matching instruction, but then...?
Do you achieve 50% compression, or less ?

 
Loris

December 16, 2001, 12:20 PM

If I remember correctly, the way I did it was:
1 byte - nibble mask.
1 byte - offset to 'best' match
n nibbles - EOR value with the mismatch in the copied word

If there were no good matches then I used binary 11111111 for the
nibble mask and didn't need the pointer byte.

This gives best case 50% compression of a word (I should mention a word is defined as 32 bits on this architecture)
Worst case is 1 word (4bytes) becomes 5 bytes, although this doesn't happen that often in practice.
I think I got around 75% compression on maybe 4-5k of code, but bear in mind that this includes the decompression code (Less than 20 instructions IIRC). If there was more data then a different method would give better results; as you have more data better compaction is possible.

When Eli-Jean wrote the 'CodePressor' utility using this algorithm he observed from the output that many best matches were in the last 16 instructions, and also often had the top 4 nibbles identical (This is a consequence of the ARM instruction format). So he special cased these and got slightly better overall compression.
For what it is worth, his utility won the 2k utility class. :-)
He has since written a (much larger) utility which tries several different modifications to get the best compression.

Thankyou for your interest.
Yours,
Tony

 
Nay

January 01, 2002, 08:28 PM

This is interesting stuff. Its a shame how us PC losers don't have quite the access to our video hardware that we once did. I agree, although 3D is a lot of fun, getting your hands filthy with asm on the frame buffer is great. Also, ingenious work with the code compression, I had to post to mention that it struck me as very similar to LZ77 compression. Cool man.

 
Loris

January 04, 2002, 01:21 PM

Probably in reverse order:
Nay, I've just looked at a LZ77 description on the web. "CodePressor" compression is similar in that it uses a rolling window as decode buffer. The main difference being that CPr uses fixed length packets with differences while LZ77 uses varying length packets. This makes me wonder whether it would be possible to have a hybrid technique, where near-perfect long runs could be patched. On second thought, this may be a little hairy. :-)

Greg. Sorry I didn't reply before. The metaballs in the demo move through different lissajous figures.

RE Acorn emulating, I found this on a RiscOS dedicated website:
http://www.iconbar.com/news/viewcomments.php3?item=1010054724
It describes and points to an emulator. Whether the demo would work I don't know; if it did it'd probably have a low frame-rate because the machine emulated is perhaps an order of magnitude slower than mine.

Alain Brobecker has asked me to post this for him:
****
> the fish is really cool. It almost looks holographic.

It's a bare rotozoom where you shift RGB values. This effect i saw in an old Amiga 1200 demo by Sanity (coder?).


> Why would you use splines for the rotozoom effect?
> Just fiddle around with the delta's a bit (like adding a sine value
> per line) and the rotozoomer gets a 'rubber' effect instantly :D

Quadratic splines can be done with 2 additions only, not even looking up a table! :)

****
Just to labor his last point, using splines is therefore quicker than sines, especially if you've got a full cache of other stuff. (The data cache on the StrongARM is 16kb, in 512 byte lines IIRC.)

Yours,
Tony

 
This thread contains 23 messages.
 
 
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.