Spiel programmieren, Hintergrundbild

[Schüler1995]

Hallo,

ich programmiere gerade ein 2D-Spiel. Dafür hat jeder Level ein Hintergrundbild (1500 x 1500 px). Um das Bild darzustellen, schneide ich (in Anbhängigkeit der Koordinaten des Player) ein Stück dieses Bildes aus, kopiere es auf ein kleineres Bild (in Größe des Viewports) und stelle dieses dann da. Diese Aktion findet laufend im Run-Loop() statt (ca. 50 FpS).

Leider schwächelt die Performanz ein bisschen. Frge: Wäre es u.U. klüger, ich würde das Bild vorab (in Gimp z.b.) kacheln und dann nur die nötigen Kacheln (i.Abhängigkeit Player) darzustellen, also mir den Ausschneide- und Kopiervorgang zu ersparen? Ich hätte dann zwar mehr Bildresourcen...

Das ganz läuft unter JAVA.

Schüler1995

[Whouzuo]

Hallo,

ich programmiere gerade ein 2D-Spiel.

Womit?

Dafür hat jeder Level ein Hintergrundbild (1500 x 1500 px). Um das Bild darzustellen, schneide ich (in Anbhängigkeit der Koordinaten des Player) ein Stück dieses Bildes aus, kopiere es auf ein kleineres Bild (in Größe des Viewports) und stelle dieses dann da. Diese Aktion findet laufend im Run-Loop() statt (ca. 50 FpS).

Hört sich ungut an. Man kann das performant machen, aber einfach ist es nicht.

Leider schwächelt die Performanz ein bisschen.

Klüger wäre es wahrscheinlich, nur einen gewissen Teil der Grafik anzeigen zu lassen. Dafür müsste man aber wissen, womit du das Spiel überhaupt programmierst.

[Steel]

Moin!

Ähm. Den Satz

Das ganz läuft unter JAVA.

verstehst Du warum genau nicht? ;)

[Whouzuo]

Ähm. Den Satz

Das ganz läuft unter JAVA.
verstehst Du warum genau nicht? ;)

Kam gerade vom Workout... da spielt das Oberstübchen manchmal nicht ganz mit =/

[Schüler1995]

Hallo,

ich programmiere gerade ein 2D-Spiel.

Womit?

mit Java.

Leider schwächelt die Performanz ein bisschen.

Klüger wäre es wahrscheinlich, nur einen gewissen Teil der Grafik anzeigen zu lassen. Dafür müsste man aber wissen, womit du das Spiel überhaupt programmierst.

Na ja, ich zeige ja nur einen gewissen Teil der Grafik. Den muss ich allerdings ständig "ausschneiden" und auf eine neue Grafikinstanz "kopieren". Anders geht das mit Java meines Wissens nicht.

[Encoder]

ca. 50 FpS

viel zu viel.
25 sollte doch reichen. Oder sogar 15?

[Schüler1995]

ca. 50 FpS
viel zu viel.
25 sollte doch reichen. Oder sogar 15?

Warum? Ich möchte aber gerne 50 FPS, und das erreiche ich auch auf meiner schwachen Linux-Maschine. Mein Homerechner (Win7) würde sogar wesentlich mehr schaffen, aber das muss ich ja künstlich drosseln, sonst würde dort das Spiel ja schneller laufen.

[Encoder]

Ich möchte aber gerne 50 FPS

Das sieht aber niemand mehr so aufgelöst.

aber das muss ich ja künstlich drosseln, sonst würde dort das Spiel ja schneller laufen.

Du solltest da mit Timern arbeiten. Die Zeiten dass man am Rechner aus diesem Grund einen Knopf zum runterfahren der CPU Frequenz hatte sind schon lange vorbei ;-)

[Schüler1995]

Hik

aber das muss ich ja künstlich drosseln, sonst würde dort das Spiel ja schneller laufen.
Du solltest da mit Timern arbeiten. Die Zeiten dass man am Rechner aus diesem Grund einen Knopf zum runterfahren der CPU Frequenz hatte sind schon lange vorbei ;-)

he he, ich arbeite sogar mit Nanosekunden! Das meinte ich mit Drosseln. Ich drossel den run-Thread.

