spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

also als ich 2d mit Sprites programmiert habe, habe ich mir die aktuelle Auflösung geholt und dann prozentual auf die gewünschte Größe gestretcht.

Also als Beispiel

Deine Monstergrafik hat dann immer Höhe 5% von der Screenresolution.height und Breite 3% von der Screenresolution.width
So mache ich das auch aktuell für meine GUI damit die auf allen Geräten gleich aussieht.
Je nach dem wie gestretcht wird intern, hat man da auch kaum Verluste durchs Interpolieren etc.

Üblicherweise erstellst du deine Grafik in einer sehr hohen Auflösung und exportierst dann diverse Grössen. Ich weiss jetzt nicht wie das WP erledigt, aber bei Android/iOS kannst du die verschiedenen Grafiken in den richtigen Unterordner legen und dann werden die jeweils passende Grösse genommen (Android: xhdpi, mdpi etc, iOS @2x).
Dynamisch rauf/runterskalieren ist meist nicht eine so gute Idee.

Ein Spiel für verschiedene Auflösungen zu optimieren ist nicht unbedingt das Leichteste, wenn es auch nicht zu schwer ist. Wie man genau vorgeht, hängt vom jeweiligen Spiel ab. Man könnte dafür sorgen, dass immer genau der gleiche Ausschnitt zu sehen ist, wobei man dann eine feste Breite, eine feste Höhe oder eine feste Diagonale hat. Welches davon am Geeignetsten ist, hängt vom Spiel ab.
Sollte der Spieler im Wesentlichen auf 1 Achse bewegen (hoch/runter oder links/rechts), dann wäre das ein Zeichen dafür, dass die Breite oder Höhe des Spielfelds immer konstant bleiben sollte. Das hat zur Folge, dass der Spieler an den nciht genutzten Seiten einen gewissen Abstand hat, den man auch mit Grafiken füllen sollte. Beispiele für solche Spiele sind Jetpack Joyride, Doodle Jump usw.
Sollte dies nicht der Fall sein, dann wäre eine feste Diagonale eine Überlegung wert. Der Unterschied zur festen Breite/Höhe ist, dass die skalierung des Inhalts nicht von der Höhe _oder_ der Breite abhängt, sondern von beiden Werten, wodurch man insgesamt die gleiche Menge der Umgebung sieht (daher geeignet für 2D-Spiele, bei denen beide Achsen gleichwertig sind oder grundsätzlich für 3D-Spiele). Man könnte auch eine Kombination aus Diagonal und Breite oder Höhe wählen, sodass man sich auf eine Linie bezieht, die von der Mitte der oberen Hälfte der einen Seite zur Mitte der unteren Hälfte der anderen Seite verläuft. Das hätte beispielsweise zur Folge, dass die Gewichtung der Horizontalen höher ist.

Weiterhin gäbe es die Möglichkeit, das Spiel für eine bestimmte Auflösung zu schreiben und bei anderen Auflösungen gar keine Skalierung anzuwenden, allerdings wäre das nicht gerade empfehlenswert, da so der sichtbare Inhalt zu klein werden oder dir Übersicht verloren gehen könnte.

Oder man könnte für die Elemente eine feste Breite und Höhe in einer Einheit wie cm vorsehen. Dafür muss man lediglich die Bildschirmgröße in die Berechnung einfließen lassen. Dies ist meiner Meinung nach die Beste Lösung für die meisten Apps, allerdings kann es sein, dass diese für Spiele eher ungeeignet ist, wobei es da auf das Spiel ankommt.


@imakemygame:
Ich glaube nicht, dass eine prozentuale Breite und Höhe für die grafischen Elemente grundsätzlich gut ist bzw. würde dies nicht empfehlen. Man sorgt so nämlich _nicht_ dafür, dass die Elemente auf allen Geräten gleich groß sind, sondern nur, dass sie den gleichen Teil des Bildschirms einnehmen. Bie etwas komplexeren GUIs kann es so beispielsweise passieren, dass Texte zu lang für ihre Elemente sind.

Ich wüsste nicht, warum eine Skalierung so grundverkehrt sein sollte. Bei einem solchen Spiel wäre es wichtig, ständig die gesamte Umgebung im Überblick zu bewahren. Aber dennoch könnte man dort eine Skalierung anwenden. Wenn der Faktor, um den skaliert werden muss, eine ganze Zahl ist (wird in Jamestown beispielsweise als "pixel perfet scaling" bezeichnet), dann hat man auch keine Darstellungsprobleme bei der Skalierung. Ansonsten könnte man die Szene erst zeichnen und dann skalieren, wobei die Ungenauigkeiten, je nach Filterung, minimal bleiben könnten.
Den entstehenden Rand könnte man dann mit einem Rahmen oder ähnlichem überdecken, sollte man ihn nicht einfach schwarz lassen wollen. In diesem Spiel könnte man beispielsweise oben ggf. mehr Schwarz und unten mehr Blöcke darstellen, sollte es erforderlich sein. (Problematisch wird es nur, wenn man rechts und links etwas zum Spiel passendes darstellen will, da in diesem Fall der Spieler von der einen auf die andere Seite kommt...)

