JLI Spieleprogrammierung

[Leviathan]

Hi!

Die, die das Buch haben und durchgelesen haben, werden sich wahrscheinlich an das Beispiel "Starfield 2" aus dem Kapitel 20 erinnern.
Dort werden Sterne simuliert, die von oben nach unten "vorbeifliegen".
Nun, das Beispiel ist mithilfe eines Surface programmiert worden, auf dem die einzelnen Pixel verändert (gemalt) werden, sodass der Eindruck entsteht als ob das Sterne wären.
Das ganze ist schön anzusehen, bloß ich habe schon mehrere Meinungen gehört (so stehts auch im Buch), dass diese Methode (Pixel auf dem Surface zu manipulieren) furchtbar langsam ist.
Meine Frage an auch: wie kann man das gleiche denn mithilfe von Vertizes (Polygonen) also richtig in 3D umsetzen? Man könnte ja 2 Polygone darstellen, die den gesamten Bildschirm einnehmen aber wie kriege ich die Sterne da drauf?
Ich möchte nicht unbedingt mit Texturen arbeiten sondern die "Sterne" selber im Programm erzeugen, bloß ohne des Surface...

Wie würdet ihr die Sache angehen?

mfg

[Fallen]

Das einfachste wäre wohl ein Vertexgebilde aus 2 Vertexen zu erstellen, Vertex1 bekommt zusätzlich die Farbe RGBA(255,255,255,255) und Vertex2 die Farbe RGB(0,0,0,0) nun kann man entweder D3DXLine nutzen um sich den Sterneneffekt zu holen oder man macht es ohne und nutzt die Draw Befehle der API.
_________________
"I have a Core2Quad at 3.2GHz, 4GB of RAM at 1066 and an Nvidia 8800 GTS 512 on Vista64 and this game runs like ass whereas everything else I own runs like melted butter over a smokin' hot 18 year old catholic schoolgirl's arse."

[Leviathan]

[Fallen]

DrawPrimitive oder solche Befehle, stehen in der Docu von DX drin.
_________________
"I have a Core2Quad at 3.2GHz, 4GB of RAM at 1066 and an Nvidia 8800 GTS 512 on Vista64 and this game runs like ass whereas everything else I own runs like melted butter over a smokin' hot 18 year old catholic schoolgirl's arse."

[Jonathan_Klein]

im prinzip wirst du immer die Pixel auf einen Obverfläche verändern müssen, du müsstest halt irgendwie ein Surface ekommen, das man schnell locken und schnell manipulkieren kann ( vieliehct sind Texturen ja schneller?). Das dann noch extra mit GDI zu machen, halte ich nicht für oo gut, weil man doch immer ein DC anlegen muss(oder?).
Und ich denke das bei einem kleinen Spiel und einem nicht ganz so aufwändigen Starfiled, es nicht soogroße Probleme geben sollte.
_________________
https://jonathank.de/games/

[Fallen]

[Patrick]

Wenn Du der Linearen Funktionsmathematik mächtig bist rechnest Du es aus was besser ist:

Im Durchschnitt ist das rendern von 150 Vertices schneller als das Locken und Unlocken der Surface, darüber wirds kritisch und ab 200 Punkte ist ein Lock auf der Backsurface schneller, aber hier kommt die Größe an.

