pouët.net

We hope that with this short technical write-up you’ll find the title of this intro to be well justified. Many of the effects in the intro were inspired by well known phenomena in the world of living organisms.

1. LogoIn: Uses 3 bitplanes, mostly palette transitions.
   
2. TileMoverA: A cousin of the well known fractal zoomer classic effect. The novelty here is that there’s no single vector field. With the help of external tools we’ve chosen a handful of functions that generate desired vector fields and we switch them on demand. Uses 4 bitplanes. We draw custom shapes onto a single bitplane and use the rest of bitplanes for cheap motion blur approximation.
   
3. WireWorldA: See GameOfLifeA and WireWorldB. This is the first instance of that effect that we decided to expose better later throughout the intro.
   
4. Vitruvian: Same as LogoIn, we added a little bit of sync.
   
5. GameOfLifeA: Probably so called world-first. Watching Rule30 by Andromeda we asked ourselves if we can do better than one dimensional cellular automata on A500. Our two-dimensional cellular automata are calculated using solely Blitter. We translated several automata rules thanks to the method provided by Piotr Polesiuk, who used a SAT solver to determine the settings for a reasonable number of blits that will perform the computations. Uses 4 bitplanes but renders to a single one. As with TileMover other bitplanes are used to leave a trace of previous frames. The CPU is used only to drive Blitter and for horizontal pixel doubling, vertical pixel doubling is done with Copper. We forgot to write the names of game-of-life variants… so there is classic “game-of-life” but also “day and night”, “diamoeba”, “three-four”, “maze” and “stains”.
   
6. SeaAnemone: Uses 4 bitplanes. Some Copper based gradient applied to the background. The effect draws paths of many semi-random walks. With each new step a shape is drawn onto the screen and shape’s size is decremented.
   
7. Weave: Uses 4 bitplanes, single playfield + sprites. This is a very technical effect, not sure if we saw that being explored before. Copper is used to switch between sprite / playfield priority mid-screen, to change sprite horizontal position each-line, and reposition sprites 1 & 2 to reappear on the right. Yeah… there are 10 sprites rendered on each line!
   
8. UVMapA: Uses 4 bitplanes and Copper to apply a nice gradient and perform line doubling. Chunky buffer is heavily scrambled to save on blitter passes in Blitter-based chunky-to-planar. Code that renders the uv-map uses two sets of textures and is completely unrolled for speed. Textures are drawn into respective texture buffers to change them in-flight. UVMap was prototyped using ShaderToy. The shaders were rewritten into a C program to generate uv-maps offline. An extra delta-encoding scheme was applied to each uv-map to make them compress better.
   
9. GrowingTree: The idea is similar to SeaAnemone. With each step there’s a probability that a new path will be created – this simulates branching off. At the end of the path we copy a flower to the screen to finish off the path. After all branches are finished we draw onto the screen hand drawn group names that were converted from SVG format.
   
10. WireWorldB: This is another type of cellular automaton. In contrast to GameOfLife automata this one has more state bits per cell, as it can either be an electron head, electron tail, circuit board (no electron) or empty space. We made the graphics appear nicely on the screen and then enabled 16-color sprites in the mid-screen. The sprite is animated using color-cycling that we extracted from the DRNG chunk of IFF-ILBM format. Some nice sync was added at the end of the effect.
    
11. UVMapB: Same code, different uv-map. Extra sprite is displayed for a while when the vocoder sounds.
    
12. GameOfLifeB: More of the same goodness, but this time only on 3 bitplanes. With the ELECTRIC mask in the fourth bitplane we were able to apply various opaqueness / transparency effects to the background.
    
13. TileMoverB: More of the same goodness.
    
14. Turmites: 2-dimensional Turing machines. These are basically automata that work a little bit like ants. They can leave and sense traces on the ground and make their decision based on the rules stored in their internal small brain. You can read more about them on Wikipedia.
    
15. ScrollingText: Memory optimized text scroller that draws a single line of text every 8 frames or so. That was finished off with a Copper-based foreground color gradient applied at the top and bottom of the screen.
    
16. LogoOut: Same as LogoIn but in the reverse direction.
    

