The 'rastro' diary
==================

by KeyJ from kakiarts technologies


===== Wednesday, 2005-08-10 =====
Made the first test with the raster engine in a simple standalone program.
Surprisingly, that glReadPixels() cruft works blazing fast on my 6800 AGP card.
OK, I don't know how it's going to perform on other hardware (especially on
other manufacturer's hardware, greetings to ATI!), but this wouldn't be the
first demo/intro requiring nVidia harware, so I don't care.

Finally, I asked biff to send me a copy of the current 3igel/vortexengine
source code.


===== Thursday, 2005-08-11 =====
Having received the current source from biff (by illegally using my USB memory
stick at work, because I didn't have DSL at home yet), I adopted it as a basis
for the rastro. The vortexengine version number was changed from "1.01" to
"1.2", because if vortex was 1.0, then 3igel would be 1.1(0) and rastro,
consequently, 1.2 :)

I was pleased to see how the scene management system I devised for 3igel
(which in turn is a pimped-up version of the sprite manager from kakiarts'
Breakpoint2005 fastcompo entry) is perfectly suited to apply post-processing
effects just like normal scenes. That's cool stuff ... some people would do
that in about 20 C++ classes, but this system ist just about 20 lines of
C preprocessor macros :)

At the night from Wednesday to Thursday, it occured to me that the addition of
other raster types, apart from Floyd-Steinberg, would be a great idea, so I
added support for a simple threshold algorithm and three variable threshold
algorithms. Two of them simulate AM and FM rastering (known as 'ordered
dither'), respectively. The third one simply fills the threshold reference
picture with random noise, resulting in a nice "static noise" look.


===== Friday, 2005-08-12 =====
I decided to modify the AM raster matrix from a simplistic 4x4 to a more
advanced 8x8 one. Additionally, I wanted it to be a 45-degree screen raster,
and I wanted it to be "symmetric", i.e. inverting the grayscale source image
would (at least roughly) invert the rasterized image instead of producing a
completely different look. Unfortunately, the threshold matrix needs to be set
up *very* carefully to meet these constraints, and so I spent about two hours
of my precious life with an Excel stylesheet and a lot of experimentation, just
to find out that the matrix I wanted is basically the old 4x4 matrix, copied
four times to get 64 (=8x8) instead of 16 entries. But the copy pattern is,
erm, let's say, highly non-trivial :) And the "Kipphan" (a great book about
printing) didn't help, either.

The other part of this day's rastro work was making the loader screen and intro
scene. The rastro "logo cube" thingy was again one of these situations where
standard office software comes in handy. This time, it was a vector graphics
program (in my case, Corel Draw) that was very useful to sketch the logo cube
and split it into parallelograms, prior to packing it into 90 bytes of memory.

And while I'm at it: rastro got an icon! In spite of extreme savings (only
2-color icons), the .ico file was 518 bytes -- that's *very* bad, as UPX
seems to align everything on 512 byte boundaries. This meant that the icon
added a full 1024 bytes to the executable, but about 500 bytes out of these are
wasted (read: quite a bunch of nice zero bytes in the executable).


===== Saturday, 2005-08-13 =====
I must admit that my scene management system wasn't quite as good as I thought
two days before. It was lacking one important option: Animation Control. So I
had to add another 10 or 15 lines of the most evil C preprocessor code to have
so-called "scene parameters", allowing for animations that are not global for
the whole scene.

biff tested the pre-pre-pre-alpha version from Thursday on his notebook with a
ATI Radeon 9700 Mobility graphics chip. All I can say about this is: Sometimes
I hate being right. The rastro performs badly on the ATI chip. Really, really
badly. I'm talking about less than 5 fps, nowhere near the >75 fps my 6800
is capable of rendering. So, this will be yet another nVidia-only demo, then.
Sigh. Note to ATI: You utterly need to fix your drivers!