Einfach mal ausrechnen
_________________
'Wer der Beste sein will muss nach Perfektion streben und jede Gelegenheit nutzen sich zu verbessern.' - KIA
[ German Game Dev | Boardsuche hilft sehr oft | Google rockt | Wie man Fragen richtig stellt | ICQ#: 143040199 ]

[HomeLess_PunkDrummer]

Kann mir nochmal jemand ganz langsam erklären warum das verf****** Locken/Unlocken einer Surface oder Textur so lahm ist, und wie genau es funktioniert.



Danke.
_________________
"Was die Götter angeht, so ist es mir unmöglich, zu wissen, ob sie existieren oder nicht, noch, was ihre Gestalt sei. Die Kräfte, die mich hindern, es zu wissen, sind zahlreich, und auch ist die Frage verworren und das menschliche Leben kurz."

[Jonathan_Klein]

hm, ich könnte mir vorstellen, das es daran leigt, das die surfaces im GraKa speicher sind, beim locken in den Hauptspeicher kopiert werden, dort verändert werden, und beim unlocken wieder zurückkopiert werden. Sowas gibts jedenfalls in der Art bei Texturen. Und da die dinger unkomprimiert sind, kann das wenn die Bildschirmgröße haben, halt schon etwas dauern
_________________
https://jonathank.de/games/

[Fallen]

Unter ein weilchen dauern versteht man immer was von Sekunden ;9

Bei den möglichen transferraten isses recht flott, aber die Masse der Locks/Unlocks bremst ganz schön.
_________________
"I have a Core2Quad at 3.2GHz, 4GB of RAM at 1066 and an Nvidia 8800 GTS 512 on Vista64 and this game runs like ass whereas everything else I own runs like melted butter over a smokin' hot 18 year old catholic schoolgirl's arse."

[HomeLess_PunkDrummer]

Ah ha, und das selbe gilt für Vertexbuffer?
_________________
"Was die Götter angeht, so ist es mir unmöglich, zu wissen, ob sie existieren oder nicht, noch, was ihre Gestalt sei. Die Kräfte, die mich hindern, es zu wissen, sind zahlreich, und auch ist die Frage verworren und das menschliche Leben kurz."

[Fallen]

Ich bin nicht sicher aber ich glaube die werden in einen besonders schnellen Speicherbereich angelegt. Beim locken werden die da in einen langsameren kopiert, in dem man aber schneller schreiben kann als in den anderen. oder so
_________________
"I have a Core2Quad at 3.2GHz, 4GB of RAM at 1066 and an Nvidia 8800 GTS 512 on Vista64 and this game runs like ass whereas everything else I own runs like melted butter over a smokin' hot 18 year old catholic schoolgirl's arse."

[GreveN]

Hab den Thread jetzt nur mal fix überflogen...
Ich hab mir mal überlegt, wie man am einfachsten nen Regen/Schnee/WatWeißIch-Effekt darstellen könnte. Eine Möglichkeit wäre evt. ein Quad zu nehmen, da ne Textur mit den Sternen/Tropfen/Flocken... drauf zupacken und in jedem neuen Frame die Texturen-Matrix vorm Rendern ein Stück weiter zu schieben.
Das Problem dürften hierbei nur die Füllraten der Grafikkarte sein, weil du ja doch ziemlich viel Leistung in dieser Hinsicht verschwendest...
Hängt halt ein bisschen davon ab, was du genau machen willst.

[Fallen]

Manche Spiele machen das so, in 3D hinsicht sogar schneller als es über partikel (für jeden tropfen einzeln,...) zu lösen
_________________
"I have a Core2Quad at 3.2GHz, 4GB of RAM at 1066 and an Nvidia 8800 GTS 512 on Vista64 and this game runs like ass whereas everything else I own runs like melted butter over a smokin' hot 18 year old catholic schoolgirl's arse."

[The Lord of Programming]

Ja, das lahme ist nicht unbedingt das Setzen der Pixel, sondern das (Un)locken. Und das liegt auch daran, dass das Surface so weit entfernt im Grafikspeicher liegt. Allerdings lohnt es sich bei vielen Locks/zu setzenden Pixeln, wenn du das Surface im AGP- oder sogar im Hauptspeicher anlegst. Dann fällt das Locken kaum mehr ins Gewicht und die Pixel können sehr schnell gesetzt werden. Dann ist das einzige Problem noch, dass du das so veränderte Surface aus dem Hauptspeicher wieder in den Backbuffer(im Videospeicher) bringen musst. Deshalb solltest du grundsätzlich mit wenigen Kopiervorgängen zwischen den verschiedenen Speichern auskommen.
_________________
www.visualgamesentertainment.net
Current projects: RDTDC(1), JLI-Vor-Projekt, Tetris(-Tutorial), JLI-Format
(1) Realtime Developer Testing and Debugging Console

Anschlag, Anleitung zum Atombombenbau, Sprengkörper...
Hilf Schäuble! Damit er auch was findet...