<
>
swopdoc logo
Download
a) trade for free
b) buy for 2.39 $
Document category

Specialised paper
Information Technology / Computer S

University, School

Köln, Realschule

Grade, Teacher, Year

3, Prof. lang, 2013

Author / Copyright
Text by Glenn G. ©
Format: PDF
Size: 0.07 Mb
Without copy protection
Rating [details]

Rating 4.5 of 5.0 (2)
User:
Super text und alles gut und ausführ­lich erklärt­. Keine rechtsch­reibfehl­er. Ich bin begeiste­rt und würde mich sehr um eine fortsetz­ung der reihe wünsche­n.

Live Chat
Chat Room
Networking:
0/1|0[-3]|1/1













More documents
JSP Inhalt 1 Hypertext Transfer Protocol 3 1.1 HTTP Allgemein. 3 1.2 POST / GET. 4 1.3 Error-Codes. 4 2 Sessions. 4 2.1 Allgemeines zu Sessions. 4 2.2 Sessions in JSP. 5 2.3 Wann wird eine Session beendet?. 5 3 JSP. 5 3.1 Syntax. 5 3.2 Aufbau. 6 3.2.1 Direktiven. 6 3.2.2 Skriptingelemente.­ 7 3.2.3 Action-Elemente.

GESCHRIEBEN VON:

N. G.


Spieleprogrammierung in java


Vorwort

“Warum Spieleprogrammierung?” Diese Frage ist einfach zu beantworten, wenn man selbst gerne

spielt und vielleicht auch schon ab und zu davon geträumt hat ein “eigenes” Spiel zu entwickeln: es

macht einfach großen Spaß! Aber wenn man sich etwas intensiver mit dem Thema auseinandersetzt,

dann wird man recht bald feststellen, daß sich zum Spaß auch schnell die Arbeit gesellt, denn Spiele

sind, auch wenn sie auf den ersten Blick oft einfach erscheinen, alles andere als einfach!

Genaugenommen sind Spiele kleine Simulationen einer realen Welt und verhalten sich als solche

nach einem klar definierten und abgegrenzten Logik- und Regelwerk.

Die Spieleprogrammierung ist daher fachlich betrachtet nicht uninteressant! Sie vereint in sich nicht

nur verschiedene Disziplinen wie Audio, Grafik, Animation und Logik sondern stellt den

Programmierer auch im Bereich Performance und Timing vor einige Herausforderungen.

Soll ein

Spiel dann auch noch netzwerkfähig und über das Internet in Echtzeit spielbar sein, muß man sich

mit dem Thema Synchronisation außeinandersetzen und dabei natürlich auf die Unzuverlässigkeit

des Internets Rücksicht nehmen.

Dieses ist nämlich, aufgrund ständiger unvorhersehbarer

Verzögerungen im Datentransfer, für eine flüssige Synchronisation nicht gerade optimal!

2. Grundlagen der Spieleprogrammierung in Java

“Kann man überhaupt Spiele in Java programmieren?” Das ist die wichtigste Frage, die man klären

muß, bevor man mit der Entwicklung eines Spiels in Java beginnt! Die Antwort dazu ist

“grundsätzlich ja, aber natürlich nicht alles”.

Java ist mittlerweile technisch weit fortgeschritten und obwohl es in manchen Bereichen noch etwas

hinter der Performance von C/C++ oder anderen Sprachen zurückliegt, wird es doch langsam mehr

und mehr eine ernste Alternative für die Spieleentwicklung.

Durch zahlreiche interne und externe

Bibliotheken und APIs kann man auch unter Java mittlerweile auf Hardwarebeschleunigung durch

OpenGL oder DirectX zurückgreifen und so performance-lastige Funktionen auf die

darunterliegende Hardware auslagern.

Es gibt außerdem Bibliotheken, die ein direktes Ansteuern

der Eingabegeräte über DirectInput unterstützen und so ein Event-System-unabhängiges Abfragen

von Eingabegeräten (wie z.B. Joysticks oder Gamepads) ermöglichen.

Es gibt zahlreiche Studien, die bewiesen haben, daß Java in der Ausführung von Programmcode im

Vergleich zu C/C++ langsamer ist.

Bei manchen Funktion benötigt Java etwa 130-150% der Zeit

um die gleichen Rechenoperationen durchzuführen, während es bei anderen sogar schneller ist und

nur etwa 90% der Rechenzeit benötigt. Im Durchschnitt kann man dann mit etwa 20-30% mehr

Rechenzeit im Vergleich zu C/C++ rechnen.

Diese Zahlen sind jedoch stark abhängig von der

verwendeten JVM Version und wurden mit jeder neuen Version von Java immer etwas besser.

Wenn man diese Entwicklung sieht und auch noch im Hinterkopf behält, daß bisher nur etwa 50%

der Optimierungsmöglichkeiten in den JVMs genutzt wurden, kann man davon ausgehen, daß Java

auch in Zukunft noch stark an Performance gewinnen wird.

Aber auch wenn Java um vielleicht 30% langsamer als C++ ist, reicht die Leistung immer noch aus,

um interessante Spiele zu erstellen, die auch aktuellen Erwartungen an die Qualität von Grafik und

Sound gerecht werden können.