[Steel]

Ich möchte aber gerne 50 FPS
Das sieht aber niemand mehr so aufgelöst.

Nicht? Warum werden dann die ersten Filme jetzt schon mit 48 oder mehr FPS gedreht? (Der Hobbit, naechster Avatar)
http://www.heise.de/newsticker/meldung/Hobbit-mit-hoher-Bildrate-1559141.html
http://winfuture.de/news,69385.html
http://www.golem.de/news/kino-der-zukunft-der-hobbit-irritiert-mit-48-bildern-s-1204-91388.html

Ob das nun gut oder schlecht ist, muss jeder fuer sich selbst entscheiden. Ich plane jedenfalls mit die 3 Teile des Hobbits anzusehen. Nach dem ersten Teil weiss ich mehr.

Bei Spielen kommt noch was ganz anderes dazu:
Du kollidierst ohne davon was zu sehen. Du feuerst und der Gegner is schon gar nicht mehr da. ...

Wie schon in einer anderen Antwort erwaehnt: unter 30 fps heisst im Normalfall: unspielbar.

[niklaskamenisch]

hi,

ca. 50 FpS
viel zu viel.
25 sollte doch reichen. Oder sogar 15?

Das Auge kann ca. 25 Bilder wahr nehmen, bzw ab da sollte es ruckelfrei sein.
50-60Frames per Second sind aber in Spielen üblich.
Ab 40 FPS und kleiner, sieht man das ruckeln schon leicht!

Da du nicht angegeben hast, in was du programmierst, hier mal eine idee:
Nim das Bild und verschiebe es im Hintergrund einfach nur. Damit muss es nicht jedes mal neu ausgeschnitten werden.
So kann man das zumindest bei HTML wunderbar lösen! (mit JS)

Gruß Niklas

[Schüler1095]

hi,

ca. 50 FpS
viel zu viel.
25 sollte doch reichen. Oder sogar 15?
Das Auge kann ca. 25 Bilder wahr nehmen, bzw ab da sollte es ruckelfrei sein.
50-60Frames per Second sind aber in Spielen üblich.
Ab 40 FPS und kleiner, sieht man das ruckeln schon leicht!

Richtig, in Spielen sind 50 - 70 FPS üblich. Auch der Monitor stellt mehr als 50 Bilder pro Sekunde da. Die 25 Bilder beziehen sich -soweit ich weiß- nur darauf, dass man die Bewegung dann als vollkommen flüssig sieht. In Digitalfilmen sind es 25 Halbbilder, also eigentlich 50 Bilder. Beim Projektor sind es glaube ich ca. 25 Bilder, aber 50 Lichtblitze (Bildblitze, die durch das Öffnen des Objektivs zustande kommen). Habe ich zumindest mal so gelesen.

Da du nicht angegeben hast, in was du programmierst, hier mal eine idee:
Nim das Bild und verschiebe es im Hintergrund einfach nur. Damit muss es nicht jedes mal neu ausgeschnitten werden.

Java. Nein, das geht nicht. Das Hintergrundbild ist zu groß. Könnte auch bis zu 3000 auf 3000 px sein. ich probiere jetzt mal die Kachelmethode. Hurrah!

[Der Martin]

Hallo,

Die 25 Bilder beziehen sich -soweit ich weiß- nur darauf, dass man die Bewegung dann als vollkommen flüssig sieht.

genau, und das ist ein Wert, der sich in der Evolution von Kino und Fernsehen bewährt hat. Dabei erscheinen Bewegungen zwar flüssig, aber das Bild flimmert noch wahrnehmbar.

In Digitalfilmen sind es 25 Halbbilder, also eigentlich 50 Bilder.

Andersrum: 25 Vollbilder, die aber genau wie früher beim analogen Fernsehen als 50 Halbbilder mit jeweils halber Vertikalauflösung dargereicht werden. Alternativ auch 30 Vollbilder je Sekunde, in Anlehnung an den NTSC-Standard.
HDTV bietet AFAIK auch 50 Vollbilder je Sekunde.

