Announcement: there is an English version of this forum on 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 ;-)
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.