GrabSprite über Screenbereich / Sprites zusammenfügen

[kinghanno]

Hallo!

Momentan probiere ich mich an einem 2D-Jump'n'Run, bin jedoch auf Probleme gestoßen.

Das Spiel läuft in 640x480 Vollbildmodus.
Das Level wird zuerst aus 16x16-Tile-Sprites zusammengesetzt und anschließend als ein Sprite gegrabbt. Dadurch erhoffe ich mir eine bessere Performance, da fortan immer nur das einzelne Levelsprite angezeigt werden muss und ich keine For-Schleifen-Durchläufe für die Darstellungen einzelner Tiles mehr brauche. (Kollisionsprüfung ist auch einfacher.)
Es passen also 40x30 der Tiles auf eine Screenbreite, da ein Level aber etwas größer sein sollte, ließ ich quasi 80x30 Tiles darstellen. Laut Handbuch werden diese ja dargestellt, nur außerhalb des angezeigten Bereichs, also nicht angezeigt.

Wo wir beim ersten Problem wären: Möchte ich das ganze Level mit den Maßen 1280x480 grabben, also die 80x30 Tiles, wobei der Screen nur 640x480 misst, kommt es zu Fehlern im gegrabbten Sprite.
Warum ist das so und gibt es eine Möglichkeit, dies zu umgehen?

Eine Möglichkeit dazu hätte ich mir schon überlegt: Jeweils immer eine Screenbreite grabben, also mehrmals die 40x30 Tiles, und die einzelnen gegrabbten Sprites dann als eines zusammenfügen.
Doch hier weiß ich wiederum nicht, wie ich das (Zusammenfügen) bewerkstelligen soll. Habt ihr Vorschläge?
Das Zusammenfügen halte ich nämlich für nicht unwichtig, es erleichtert mir doch den Algorithmus zur Kollisionsprüfung, da es mit einem Sprite einfacher ist, als mit z.B. 10.

Alternativ könnte ich auch das Level von vornherein als ein einziges Bild erstellen und als Sprite laden. Das ist allerdings, ohne duften Leveleditor, den ich dann zu schreiben versuchen müsste, weniger komfortabel, als einfach die Data Section zu editieren. :)

Ich bin für jeden Tipp dankbar!

[Kaeru Gaman]

ein sprite sollte nicht größer sein als der screen selber.
andernfalls kann es auf manchen grafikkarten zu darstellungsfehlern kommen

außerhalb des screens grabben ist logischerweise unmöglich,
da dort keine bildinformation vorhanden ist, es ist einer position außerhalb
des screens selbstverständlich nicht einmal speicher zugewiesen, wozu auch.

die zeit die du für die schleifen sparst ist absolut minimal, ich seh das nicht als argument.

und das mit der kollisionsprüfung kann ich nicht nachvollziehen,
die sollte sowieso über koordinaten laufen.
dafür ist es unerheblich, aus wievielen sprites sich dein hintergrund zusammensetzt.


> Habt ihr Vorschläge?
natürlich könntest du ein leeres sprite von 1280x480 erzeugen,
und deinen level dort hinein darstellen.
aber wie ich bereits schrieb:
ein sprite sollte nicht größer sein als der screen selber.

[kinghanno]

ein sprite sollte nicht größer sein als der screen selber.
andernfalls kann es auf manchen grafikkarten zu darstellungsfehlern kommen

Selbst bei neueren Modellen?

außerhalb des screens grabben ist logischerweise unmöglich,
da dort keine bildinformation vorhanden ist, es ist einer position außerhalb
des screens selbstverständlich nicht einmal speicher zugewiesen, wozu auch.

Wozu? Ich persönlich würde es schon extrem praktisch finden, sowas machen zu können:


Quasi das Sprite mit der Spielwelt einfach hin- und herschieben als Scrolling, das würde mir gefallen.
Aber wenn es nicht empfehlenswert ist, werde ich wohl eine andere Methode wählen.

und das mit der kollisionsprüfung kann ich nicht nachvollziehen,
die sollte sowieso über koordinaten laufen.

War auch meine erste Idee, aber wenn ich ein Level darstelle mit transparentem Hintergrund (sagen wir einfach ich benutze verschiedene Schichten, Layer), ist eine Kollisionsprüfung wesentlich einfacher, da ich mit SpritePixelCollision einfach das gesamte Level-Sprite auswählen kann und fertig.

[Kaeru Gaman]

> da ich mit SpritePixelCollision einfach das gesamte Level-Sprite auswählen kann und fertig

und dann denkst du über die performance beim darstellen nach?

SpritePixelCollision ist DER performancekiller schlechthin!


> Wozu? Ich persönlich würde es schon extrem praktisch finden, sowas machen zu können:
das ist klar, und das habe ich auch verstanden.
ich meinte aber, das GRABBEN außerhalb des screens nicht möglich ist,
weil die information, die du vorher außerhalb der screens darstellst in keinem speicher landet.
übrigens:
im grunde ist es genau das, was eine TileEngine macht, dazu schreibt man eine.

> Selbst bei neueren Modellen?
weiß ichs?
ich fänd's aber schon etwas lächerlich, ein Minigame rauszubringen,
und bei den hardware anforderungen steht:
läuft ab 450MHz, aber braucht ne GForce FX7500


zu der kollision:
wenn du tiles der größe 16x16 hast, dann wirst du ja wahrscheinlich
leere, teilgefüllte und volle tiles haben.
wenn du jetzt einfach prüfst, ob sich der player über einem komplett gefüllten tile befindet,
also einem, mit dem er in jedem fall kollidieren muss,
dann hast du es auch einfach und bist wesentlich schneller
als SpritePixelCollision jemals sein kann....

wenn du unbedingt große scrollbereiche haben willst:
pack deinen level in sprites, die 320x480 groß sind, dann brauchst du immer nur 3 darzustellen.

jedes pixel, das dargestellt werden soll, kostet performance, auch wenn es außerhalb des screens liegt.
(zwar etwas weniger, als wenn es wirklich angezeigt wird, aber es braucht zeit)

wenn du deinen hintergrund ständig aus tiles zusammensetzt,
brauchst du nur 656x480 pixel darstellen,
nämlich immer eine spalte mehr als der screen breit ist.

wenn du einen level-sprite von z.b. 12800x480 erzeugst, brauchst du nicht nur 23,4375MB mehr Grafikkartenspeicher,
du zeigst auch in jedem frame 5.829.120 pixel an, die du nicht anzeigen müsstest,
weil sie außerhalb vom screen liegen.

[kinghanno]

Gut, kling alles plausibel. Hatte ja keine Ahnung, was ich mir da für Performanceeinbußen einhandle.
Danke für die Tipps! Werde mich wohl an 'ne neue Engine machen müssen. Seufz.