JLI Spieleprogrammierung

[Leycarno]

Ich nutze immer noch D3D'X'... aber das ist nicht gemeint

Ich frage mich grade ob ich für jedes 2D-Objekt jeweils einen Sprite und eine zugehörige Texture anlegen muss, oder ob es reicht, nur einen Sprite zu nutzen, da ich vor/bei der Draw-Funktion sowieso die Texture und den zu blittenden Ausschnitt zuweisen muss...

Hat es Vorteile/Nachteile, nach der einen oder anderen Methode vorzugehen? Speicher würde ich wohl sparen, wenn ich statt x Sprites nur ein Sprite habe, doch vielleicht übersehe ich irgendetwas...

Kann auch sein, das die Antwort im Kapitel mit dem ResourcenManager steht, aber ich habe das Buch grade verliehen

[Maxim]

Auf jeden Fall ein Sprite für jede Textur (ein Sprite kann auch mehrere Texturen haben, bei Animationen zum Beispiel). Viel Speicher wirst du nicht sparen können, denn die Klasse selbst und ihre Methoden belegen kein Speicher, nur die Attribute und das sind ein paar Bytes. Texturen sollen sowiso durch einen TexturenManager verwaltet werden. Kannst ja ausrechnen wie viel Speicher du bei 1000 Sprites sparen kannst. Ich sags dir: "Nicht viel!" Heute, in zeiten von Gothic 3 (braucht 2Gb RAM) darf man sich, aus Zeitgründen, nicht mit sollchen Optimierungen nicht beschäftigen.

Sprite-Klassen sind extra dafür da, damit der Programmieren ein wenig Komfort hat und sich nicht ständig mit Texturen und sonem Kramm sich beschäftigen muss. Sprites liegen eine Ebene höher. In deiner Sprite-Klasse sind doch auch Koordinaten und evtl. andere Eigenschaften drin. Wo willst du sie sonst abspeichern?

Ein Tipp: Programmiere erst mal das, was du willst, zu Ende. Wenn es dann langsam läuft, kannst du immer noch optimieren. Ich kenne es selbst aus eingenen Erfahrung, dass man als Anfänger alles besser, schneller, optimaler machen will, aber am Ende hat man gar nichts.

[Fallen]

Wenn du ID3DXSprite meinst dann nutze davon nur ein einziges, für jedes Objekt/Textur würde das ziemlich viel Speicher beanspruchen.

Methoden beanspruchen sehr wohl Speicher Ich weiss aber nicht genau wie das interface von der Sprite klasse aufgebaut ist unter anderem hängt das davon ab. Wenn du aber nur ein einziges Sprite hast ist dies ziemlich egal.

Deine Objekte/Texturen können sich dieses Sprite dann teilen.

Texturen werden im Normalfall nur 1x geladen und dann nur über den Verweis auf diese verwendet.

Um Geschwindigkeit zu gewinnen kannst du dann vor dem Rendern deine Objekte so ordnen das folgendes möglich ist:

[Jonathan_Klein]

jo, wenn du eh vorm rendern die Position neu setzen musst ( die meisten Sprites bewegen sich ja nicht) und alles andere eh gleich bleibt, solltest du nur ein D3DXSprite Objekt benutzen.
Ich habs übrigens irgendwann so gemacht, das ich eine Spriteklasse programmiert habe, die einen Zeiger auf ein D3DXSprite erwartet hat und damit gerendert hat.
In den Beispielen vom Buch ist es anders, aber da hat ein Sprite auf eine Move Funktion. Sowas mach ich niemals, ich habe Objekte die Move Funktionen haben und um sich zu rendern ein Sprite besitzen. Sprite ist für mich nur eine Textur die ich irgendwo anzeigen kann, mehr net.
Es wird quasi Spiellogik und Anzeigelogik voneinander getrennt, nützlich wenn man eins von beiden stark verändern muss.
_________________
https://jonathank.de/games/

[Leycarno]

Erst mal: Dank euch für die Anregungen.


Das Beispiel aus dem Buch (Spite-Manager) habe ich bisher nicht genutzt, da ich vorher nie mit maps gearbeitet gabe... jetzt wo ich sie endlich benutze überlege ich, was ich an Mehrarbeit sparen kann...

In meiner 'spriteKlasse' habe ich nun eine Map mit der Strukur der SpielObjekten (Position, Skalierung, Rotation, Texture-Key, bool Activ) und eine weitere Map mit den Texturen und dem Texture-Key. Hinzu kommt EIN D3DXSprite.
In der Draw-Methode wird die StrukturMap der SpielObjekte auf den "ActivKey" getestet und alle aktiven werden dann mittels der Attribute und des TextureKeys in die Sprite 'geladen' und dargestellt.

Ich überlege noch, ob ich die speziellen Methoden, die zur Manipulation der Objekte dienen (Move, MoveCrazyToThePlayer, MoveWithKey, CollisionTest usw. :mrgreen) in eine andere Klasse auslagere (und Zeiger übergebe) oder alles in diese eine Klasse haue, oder doch Vererbung betreibe, da es ja Spezialisierungen sind...
Um so mehr man C++ lernt um so mehr Möglichkeiten gibt es und während ich meinen aktuellen Aufbau hier beschreibe merke ich das ich es schon wieder zu kompliziert mache und ein paar Sachen lieber nochmal übedenken sollte...

Ich meld mich wieder, wenn ich feststecke