Inside the Fire Coral - Insights
category: code [glöplog]
Code:
An attempt to explain details and correlations between
"Fire Coral", "Dragon Fade" and "Autumn"
https://www.pouet.net/prod.php?which=64484
https://www.pouet.net/prod.php?which=63522
https://www.pouet.net/prod.php?which=64159
1.) DRAWING TECHNIQUE
We use the "Set Pixel" function of interrupt 0x10
CX = x, DX = y , AL = color, AH = 0x0C (set pixel)
http://en.wikipedia.org/wiki/INT_10H
NOTE : Depending on the Graphics BIOS, you might
see different results when plotting negative
coordinates, or exceeding the legal amount of
colors. Here, one underflow is accepted, the other
is catched with a signed flag branch
"sub cx,dx" + "js Skip" = don't draw on negative x
2.) THE FRACTAL
We use a simple iterated function system (IFS)
consisting of two functions with equal probability.
http://en.wikipedia.org/wiki/Iterated_function_system
We use a discrete, scaled up version to save space.
This also fits the drawing technique in a good way.
Used in sizetros:
Dragon Fade :
https://www.pouet.net/prod.php?which=63522
Autumn :
https://www.pouet.net/prod.php?which=64159
NOTE : Obviously keeping both functions similar
and having coefficients of "0.5" enables binary
commands (arithmetic shift!) and uses little space.
IFS1 CX DX
initial x y
add dx,cx x x+y
sar dx,1 x (x+y)/2
sub cx,dx (x-y)/2 (x+y)/2
Scaled down, normalized floating point equ.
f(x) = 0.5x - 0.5y f(y) = 0.5x + 0.5y
IFS2 CX DX
initial x y
add dx,cx x x+y
sar dx,1 x (x+y)/2
sub cx,0x533 x-0x533 (x+y)/2
sub cx,dx (x-y)/2-0x533 (x+y)/2
Scaled down, normalized floating point equ.
g(x) = 0.5x - 0.5y - 1 g(y) = 0.5x + 0.5y
f(x) & g(x) written in coefficients with probability
0.5 -0.5 0.5 0.5 0 0 0.5
0.5 -0.5 0.5 0.5 -1 0 0.5
copy paste to http://cs.lmu.edu/~ray/notes/ifs/
to see what it looks like (and to explore further)
check http://guyanddeb.com/af.html to see, where
the fractal is located on the plane (clipping!)
separate coefficients with commas there, and
supress probability, then hit "Correct Input"
0.5, -0.5, 0.5, 0.5, 0, 0
0.5, -0.5, 0.5, 0.5, -1, 0
Adjust xmin, xmax, ymin, ymax and hit "Draw"
3.) MAKING THE CHAOS PREDICTABLE
Normally, to implement the "chaos game" version
of iterated function systems, you would need a
random number generator. To be precise, you would
need a VERY GOOD one, as carefully pointed out by
Peitgen, Jürgens and Saupe in "Chaos and Fractals:
New Frontiers of Science" (just google for "random
number generator pitfall") Surprisingly enough, if
done right, one doesn't need ANY rng - at all!
The secret lies in converting the chaotic infinite
real number system into a deterministic, finite,
discrete system with a rather short period, somewhat
like a "knights tour" on a chess board. In other words,
we need a function F which we apply N times to a point P
so that
F(F(F(F ... F(P)))) = F^N(P) = P
and so that every pixel on the plane inside the fractal
is actually "visited" once per cycle. It turns out, that
at least one such function exists (several, actually),
characterized by the magic number 0x533, and the branching
criteria "sum of x and y is even" (checking the carry
flag after "add dx,cx" and "sar dx,1") Currently, i
dont't know exactly what "magic numbers" produce stable
plane filling cycles, how they are connected to the
branching criteria, or how to find them, other than by
trying. I'll leave that for later - or for the
mathemagicians amongst us ;)
Link to "random number generator pitfall"
TL/DR : the final function is both : the fractal, as well
as the random number generator it needs =)
NOTE : Every pixel is drawn once per cycle, with the very
same color each cycle, which makes it a rather still image.
The "noise effect" happens due to the drawing technique,
different points of the fractal are projected to the same
screen coordinates.
4.) COLORING
The idea is to code the branching history directly
into the pixel color, so that all pixels which branched
equally in their last 4 iterations are plotted with the
same color. "shl ax,1" keeps all the iteration history,
except one (the oldest), and the free (lowest) bit is
marked according to the latest. "inc ax" is just
a shorter version of the more comprehensive "or ax,1"
This has been used in "Dragon Fade", and generates
very regular color structures. To achieve a mixture
between random and regular structures, we can use the
fact, that we have several ways to initialize the graphic
mode to 0x12 from an initial emtpy AL, "xor" beeing one
of them. "xor al, 0x12" works together with "shl ax,1"
as a minimized xorshift randomizer, which is yet still
dominated by the regularity of the branching history.
"aam ??" is a tuneable coloring parameter.
NOTE : "aam ??" and skipping the drawing of certain
points, while keeping track of iteration history, lifts
the coloring beyond simple predictability. At this point,
i stopped analyzing and was satisfied with the
tuning parameters i found ;)
5.) USER EXIT FUNCTION
Normally, you would use the infamous "in al,0x60" to
check if the user wants to ESCape. Unfortunately, AL
holds the current pixel color all the time, so that
at least two bytes (push ax,pop ax) would be needed
to do it that way. Luckily, MSDOS provides another
function to check the keyboard, modifying the Zero Flag
if some key was pressed. And since a simple "mov" does
not alter that flag, we can smoothly weave that into
the code. Still, all together this takes up 5 bytes,
and i am somewhat happy, that there was enough space
to include this.
http://www.ctyme.com/intr/rb-1755.htm
6.) ADDITIONAL NOTES
The fading effect of "Dragon Fade" is actually just
a well tuned coloring function. Since every pixel is
"touched once" per cycle, and colors above 0x80 are
"xor"ed onto the screen, you just need to make sure,
that the color function remains constant for each
pixel (for consecutive iterations).
http://webpages.charter.net/danrollins/techhelp/0127.HTM
To be independent from "magic numbers", you can delay
the iteration history. You basically choose the function
by the branch another pixel took X iterations ago. Simply
"rcr bp,1" or "rcr ebp,1" does the trick (between generating
and checking the carry flag). This advanced selection
is used in "autumn". It is basically needed there, because
the average achieved period is way too low to cover every
pixel of the screen. Just change the delay from 32 to 16 by
replacing "rcr ebp,1" with "rcr bp,1" to see what i mean.
Note, that even if you don't get total garbage with "unlucky"
numbers using this technique, some numbers still do better
than others. But the chance to find one, and the overall
screen coverage is really heavily increased.
Note, that besides clever usage of just one call to
int 0x10 and some flag shenanigans (carry, sign, zero)
no real "dirty" tricks have been used here, like, odd
alignment, self modifying code etc. Checking politely
for a key and quitting takes up 5 bytes, "sub cx,0x533"
occupies a whooping 4 bytes, and in fact the shortest
fading dragon i can come up with, is 23 bytes long.
What i want to point out is, this is nowhere near the
limit, when we think 32b, and i think, it can be MUCH
more impressive when we think 64b (think about a lot
better "autumn").
Greets and Respect go to : rrrola, frag, Baudsurfer,
Sensenstahl, Whizart, g0blinish, Rudi, orbitaldecay,
igor, Drift and all Desire members =)
If you have further questions, don't hesitate to
mail me : storrryteller@hotmail.comCode:
Start
xor al, 0x12 ; Set 640*480*16 Mode, also Coloring (special)
int 0x10 ; Set Resolution, also : Set Pixel
Skip
add dx,cx ; Shared IFS
shl ax, 0x01 ; Coloring (base)
sar dx, 0x01 ; Shared IFS
jnc Branch ; Deterministic alteration
sub cx, 0x533 ; Special IFS (Difference)
inc ax ; Coloring (base)
Branch
aam 0x0E ; Coloring (special)
sub cx,dx ; Shared IFS
js Skip ; Clipping
mov ah, 0x01 ; User Exit Function
int 0x16 ; User Exit Function
mov ah, 0x0C ; Set Command to "Set Pixel"
jz Start ; User Exit Function
ret ; Quit
Thank you very much for these comments, this was a very interesting read.
