Dies ist ein generelles Problem. Wenn in Objekten die von Constants erben width und height als Objektvariablen genutzt werden sollen, ist die Größe der Zeichenleinwand nicht mehr direkt abrufbar.
Ggf. sollten die Variablen in Constants spezifischer benannt werden (z.B. `zmwidth` oder `canvaWidth`).
Sound spielt kurze Clips (z.B. Soundeffekte) ab.
Music für längere Hintergrundmusik.
MP3s werden nur über die Einbindung der externen Abhängigkeiten jlayer, tritonus-share und mp3spi ermöglicht.
Es können Tasks (Runnables) für die geplante Ausführung (z.B. in 100 ms) übergeben werden. Die Tasks werden dann jeweils am Ende eines Frames abgearbeitet. Bei Bedarf auch parallel mit dem TaskRunner.
Das System sollte noch einmal Refactored werden. (Und ggf. auch auf seine Sinnhaftigkeit geprüft werden.)
Eingaben der Swing Componente werden nun in eine interen EventQueue einsortiert, die einmal pro Frame abgearbeitet wird. Das verhindert Probleme bei der Synchronisierung der ZM mit dem EDT von Swing.
Im Moment werden die Originalen InputEvent gespeichert und verarbeitet. In Zukunft könnte eine eigene Event-Klasse sinnvoll sein, die die Events für die Nutzer vereinfacht (siehe Processing).
TaskRunner ist eine statische Klasse, die einen ThreadPool verwaltet und es anderen KLassen ermöglicht, Parallele Prozesse auszuführen. Die ZM ist grundsätzlich erstmal nicht auf Parallelität ausgelegt, da alle im „GameLoop“ (Zeichenmaschine$Zeichenthread) pro Frame synchron läuft. Einige Aufgaben erfordern aber eigene Therad (z.B. das Abspielen von Musikdateien oder zukünftige Animationen).
Der TaskRunner ist eine erste Verison einer Klasse, die zukünftig in der ZM an Bedeutung gewinnen könnte, wenn Parallelität wichtiger wird (z.B. in der Spielemaschine).
Die ZM kann nun beliebige Runnables mit einem Zeitdelay versehen ausführen. Mitteles `scheduleTask(Runnable, int)` wird das angegebene Runnable nach der angegebene Anzahl Millisekunden ausgeführt.
Tasks werden immer am Ende eines Frames ausgeführt.
Tastatur- und Mauseingaben werden nun nicht mehr direkt verarbeitet, sondern in eine interne EventQueue geschoben, die nach dem Aufruf von `draw()` abgearbeitet wird. Die `InputEvent`s werden momentan direkt an die üblichen Listener Methoden weitergegeben. Ggf. ist in Zukunft hier auch ein vereinfachtes Eventsystem (siehe Processing) sinnvoll.
Ist die ZM pausiert, werden Events ohne verzögerung direkt ausgelöst.
