Server/Client-Spiel durch reine Bildübertragung?

Kai008

Erfahrenes Mitglied
Würde es eigendlich performencemäßig gutgehen, wenn eine Serveranwendung nur Bilder überträgt, und der Client im Gegenzug alles Tastendrucks zurücksendet? Weil ich denke, dass das einiges an Programmier-Arbeit erspaaren würde.

Und wenn ja, hat eventuell jemand Links zu einer Anleitung wie man 1. Bilder über Socket senden könnte, 2. Bilder wieder empfangen könnte und 3. aus mehreren kleinen Bilder ein Gesamtbild erstellt? (So wie bei java.awt.Graphics/void paint())
 
Hm. Aber Java ist doch Open-Source, oder?
Das hieße doch eigendlich, dass ich die original class des BufferedImage in das Package einfügen und einfach das implements ändern könnte, oder?
 
Geht es um Echtzeit im Frames per Second - Bereich ? Dann kannst Du es schon von der Idee vergessen, Navigate&Klick kann funktionieren, macht aber nen Heidenwind auf der Datenautobahn..

mfg chmee
 
Hm. Aber Java ist doch Open-Source, oder?
Das hieße doch eigendlich, dass ich die original class des BufferedImage in das Package einfügen und einfach das implements ändern könnte, oder?

java.nio.ImageIO wenn ich mich beim package-Namen nicht irre. Auf jedenfall ImageIO... das hilft beim Serialisieren von Bildern in beliebige Formate (png, jpeg) und zurück weiter.
Zum Zusammensetzten eignet sich das BufferedImage, das bietet die Möglichkeit, sich mit getGraphics() ein Graphics(2D) Objekt zu holen, und damit auf dem BufferedImage zu zeichnen (und andere Images auf dieses Image zu zeichnen).
 
Weil ich denke, dass das einiges an Programmier-Arbeit erspaaren würde.

"Das glaube ich nicht Tim".

Ich weiß ja nicht so genau was Du programmieren willst, aber in den meisten Fällen ist es deutlich performanter (und auch einfacher zu programmieren) wenn der Client das Bild baut.

Du kannst immer noch nen schlanken Klienten programmieren, nur solltest du die Daten übertragen die dein Client-Programm interessieren und ihn dann das Bild bauen lassen.

Wenn du auf dem Klienten keine Bilder hinterlegen willst kannst du sie auch bevor sie das erste mal gebraucht werden vom Server laden.

Eh du dir überlegst wirklich eine Bilderorgie zu veranstalten, solltest du dir überlegen ob es ein Datenpicknik nicht auch tut.

MfG

Andibert
 
Hi,

wie Andibert schon sagte, wäre es von der Performance her besser wenn die Bilderstellung der Client übernimmt.

Abgesehen davon ist es natürlich möglich ein Image in ein ByteArray zu wandeln und dieses (mittels Sockets) über die Leitung zu schieben.

Java:
// format: "jpg" oder "png 
public static byte[] bufferedImageToByteArray(BufferedImage image, String format) throws IOException {
		ByteArrayOutputStream baos = new ByteArrayOutputStream();
		ImageIO.write(image, format, baos);
		return baos.toByteArray();
	}

Gruß
joschi
 
OK, danke.
Ich dachte, dass es schon alleine einfacher wäre, wenn z, B, dass Terrain eingebaut wird. So wie ich es machen wollte müsste es ja nur der Server die Objekte erzeugen, so beide. Außerdem müsste ich ständig hin- und herwechseln. Und ich dachte, dass ein komprimiertes Bild ungefähr dem selben Traffik frisst wie wenn man ständig die Tätigkeiten aller Mitspieler empfängt.
 
Der Server hat im Bestfall nur Listen mit den sich bewegenden Objekten und deren Aktionen. Die Clients übernehmen Darstellung, Aktionsauslösung und Verarbeitung der Daten, die vom Server kommen. Da denke ich doch, dass eine Zahlenkolonne (Objektdaten) sehr viel weniger ist als das ganze Bild, sicherlich um einen Faktor 100+

mfg chmee
 
Hm.
Ich habe das wie das mit dem Echtzeit funktioniert nie kapiert. Ich dachte immer, man sendet einfach ein KeyPressed/Released-Event an den Server. Aber bis der das mal empfängt vergeht doch Zeit, und bis er es auch an alle anderen Clients verteilt hat noch um einiges mehr, womit man doch immer weiter ist als es die anderen sehen.
 
Zurück