View source for Design Tips and Demoscene effects with pseudo code

== Introduction ==
On this page we will provide a bunch of general design tips as well as examples for commonly used effects. Its always good to know in a more broader sense how certain effects are approached, before thinking about how to do them in a small size or how to best implement them for a specific platform.

== General Tips ==
Before we start diving into the effects themselves, here are some general tips if you are new to demoscene coding:

* Make prototypes in another language you're familiar with
* Make sure to write comments, your future self will thank you.
* Learn from the source code of others (a lot of productions include the sourcecode)
* Collect your own bag of tricks and document them for easy access
* If your idea is complex: approach your problems one at a time in seperate files and merge them together at a later stage
* Write down a simplified list how much bytes each of the commonly used instruction costs 
* Don't be afraid to itterate on existing ideas and code
* Get comfortable making mistakes. 
* Cherish the happy accidents

== Effects and Techniques == 
There are basically two strains of effects being used. 
* The first would be Hardware Effects (rasterbars, sprites,etc.) that are often used on 8/16bit machines to compensate for the lack of CPU power. 
* The second group is pixel-based effects where the pixel color or index is calculated for each pixel (or chunky pixel on older platforms) on the screen. 

== Common Demoscene Effects ==

==== Size / CPU-Load / Effect table ====
{| class="wikitable"
|-
! Size !! Effects
|-
| Small || Oscillators, Fractals, 2D Starfields, Hardware hacks
|-
| Small || Pixel-Summing, Mathematical Functions
|-
| Medium || Sine-plotters, Twisterbars, 3D Starfield, Dot Tunnels
|-
| Medium || Plasma, Attractors
|-
| Medium || UV/Image Distorters, Rotozoomers
|-
| Medium || Raycasting, Voxels
|-
| Large || Raymarching, Raytracing
|-
|}

====Oscillators====
Oscillators can be use to draw circles and other interesting fractal-type shapes in only a few lines of code. Sometimes these oscillators are refered to as Minsky circles or Minsky machines. Note that oscillators can also be used in different settings as an alternative for sine/cosine in case of 2D or 3D Rotations.

In its most basic form it looks something like this:
<syntaxhighlight>
s=128
t=0
for i=0, numdots do
x = x + y / 2
y = y - x / 2
plotPixel(x,y,color)    
end
</syntaxhighlight>

====2D Starfields====
2D Starfield can be generated cheaply using a pseudorandom for horizontal position and locking the speed to the vertical position/loopcounter. These can ofcourse be done in any 2D direction.

<syntaxhighlight>
r=0
for y=0,height do 
tt=time<<(y&3)
x=(y+tt+r)%256
plotPixel(x,y,color)
r=r+11
end
</syntaxhighlight>

====Pixel-summing / Automatons====
Here you add a number of different pixels and shift back the result to create interesting effects, e.g. Fire effect, Random Walk, Color fight, GameOfLife, etc.
<syntaxhighlight>
color = (img[x,y] + img[x,y+1] + img[x-1,y+1] + img[x+1,y+1]) / 4;
</syntaxhighlight>

====3D Starfield====
Similar to a 2D starfield, but with 3D to 2D projection, here we are projecting a set of pseudo-random
dots in 3D space down to 2D pixel coordinates
<syntaxhighlight>
y=74
for i=0,numdots do 
x=y
y=((y*5)&127)-64
z=(i*2-time)&127
plotPixel(x * 127 /z + centerx,y * 127 / z + centery,color)
end
</syntaxhighlight>

====Dot Tunnels====
Dot tunnels have been classic demoscene effects since the early 90s. 
These are very similar to the 3D starfield, but instead of projecting random dots, you are now projecting various moving layers (zz) of circles (sin(a)/cos(a)) and moving the center position about.
 
<syntaxhighlight>
for a=0,32 do
for z=0,32 do
// project tunnel dot
zz = (z-time) % 32
x = SIN(6.28/32*a) * 127 / zz
y = COS(6.28/32*a) * 127 / zz
// move tunnel center
centerx = SIN(t/32+zz/16)*64 + 120
centery = SIN(t/9+zz/14)*64 + 68
plotPixel(x + centerx, y + centery, color)
end end
</syntaxhighlight>

====Fractals====
Rendering and/or animating a fractal like the IFS, Mandelbrot of Julia Set or something more simple like a sirpinski triangle. Here is an example of a julia fractal:
<syntaxhighlight>
iterations=16;
while (--iterations>0) {
Y_new = (X+X)*Y-p
X_new = X*X-Y*Y+q;
X = X_new; Y = Y_new;
if (X*Y<3.5) goto storepixel;
}
color=iterations;
</syntaxhighlight>