For the explanatory "text book" texts, I developed some kind of a metafile or
drawing system for use with my texture generator. Instead of creating each
texture "by hand" using a whole bunch of texture generator calls, a compact
structure is used that occupies a fixed 12 bytes per drawing command (string
constants not included). The usual preprocessor stuff makes the metafile source
code more readable. The only thing I didn't like is the fact that the
metafile playback function, although only 45 C lines long, weighs 334 bytes ...

Construction of the text book pages itself was a tedious task. First, I made
"prototypes" of the pages in Corel Draw and exported them as raster images to
get an idea of how the coordinates and font sizes have to be. Creating the
figures took me another one or two hours. This all resulted in about 150 lines
of drawing commands, occupying 1212 bytes of object code.


===== Sunday, 2005-08-14 =====
I knew it had to be done, and I finally did it: A simple OpenGL state
management system that keeps track of the most frequently changed OpenGL
states, avoiding a whole bunch of potential errors. And I do get additional
comfort for free as well: instead of
  glDisable(GL_LIGHTING);
  glEnable(GL_DEPTH_TEST);
  glEnable(GL_TEXTURE_2D);
  glEnable(GL_BLEND);
  glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
I can now write a simple
  glsSet(GLS_TEXTURE | GLS_DEPTH_TEST | GLS_ALPHA_BLEND);
That makes further development a lot easier.

I implemented two additional cool-looking scenes before I finally got fed up
with the 3igel tune -- it does get better every time I listen to it, but it
totally doesn't fit the mood of the rastro. So I switched over to the demo song
from farbrausch's V2 library, "welcome to", which happens to be exactly the
kind of tune I had in mind when designing the rastro concept. Integrating the
music was so much fun that I actually made some kind of an early beta version,
including synchronisation. The Release build had two amazing properties, in the
positive sense: First, it was only 33.5 kilobytes in size, that's about 70% of
my Debug builds. Second, it worked like a charm on biff's ATI (!) chip. I
didn't have the slightest clue why the Release build did perform sooo much
better than the Debug one, but Hey!, I always prefer this situation to the
opposite one ... :)


===== Monday, 2005-08-15 =====
This day, I was leaving work early (read: just before lunch) because the phone
technician would come and, HOORAY!, install my DSL connection. He did come, but
fortunately after I finished the helix/balls scene, because after he left, I
couldn't help but test if my DSL really worked. And it did. Immediately. Speed
is totally OK, I didn't believe that this DSL 2000 crap would really be fast
enough to surf the web with acceptable delays.


===== Tuesday, 2005-08-16 =====
My fresh DSL installation needed some fine tuning: I wrote a script to query
and set online status from the router. And, of course, I had to test if all my
pr0n sources were still there ;) (Just kidding.) So, I didn't do anything for
the rastro this day. Shame on me.


===== Wednesday, 2005-08-17 =====
My motivation wasn't quite as good as it should have been: I only wrote *part*
of the extro scene, which (together with the day before) set me back in my
timetable quite a bit.

Hovever, at the evening biff told me that the music for the rastro is
deliberately being worked on, something I was quite happy to hear, and
something that re-established my motivation quite quickly :) (But not strongly
enough to beat my tiredness at that moment, though ...)


===== Thursday, 2005-08-18 =====
Time to work again. I kind of finished the extro scene I began the on Wednesday
and sent another rastro development snapshot to biff, because he requested it
to fit the music better to the pace of the demo.


===== Friday to Sunday, 2005-08-19 to 2005-08-21 =====
This was an ordinary weekend, in the sense that I went back home to visit my
family. Sadly, the compiler that was installed on the machine at home was way
too old and buggy and wouldn't compile the rastro. Thus, I could not do
anything during these three days.

Sunday evening, I chatted with trs^drg and biff simultaneously and made some
kind of special deal: If trs^drg submitted a new, chilly tune until friday, I
would add it as an alternative to the rather progressive biff/dq music I had
then. To my knowledge, the rastro would be the first 64k with switchable
soundtrack, then :)


