HTML5-Tutorium: Canvas: MiniPong 02

Dieser Artikel erfüllt die GlossarWiki-Qualitätsanforderungen nur teilweise:

Korrektheit: 3 (zu größeren Teilen überprüft)

Umfang: 3 (einige wichtige Fakten fehlen)

Quellenangaben: 5 (vollständig vorhanden)

Quellenarten: 5 (ausgezeichnet)

Konformität: 5 (ausgezeichnet)

HTML-Tutorium: MiniPong

MiniPong: | Teil 1 | Teil 2 | Teil 3 | Teil 4 | Teil 5

Musterlösung: MiniPong 2 (SVN-Repository)

Ziel: Animation des Balls

Die Ball-Animation des ersten Teils des Tutoriums zeichnet sich noch durch ein prinzipielles Problem aus: Bei der Darstellung der Animation wird die Leistungsfähigkeit des Rechners des Benutzers der Anwendung nicht berücksichtigt. Das ist bei einer einfachen Ball-Animation sicher auch nicht notwendig. Bei komplexeren Anwendungen kann dies allerdings schnell zu großen Performanz-Problemen führen.

Mit Hilfe zweier Optimierungstechniken kann man diese Probleme deutlich abmildern. (Das heißt allerdings nicht, dass jede Animation auf jedem Endgerät läuft.)

Neues Projekt anlegen

Legen Sie ein neues Projekt mit dem Namen „MiniPong02“ an.

Kopieren Sie alle Dateien des Projektes MiniPong01 in das neue Projekt.

Nehmen Sie folgende Anpassungen vor:

• Umbenennung des Ordners „app“ in „app1“.
• Umbenennung der Datei „main.js“ in „main1.js“.
• Umbenennung der Datei „index.html“ in „index1.html“.
• In der Datei „main1.js“:
  • Ersetzen von „app: 'app'“ durch „app: 'app1'“.
• In der Datei „index1.html“:
  • Ändern des Titels in „MiniPong02 (App1)“:
  • Ersetzen von „js/main'“ durch „js/main1“ im Script-Befehl.

Nun sollte die Anwendung wieder laufen.

Trennung von Physik und Grafik

Prinzipiell müssen in jedem Animationsschritt der Anwendung „MiniPong“ aus zwei wesentliche Aktionen durchgeführt werden:

1. Aktualisierung der Simulation eine physikalischen Welt.
2. Aktualisierung der Darstellung der Objekte, deren Physik simuliert wird, auf der Bühne.

Der erste Schritt ist meist nicht sonderlich rechenintensiv: Es müssen einige mathematische Operationen durchgeführt werden, um die Position, die Masse, den Zustand und evtl. andere Eigenschaften der simulierten Objekte zu ermitteln. Allerdings ist es notwendig, diese Berechnungen möglichst häufig pro Sekunde durchzuführen. In der realen Welt erfolgen die meisten Änderungen physikalischer Größen kontinuierlich. Beispielsweise ändern sich die Position, die Geschwindigkeit und die Beschleunigung eines Balles stetig. Die Simulation derartiger Größenänderungen erfolgt an Rechner dagegen fast immer in diskreten Schritten (Ausnahme: Analogrechner): Mehrmals pro Sekunde werden die Größen neu berechnet. Durch die diskrete Berechnung kontinuierlicher Änderungen kommt es unweigerlich zu Rechenfehlern.

Aus mathematischer Sicht wird bei der Simulation einer physikalischen Welt die Integration durch die Bildung diskreter Summen ersetzt. Bekanntlich kann ein Integral mit Hilfe von Grenzwerten von Flächensummen definiert werden. Die Grenzwertbildung bedeutet, dass die Flächen von immer mehr, immer kleineren Bereichen aufsummiert werden. Im Grenzfall sind die betrachteten Flächen unendlich klein und die Anzahl der Flächen ist unendlich groß. Diese Grenzwertbildung können wir am Rechner natürlich nicht nachbilden. Wir können allerdings versuchen, diskrete Summen von möglichst vielen, möglichst kleinen Elementen zu bilden. Das erreicht man, indem die Frequenz der physikalischen Berechnungen möglichst groß gewählt wird. 500 Neuberechnungen pro Sekunde sind deutlich besser als 20 Neuberechnungen. Und diese sollten möglichst gleichmäßig erfolgen, ohne große Lücken zwischen den einzelnen Schritten, da der zeitliche Abstand zwischen zwei Berechnungsschritten bei der Simulation berücksichtigt werden muss: Ein Ball bewegt sich in 20 ms weiter als in 10. Es ist zwar auch möglich bei jeder Neuberechnung die aktuelle Berechnungsfrequenz zu berücksichtigen – indem man für jeden Berechnungsschritt einen Zeitstempel vergibt, mit dem man ermitteln kann, wann die letzte Berechnung erfolgt ist –, besser ist es jedoch, wenn zwischen zwei Schritten stets gleich viel Zeit vergeht.

