*******************************************************************************
*                                                                             *
*   Demo:   Vector Graphic Demo Type:    Amstrad CPC Emulator DSK File        *
*   Author: Odiesoft            Webpage: http://www.odiesoft.de               *
*   Size:   1 * 194816 Bytes   Date:    n/a                                   *
*   File:   Odiesoft Demos - Vector Graphics (1990).dsk                     *
*                                                                             *
*******************************************************************************

Title: Vector Graphic Demo
Year:  1990

This was one of my first big demo parts and I was pretty proud on it, since it
also was one of the first real vector graphic demos on the CPC - as far as I
know. I’ve created this demo in 1990, but it was finally published two years
later in the SYSCRASH asc production: "GOS Party 4 - The Revenge Demo" (Side 2,
Part 5).


It’s creation is a weird story, because I wrote this whole program using an
Assembler called GMON. This GMON package was absolutely below the average, since
it neither had macros nor relative adressing. That is, I’ve created the whole
part by adressing, jumping and calling to fixed memory adresses in the RAM!
Every time I had to move parts of the program to a different location (sometimes
just one byte upwards or downwards to add/ delete a command) I had to rearrange
all the non-relative jumps, calls and adressing commands by hand!

This really was a lot of work, but upto then I didn’t have a good version of the
Maxam assembler. In 1988 I got the Maxam assembler as christmas present (I had
wished for it), but it just ran in CPM and didn’t help me a lot to write my
programs, so I kept to my GMON with which I had a lot of experience.

Writing a complex demo like this vector graphics part posed a really big and
time consuming task with this bad assembler! Every time I told people about
using GMON and showing the program to them they called me crazy - probably I was
crazy! After I got an introduction to Maxam some years later I couldn’t imagine
how I ever had used such a ridiculous program like GMON before.

But GMON is good for one thing: cracking games! Because GMON had a decent
disassmebler to take a look at the code of other people :-)

Back to the demo. There’s more to tell...

Creating vector graphics on the CPC wasn’t an easy thing to do. Calculating the
correct coordinates of the edges was very time consuming and even more time-
critical were the calculation and drawing of the vertices.

My routines in this first vector graphics demo surely are not state-of-the-art,
but they were good enough to display simple vector objects and were able to
become dotted, in order to dim the object in the distance (this was a feature I
was pretty proud on, but afterwards I had the feeling that people watching my
demo just didn’t appreciate this extra programming effort...)

The biggest timing problem I had in this demo was the clearing of the screen.
Clearing the whole screen with a regular LDIR command took way too much time, so
that I had to come up with a better idea.

At first I tried erasing the vector graphics by repainting it with empty lines,
but that didn’t really help. So I ended up using the Stack Pointer (SP) to clear
the screen. I think it was Thriller who put me to this idea in a letter. The
idea is simple but brilliant. When you push an empty register (usually the HL
register) on the stack pointer you can clear two bytes at the same time with
just three NOPs of time. This is at least twice as fast as using an LDIR command
to perform this operation.

The only problem with that approach is that the Stack Pointer is being used by
the system and by me to keep information in the memory to free up some
registers. So every time an interrupt is called and I push the registers I need
to change in the interrupt onto the SP I actually change the content of a couple
of bytes below the current address of the SP. When I pop them (get them back)
the SP should return to his initial adress and the clearing of the screen can
continue.

This works allright, but there’s a problem when the vertical retrace beam of the
screen passes the current position of the SP once I have pushed my registers on
it. Then you can see some byte flicker on the screen, because before the bytes
are correctly erased the vertical retrace beam of the screen is already
somewhere below and the bytes that the beam had painted on the screen are being
erased the next time the beam passes this position.

In other words (for all you people who haven’t understood this techno babble),
sometimes you can see some dots in one row flicker on the screen. But don’t
worry, this is not an idication for a crash coming up, but rather an artefact of
my programming...

By the way, the sound for this demo comes from the tape loading program of
Druid, the Gauntlet clone from 1989. Even though the music sounds a lot like it
is from a fair or circus or so I like it a lot. I think it was the first time I
heard a tapeloader play a music while it was loading. I was really amazed that
this was possible (years later I had to learn that even discloader are able to
play sound and animation during the loading...).

If I remember correctly I ripped this sound myself from the loader while I tried
to crack Druid. But since Druid had to load all levels seperately from tape I
never actually cracked all of it. I just transferred the main program to disc so
that it loads faster. When I was playing I let the program load its levels from
tape, because I didn’t know enough of FDC (Floppy Disc Controller) programming
to be able to write disc loading routines for the tape levels.

This demos is a typical bit by bit revealing demo. First there’s just a blocky
scroller, then there’s the first vector graphics object and finally some music
starts.

If you wait some time you’ll get to see one of my most favorite vector graphics
objects of all time: The Space Paranoid!

This reverse-U shaped aircraft comes from the classic Disney computer movie
"Tron" (the only movie I know that really tries to display the computer in a
down to earth manner, i.e. shows that working with a computer involves typing,
responding to commands on the screen and spending a lot of time working on it.
This is in contrast to most other computer-flicks where people fly through
rendered labyrinths in order to hack into the computer or type blindly on the
keyboard without seeing a single ASCII sign appear on the screen.).

I liked the story and the art of the movies so much that I always wanted to
create a CPC conversion of the game "Space Paranoids" that main character Flint
(Jeff Bridges) plays in his arcade. But my Space Paranoid vector object had 120
edges and some 80 vertices and moving this huge object alone took up way too
much calculation time to allow much else happening on the screen!

I hope that at some other point I would be able to write a conversion of ‘Space
Paranoids’ on some other system - but upto now I never got to do it. I’ve
created a small vector graphics program on the Acorn Archimedes once where I
also had my Space Paranoid flying around. It was also fast enough, but I didn’t
knew enough of vector graphics and especially of vector world coordinate
conversion and storage or processing of vector worlds that I was able to create
a game.

Displaying a single object that turns around its own center isn’t this hard, but
creating a vector graphics world unfortunately is a completely different
thing...

*******************************************************************************
*                                                                             *
* This program can be distributed freely and without the need of a written    *
* of a written permission by Odiesoft, as long as it is distributed free of   *
* charge!                                                                     *
*                                                                             *
* If you had to pay for this, you've been ripped off!                         *
*                                                                             *
*******************************************************************************

