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!
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.
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...
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
;-)
