Erfahrungsberichte dazu:
Applets (VM) sind da – Programmierung mit Events – 1996+ [Erfahrungsbericht]
https://research.swissdigitization.ch/?p=1860
Flash & JavaApplets – die Idee von einer Zukunft jenseits von Plattformen [Erfahrungsbericht Zukunft 1996+]
https://research.swissdigitization.ch/?p=4994
Das neue Framework Java-Serverseitig und JavaApplet-Front-End
Java Applets erweiterten wie andere Plugins ab 1996 das Web. Dadurch wurde das Web um ein interaktives unpropriertäres offenes Format erweitert. Es war mit einer ’normalen‘ Programmiersprache gemacht und nicht wie FLASH oder Director mit etwas ‚abstraktem‘. Zusätzlich liessen sich mit Java auch Serverseitige Dinge realaisieren. Die Idee war damit klar: Java konnte die umfassende neue klammer werden und schloss das Webfrontend auch für ’normale‘ Programmiersprachen aus der C-Familie (extended) auf.
Konkreter
Sie waren wie ein Bild aber mit der Möglichkeit der Interaktion. Allgemein beschrieben etwa hier:
A Java applet is a Java program that is launched from HTML and run in a web browser. It takes code from server and run in a web browser. It can provide web applications with interactive features that cannot be provided by HTML. Since Java’s bytecode is platform-independent, Java applets can be executed by browsers running under many platforms, including Windows, Unix, macOS, and Linux. When a Java technology-enabled web browser processes a page that contains an applet, the applet’s code is transferred to the client’s system and executed by the browser’s Java virtual machine.[5] An HTML page references an applet either via the deprecated
<applet>tag or via its replacement, the<object>tag.[6]
https://en.wikipedia.org/wiki/Java_applet
Mehr dazu auch hier: https://medium.com/@BitrockIT/java-the-world-wide-web-the-beginnings-d186cb0d381
HTML
Im HTML-Text sah dieses Objekt dann direkt so aus:
<HTML>
<BODY>
<APPLET CODE=SimpleApplet.class WIDTH=200 HEIGHT=100>
</APPLET>
</BODY>
</HTML>
https://www.oracle.com/java/technologies/jpl1-building-applet.htmlCodeStructure
Das Konzept der Applets unterscheidet sich grundsätzlich von normaler Gameprogrammierung damals.
CodeStructure MacOS (Klassische Spielprogrammierung)
Die Programmierung eines Macspiels wie etwa breakIn (Imp89) sah folgendermassen aus in C(++). Dabei kamen letztlich die genau gleichen Code-Paradigmen wie in Assembler / BASIC / Pascal zum Einsatz: Es war letztlich ein File – ein MainPrg, das den Prozessor nutzte.
Das heisst, der ganze Code wurde von Oben nach Unten abgearbeitet, dann wurde falls nötig auf den Vsync gewartet und es ging von vorne los. Das Resultat waren etwa die Spiele von Imp89.
Anders gesagt: Es gab eine „Funktion“ und die durchlief ewig bis zum „Exit“ eine Schlaufe. Der bekannte Gameloop.
Mehr zu diesen Games siehe hier: https://www.la1n.ch/macosclassic/
CodeStructure JavaApplets
JavaApplets hingegen funktionierten prinzipiell anders. Sie hatten Events. Der Code war also schon von Beginn an aufgestückelt in verschiedene Bereiche, die von der VirtualMaschine dahinter aufgerufen wurden.
Der SourceCode wurde hier nicht mehr in eine EXE für ein System übersetzt sondern für eine JavaVirtualMaschine, die bei jedem System dann anders implementiert war. Diese JavaVM war schon abstrakt oder transparent für den Nutzer. Auf einer Webseite lief das Applet also dann in der VM des Browsers.
Dabei entzog sich dem Developer, wie und was dahinter passierte. Die Events gab es nun einfach so, als Minimum der Ausführung.
import java.applet.Applet;
import java.awt.Graphics;
import java.awt.Color;
public class SimpleApplet extends Applet{
String text = "I'm a simple applet";
public void init() {
text = "I'm a simple applet";
setBackground(Color.cyan);
}
public void start() {
System.out.println("starting...");
}
public void stop() {
System.out.println("stopping...");
}
public void destroy() {
System.out.println("preparing to unload...");
}
public void paint(Graphics g){
System.out.println("Paint");
g.setColor(Color.blue);
g.drawRect(0, 0,
getSize().width -1,
getSize().height -1);
g.setColor(Color.red);
g.drawString(text, 15, 25);
}
}
https://www.oracle.com/java/technologies/jpl1-building-applet.htmlHTML-Umgebung – eine unsichere dynamisierte Welt
Die klassische Umgebung von MacOS/Finder oder dann Win95 war klar: Ein Programm wird gestartet, läuft und wird dann wieder beendet. Ausnahmefall: Taskmanager. Aber sonst war das Programm für seinen Lebenszyklus zuständig.
Bei HTML war das ganz anders. Die Webseite wurde geladen HTML. Dann wurde die Webseite gerendert und die Zusatzinhalte wie Bilder oder etwa auch Applets hinzugeladen. All das konnte das Layout wieder verändern. Oder der User machte das Fenster grösser oder kleiner. Anders gesagt: Ein Applet existierte in einem sehr dynamischen Umfeld oder pragmatischer: Applets mussten anpassungsfähig sein.
Und dies findet sich dann auch in den „Events“ und deren Parametern eines Applets. Wobei nie klar war wie die verschiedenen Umgebungen alias Browser genau damit umgingen.
Dazu sind folgende Events einigermassen klar: init() > start() > stop() > destroy()
OOP und AppletEvents
Diese Methoden sind selbstverständlich schon vordefiniert in der Grundklasse Applet, auf die der Browser und die Virtual Maschine dann zugreift.
public class SimpleApplet extends Applet{ }
Hier wird dann überschrieben, was gebraucht wird und der Rest wird so belassen, wie es ist.
Paint()
Die seltsamste Methode bleibt für das alte Paradigma die Methode Paint. Diese wird an verschiedenen Orten benutzt (println zeigt das). Wird etwa das Applet zuerst gezeichnet oder wird ein Bild darüber geschoben, dann wird diese Methode ebenfalls aufgerufen. Das heisst, Paint wird nicht immer wieder aufgerufen. Es ist mehr eine Funktion.
Deswegen eignet sie sich auch nicht als Gameloop-Funktion wie etwa bei Processing. Es muss also eine andere Methode benutzt werden.
GameLoop
Aus diesem Grund wird oft in der Start Methode ein Thread konstruiert, der dann immer wieder aufgerufen wird und eine eigene Methode aufruft, die der GameLoop etwa update() ist. Darin wird dann die Grafik „repainted()“. Und so entsteht dann das interaktive Spiel, das sich immer selbstupdated. Dabei läuft dann das Spiel in einem Browser in einer VirtualMaschine. Ist also maximal weit weg von der Hardware.
Dies war natürlich auch die Idee dahinter. Der Vor- und auch gleichzeitig sein Nachteil: Es war langsamer. Dafür gab es aber auch keine Probleme mehr mit Speichermangagement und verschiedenen Versionen – es gab ja Java (Garbage Collector).
Zerstückelung von Algorithmen/Code – das Update/GameLoop
Neu war allerdings auch, dass der Code irgendwie nicht mehr jener AssemblerCode war, der ein Methode war sondern eher ein Spiel war eher nun eine Ansammlung von Methoden, die ineinander griffen. Paint war getrennt vom Gameloop. Es entstand so eine Unabhängigkeit und Beiläufigkeit im besten Fall. Datenstrukturen bedienten die Spielmechanik wie auch die Grafikgenerierung. Eine Tendenz, die auch bei den GameEngines zu beobachten war: Das Spiel sollte nicht an der Ausgabe hängen.
Microsofts Zerstörungswerk
Die Java-Applets waren ein interessantes Framework im Gegensatz zu Shockwave oder Flash oder Active X (nur MicrosoftPlatform). Java war „offen“ als Programmsprache damals von SUN. Und Java hätte sich entwickeln können, leider versucht dann Microsoft den Standard für sich zu „gewinnen“ und seine eigene Version daraus zu machen. Damit lief eigentlich nur JavaApplet 1.1 maximal auf ihren Browsern und damit entwickelte sich das Plugin dann leider nicht flächendeckend und starb geradezu an Inkompatibilität auf der Mainstreamplatform Windows.
Im Anwendungsbereich auf dem Desktop entwickelt sich Java ebenfalls nicht schnell genug und die Performance war immer hinter native Applicationen zurück. Besser war es auf der Serverseite, hier konnte Java sich durchsetzen – gerade weil es überall lief.
C#
Microsoft entwickelt dann ein eigenes Framework und eine Programmiersprache dazu: .NET. Dieses nutzt letztlich ein VM mit einer Javaähnlichen aber nun an C orientierten Sprache C#. Die Mono-Version davon kommt in vielen platformübergreifenden Projekten zum Einsatz. Bestes Beispiel ist etwa Unity. Das dann so schnell funktionierte compiliert, dass es keine Scriptsprache mehr braucht für Unity 2003+.