Dokumentation Game.i -------------------- Einleitung ---------- Was macht man (oder Frau), wenn man ein Spiel programmieren will? Man macht sich schlau! Und warum? Weil nur wenige Leute Informationen über die Spieleprogrammierung veröffentlichen oder man bekommt überhaupt keine Infos (so wie ich). Aber damit ist jetzt Schluß!!! Warum? Na, ich will euch mit den von mir programmierten Funktionen und Ideen dazu bewegen, eigene Spiele zu entwickeln. Ziel ist es, daß die Routinen so leicht wie möglich aufzurufen sind und so effektiv wie möglich arbeiten. Ein weiteres Ziel: Jeder soll sie verstehen!! Und noch ein weiters Ziel: Es ist egal, ob die Routinen in PCQ-Pascal geschrieben sind oder in Assembler (wobei natürlich PCQ-Pascal zu bevorzugen ist), hauptsache sie laufen, passen in das Gesamtkonzept und sind getestet. Oh Gott, hoffentlich sind das nicht zu hoch gesteckte Ziele, aber wer weiß, wenn ihr voll mit dabei seit, so ist es kein Problem. Ich (und auch andere) setzen auf euch !!! Wenn ihr jetzt denkt, daß ein Spiel in Pascal unmöglich zu schreiben ist, dann werde ich euch mit meinem ersten Spiel "TakeIt" überzeugen. Fertig solls Ende Juli '92 sein. Soweit zum Vorwort. Und was kommt jetzt? Na, die Erläuterung meiner Routinen und Strukturen aus "Game.i" natürlich. Also fangen wir an. a) Die zu verwendenden Typen, Constanten und Variablen - ObjektDef Dieses ist die eigentliche Struktur für die Definition von Spielobjekten. Wenn ihr genauer hinschaut werdet ihr sehen, daß sich aus der Graphics.Lib viele Sachen wiederspiegeln die dort mit den AnimObjekts verwendet werden. Ich habe bloß keine Lust, das umständliche Handling der Graphics.Lib zu nutzen inkl. der sehr großen Strukturen. "Na ist den der verrückt geworden?" werdet ihr jetzt denken. Nein, ich bin nur jemand, der Wert auf Geschwindigkeit und Einfachheit legt und deshalb nicht die AnimObjekt-Routinen nutzt. Die laß ich lieber den Basic-Programmieren übrig ( hiervon kann jeder reden, der mal die Routinen genutzt hat. Einfach Grauenhaft!!!). Schaut euch die ObjektDef genau an, ihr werdet sie noch oft in meinen Routinen sehen. - Objektsitze Definiert die Größe eines Objektes in Byte für die Funktion CollObjekt (siehe unten). - Objekt Ist ein Array von max. 256 Objekten. Dient als eigentliche "Spielwiese" für meine Soielobjekte, da hier alle erforder- lichen Daten abgelegt sind. - Picture Ist wieder ein Kernstück der Routinen. Mit Picture de- finiere ich mir ein Array mit 100 Imagepointern aus Intuition. Warum denn das? Nun, um Objekt auf den Bildschirm zu bringen kann man Punkte verwenden (viel zu aufwendig), Linien (nicht immer zu gebrauchen), den Zeichensatz (sehr unflexibel), die Bobs (will ich nicht wegen dem Handling) oder die Images. Was ist der Vorteil der Images? Also eins Vorweg: sie werden vom Blitter gezeichnet und sind deshalb unheimlich schnell auf dem Bildschirm (siehe auch das Testprogramm). Außerdem muß ich nicht in die Blitter- programmierung einsteigen. Und zum anderen sind Images sehr flexibel: die Höhe und Breite ist vorgebbar, die Anzahl der verwendeten Bitplanes und, was auch sehr wichtig ist, die verwendeten Farben lassen sich sehr einfach ansteuern. Deshalb habe ich mich für die Images entschieden. In einer zukünftigen Version werde ich vielleicht eine andere, schnellere Routine verwenden (kennt jemand eine, die genau das selbe tut, nur schneller?). - blitctrl Wird als Globale Variable UNBEDINGT FÜR DIE BLITTERERGEBNISSE aus der Funktion "Graphcollision" verwendet. - Blittispeicher Ja, den müßt ihr selber initialisieren. Und zwar sollte er so groß sein wie das größte von euch benutzte Objekt ist. Ansonsten macht der Amiga einen Abgang ...... - MyBitMap Muß die Adresse der BitMap sein. NICHT die Adresse der BitPlanes!!! - MyRPort Muß der Zeiger auf den dazugehörigen Rastport sein. Außerdem fehlt noch eine wichtige Sache: die Graphics.Lib MUß VOM HAUPTPROGRAMM ERÖFFNET SEIN!!! Ansonsten hol's der Guru..... Schön und gut, das waren erst einmal alle Konstanten, Variablen und Strukturen. Und was kommt jetzt? Logo, die Funktionen. Wenn ihr detailierte Informationen haben wollt, so schaut in dem entsprechen- den Directory nach, sofern dieses vorhanden ist. b) Die verwendeten Proceduren und Functionen - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1) Procedure GraphCollision( x1, y1, xsize, ysize : short); Diese Funktion testet den rechteckigen Bereich mit den Eckpunkten x1, y1, x1+xsize, y1+ysize, ob in diesem ein Punkt gesetz ist. Aufgerufen wird die Prozedur mit GraphCollision(x1, y1, xsize, ysize); Alle Werte müßen vom Typ Short sein. x1 und y1 bezeichnen den oben links stehenden Punkt in einem Rechteck. Der unten rechts stehende Punkt wird aus der Addition mit den x- bzw. y-Size Werten durch das Betriebssystem ermittelt. Zu beachten ist, daß meine Routinen folgende Globale Werte im Hauptprogramm voraussetzt: - MyBitMap ---> Ein Zeiger auf die zu bearbeitende BitMap ( siehe auch das TestProgramm ). - Graphics.Lib ---> Diese MUß im Hauptprogramm ERFOLGREICH geöffnet worden sein. Sonst gibts den GURU ! - blitctrl ---> Enthält nach dem Aufruf den Wert 0 (in dem untersuchten Grfikblock gab es keinen gesetzten Punkt) oder 1 (es war mind. ein Punkt gesetzt). Nach Ende der Prozedur braucht man nur in der Variablen blitctrl nachzusehen, ob eine Kollision vorgekommen ist! Recht einfach, oder? Aber es wird noch lustiger: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 2) Function CollObjekt(von, bis, x1, y1, sizex, sizey : short) : short; Die Funktion ermittelt, welches Objekt in dem Rechteck x1, y1, x1+Sizex und y1+Sizey kollidiert ist. Hierbei kann ein von / bis Bereich für die Objektuntersuchung angegeben werden (0 - 255 ). Wird als Von-Wert -1 angegeben, so werden alle Objekte untersucht und die erste Objektnummer, die zur Kollision führte, zurück gegeben. Ist der Rückgabewert -1, so gab es eine Kolision mit einem nicht definierten Objekt bzw. das Objekt wurde nicht gefunden. Die Funktion selber untersucht das definierte Array "Objekt" nach folgendem Schema (tut mir leid, passte nicht auf einen normalen Bildschirm rauf): ---------------------------------------------------------------------------------------------------- Treffervergleich (O = Objekt, T = Trefferbereich) Ox1 >= Tx1 und Ox1 =< Tx2 == Ja ==> Oy1 >= Ty1 und Oy1 <= Ty2 == Ja ==> Treffer ! ^ ! ^ ! ! ! ! Nein ! Nein ! ! ! ! ! V ! V ! Ox2 >= Tx1 und Ox2 =< Tx2 == Ja -+ Oy2 >= Ty1 und Oy2 <= Ty2 == Ja -+ ! ^ ! ^ ! ! ! ! Nein ! Nein ! ! ! ! ! V ! V ! Tx1 >= Ox1 und Tx1 =< Ox2 == Ja -+ Ty1 >= Oy1 und Ty1 <= Oy2 == Ja -+ ! ^ ! ^ ! ! ! ! Nein ! Nein ! ! ! ! ! V ! V ! Tx2 >= Ox1 und Tx2 =< Ox2 == Ja -+ Ty2 >= Oy1 und Ty2 <= Oy2 == Ja -+ ! ! ! ! Nein Nein ! ! V V Kein Treffer Kein Treffer ---------------------------------------------------------------------------------------------------- Wer jetzt sagt "Oh Gott, was ist das für eine komplizierte Abfrage" dem kann ich nur Recht geben. Aber schaut euch bitte auch das Testprogramm an. Und wenn das nicht hilft, dann macht es wie ich: malt euch auf ein Blatt Papier alle Variationsmöglichkeiten, an dem es Kollisionen zwischen Objekten geben kann (auch zwischen unterschiedlich großen). Das Stück hat mich einige Jahre altern lassen!!! Ganz zu schweigen von der Zeit. Aber ich habe es ausgiebig getestet, weil mit dieser Routine eine Kollisionserkennung steht und fällt. UND SIE STEHT!!! Sicher, man kann noch einiges zur Beschleunigung tun (auch wenn sie jetzt schon, wie mir Tests gezeigt haben, sehr schnell ist), aber ich hatte einfach keine Zeit mehr dafür. In einem späteren Release werde ich sicherlich noch einige Minuten dafür verwenden, um sie zu optimieren. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 3) Procedure DrawObjekt( VonNr, BisNr : short); Diese Routine zeichnet ein oder mehrere definierte(s) Objekt(e), die im IMAGE-Format vorliegen müssen. Und dieses alles mit einer eigenen Blitter-Routine (schaut sie euch an, hab einige Stunden Lehrgeld zahlen müssen). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4) Procedure UnDrawObjekt( VonNr, BisNr : short ); Diese Routine löscht die mit VonNr bis BisNr gekennzeichnete Objekte auf dem Bildschirm. Ihr seht, es gibt auch einfache Routinen. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 5) Function GetChar() : byte; Diese Funktion greift direkt auf die Hardwareregister zu und ermittelt die gedrückte Taste. Der zurückgegeben Wert ist aber NICHT der ASCII-Wert sondern vielmehr das Zeichen im "rohen" Format. Hierzu einige Werte: - AMIGA-links : $33 - AMIGA-rechts : $31 - DEL : $73 - Cursor hoch : 103 - Cursor runter : 101 - Cursor rechts : 99 - Cursor links : 97 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6) Function GetJoy2(): byte; Diese Funktion fragt über die Hardwareregister den Joystick am Port 2 ab und gibt folgende Wert zurück: ---> 0 - Joystick wurde nicht berührt ---> 1 - Joystick nach rechts ---> 2 - Joystick nach links ---> 4 - Joystick nach hinten ---> 8 - Joystick nach vorne ---> 16 - Feuertaste gedrückt. Zu beachten ist, das jeweils nur das entsprechende Bit gesetzt wird, so das es sehr leicht ist, auch mehrere Aktionen gleichzeitig abzufragen (z.B. Joystick nach rechts und hinten und gleichzeitig wurde die Feuertaste gedrückt). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7) Function ChipCopy( Source : Address; Size : integer) : Address; Eine ungeheuer nützlich Funktion (jedenfalls für mich). Sie allokiert ChipMem in der Größe Size und kopiert die Daten von der Addresse Source dort hinein. Zurückgegeben wird die ChipMeM-Adresse für die weitere Verwendung. Da eine Programmierung über Pascal zu umständlich war, habe ich das ganze über Assembler programmiert (siehe Source). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 8) Procedure IntToStr6(s : string; i : integer); Diese Procedure konvertiert positive Zahlen in das Stringformat mit führenden Nullen. Max. 6 Nullen und max. ist die Zahl 999999 erlaubt. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 9) Procedure PowerLEDOn(); Ja, Ja, was könnte diese Procedure und die folgende wohl machen? Dieses beiden sind aus der Tatsache entstanden, daß ich nicht immer Bock hatte, in Handbüchern nachzusehen, wo wohl die entsprechenden Adressen sind und was man in diese hineinschreiben sollte. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 10) Procedure PowerLEDOff(); Ja, Ja, was könnte diese Procedure wohl machen? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 11. Procedure InitVB(); Diese Prozedur initialisiert, natürlich Systemkonform, einen Vertikal-Blank-Server. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 12. Procedure Exitvb(); Diese Prozedur gibt den VB-Server wieder frei. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 13. Procedure Settime(); Diese Prozedur setzt den Startwert des Zählers für den Vertikal-Blank-Counter wieder auf 0. Ohne Probleme kann das zurücksetzen erfolgen, wann immer und wie oft auch immer dieses gewünscht ist. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 14. Function Gettime(): integer; Diese Prozedur liefert den Wert des VB-Server-Zähler zurück. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 15. Procedure WaitVB(ticks : short); Und Zum Schluß, für diesen Bereich, etwas ganz simples: WaitVB wartet soviele ticks ab, wie ihr angebt. Die Verwendung schaut euch mal im neuen UFO-Game an. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 16. Function LoadSample(Nummer : byte; name : String): short; Lädt ein IFF-8SVX Sample und gibt diesem alle erforderlichen Werte mit. Es MUß sich um ein 8SVX-Sample handeln! Folgende Rückgaben sind möglich: 0 ---> Sample konnte O.K. initialisiert werden. -1 ---> File konnte nicht geöffnet werden. -2 ---> Kein Filename. -3 ---> Sampleplatz schon belegt. -4 ---> Kein IFF-8SVX-File. -7 ---> Kein Speicher für Sample. -9 ---> Kein Speicher für Dekompression. -10 ---> Unbekannter Kompression-Type. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 17. Procedure PlaySample(nummer : short); Spielt den in der Sampletab abgelegten Sound ab. Diese Assemblerroutine ist NICHT systemkonform, aber mir fiel partout nichts besseres ein, was ich machen sollte. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 18. Procedure FreeSample(Nummer: byte); Gibt das Sample mit der Nummer nummer aus der Sampletab wieder frei inkl. aller belegter Speicherbereiche. c) So, das wars erstmal. Als Beispielprogramm für die Verwendung der Routinen schaut euch UFO2 an, welches auch von mir geschrieben worden ist. Nichts desto trotz liegt es an euch, ob ihr nicht auch entsprechende Routinen schreiben wollt (welche noch zu entwickeln wären steht weiter unten). Oder setzt euch an eure Freundin und probiert mit den hier vorgestellten Routinen aus, ob ihr was auf die Beine stellt. Die Grundausstattung habt ihr und es gilt weiterhin der alte Spruch: "Jeder ist seines Glückes Schmied". Aufruf, Übergabeparameter ------------------------- Siehe in der obigen Dokumentation. Einbindung in eigene Programme ------------------------------ Hierzu sind folgende Dinge erforderlich: a) Im Sourcecode ist die Datei "GAME.I" als Include -File einzubauen, damit der Compiler auch weiß, was er machen soll. b) Der Linkeraufruf ist wie folgt zu modifizieren: blink .o to library PCQ.lib Game.Lib Erklärung des Source-Codes -------------------------- Ich glaube, eine Erklärung erübrigt sich, da ich die einzelnen Schritte dokumentiert habe. Sonstiges --------- Also fangen wir mal wieder an: a) Die Funktionen sind ALLE von mir ausreichend getestet worden. Sie laufen einwandfrei unter der Voraussetzung, das man für den Rastport eine WindowRastport wählt! Warum das so ist weiß ich nicht. Ich weiß nur, das alle Versuche, mit einem ScreenRastport zu arbeiten (wg. der Ersparnis des gesamten Windowhandlings), mit einer Reise zum Guru aufgehört haben. Vielleicht kann mir ja einer von euch sagen, warum dieses so ist. Ich habs nicht verstanden. b) Die Zeit, die ich in diese Routinen investiert habe, sehe ich als sehr groß an (bewegt sich so ca. zwischen 40 - 80 Stunden inkl. aller Test und Abstürze). Deshalb solltet ihr nach Möglichkeit nicht auch nochmal versuchen, daß Rad ein zweites Mal zu erfinden! Ich kann euch nur warnen. Wer nicht gewarnt sein will, den belegt der Gurumaster mit einer langen Zeit schlafloser Nächte, vielen Zigaretten (sofern ihr Raucher seid) und jeder Menge Kaffee (am anderen Morgen). Die Testzeit habe ich als sehr kritisch angesehen, da ich der Meinung bin, das nur wirklich ausgetestete Programme an andere weitergegeben werden sollten. c) Verbesserungen O.K., O.K., nicht alle Routinen sind das gelbe vom Ei. Vieles könnte sicher noch weiter optimiert werden. Wenn ich die entsprechende Zeit habe werde ich mich auch daran setzen. Oder wollt ihr dieses vornehmen? Wenn ja, dann schickt mir doch bitte eine Diskette mit den Änderungen die ihr vorgenommen habt. Nur um eins möchte ich euch bitten: bleibt bei der ObjektDef! Nicht, das ich hierüber das Ja und Amen ausspreche, aber solange mir keiner sagen kann, warum die Struktur unbedingt erweitert werden müßte, solltet ihr diese auch bei euren Programmen nicht weiter verändern. Falls doch, so laßt uns erstmal darüber diskutiern. Auch ich kann noch was lernen. Und denkt bitte dran: eine ausreichende Dokumentation sollte schon sein, sonst ist keinem damit geholfen, weder dem Ein- steiger, der verzweifelt ist, weil er den Source nicht lesen kann, noch der Programmierer, weil er nach 3 Monaten nicht mehr weiß, wie sein Programm funktionierte. d) Neuentwicklungen Ich glaube, hier gibt es noch einiges zu machen als da wären: 1) DualPlayfields Um auch einen unabhängigen Hintergrund darstellen zu können wäre eine Routine erforderlich, welche im DualPlayFiled-Modus IFF-Bilddaten lädt und diese in einem entsprechende Screen speichert. Wie's dann weitergeht, weiß ich nicht. 2) Eine Joystickabfrage für den Port1 bzw. eine Mausabfrage. und so weiter, und so weiter. Ihr seht, es sind keine Grenzen gesetzt. Copyrights ---------- Die Copyrights für diese Routinen liegen bei mir. ( (c) 1992, 1993 Jörg Wach ) Ich erlaube allerdings, daß diese Routinen in anderen Programme eingesetzt werden dürfen, sofern diese nicht für gewerbsmäßige Zwecke verwendet werden. Gewerbsmäßig bedeutet, daß die Routinen in einem anderen Softwareprodukt genutzt oder benutzt werden und dieses Softwareprodukt gegen einen Geldwert an Dritte verkauft oder verliehen wird. In diesem Fall bestehe ich auf die Übersendung einer Kopie des Programmes sowie auf den Abschluß eines Nutzungsvertrages. Die Nichtbeachtung kann zu einer strafrechtlichen Verfolgung führen. Ich persönlich möchte hiermit keinen abschrecken, der meine Routinen verwendet und möchte auch nur sehen, was mit meinen Routinen so passiert, aber bei einer gewerbsmäßigen Verwendung in einem Produkt betrachte ich es schon als unfair, wenn ich für die erbrachte Arbeit nicht entlohnt werde, zumal es sich hierbei um harte Basisarbeit gehandelt hat. Sollte jemand auf die Idee kommen und die Routinen zu modifizieren oder zu optimieren so bitte ich doch um die Übersendung der neuen Routinen. Auch ich kann noch was lernen! 7. Dateiverzeichnis Folgende Dateien sollte das Gesamtpacket umfassen: GAME.MOD ---> Der Sourcecode GAME.I ---> das Includefile GAME.DOC ---> na was wohl ? GAME.LIB ---> Die Library für Blink sowie die entsprechenden Info.-Files. Historie -------- V1.20 ---> 07.06.1993 Nach diversem Grauen und Schrecken sind jetzt die Funktionen für den Vertikal-Blank-Server (war eigentlich leicht) und für die Sound-Routine (DAS Grauen) hinzugekommen. Ausreichend alles getestet und in die neue Version von Ufo2 (2.2) eingebaut. Viel Spaß! V1.10 ---> 05.09.1992 - Warum hat mir keiner gesagt, daß in der Graphics.Library ein BUG ist? Bei Verwendung der BltBitMap-Routine muß der y-Bereich um eins erhöht werden! Deshalb klappten meine Grafikkollisionsabfragen nicht, und ich dachte schon, ich werd verrückt (oder bin es?). - Die Routine DrawObjekt ist jetzt absolut neu geschrieben worden. Ich habe dazu lernen müssen, wie der Blitter arbeitet, abstürzt, aufstürzt ..... na ja, und so weiter, aber es hat sich gelohnt. Gegenüber der DrawImage-Funktion aus der Intuition.Lib, die ich sonst verwendet habe, ist das Zeichnen jetzt wesentlich schneller geworden. Echt stark. V1.04 ---> 28.08.92 - Die Funktionen DrawObjekt und UnDrawObjekt funk- tionieren jetzt auch mit gelöschten Objekten. D.h. diese werden beim zeichnen einfach übergangen. - Die Funktion CollObjekt ist verbessert worden. Fol- gendes habe ich angepaßt: a) Unterscheidung, ob von/bis-Bereich richtig angege- ben wurde, sprich zuerst der kleinere und dann der größere Wert. Wenn dies nicht der Fall ist werden beide Werte vertauscht. b) Hab einen CMP gegen einen TST getauscht. c) Wenn der von/bis-Bereich gleich ist muß eine geson- derte Besetzung der Startwerte erfolgen. Dieses war ein klarer BUG! d) Die Routine zur Ermittlung der Objektadresse habe ich so geändert, daß jetzt der Mulu-Befehl zum Zuge kommt. Ist wesentlich schneller (70 Zyklen) als meine ehe- malige additionsroutine ( 30 Zyklen * Nummer des Objektes, also bei z.B. 200 Objekten = 6000 Zyklen). V1.03 ---> 22.08.92 - Die Funktion CollObjekt ist so abgeändert worden, daß nur noch SizeX und SizeY des zu betrachtenden Aus- schnittes mitgegeben werden brauchen. Warum ich das geändert habe? Weil alle Routinen der Game.Mod mit den SizeX bzw. SizeY-Werten arbeiten. - Die maximale Anzahl von Picture-Pointern habe ich auf 100 erhöht. Kann ja sein, daß man soviel braucht. Kostet auf jedenfall nicht viel Platz (400 Byte). - Die UndrawObjekt-Routine ist schneller geworden, weil ein löschen jetzt mit RectFill erfolgt. V1.02 ---> 14.08.92 - Neue Proceduren PowerLEDON und PowerLEDOFF, um mit der PowerLED ein Bischen rumzuspielen. - Pictures sind jetzt als Imagepointer zu betrachten! Wer mit der alten Version was programmiert hat sollte dieses beachten. - Die Routine DrawObjekt ist abgeändert worden. Es können jetzt keine Plane-Masken mehr vorgegeben werden, damit das Aussehen eines Bildes nicht verändert wird. V1.01 ---> 08.06.92 - Neue Procedure IntToStr6, die Zahlen bis 999999 in das Stringformat mit führenden Nullen konvertiert, wie von professionellen Spielen gewohnt. So, nun schreibt mal schön eure Programme mit den Routinen und vergesst bitte nicht, mir eine Kopie zu schicken (natürlich auf Diskette). Ihr erhaltet die Diskette mit PD-Soft oder der neuesten SoftWare aus meinen Fingern zurück. PCQ, Take it or Break it !! !!!!! !!!!! ! ! !!!!! !!!!! !! !! !! !! !! ! ! !! !! !! !! !!!!! !! !! ! ! !!!!! !!!!! !!! !! !! !! ! ! ! !! !!! !!!! !! !!!!! !!!!! !!!!! !! !! !!!! !! Jörg Wach !! Waitzstr. 75 !! !!!! 2300 Kiel 1 Neue PLZ ab 1.7.93: 24105 !! Tel.: 0431/57 84 85 !! !! Westdeutschland !! !!!!! 07.06.93