====Attractors====
An attractor is a pattern or set of behaviors that a system naturally settles into over time, even if it starts from different points. In systems like the Lorenz attractor, you repeatedly feed the output of a function back into itself, creating a feedback loop. Although the results may look chaotic, they tend to form a consistent shape or behavior, showing how complex systems can have underlying order.
As a shorter hack, a form of attractor can be achieved by feeding the previous output of a sine/cosine calculation back into the phase of another function, like for example the 'universe' example.

<syntaxhighlight>
  n=40
  m=200
  r=2*PI/235
  for i=0,n do
    for j=0,m do
      a=i+v
      b=r*i+x
      u=SIN(a)+SIN(b)
      v=COS(a)+COS(b)
      drawPixel(u * SCALE + centerx, v * SCALE + centery , color)
      x=u+t
    end
  end
  t=t+0.02
</syntaxhighlight>

====Mathematical Equations====
Rendering a (2D) mathematical equation for each x,y value in relation to a algebraic formula. For example the heart-shaped equation looks something like this:
<syntaxhighlight>
a=heartsize;
if (pow(y*y + x*x - a*a, 3)<y*y*y * x*x * a) then  we are inside the heartshaped curve; 
</syntaxhighlight>

====Plasma====
Calculate the color for each pixel by adding a number of sine values, e.g. 
<syntaxhighlight>
color = sin(x*val+t) + sin(y*val2+t) + sin((x+y)*val3 + t)
</syntaxhighlight>

====Sine Plotters====
Drawing pixels or shapes onto (a combination of) sine curves. 
These can be done on any number of axes. The most common ones use 2 axes, but for example you can imagine just locking the X or Y axis to the dot counter and only updating the other axis (i.e. starballs, starcoils, etc.). 
<syntaxhighlight>
for i=0, numdots do
x = sin(t/17 + i/spacing) * xrange + centerx;
y = sin(t/19 + i/spacing) * yrange + centery;
plotpixel_or_shape(x,y,color)    
end
</syntaxhighlight>

