Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

1

28.07.2011, 08:31

spritesheet verwenden oder nicht?

Hallo leute.

Ich arbeite seit einiger zeit an einem 2D sidescroller (leider komm ich nur am we dazu).

das ganze lauft eigentlich gut, auch von der performance. ich habe ca 20 verschiedene tile-texturen, die ich alle lade
und in einer liste verwalte. Wenn ich dann z.b. einen neuen Block erstelle, dann holt sich der Block aus der Spritelist seine passende Textur.

Jetzt bin ich bei xnamag auf den begriff Spritesheet gekommen und hab mir das einmal angeschaut.
Von der überlegung her ist es ja "besser" als alle sprites einzeln zu verwalten.
Und es soll schneller von der graka verarbeitbar sein.

Allerdings sollte man, soweit ich weiß, keine features implementieren die man nicht braucht und ich frage mich daher ob ich ein Spritesheet verwenden soll,
obwohl ich keinen performance gewinn sehe. jetzt noch.

lg

TrommlBomml

Community-Fossil

Beiträge: 2 117

Wohnort: Berlin

Beruf: Software-Entwickler

  • Private Nachricht senden

2

28.07.2011, 09:04

aber natürlich bringt ein spritesheet performancevorteile, denn du musst wesentlich weniger texturen austauschen - das mag die grafikkarte nicht. vllt macht sich das auf deiner kiste nicht bemerkbar - aber wenn jemand nur einen intelchip hat und du 3 layer tiles mit 30 x 20 tiles zeichenst, was im worst case 1800 tiles sind und 1800 texturwechsel bedeuten - macht sich das bei einem einzigen texturwechsel am anfang deutlich bemerkbar ;)

Lares

1x Contest-Sieger

  • Private Nachricht senden

3

28.07.2011, 09:10

Ich persönlich würde das an deiner Stelle machen, da du dadurch nicht nur Performance, sondern vor allem Überblick über deine zusätzlichen Dateien erhälst, da du ja dann weniger Daten hast.

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

4

28.07.2011, 09:28

Also beim Punkt "Übersicht" kann ich nicht zustimmen. Tausend Tiles in einem File *sind* unübersichtlicher als je 10 in 100 Files. Aber es sollte ja auch kein Problem sein die Files zur Laufzeit zu einer einzigen Map zusammenzupappen.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

5

28.07.2011, 09:39

ok... zur performance sollte ich noch sagen, dass mein laptop mit dem ich das programmiere ca 4 jahre alt ist. also nicht gerade schnell.
Und zur übersichtlichkeit: naja. ich habs jetzt mit einem dictionary gelöst und wenn ich einen block erstelle hol ich mir mit dem key(string) die richtige
textur. Da kommt mir ein Spritesheet wesentlich komplizierter vor, aber das liegt möglicherweise daran, dass es für mich neu ist und ich noch nie eines verwendet hab...

Aber da man ja was lernen will, werd ich mir die sache mal genauer anschauen und dann auch einbauen. Schaden kanns sicher nicht und gleichzeitig lern ich was.

danke für eure antworten.

edit: noch eine ganz andere frage. Wenn ich listen verwende, und ich häufig die gesammte liste durchlaufen muss und alle objekte anschaue (klassen),
welche struktur ist da am schnellsten. und macht es überhaupt sinn so viel "herum-zu-performancieren", wenn ich es eigentlich nicht brauche?


lg

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

6

28.07.2011, 10:16

Ein Lookup ist eh langsam, egal ob der Map oder Liste oder Array, die Idee ist schlecht. Mach eine statische Zuordnung per Attribut. Ein Block hat ein Sprite und dieses Sprite kennt seine Textur direkt, denn es liegt ja darin. Und dann ist es egal, was für eine Textur das ist, ob eine kleine oder eine riesiges Spritesheet. Beides ist eine Textur.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

7

28.07.2011, 12:20

naja. also soll das ganze also "hardcoded" sein. und wenn ich jetzt einen block mit grüner textur hab und einen mit roter, dann brauch ich zwei verschiedene klassen für 2 verschiedene blöcke.

zur zeit kann ich ja, da jedes tile gleich groß ist, einen block mit einer beliebigen (in meiner liste befindlichen) textur erstellen und hab quasi nur einen block der alle blöcke sein kann.

hab ich dich richtig verstanden? und hast du mich richtig verstanden?

lg

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

8

28.07.2011, 13:10

Äh, nein, du hast mich falsch verstanden. Ein Attribut ist keine Konstante:

C-/C++-Quelltext

1
2
3
4
class Sprite {
private:
   Texture tex; // oder Pointer oder Referenz oder was auch immer
}


Darauf kann das Sprite direkt zugreifen, ohne irgendein Lookup.
Von hardcoden hat keiner was gesagt. Aber Listen, Maps oder sonstiges sind so total überflüssige Rechenzeitverschwendung.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Schorsch

Supermoderator

Beiträge: 5 145

Wohnort: Wickede

Beruf: Softwareentwickler

  • Private Nachricht senden

9

28.07.2011, 13:44

Wie BlueCobold schon sagt speicherst du einfach die Textur in deiner Klasse. Kannst du ja im Konstruktor übergeben oder machst eine Set-Funktion dafür. Mit Spritesheets wäre es nicht wirklich komplizierter. Alle Tiles sind in einer Textur. Der Draw Funktion von XNA kann man nun ein Source-Rect mitgeben. Quasi ein Rechteck, was auf den Ausschnitt der Textur zeigt, der gezeichnet werden soll. Jetzt speichert deine Tile Klasse also nicht einfach nur die Textur(Spritesheet), sondern zusätzlich noch ein Rectangle für die Position der Tiletextur im Spritesheet. Hoffe ich habe mich verständlich ausgedrückt.
Du kannst dir am Anfang natürlich eine Map machen, in der alle Rectangles einen Key zugeordnet kriegen. Dann kannst du wenn du ein neues Tileobjekt erstellst einfach das passende Rectangle aus der Map holen. Kann man aber auch anders lösen.
„Es ist doch so. Zwei und zwei macht irgendwas, und vier und vier macht irgendwas. Leider nicht dasselbe, dann wär's leicht.
Das ist aber auch schon höhere Mathematik.“

10

28.07.2011, 15:24

ok gut. ich hab mich offenbar nicht klar ausgedrückt.

aber ich werd mir spritesheets mal anschaun.

danke

Werbeanzeige