spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »Sacaldur«

@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.

Ja das sie den gleichen Teil des Bildschirms einnehmen ist ja auch beabsichtigt. Davon ausgehend, dass der Faktor Höhe:Breite auf den Devices in etwa gleich ist, verzerrt sich das ganze auch nicht und man muss "nur" schauen, dass die Schriftgröße angepasst wird. Je nach "Engine" etc. ist das dann leichter oder schwerer.

Das ist sicher nicht die beste Lösung, aber für mich funktioniert das zufriedenstellend - ist nicht schwer zu implementieren - und von der Qualität ist das BISHER auch ok.

32MB pro App? Das sind nur 4 Bilder in Full HD und das wär's. Ernsthaft?

Jo ernsthaft. Du kanst mehr Speicher in deinem Manifest XML anfordern. Aber die Google Enwickler sagen halt das man das nur machen soll wen es wirklich nötig ist. Weil dan dem OS und den anderen im Hintergrund laufenden Apps unter Umständen Ram enzogen wird.

Wie soll man denn da bitte vernünftig eine App für HD entwickeln, wenn schon allein die Hintergrund-Grafik mehr Speicher benötigt? Das ist doch sehr bescheiden.

Eine Möglickeit sind sicher Vektorgrafiken. Es gibt sicher Möglichkeiten.

Aber Vektorgrafiken jeden Frame neu zu rendern ist sicherlich auch nicht gerade toll für ein Mobilgerät. Wäre mir auch neu, dass das eine gängige Methode im Mobile-Bereich ist. Nee, jetzt mal ernsthaft, wie soll eine App da genug Speicher haben? Werden Texturen auf der GPU automatisch komprimiert oder ähnliches?
4 Bilder Full HD, das wäre bei Rickety Racquet allein der Hintergrund, ohne den ganzen Rest wie Pflanzen, GUI, Fonts, etc, etc. Das ist ja erschreckend.

Man könnte doch Anhand der Bildschirmauflösung/diagonalen die texturen vektorisieren. dan packst sie in ein Bitmap object. Ich bin bis jetzt immer vom canvas als renderer ausgegangen.
Und wen du nicht Texturen doppelt in den Speicher lädst nur weil du sie 2x zeichnest und mit einem Texturatlas, kanste schon einiges rausholen.
Mit openGL werden die texturen komprimiert, soweit ich weiss.

Doppelt laden ist ohnehin dusselig, egal auf welchem System
Ein Bild erst vektorisieren, Deine Ideen werden meiner Meinung nach immer gruseliger für mobile Geräte

Du hast mich jetzt allerdings neugierig gemacht, ob Rickety Racquet jetzt schon Android sprengen würde. Muss ich mal auf dem Galaxy meiner Freundin austesten und einfach mal alle Ressourcen laden.

Nei ich meine nicht zuerst ein Bild vectorisieren. Sondern die Ressurce Date ist eine Vectorgrafik. Die Skalierst du dan hoch und packst sie dan auf eine Bitmap.Aber ich hab das nie ausprobiert, ist nur so ne idee. Aber die wirst sehen das man nicht sooooo gewaltig grosse Texturen benötigt auf den mobilen Geräten.Man muss halt bissel schauen wie man den Speicher verbraucht.

Btw, es sind 50 MB, die einer Android-App in Defaulteinstellungen zur Verfuegung stehen. Auf 4 GB "aufruestbar." Mal ganz abgesehen davon, dass man auch beim ersten Start noch aus firmenservern daten nachladen kann.
So wurde das vor einem Jahr auch bei Spielen gemacht, weil es da die 4 GB Aufruestungsmoeglichkeit noch nicht gab. Prinzipiell ist es aber eher schlecht, nach dem regulaeren Installieren nochmals Daten nachzuladen.
Mir passierte es etwa bereits, dass ich "noch schnell" vorm Weggehen eine App installierte (unter WIFI) und dann das Haus verlies. Als ich die App dann testen wollte, haette ich erst noch 200 mb nachladen muessen (Texturen, Models, maps, ..). Das war nicht schoen.

PS: spitzohr, bitte achte ein bisschen mehr auf deine Rechtschreibung, wenn es geht . Es ist oft schwierig, deine Texte nachzuvollziehen