====Twisterbar====
Colored or textured twister bars connecting and clipping the edges of 3 or 4 sinevalues that differ across the Y axis. Here is an example of per-pixel twisterbar, but on oldschool platforms it is usually done with drawings simple (vertical) slices of a precalculated image.
<syntaxhighlight>
w=(x-centerx)/32
v=(y-centery)/29 - 4
r = v * sin(t/19)%1.57 - 183
c = sin(r+11)
barshade = ((w-c)//2+c)*4
color = (w>S(r+22) AND w<S(r)) ? barshade : bgcolor
plotpixel(x,y,color)
</syntaxhighlight>

====Image/UV Distorters====
Distort each pixel by essentially transforming your X,Y screenspace to something different (for example a polar space by taking the atan to center for x-axis and distance to center for y-axis). Other know distortion spaces for example are the Rotozoomer and Floorcast, which transforms your X,Y space into a perspective floor.

=====Perspective Floor=====
<syntaxhighlight>
dx=x-centerx;dy=y-centerx
z = abs(dy);
U = x * scalevalue / z
V = perspectivevalue / z
</syntaxhighlight>

===== Polar Coordinates/Tunnel =====
<syntaxhighlight>
dx=x-centerx;dy=y-centerx
U = atan2(dx,dy) * 128/MATH_PI;
V = sqrt(dx*dx + dy*dy);
</syntaxhighlight>
For a perspective tunnel: <syntaxhighlight>V=somevalue/sqrt(dx*dx+dy*dy)</syntaxhighlight>

=====Rotozoomer=====
<syntaxhighlight>
dx = x-centerx
dy = y-centery
U = cos(angle)*dx - sin(angle)*dy
V = sin(angle)*dx + cos(angle)*dy
</syntaxhighlight>

These U,V coordinates can then be used for either a bitwise operation (like a XOR or AND pattern for example) or lookup coordinates for your texture.

==== Raycasting ====
Walking through a 3D Space using a fixed step in the Z direction (usually using fixed point math) and using these values inside a logic formula (e.g. 3D Sirpinski (Deus faber) or Cubic Grids (Into a new era, Starpath, etc.) or a map lookup (Landscapes, Wolfenstein).

See here a small example of pseudo code as used in into a new era:

<syntaxhighlight>
dx = x-centerx
dy = y-centery
for d = -10,-99,-1 do
h = ((d*d + (d*dx) xor (dy*d)) / 256 + 4) and (d-t)
if (h&8>0) then plotpixel(x,y,(h-7 + ((x xor y)&1) )) break end 
end
</syntaxhighlight>

==== Raymarching ====
Step through 3D Space in Z direction using a variable step size, doing depth testing with all kinds of geometric equations (SDF's or Signed Distance Fields) to see if you've hit something, and if not step forward with that distance (usually multiplied with a factor less than 1 to avoid overstepping), getting you closer and closer to the actual distance each time.
More often used in 4k and 1k intros than the really smaller ones because it takes a bit more setup, but definitely also possible for simple SDF's in smaller sizes.

<syntaxhighlight>
float px = 0.0f, py = 0.0f, pz = -1.0f;
float ray_x = u, ray_y = v, ray_z = 1.0f;
float z = 0.0f;
for (i = 0; i < 32; i++) {
    // repetition in all 3 axis
    float mpx = mod(px,1.0f) - 0.5f;   
    float mpy = mod(py,1.0f) - 0.5f;   
    float mpz = mod(pz,1.0f) - 0.5f;   
    float d = sqrt(mpx*mpx + mpy*mpy + mpz*mpz) - 0.3; // 0.3 = sphere size     
    if (d < 0.01) break;  // break out when hit
    // step through scene
    px += ray_x * d * 0.5f; 
    py += ray_y * d * 0.5f; 
    pz += ray_z * d * 0.5f; 
    z += d * 0.5f;
}
color = 1.0f / z;
</syntaxhighlight>
The benefit of this technique vs raytracing is that you can find distances to a lot more shapes than analytical intersections, which gives you a lot more flexibility. Also you can distort the raydirection
in any way you like during the stepping process, which can lead to interesting visuals. 
The downsides are ofcourse the code/cycles involved in the stepping process as well as the trickery required to get fake normals and somewhat decent UV coordinates.

==== Raytracing ====
CPU/FPU heavy calculations allow for calculating a intersection point and/or light model between your ray and 3D Solid / quadratic equation (often spheres or planes, see: stainless steel, etc.). Slower than raymarching in most cases, but often slightly less setup.

Here is an example of a ray/sphere intersection, based on the ABC-formula equation we've been taught in highschool and you thought you would never need in your life probably 😉 

<syntaxhighlight>
// quadratic formula (ray_z is assumed 1, r = spheresize)
a = (ray_x * ray_x) + (ray_y * ray_y);
b = 2.0f * (originx * ray_x) + (originy * ray_y);
c = (originx * originx) + (originy * originy) - (r*r);
// find intersection distance
d = (b*b) - (4.0f*a*c);
if (d<0) t=0;
if (d==0) t=-b/(2*a);
if (d>0) {
 t1 = (-b - sqrt(d)) / (2.0f * a);
 t2 = (-b + sqrt(d)) / (2.0f * a);
 t = min(t1,t2);
}                                   
}
// Find intersection point
intersectionX = originx + t*ray_x;
intersectionY = originy + t*ray_y;
intersectionZ = originz + t*ray_z;
// Optional: calculate UV
u = fabs(intersectionZ * 0.5f);
v = fabs(atan2(intersectionY,intersectionX) * 128.0f / pi);
</syntaxhighlight>

== Design Tips ==
====Design tip #1==== 
Try to look around to see what is out there and where there is room for new stuff: Whenever i start experimenting with a new platform (like spectrum, atari, fantasyconsole, etc.) I literally watch EVERYTHING that is ever released in 256, 128 and below for that platform to get a feel for what is out there and where i can maybe add something.

====Design tip #2====
The actual execution is in (re-)combining tools from your bag of tricks... The more tricks in your bag, the amount of combining possible increases tenfold... So imho its always worth to try experimenting with (new) things/techniques without ever having a point of releasing it, or doing something concrete with it...

====Design tip #3====
Don't try to optimise early, but don't do things 'the expensive way' deliberately either. Try to sketch out the idea as complete as possible to what we had in mind. (trying to make zero to little compromises, regardless of size). So your intro will probably always go overboard by quite a bit in the beginning (300-350 bytes for 256, ~160-170 for 128 byte stuff) and once you're happy with the end result tone back from there and THEN start to make compromises (or not at all, so a 128 byte intro ends up as a 256b down the road , or a 256b intro is on hold , changes platform, or dismantled for parts) .

====Design tip #4====
If you can afford the luxury: Ideally you'd like to have at least 1 intro ready for release at any time , without a party in sight...  This allows you to have a choice, maybe tweak on the end-result a bit more or to have something to submit last minute.