Ganz anders stellt sich die Situation im Falle der Grafikausgabe dar. Während für die physikalische Simulation ein paar tausend oder zehntausend Rechenschritte notwendig sind, benötigt man für die Darstellung der Objekte auf dem Bildschirm meist mehrere Millionen Operationen. Beispielsweise besteht ein Full-HD-Bild aus $1920 \cdot 1080 = 2.073.600$ Pixeln. Heute werden i. Allg. Hochleistungsgrafikarten eingesetzt, um mindestens 60 Bilder pro Sekunde zeichnen zu können. Anderenfalls würde das Bild zu sehr flackern. Eine Framerate von 500 Bildern pro Sekunde ist meist vollkommen undenkbar. Das ist aber auch gar nicht notwendig. Es reicht, wenn das Bild auf dem Minitor so oft wie möglich aktualisiert wird. Es müssen nur jeweils alle Objekte, an ihren aktuellen Positionen gezeichnet werden. Und ob zwischen zwei Frames mal ein paar Millisekunden mehr oder oder weniger vergehen, ist auch nicht wesentlich. Wichtiger ist, dass der Rechner für die Verarbeitung des nächsten Bildes bereit ist. Wenn er das letzte Bild noch nicht gezeichnet hat, sollte er nicht mit dem nächsten anfangen. Sonst kann es passieren, das viele aufeinander folgende Bilder nur jeweils unvollständig gezeichnet werden oder dass das System zu ruckeln anfängt, weil die Zeichnen eines jeden Bildes zu lange dauert.

Um diese Probleme zu umgehen, gibt es in JavaScript den Befehl „window.requestAnimationFrame“. Diese Methode erwartet als Input eine Callback-Funktion, die aufgerufen wird, sobald der Bildschirm wieder für eine Grafikausgabe bereitsteht. Üblicherweise aktualisiert diese Callback-Funktion zunächst die Bildschirmdarstellung (Neuzeichnen eins Canvas-Elements, Ändern von SVG-Elementen im DOM-Baum etc.) und ruft dann requestAnimationFrame rekursiv mit derselben Call-Backfunktion auf:

function updateView()
{
   // app: update view
   window.requestAnimationFrame(updateView);
 }

Der Callback-Funktion wird bei jedem Aufruf ein Zeitstempel mitgegeben. Damit kann beispielsweise die aktuelle Framerate ermittelt werden:

var l_last_step = Date.now();
function updateView(p_timestamp)
{
  // app: update view
  console.log('FPS: ' + (Math.round(1000/(p_timestamp - l_last_step))));
  l_last_step = p_timestamp:
   window.requestAnimationFrame(updateView);
 }

Jetzt muss die Animation nur noch gestartet werden. Dazu reicht es, requestAnimationFrame einfach einmal direkt aufzurufen:

window.requestAnimationFrame(updateView);

Dieser Befehl liefert übrigens einen Identifikator zurück, den man in einer Variablen speichern kann:

var v_animation_id = window.requestAnimationFrame(updateView);

Damit ist es möglich, die Animation zu einem späteren Zeitpunkt mittels cancelAnimationFrame wieder zu stoppen:

window.cancelAnimationFrame(v_animation_id);

Model und View

Aufgrund der obigen Erkenntnisse, sollte man in jede Web-Anwendung, die eine Welt simuliert und animiert, zwei Update-Methoden zur Verfügung haben:

• updateModel: Aktualisiert das (physikalische) Modell.
• updateView: Aktualisiert die Bildschirmausgabe.

Die erste Methode wir regelmäßig mit Hilfe eines Timers aufgerufen. Die zweite Methode wird dagegen mit Hilfe von requestAnimationFrame aktiviert.

Konsequenterweise ersetzen Sie zunächst den Begriff “frames per second” und alle Dateien durch “simulation frequency”.

• Edit → Find → Replace in Path...
• Text to find: FindframesPerSecond, Replace with: simulationFrequency/code> → Find → All Files

Ersetzen Sie auf dieselbe Art in allen Dateien fps durch f und passen Sie die Dokumentation von Ball.prototype.move geeignet an.

