JLI Spieleprogrammierung

[GreveN]

Hi allerseits,
mein Problem in aller Kürze: Ich benötige eine Grafik-API, welche mir die Manipulation jedes einzelnen Pixels gestattet, welche später auf dem Screen erscheinen sollen und das sollte auch noch möglichst performant geschehen. Unter "performant" verstehe ich >100 FPS bei einer Auflösung von 640x480 Pixel und einer Farbtiefe von 16 Bit auf einem low-end-System wie dem Meinigen (P4 1,7GHz, 512MB RAM, Radeon 9200 mit 64MB). Diese Werte sollten aber eher als Richtlinie dienen, 8 Bit würden mir gegebenenfalls sogar reichen - vielleicht sogar der gute alte ModeX, aber ich glaube, das geht zuweit.

Als ersten Gedanken hatte ich natürlich DirectDraw, aber ich musste mit Schrecken feststellen, dass es recht lahm ist damit 640x480 Pixel einzeln zusetzen (ca. 50 FPS im Fullscreen), eigentlich auch logisch, da DirectDraw ja afaik nicht mehr direkt auf Graka-Unterstützung bauen kann.

Das heißt aber auch, das ich irgendeine Alternative finden müsste, ein Gedanke den ich noch hatte, wäre die Funktion 'glDrawPixels', welche OGL bietet, aber nach ersten Recherchen scheint diese Funktion auch sehr langsam zu sein.

Noch ein Gedanke war, irgendwie in jedem Frame eine Textur aus einem Datenblock zu erzeugen und einfach über ein bildschirmgroßes Quad zu rendern. Ich kann mir aber irgendwie nicht vorstellen, dass das sonderlich performant wäre, da die Textur ja bei einer Auflösung von 640x480 Pixeln immerhin 1024x1024 Pixel groß sein müsste und das Ding in jedem Frame über den Bus zu jagen... adieu ihr schönen FPS. Ich hatte in dem Zusammenhang noch den Gedanken eventuell "dynamische" Texturen zu verwenden, OGL bietet ja die Möglichkeit dynamische VBOs auf der Grafikkarte zu speichern, welche gelockt und verändert werden können, warum sollte so etwas also nicht auch mit Texturen gehen? Gibt es da etwas in der Art? Kennt da vielleicht jemand eine passende Extension, welche auch schon seit geraumer Zeit existiert, wegen meinen Ansprüchen an die Hardware?

Vielleicht reicht auch die GDI vollkommen aus?

Bietet D3D etwas Vergleichbares zu 'glDrawPixels'?

Hat jemand vielleicht noch 'ne komplett andere Idee, kennt irgendein tolles SDK oder dergleichen? Oder will mich unwissenden Naivling vielleicht aus dem Irrglauben erlösen, dass es mit DD doch noch irgendwie schneller geht?

P.S.: Plattformunabhängigkeit wäre ein nettes Feature, aber kein Must-have.

[Kovok]

schau dir mal das buch an, der Autor macht genau dies. Ansonsten mach es selbst. Directx 7 nehmen und alles was du brauchst ist direkten zugriff auf Pixelspeicher, alles andere machste von hand

[manu]

Vielleicht kann dir ja die SDL da alles bieten, was du brauchst. Ich kenne mich zwar nicht besonders gut mit der SDL aus, aber der direkte Zugriff auf Pixel ist so viel ich weiß schon möglich.

offizielle seite:
http://www.libsdl.org/tutorials.php

vllt. ist das ganz nützlich:
http://sol.gfxile.net/gp/ch04.html

[Jonathan_Klein]

dynamische Texturen werden nur ein wenig bringen. Fakt ist doch, das der Prozesor die Pixel berechnen soll, und die Graka die anzeigen sollen. Daher müssen auf jedne Fall alle auf die Garifkkarte kopiert werden.
Ich schätze aber mal, das es schneller gehen dürfte alle zusammen zu kopieren, statt jedne einzelnt.
_________________
https://jonathank.de/games/

[Dr. Best]

Du könntest mal ausprobieren dir in D3D per IDirect3DDevice::GetBackBuffer einen pointer auf das backbuffer surface zu holen und den dann zu locken. Ich weiß nicht ob das möglich ist aber wenn es geht dürfte es doch eigentlich halbwegs effizient sein .
Ansonsten fiele mir da auch noch die Funktion IDirect3DDevice8::CopyRects ein. Die dürfte zumindest effizienter sein als alles in eine überdimensionierte Textur zu speichern und die dann zu rendern.

Edit:
P.S. Die "realtime"-raytracing Fraktion in diesem Forum müsste doch eigentlich wissen wie das am effizientesten geht.

[Christian Rousselle]

Ich denke, dass deine D3D Texture-Idee schnell genug sein sollte.Texturegröße von 768x512 sollte reichen.

[GreveN]

Ah, schon soviele Antworten, das ist toll. 8)

[Dr. Best]

768 als Dimension einer Textur? Hört sich für mich nicht gut an. In der D3DCAPS9 Struktur findet man unter TextureCaps die Capability D3DPTEXTURECAPS_POW2 die festlegt ob eine Grafikkarte dazu in der Lage ist bei Texturen Dimensionen zu verwenden die keine Potenzen von 2 sind. Und afaik ist das bei den meisten Grafikkarten nicht möglich.
Oder stellt 768 eine Ausnahme da?

Keine Ahnung wie sich das bei OGL verhält.

[GreveN]

Das hatte mich auch etwas verwundert, das Problem ist, das ich von ziemlich antiquierter Zielhardware ausgehen muss, also nehme ich einfach mal an, dass es definitiv nicht unterstützt wird. ;) Bringt mich aber gerade auf die Idee, das man eventuell 2 kleinere Texturen verwenden könnte, um sich der gewünschten Auflösung anzunähern (z.B.: 512x512 und 512x256).

[AFE-GmdG]

768 als Dimension für die Textur würde ich auch als unsinnig Ansehen, aber was möglich und Sinnig wäre ist eventuell 2 Texturen zu verwenden, eine 512x512 und eine 128x512.
Diese Texturen Packst du am besten mit FVF_XYZRHW|FVF_TEXTURED auf den Screen.
Ich denke dass sollte mit DX9 kein Problem darstellen. Langsamer als andere Varianten sollte es nicht sein und du kannst hierbei sehr schön die Direct3DFunktionen zum Blenden, Rotieren und Skalieren nutzen (einfach passende Koordinaten für die Eckpunkte aussuchen ^^; )
Was du noch machen kannst, ist die Auflösung 512x384 zu nutzen, das ist zwar ein kleines bisschen kleiner als 640x480 aber passt auf eine 512x512 Textur.
_________________

[magynhard]

[Jonathan_Klein]

Ich habe zwar übewrhaupt keien Ahnung von OGL, aber sind Mipmaps nciht schwachsinnig?
_________________
https://jonathank.de/games/

[Kovok]

[GreveN]

Ich hab die "Hardcore"-Variante über eine Textur, die in jedem Frame verändert und auf die Karte geschoben wird mal ausgetestet, die Ergebnisse waren nicht überwältigend, ~60 FPS bei 512x512 Pixeln und 24 Bit. Hier einmal der Testsource, vielleicht hab ich auch nur einen grob fahrlässigen Fehler gemacht, kA:

[Dr. Best]

Eine Optimierung hätt ich für deinen Code. Wenn du die OpenGL Entsprechung zu D3DRS_ZENABLE auf false setzt müsstest du dir das Clearen eigentlich sparen können. Das dürfte eine merkliche Verbesserung mit sich bringen.