Man sollte auch beachten, dass eine Skalierung nicht zwingend ein Verzerren des Bilds (Strecken oder Stauchen) zur Folge haben muss.

Ich finde Skalierung bei 2D-Spielen immer Mist. Es sieht eben meist bei Sprites nicht schön aus. Bei Faktoren von 10-50% der Originalgröße geht's mit dem richtigen Filter ja noch. Aber wenn es sich um eher 60-90% handelt, sieht es total dämlich aus. (Sprich: Von 1000 Pixeln Breite auf 850 runter skalieren sieht blöd aus)

Das Problem auf das ich gestossen bin bei der Android Programierung ist das folgende:
Wen man grosse Texturen skaliert dan werden sie kurzeitig in den Speicher geladen.
Dies kan bei grossen Texturen problematisch werde z.b für Background Texturen.
Man müssten sich also immer ein Teil des Ram's freihalten für die Skalierung was denke ich nicht immer so einfach ist, da die Ram Kapazität für eine App beschränkt ist.
Was auch zu beachten ist das der Speicher für die Ausgangstextur auf jeden Fall wieder freigegeben wird.
(auf android wäre das die Methode Bitmap.recycle(); )
Ausserdem braucht dein View länger bis er geladen hat(wobei der Unterschied nicht so gravierend sein sollte)wen man die Bitmaps scaliert als wen man verscheidene die Textur in verschiedenen Auflösungen im Resurcen Ordner liegen hat.

Mein Fazit ist folgendes :
Grosse Texturen (Backgrounds z.b) in seperaten Auflösung bereitstellen so das der Speicher geschohnt ist und die Skalierung nicht extrem wird(Von ganz gross auf klein sieht unter Umständen zimlich schlecht aus und umgekehrt genau so)
Bei kleinen Texturen würde ich die Skalierung empfelen. Ich denke das dies bei anderen mobilen Systemen(Mac OS,Windows ) nicht gross anders sein wird.Wobei ich es nicht selber getestet habe.

Ich hoffe ich konnte helfen.

Grüsse Spitzohr

Hmm, die Aussage finde ich irgendwie merkwürdig.
Wenn ich ein Bild 4000x2000 Pixel lade und es runter skaliere, dann ist das ja nicht die einzige Textur, die man so hat. Im Gesamtspeicherverbrauch ist das ja eher nur ein kleiner Teil dessen, was man eh am Ende alles im Ram hat. Kann mir nur schwer vorstellen, dass das praktisch relevant ist.
Wie groß waren denn die Bilder vorher und hinterher, dass diese Skalierung Probleme mit freiem Ram hervorgerufen hat?

Zitat

Wenn ich ein Bild 4000x2000 Pixel lade und es runter skaliere, dann ist
das ja nicht die einzige Textur, die man so hat. Im
Gesamtspeicherverbrauch ist das ja eher nur ein kleiner Teil dessen, was
man eh am Ende alles im Ram hat. Kann mir nur schwer vorstellen, dass
das praktisch relevant ist.

Eben genau da liegt der Hund begraben. Soweit ich weiss hat man pro App 32Mb ram zur verfügung(Wen man mehr braucht muss man das extra im Manifest.xml deklarieren)
Gehen wir von der 4000X2000 pixel Textur für den Background aus. Dan haste noch mehere layers für den Background. Ausserdem der andere Speicher der deine App nocht benötigt.
Jede Textur die du skalierst wir beim Skaliervorgang doppelt im Ram liegen.Da der GC von Java ja nicht auf Befehl den Müll einsammelt liegen diese Texturen im Ram. Dies kan schnell zu einer OutOfMemory Exeption erhalten, da man nicht die totale Kontrolle über den GC hat. Es gibt sicher Möglichkeiten dieses Problem zu umgehen. Was ich z.b gemacht habe sind Texureatlasse zu generieren. Aber das funktioniert auch nur in einem gewissen Mass. Was ich auch mal versucht habe sind die grossen Texturen im Gimp zu teilen und dan nacheinander zu laden. Mit mässigem Erfolg.
Für jeden den es interesiert: hier ist ein link zu einer Interesannten Vorlesung eines Google Entwickler über Speicher Management http://www.youtube.com/watch?v=_CruQY55HOk