Forum: PC-Programmierung [LabView/C/C++/2D-Grafik] Bilder mit Transparenz und Performance


von balsamico (Gast)


Lesenswert?

Hallo ihr,

in LabView entwickle ich zur Zeit ein Spiel als Leistungsnachweis eines 
Kurses. Ein Bild mit transparentem Hintergrund wird dabei über den 
Bildschirm bewegt. Weil LabView keinerlei Möglichkeiten Grafik 
hardwareseitig berechnen zu lassen bietet, ruckelt die Geschichte 
extrem, wenn ich anstelle eines einfarbigen Hintergrundes zu verwenden, 
die Grafik über Texturen hinweg bewegt wird.

Kennt sich jemand von euch aus mit sowas? Gibt es Bildformate, die 
vielleicht irgendwelche entsprechenden Optionen bieten, die effizienter 
sind als andere was die Performance beim Berechnen der Transparenz 
angeht? Oder ist es wahrscheinlich eher so, dass jede Grafik nach dem 
Einlesen auf die gleiche Art und Weise im RAM gespeichert wird und das 
Format und dessen Optionen keinen Unterschied machen?

Man kann ich LabView C/C++-Funktionbibliotheken einbinden (DLLs). C/C++ 
in Kombination mit einer 2D-Engine würde die nötige Leistung bieten, nur 
leider habe ich in diese Richtung nur ein kleines bisschen Erfahrung. 
Hat jemand von euch vielleicht eine Idee, wie ich auf diesem Weg 
vorgehen könnte und welche Grafikengine geeignet und vergleichsweise 
unkompliziert wäre? Was ich mir da vorstellen könnte wäre, dass einer 
C-Funktion von LabView die Koordninaten des Objektes auf dem 
Hintergrundbild übergeben werden und ein quadratisches Bild ohne 
Transparenz zurückgegeben wird - sprich: die in LabView eingebundene 
C/C++-DLL, in die wiederum die Enginge-Bibliothek eingebunden ist, die 
transparenten Bereiche des Objektes mit dem den Koordinaten entsprechden 
Teil des Hintergrundes ausfüllt. Hat jemand von euch Ahnung davon?

Falls euch sonst irgendetwas druch den Kopf geht dazu, bitte bitte her 
damit.

Danke schonmal!

von Max (Gast)


Lesenswert?

balsamico schrieb:
> Falls euch sonst irgendetwas druch den Kopf geht dazu, bitte bitte her
> damit.

Du hast ja gefragt ... "The right tool for the right job"
Ein Spiel in LabView als Leistungsnachweis? Hast Du Dir hoffentlich 
selbst ausgedacht das Thema, sonst müsste man am Verstand des 
Aufgabenstellers zweifeln ;-) SCNR

balsamico schrieb:
> Weil LabView keinerlei Möglichkeiten Grafik
> hardwareseitig berechnen zu lassen bietet, ruckelt die Geschichte
> extrem

Also ein bischen alpha-blending im Framebuffer schafft jede halbwegs 
aktuelle CPU spielend. Daran kann es kaum liegen. Vermutlich ist LabView 
für derartiges nicht konzipiert ("The right tool", Hust). Dann 
könntest Du noch versuchen, das selbst in einen Framebuffer zu rendern, 
notfalls in einer eigenen dll, wie du schon vorschlägst. Das ganze ist 
aber für den Außenstehenden noch sehr undurchsichtig, so dass Dir kaum 
jemand "Tiny2dEngineForLabview.dll" vorschlagen wird. Weiter wird das 
dann mehr ein C/C++ Projekt als ein LabView Projekt ("the right job").

balsamico schrieb:
> Oder ist es wahrscheinlich eher so, dass jede Grafik nach dem
> Einlesen auf die gleiche Art und Weise im RAM gespeichert wird und das
> Format und dessen Optionen keinen Unterschied machen?
Sehr wahrscheinlich. Eventuell gibt es verschiedene Buffer-Typen für 
verschiedene Anwendungen.

von Emil G. (balsamico)


Lesenswert?

Max schrieb:
> Du hast ja gefragt ... "The right tool for the right job"
> Ein Spiel in LabView als Leistungsnachweis? Hast Du Dir hoffentlich
> selbst ausgedacht das Thema, sonst müsste man am Verstand des
> Aufgabenstellers zweifeln ;-) SCNR
>

Danke dir für deine Antwort!

