Hi Leute,
mit Raylib kenne ich mich 0% aus. Auch mit OpenGL habe ich noch nie etwas eigenständig gemacht oder abgetippt
ABER zwangsläufig werde ich das ablaufen müssen.
Ich habe mir in PB eine "Mini-GUI Lib" gebastelt (ist eigentlich schon die 2e oder 3e), die ist leider sehr langsam weil ich von Sprite zu Sprite bzw. Bilder in Sprites render, und die anscheinend jedesmal hin und her kopiert werden (in der Linux/ScreenOutput() Hilfe steht auch, daß das sehr langsam ist.) SpriteOutput() funzt im Prinzip wie Screenoutput(), nur dass Sprites in der Regel kleiner sind, gelle?
Auf Windows verursacht ein wechsel von DX auf OGL einen FPS Abfall von 60 auf 30, weil ich 1x den ScreenOutput benutze und/oder ein sehr großes Transparentes Sprite benutze, auf das die gesamte GUI gerendert wird.
Auf dem R400 liegt die FPS Rate der GUI bei gefühlt WEIT unter 1FPS
Es sind zero FPS und ein paar zerquetschte.
Also habe ich auch in diesem Zusammenhang und Spieleprogrammierung gesucht und folgendes rausgefunden. Der ultimative Königsweg um eine FPS weit über 100 zu bekommen (wer's braucht), ist OpenGL zu benutzen, und das finale Sprite über einen Shader zu rendern. Fragt mich nicht was das bedeutet oder wie das genau geht. Aber die Logik wäre, um alle unnötigen Kopiervorgänge und blockierenden Befehle zu vermeiden: Alle Mal-Operationen finden nahe der CPU statt, also mit 2D Image bzw. selbstgebrauten copy/paste Sprite-Befehlen welche direkt in den Buffer (DrawingBuffer, nicht OGL/GraKa Buffer) schreiben würden. Soviel nur zur Theorie, es sollte aber ein super Trick sein, der auch auf andere Systeme portierbar wäre. Eine Herrausforderung läge hierbei beim genauen Timing zwischen den nichtblockierenden Befehlen und dem rechtzeitigen Framewechsel (genannt FlipBuffers(), daß dieser nicht zu früg erfolgt, vermutlich, und VSync gibt es bei einer FPS>160 vermutlich nicht, sofern dies eine Rolle spielt)...
Ich wollte sowieso eine neue GUI schreiben, und die sollte doch bitte so schön wie CEGUI sein - daher steckt diese noch in der Analysis Paralysis...
Dafür habe schreibe ich an einer mini-Datenbank, weil ich weit von GUI kurz abgedriftet bin... (ich dachte mir ich bräuchte ein Region/Quadtree und meine funktionierende Modelle sind aber keine Region trees)... Weil man solle erst "einfachere" Trees als Quadtrees probieren, meinte einer, und meinte AVL und Btrees... Ich finde die aber schon viel komplizierter bzw. Anspruchsvoller als Quadtrees, irgendwie. Glücklicherweise habe ich für AVL's portierbare codes gefunden, und diese kräftig ausgebaut und getestet. Für BTree gibts nichts Brauchbares auf Anhieb, was man so ohne Weiteres für meine Grundlagenforschung verwenden könnte - mit meinem Suchgkück.
Ich habe die Leistung von PC und R400 ein wenig verglichen, wie man Äpfel und Birnen halt vergleichen kann. Es ist alles bedeutend langsamer, und ich lese hier und da SDL sei aber langsam, insbesondere für Desktop Bezogenes. Macht bitte nicht doofe tests wie die auf youtube. Ihr müsste das VNC Fenster auf dem PC minimieren oder schließen während des Tests, der VNC Server und Xorg verballern 30-50% von einem CPU Kern, mindestens, wenn ihr hohe Frameraten habt und viel sich auf dem Monitor ändert. Filme über VNC konnte ich nicht ruckelfrei sehen (bei einer Auflösung von 1920x1080 geht das nicht), weil der VNC Server einfach nicht hinterher kommen kann.
Dann möchte ich noch was anmerken, es gibt anscheinend 2 OpenGL's auf dem R400, zumindest in VLC Player zur Auswahl. Benutzt das OpenGL for embedded systems v2 explizit, und wählt den Monitor Ausgang explizit aus, sofern ihr einen habt. So kann VLC bei unter 20% arbeiten, bei normalen OpenGL schon ca. 150% CPU Leistung (also mehr als ein Kern, vermute ich), und mit den anderen Modi geht das noch viel schneller nach oben; weil anscheinend zwischen den verschiedenen Software-Layern rumkonvertiert und kopiert. Was auch der Grund ist, weshalb einige Sachen langsam in SDL/Desktop sein können (meine Vermutung).
Lange Rede kurzer Sinn, aber ich denke meine Erfahrungen können auch dem Einen oder Anderen nützlich sein...