===== Monday, 2005-08-22 =====
Back in Hanover, I worked the whole evening on one lousy scene. The result
wasn't quite what I expected, it's just that after tinkering around for hours
I got an acceptable result merely by accident. I also inserted the biff/dq tune
and did some *very* preliminary sync on it. The filesize of the Release build
almost reached 40kb.


===== Tuesday, 2005-08-23 =====
This day was almost completely spent with the one thing I hate most when
creating demos: synchronization. It's not that I consider sync to be
unimportant; I realize that bad sync can make a good demo lousy and good sync
makes the public much more forgiving if the artistic quality is questionable.
But, to put it clearly, synchronizing a demo (and especially an "untooled",
pure C one like mine) is a plain PITA. You always end up playing the whole
thing some thousand times or so, listening and watching carefully to adjust
another 50 milliseconds of *one* specific scene transition or other event.

To make things easier, I added a new sync system. With the new code, I could
simply set the absolute time point (in min/sec/cc) for every scene transition.
To get the timestamps, I rendered the .v2m tune to a .wav using WinAMP and its
V2 plugin, and then I used good ol' Cool Edit 96 to navigate in the stream and
determine the needed timestamps.


===== Wednesday, 2005-08-24 =====
The version from the day before still needed quite a lot of polishing, so this
is what I did: polishing. I generalized per-scene "beat flash" code and added
some nifty effects at the points where a transition of some kind had to be made
because of the music, but no scene change was scheduled.

I also added the kakiarts logo, the "Äffchen", into the intro scene. It was an
192x256 bitmap that, to my great appreciation, looked still well when reduced
to a 4-bit grayscale image. And it compressed quite well: UPX crunched it down
to 19 kilobytes, which was still "on par", as the rastro was only 38 kb at that
time. Originally, I wanted to use (yet another) H.264-like transform coding
scheme to compress the image, but compression was already so good (and time
was so short) that I opted for a lossless scheme. Simple linear prediction from
the previous pixel in scan order did the trick -- after UPXing, the bitmap was
a mere 8 kb!


===== Thursday, 2005-08-25 =====
The last day before Evoke, and I did eventually come up with an acceptable idea
for the last, missing scene, featuring "poor man's depth of field rendering
(tm)". So, I simply implemented this last scene so that the rastro finally
was a complete intro. If *everything* would go wrong, I could at least parti-
cipate in the competition. To be on the safe side, I made backups on every
media (or internet server) I came across. Finally, I packed my computer stuff
together to ensure a quick departure the next day.


===== Friday, 2005-08-26 =====
I stopped working at the lunch break this day to get to Evoke in time. And I
did get there in time: Just after arrival in Cologne at 16:45, the official
entry was started. So I installed my system and reserved some other seats for
biff, gabi and SubC. Sadly, they didn't arrive soon, it wasn't until 20:00
that biff and gabi joined me. But that wasn't something to worry about -- I
watched some Amiga Demos at moodsplateau's place and talked to a lot of people.

It wasn't until then that I realized that kakiarts would have again three
entries, just like in the not-so-old days of glory (Breakpoint 2005, that is).
And the other entries were just awesome. Gabi created a great picture and biff
did an equally great MP3 (together with dq). We were readly to rumble, let the
compos begin ...

Overall organisation of the Evoke was OK, but there were *severe* technical
problems. First, the network didn't work at all until something past 5 o'clock
the next day. And second, they seemed to have problems with the compo or
demoshow PC: After some seconds, the computer either crashed or showed the
infamous ATI "VPU Recover" message.


===== Saturday, 2005-08-27 =====
After sleeping quite well in my car, we started the day with a long walk
through the city, looking for an ATM and having lunch at Burger King. The
afternoon was simply boring. Almost nothing interesting happened, and the 4k
demo competition was delayed until ... well, too much hours to count :)