Erhöhen Sie die Simulations-Frequenz in der Datei „init.json“ auf 100. Laut developer.mozilla.org ist der minimale Abstand zwischen zwei Timer-Events gemäß HTML5-Spezifikation 4 ms. Dieser Wert wird auch von Browsern, die nach 2010 veröffentlicht wurden erreicht. Bei älteren Browsern betrug der minimale zeitliche Abstand noch 10 ms. Das heißt, mit einem Wert von 100 (= 1000/10) ist man immer auf der sicheren Seite, HTML5 erlaubt Werte bis 250 (=1000/4).

Überprüfen Sie, ob Ihre Anwendung noch läuft. Wenn das der Fall ist, sollten Sie in der Datei „minipong.js“ die Methode „draw“ durch folgende zwei Methoden ersetzen:

this.updateModel =
function()
{
  // collision detection and handling
  collision(l_canvas, l_ball);

  // model update
  l_ball.move(l_f);
};

this.updateView =
function()
{
  // clear canvas
  p_context.clearRect(0, 0, l_canvas.width, l_canvas.height);

  // draw the ball
  l_ball.draw(p_context);
};

Als nächste muss noch die Timerfunktion in der Init-Datei angepasst werden. Anstelle von l_game.draw ruft sie jetzt periodisch l_game.updateModel auf:

// model update
p_window.setInterval(l_game.updateModel, 1000/p_init.physics.simulationFrequency);

Damit wir jetzt zwar das physikalische Modell des Balles animiert, aber die Animation wird noch nicht angezeigt. Dazu wird jetzt wie oben beschrieben der Befehl „requestAnimationFrame“ eingesetzt:

// view update
function f_update_view(p_timestamp)
{
  l_game.updateView();
  p_window.requestAnimationFrame(f_update_view);
}
p_window.requestAnimationFrame(f_update_view);

Wenn Sie zusätzlich die Framerate im Canvas ausgeben möchten, fügen Sie zunächst folgendes Objekt in das Objekt „view“ in der Datei „init.json“ ein:

"fps":
{
  "x": 5,
  "y": 15,
  "font" : "bold 10px \"Times New Roman\", Times, serif",
  "color": "black"
}

Dieses Objekt gibt an, wo auf der Bühne die FPS-Angabe erfolgen soll und in welchen Font und in welcher Farbe der Text gesetzt werden soll. Nun können Sie die View-Update-Methode folgendermaßen definieren:

// view update (displaying the frame rate)
var l_last_step = Date.now(),
    l_context   = l_canvas.getContext('2d'),
    l_fps_style = p_init.view.fps,
    l_fps_x     = l_fps_style.x,
    l_fps_y     = l_fps_style.y,
    l_fps_color = l_fps_style.color;

l_context.font = l_fps_style.font;

function f_update_view(p_timestamp)
{
  l_game.updateView();
  l_context.fillStyle = l_fps_color;
  l_context.fillText('FPS: ' + (Math.round(1000/(p_timestamp - l_last_step))),
                     l_fps_x, l_fps_y
                    );
  l_last_step = p_timestamp;

  p_window.requestAnimationFrame(f_update_view);
}
p_window.requestAnimationFrame(f_update_view);

Trennung von Model-Klasse und View-Klasse

Jetzt, nachdem die Berechnung der Animation erfolgreich in Model und View getrennt wurden, sollte man dasselbe auch mit der Ball-Klasse machen. Künftig gibt es zwei Ball-Klassen:

• ModelBall: beschreibt das physikalische Ball-Objekt
• ViewBall: beschreibt das Aussehen des Ball-Objekts (Theme, Skin)

Damit ist es möglich, künftig unterschiedliche Themes für das Ballspiel zu definieren.

Erzeugen Sie zunächst zwei neue Ordner:

• js/app2/model
• js/app2/view

Verschieben

Quellen

1. Braun (2011): Herbert Braun; Webanimationen mit Canvas; in: c't Webdesign; Band: 2011; Seite(n): 44–48; Verlag: Heise Zeitschriften Verlag; Adresse: Hannover; 2011; Quellengüte: 5 (Artikel)
2. Kowarschick (MMProg): Wolfgang Kowarschick; Vorlesung „Multimedia-Programmierung“; Hochschule: Hochschule Augsburg; Adresse: Augsburg; Web-Link; 2018; Quellengüte: 3 (Vorlesung)
3. Musterlösung MiniPong 01 (SVN)
4. Musterlösung MiniPong 01a (SVN)