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!

Das neue SDK / IndexBuffer

Werbeanzeige

Anonymous

unregistriert

1

07.05.2005, 13:17

Das neue SDK / IndexBuffer

Hi!

Ich hab gestern das neue SDK runtergeladen und gleich mal getestet. Bei meinen Mini-Progrämmchen kann ich keine Unterschiede feststellen, bis auf einen: Anscheinend bei hat bei den IndexBuffern etwas verändert, nämlich die Typ"toleranz". In der Vorversion (Summer 2004) funktionierte das hier wunderbar:

C#: (In C++ sieht die Instantiierung ja fast genauso aus)
gIndexBuffer = new IndexBuffer(
typeof(int),
TOTALINDICES,
gD3DDevice,
Usage.None,
Pool.Managed
);

wobei int in C# normalerweise 32Bit lang ist.
Mit der neuen Version (April 2005) knallt diese Definition, wenn man den IndexBuffer an die Indices des Devices zuweisen will:

gD3dDevice = gIndexBuffer;

Das tat es früher nicht.

Ich hab gestern rumgespielt und wenn man es statt dessen mit etwas 16bittigen wie z.B. ushort versucht, geht es:

gIndexBuffer = new IndexBuffer(
typeof(ushort),
TOTALINDICES,
gD3DDevice,
Usage.None,
Pool.Managed
);
gD3dDevice = gIndexBuffer;

Habt Ihr ähnliches festgestellt?

Ich halte es erstmal für einen Bug im SDK, denn es kann ja schon mal sein, daß man mehr 64.000 Indices ansprechen muss und dann reichen 16bit nicht.


Ciao,
Wolfram

Osram

Alter Hase

Beiträge: 889

Wohnort: Weissenthurm

Beruf: SW Entwickler

  • Private Nachricht senden

2

07.05.2005, 15:48

32bit Indicees machen das Rendern ca 20% langsamer! Daher würde ich Sie sowieso nicht verwenden.
"Games are algorithmic entertainment."

Anonymous

unregistriert

3

08.05.2005, 11:43

Ah... gut, das zu wissen.

Aber was machst Du, wenn Du mehr als 2^16 Vertices hast (oder ist die Frage zu akademisch, weil ich in echten Leben nicht vorkommt?). Man kann den Stream umschalten und einen anderen Bereich des IndexBuffers verwenden z.B.
Was kann man noch machen?

Osram

Alter Hase

Beiträge: 889

Wohnort: Weissenthurm

Beruf: SW Entwickler

  • Private Nachricht senden

4

08.05.2005, 13:42

DrawIndexedPrimitve hat einen BaseVertexIndex Parameter. Jedes Subobjekt merkt sich, wo es anfängt. Mit Objekt meine ich z.B. ein Flugzeug (oder Cockpit, Auto, Baum, gebäude etc). Mit Subobjekt meine ich z.B. die rechte Flügelspitze. Ich kenne momentan keinen Flusi, bei dem die ausgelieferten Modelle mehr als 65 k Vertices (oder Polys) haben. Bei der MSFS/CFS Reihe kann der Benutzer ja selber 3D Modelle machen. Hier gibt es einen Trend welche zu machen, die sehr gut in Screenies aussehen, aber die man entweder nur alleine (ohne Flügelmann) auf einem High End Rechner bei guter fps spielen kann oder sogar gar nicht. Hier geht die Zahl bis ca 150 k.

Bei uns (BoB 2) besteht ein Flugzeug typischerweise aus grob 100 Subobjekten. Dies ist wegen "damage model" (z.B. Flügelspitze, die man verlieren kann) und wegen Animation nötig (z.B. Querruder). Ausserdem verlangen intern verschiedene Materialien (z.B. Glas, Metal) nach verschiedenen SubObjekten. Ich weiss ehrlich gesagt keine genauen Zahlen vom MSFS/CFS, aber wenn wir auch einfach von 100 ausgehen, ist also selbst bei den unoptimierten Freeware Hammer Flugzeugen die durchschnittliche Poly-zahl bei ca 1.5 k. Sollte wirklich mal ein einzelnes über 64 k sein, kann man es immer noch unterteilen.
"Games are algorithmic entertainment."

Werbeanzeige