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...