Wir konnten uns frei was überlegen. Der Dozent der die Laborübung macht 
meinte, dass der Prof der den Leistungsnachweis abnimmt hier gerne 
Spiele sieht, weil es alles andere schon 100 Mal gab. Außerdem macht 
fast alles andere keinen Sin ohne LabView-Hardware und die ist sehr 
teuer. Nur hätte ich mir ein Spiel überlegen sollen, dass keine 30 
Frames pro Sekunde aufbauen muss -sowas wie Tetris oder so....


> balsamico schrieb:
>> Weil LabView keinerlei Möglichkeiten Grafik
>> hardwareseitig berechnen zu lassen bietet, ruckelt die Geschichte
>> extrem
>
> Also ein bischen alpha-blending im Framebuffer schafft jede halbwegs
> aktuelle CPU spielend. Daran kann es kaum liegen. Vermutlich ist LabView
> für derartiges nicht konzipiert ("The right tool", Hust).

Allerdings ja, da hast du recht.


> Dann
> könntest Du noch versuchen, das selbst in einen Framebuffer zu rendern,
> notfalls in einer eigenen dll, wie du schon vorschlägst. Das ganze ist
> aber für den Außenstehenden noch sehr undurchsichtig, so dass Dir kaum
> jemand "Tiny2dEngineForLabview.dll" vorschlagen wird. Weiter wird das
> dann mehr ein C/C++ Projekt als ein LabView Projekt ("the right job").

Ich verstehe nicht ganz was "in einen Framebuffer zu rendern" bedeutet, 
aber wenn es das ist, was die Engine erledigen sollte dann nein danke 
:). Wie du sagst würde das dann mehr ein C/C++-Projekt werden. Aber wenn 
ich eine komlette Engine wie sfml einbinden würde, könnte es doch recht 
einfach gehen vielleicht.


Klar, der Schwerpunkt hier im Forum liegt ganz woanders. Das Beste wird 
sein ich poste das Ding hier mal in einem Gamedesign-Forum...

von Max (Gast)


Lesenswert?

Emil G. schrieb:
> Wir konnten uns frei was überlegen. Der Dozent der die Laborübung macht
> meinte, dass der Prof der den Leistungsnachweis abnimmt hier gerne
> Spiele sieht, weil es alles andere schon 100 Mal gab. Außerdem macht
> fast alles andere keinen Sin ohne LabView-Hardware und die ist sehr
> teuer. Nur hätte ich mir ein Spiel überlegen sollen, dass keine 30
> Frames pro Sekunde aufbauen muss -sowas wie Tetris oder so....

Dachte ich mir fast. Bei uns im µC Kurs hat sich auch jemand ausgesucht 
eine GUI auf dem PC für das Programm des Controllers zu machen. Zum 
Schluss musste es multithreaded sein, weil der Prof nicht akzeptiert 
hat, dass die GUI nicht durchgängig flüssig lief. Kleine Anekdote 
nebenbei.

Emil G. schrieb:
> Ich verstehe nicht ganz was "in einen Framebuffer zu rendern" bedeutet,
> aber wenn es das ist, was die Engine erledigen sollte dann nein danke
> :). Wie du sagst würde das dann mehr ein C/C++-Projekt werden.

Ein Framebuffer ist in dem Fall ein Speicherbereich, der die später 
anzuzeigende Grafik enthält, quasi das Bild das angezeigt wird. Rendern 
wird allgemein als Begriff verwendet, ein solches Bild zu berechnen. Du 
könntest also Pixel für Pixel die erforderliche Operation durchführen.

Unter "Engine" verstehe ich etwas, das mehr macht als eine Grafik zu 
berechnen. Sound, I/O, Spielmechanik. Nur die Anzeige berechnen läuft 
eher unter "scene graph". Vielleicht findet sich dazu was.

> Aber wenn
> ich eine komlette Engine wie sfml einbinden würde, könnte es doch recht
> einfach gehen vielleicht.

Klar. Stelle dich aber auch darauf ein, dass die Schnittstelle nicht so 
aussieht, wie Du es dir wünschst. Du wirst auf jeden Fall viel lernen. 
Nur nicht LabView. Wenn es unbedingt transparent sein muss und flüssig 
laufen muss und Du das Performance-Problem nicht in den Griff kriegst 
(z.B. nur das alpha-Blending auszulagern), mach das.

Emil G. schrieb:
> Das Beste wird
> sein ich poste das Ding hier mal in einem Gamedesign-Forum...
Sorry für Sarkasmus, aber da kennen sie sich bestimmt aus mit LabView 
;-)

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.