Beim Projektor sind es glaube ich ca. 25 Bilder, aber 50 Lichtblitze (Bildblitze, die durch das Öffnen des Objektivs zustande kommen). Habe ich zumindest mal so gelesen.

Das ist mir neu. Vorstellbar, aber ich hab davon noch nie gehört. Es sei denn, du meinst moderne Projektoren, die mit einem Fernsehsignal gespeist werden. Die werfen natürlich auch 50 Halbbilder an die Wand.

Ciao,
 Martin

[Schüler1095]

Hi Martin,

In Digitalfilmen sind es 25 Halbbilder, also eigentlich 50 Bilder.

Andersrum: 25 Vollbilder, die aber genau wie früher beim analogen Fernsehen als 50 Halbbilder mit jeweils halber Vertikalauflösung dargereicht werden. Alternativ auch 30 Vollbilder je Sekunde, in Anlehnung an den NTSC-Standard.
HDTV bietet AFAIK auch 50 Vollbilder je Sekunde.

ah, ok, das wusste ich nicht.

Beim Projektor sind es glaube ich ca. 25 Bilder, aber 50 Lichtblitze (Bildblitze, die durch das Öffnen des Objektivs zustande kommen). Habe ich zumindest mal so gelesen.

Das ist mir neu. Vorstellbar, aber ich hab davon noch nie gehört. Es sei denn, du meinst moderne Projektoren, die mit einem Fernsehsignal gespeist werden. Die werfen natürlich auch 50 Halbbilder an die Wand.

nein, ich meinte schon alte Projektoren. Aber ich bin da kein Experte, hab das mal in einem Buch über Spieleprogrammierung im Zusammenhang mit Framerates gelesen. Kann mich aber auch täuschen.

[niklaskamenisch]

hi,

Beim Projektor sind es glaube ich ca. 25 Bilder, aber 50 Lichtblitze (Bildblitze, die durch das Öffnen des Objektivs zustande kommen). Habe ich zumindest mal so gelesen.

Das ist mir neu. Vorstellbar, aber ich hab davon noch nie gehört. Es sei denn, du meinst moderne Projektoren, die mit einem Fernsehsignal gespeist werden. Die werfen natürlich auch 50 Halbbilder an die Wand.

nein, ich meinte schon alte Projektoren. Aber ich bin da kein Experte, hab das mal in einem Buch über Spieleprogrammierung im Zusammenhang mit Framerates gelesen. Kann mich aber auch täuschen.

Die alten Projektoren laufen mit 220V (heute 230V) Glühbirnen.
Diese sind dann mit 50Hz betrieben und werden somit 100mal pro Sekunde mit vollen 230 bzw -230V beglückt. Die kurze Abkühlpause reicht nicht aus, als dass man sie sehen könnte.

Selbst unser alter RöhrenTV hatte schon die 100Hz technik verbaut. 50Hz für TVs ist somit eigentlich schon wieder recht alt.
Man muss aber unterscheiden, zwischen Bilderneuerung (immer fester Wert) und aktuallisierung des Anzuzeigenden Bildes (FPS).

Gruß Niklas

[Der Martin]

Hallo,

Die alten Projektoren laufen mit 220V (heute 230V) Glühbirnen.

wieso taucht eigentlich immer noch häufig die Zahl 220 auf? Die Umstellung von 220 auf 230V war AFAIR irgendwann in den 70er Jahren, da müsste das 220V-Gen doch allmählich verschwunden sein?

Diese sind dann mit 50Hz betrieben und werden somit 100mal pro Sekunde mit vollen 230 bzw -230V beglückt. Die kurze Abkühlpause reicht nicht aus, als dass man sie sehen könnte.

Stimmt. Aber diese Projektoren haben/hatten auch noch eine Blende, die die Lichtquelle immer nur für einen kurzen Augenblick freigab (Stroboskop-Effekt). Sonst würde man ja den Filmtransport als andauernde vertikale Bewegung sehen. Ob diese Blende nun jedes Einzelbild nur einmal belichtet oder zweimal kurz hintereinander? Ich kann mir beides vorstellen.

Selbst unser alter RöhrenTV hatte schon die 100Hz technik verbaut. 50Hz für TVs ist somit eigentlich schon wieder recht alt.