Natürlich können keine Highend-Spiele erstellt werden, die durch

hardwarenahe Programmierung und hardwarespezifische Optimierung jedes bischen Performance

nutzen. Aber dafür ist Java auch nicht gedacht! Der Vorteil bei der Verwendung von Java ist ein

hohes Abstraktionsniveau durch Objektorientierung und die Verwendung funktionsreicher und

“intelligenter” APIs, um so eine erhöhte Produktivität und Wiederverwendbarkeit zu erziehlen.2.1. Java 2D

Java bietet mit Java2D ein mächtiges und flexibles Framework für die Darstellung von geräte- und

auflösungsunabhängiger 2D Grafik.

Es ist eine Erweiterung des Abstract Windowing Toolkits

(AWT) und stellt eine Sammlung von Klassen, für die Arbeit mit geometrischen Formen, Text und

Rasterbildern, zur Verfügung. Als Bestandteil der Java Foundation Classes (JFC) ist Java2D

automatisch in jeder aktuellen JVM vorhanden.

Zusammen mit Java Swing bietet Java2D alle Grundlagen für die Darstellung und Verarbeitung von

Grafik.

Eine Einführung zu Java Swing und Java2D befindet sich im Anhang.

Als generelle, vielseitige und mächtige API zur Darstellung von Grafik und GUI sind Java Swing

und Java2D natürlich nicht auf Spiele optimiert und deshalb weniger performant als andere

spezialisierte Bibliotheken.

Seit der Java Version 1.4 sind jedoch zahlreiche Grafikfunktionen von

Java Swing und Java2D hardwarebeschleunigt und somit gut für die Spieleprogrammierung

einsetzbar. Insbesondere das Zeichnen von Lienen und das Füllen von Rechtecken, sowie das

Zeichnen / Kopieren von Bildern sind optimiert. 1-Bit Transparenz von Bildern (also komplett

durchsichtige Bereiche) ist ebenfalls hardwarebeschleunigt, während teilweise Transparenz rein

softwarebasiert berechnet wird.

In Java Version 1.5 soll die Hardwarebeschleunigung noch weiter ausgebaut werden.

Da es aber zu

Beginn unserer Arbeit noch keine (stabile) Version von Java 1.5 gab, können wir darüber auch noch

keine Angaben machen. Für unsere Arbeit haben wir Java 1.4.2_04 verwendet und alle Aussagen

sind daher auf dieser Version von Java basiert.

a) Aktives Rendern

Will man eine Anwendung schreiben, die den Bildschirminhalt häufig verändert und neuzeichnet,

dann wird man früher oder später zwangsläufig an die Grenzen des Event-Handling-Systems stoßen.

In AWT / Swing wird nämlich ein Neuzeichnen von Fenstern und Komponenten über die Methode

repaint() angefordert.

Diese Methode gibt dann die Anforderung in Form eines Repaint-Events an

den Main-Thread des GUI-Toolkits weiter. Dieser ist jedoch zuständig für das Zeichnen (Rendern)

aller GUI Komponenten und somit ziemlich beschäftigt. Wird nun ein repaint() in häufigen

Intervallen (z.B. 25 mal pro Sekunde) durchgeführt, dann führt das zu einer erhöhten Belastung des

Event-Systems und des Main-Threads.

Dies erzeugt nicht nur einen erhöhten Verwaltungsaufwand

für Events und so eine verzögerte Verarbeitung von Benutzereingaben wie z.B. Tastatur- und

Mouse-Events, sondern auch eine insgesamt langsamere Reaktion der gesamten GUI.

Um dies zu vermeiden, sollte das Neuzeichnen in einem eigenständigen Thread unter Umgehung

des Swing Repaint-Modells erfolgen.

Hierfür wird die entsprechende Methode paintComponent

(Graphics g) überschrieben und eine zusätzliche Methode renderScreen() erstellt, die dann in

regelmäßigen Abständen vom Render-Thread aufgerufen wird. Diese Methode ist nun für das

Rendern der Komponente zuständig und verwendet hierfür das Graphics-Objekt der Komponente.Der entsprechende Quellcode dazu könnte in ungefähr so aussehen:

import java.awt.*;

import javax.swing.JComponent;

public class MyComponent extends JComponent

{

private Image myImage;

// more code to write here .

public void paintComponent(Graphics g)

{

// do nothing here .

}

public void renderScreen()

{

// get Graphics object from component

Graphics g = getGraphics();

// perform rendering

g.drawImage(myImage,0,0,this);

g.drawLine(0,0,10,20);

// .

}

}

public class Renderer extends Thread

{

private MyComponent myComponent = new MyComponent();

// more code to write here .

public void run()

{

while(true)

{

// render component

myComponent.renderScreen();



// rest a bit and give time to other Threads

try

{

Thread.sleep(20L);

}

catch (InterruptedException ex) {}

}

}

}

Double Buffering

Führt man diesen Code aus, dann wird man feststellen, daß das Rendern zwar funktioniert, aber

Preview page 1 of 4 : [1] [2] [3] [4]
The site owner is not responsible for the content of this text provided by third parties

Legal info - Data privacy - Contact - Terms-Authors - Terms-Customers -
Swap+your+documents