Let me try to explain it :)

IMHO that's a common misconception that C language is not good enough for Amiga 500 coding. We put a lot of effort into understanding gcc 2.95.3 idioms, i.e. how given C statements will translate into 68000 assembly, so we can quickly estimate if the generated code has a chance to be close to optimal. Of course performance critical code is not left unchecked. We have a primitive yet efficient profiler. We verify the output from the compiler to see if it did not do something stupid or unexpected (e.g. allocated variables on the stack). We have a tool that shows how each line of C source code translates into assembly. It also annotates each instruction with the number of cycles it takes. In other words we developed tools to make sure we invest our time only where it brings the most benefit wrt. performance.

Why such an old gcc version? Well... we tried to switch to gcc 6.5.0 from bebbo and to our surprise the generated code was 30% slower on average. There are two possible explanations here. Either our code uses idioms that the more recent gcc is unable to recognize and fails to optimize them or the default set of high-to-mid level optimizations in more recent gcc compilers are tailored towards x86-64 processors (e.g. lack of postincrement and predecrement, cheap array indexing, etc.). That could in turn result in RTL representation that cannot be translated into an efficient 68000 code. That’s why we are stuck with old gcc. Though we may reconsider the new gcc at some point, since bebbo has been actively improving its quality.

We're aware of the fact that the intro misbehaves or crashes on more powerful Amigas. It's difficult to test a production on all possible configurations, especially in the face of a rapidly approaching deadline. We’re actively working to resolve all issues we know of.

Hello :) Thank you everyone for the very warm welcome, both here and during the party, it was an amazing experience. I hope we will see each other again soon!


To add a little more context - yes, back in 2021 Cahir gave a course called "Demoscene production" at the University of Wrocław. We've tackled bitplanes, Copper, Blitter and other good stuff through a series of lectures and exercises, some of which actually evolved into full-fledged effects and ended up in this production!

As for me personally - I am not technically a student there, but I've learned about the course from Kris and Cahir was kind enough to let me in as a guest. One thing led to another and after the semester ended, we decided to stick around and work on Electric Lifeforms with the rest of the group.
In all seriousness, it was one of the best decisions in my life - I got to learn a ton of stuff about low-level programming, made new friends and fulfilled my little childhood dream.

I also must admit that seeing our work on a big screen for the first time was a very emotional experience, I've shed a tear or two. :) It was a labor of love for all of us and I am very happy and honored I've got to work with such talented and passion-driven people.

All in all, not bad for the first time, eh? And it surely won't be the last!
／(> x <)＼

Hi, Kris here!

Many thanks to all the warm comments and welcomes coming our way. As Spook already explained this started as an experimental project by Cahir at university. Me being the retro computer enthusiast that I am, I couldn't pass up this opportunity and attended the course ;) I've only ever coded a little bit for the C64 before (in terms of retro platforms anyway), so I had some preliminary knowledge which comes with low-level coding, but all of the machine-specific details were new to me. Suffice to say, Cahir did incredible job explaining all the Amiga intricacies to us, so the demoscene can thank him specifically for raising two new coders. I’ve stuck around after the course since it was fun coding for another platform where I have full control over the hardware and now we’re here ;)

I was mostly responsible for the game of life and wireworld (flowing electrons) effects in this prod. The idea for the former sprung up after watching Rule 30 by Andromeda way back in fall 2021. Piotr Polesiuk (another professor at the same university) came up with the idea of using a sat-solver to find a sequence of blits that would compute the next step of any 2D CA (cellular automata) by leveraging the blitter's function generator. He kindly provided us with a script for that and I coded and expanded the effect. What you can see in the intro are CA with different rules switched dynamically, sprinkled with some synchro. Wireworld takes from these ideas but has an additional (perceived) difficulty that the CA states are now 2-bit, but due to some simplifications they can be reduced to 1-bit + some tiny bit of extra logic, so it was possible to reuse almost all of the code used in game of life.

There's a little more going on behind the scenes but we're hoping to release a technical writeup on how these effects work in detail so stay tuned. In the meantime you can browse the effects' source since there are more technical explanations there.