Mein Röhrenfernseher, den ich vor knapp einem Jahr in den Ruhestand verabschiedet habe, hatte das nicht. Das war ein konventionelles 50Hz-Gerät. Baujahr 1997, wenn ich mich nicht irre.

Man muss aber unterscheiden, zwischen Bilderneuerung (immer fester Wert) und aktuallisierung des Anzuzeigenden Bildes (FPS).

Sieht merkwürdig aus, "aktualisieren" mit Doppel-l ...

Ciao,
 Martin

[Steel]

ca. 50 FpS
viel zu viel.
25 sollte doch reichen. Oder sogar 15?

Kommt schwer auf das Spiel an. Sicher braucht man fuer Solitaer keine 70 fps.
Bei 'normalen' Spielen faellt das eher unter 'unspielbar'. (unter 30 is fies)

[Der Martin]

Hallo,

ca. 50 FpS
viel zu viel.
25 sollte doch reichen. Oder sogar 15?
Kommt schwer auf das Spiel an. Sicher braucht man fuer Solitaer keine 70 fps.
Bei 'normalen' Spielen faellt das eher unter 'unspielbar'. (unter 30 is fies)

das ist alles eine Frage der Gewohnheiten - für mich fällt Solitaire, Mahjongg oder Texas Hold'em eher unter "normale Spiele" als Egoshooter und Baller-Orgien mit schneller Grafik. Diese Kategorie ist bei mir eher "Zum Zuschauen ganz lustig, aber sonst uninteressant".

So long,
 Martin

[Encoder]

Was bedeutet eigentlich ausschneiden in deinem Fall? Es geht doch nur darum, den Teil des Bilds an die richtige Stelle des Screens zu bringen. Musst du da wirklich den Umweg über ein separates Bild gehen?
Noch effizienter wärs natürlich wenn du nur den Teil es Bilds aktualisierst, der sich tatsächlich ändert. Also wenn die Spielfigur (ich nehm mal an es gibt eine) sich bewegt, muss ja nur der Teil ersetzt werden in dem sie sich bewegt hat.

Ich verstehe aber auch noch nicht so ganz, was du dann wann wie genau machst. Und woran du merkst dass die Performance hängt, denn du sagtest ja irgendwo, du musst das ganze noch bremsen.

Beschreib mal deine Vorgehensweise und die Probleme dabei etwas genauer, vielleicht kommt dann ein guter Tip.

[Schüler1095]

Hi,

nur kurz, muss ins Bett, Schule :)

Was bedeutet eigentlich ausschneiden in deinem Fall? Es geht doch nur darum, den Teil des Bilds an die richtige Stelle des Screens zu bringen. Musst du da wirklich den Umweg über ein separates Bild gehen?

Ich habe ein sehr großes Hintergrundbild. Das könnte auch 3000 x 3000 Pixel groß sein. Aus diesem Bild "schneide" ich einen Teil aus, je nachdem, wo sich der Spieler befindet. Das mache ich mit getSubimage(). Dieses Bild hat die Größe des Viewports. Simpel das Bild verschieben geht nicht. Bzw. geht schon, aber dann kommen Performanceschwierigkeiten (Framerate geht runter, mit allen unschönen Dingen, die dazugehören.)

Ich habe jetzt die Kachelmethode angewendet. Das ist unglaublich schnell. Und das obwohl ich immer noch alles rendere, und nicht nur das sichtbare (Kacheln, die sich innerhalb des Viewports befinden bzw. diesen in irgendeiner Art und Weise tangieren)

Ich verstehe aber auch noch nicht so ganz, was du dann wann wie genau machst. Und woran du merkst dass die Performance hängt, denn du sagtest ja irgendwo, du musst das ganze noch bremsen.

Bremsen: mein Linux-Laptop ist alt, der ist nicht schnell. Aber eine Framerate von 50 bringt er, wenn alles gut optimiert ist. Mein Windows-Rechner ist neu, auf dem geht das Spiel natürlich shcneller, was  ungünstig ist. Deshalb bremsen (run-thread). Soll dort natürlich auch nur 50 FPS haben und nicht plötzlich 100 oder so.

Also Kachelmethode passt!
danke nochmals