Viele Laptops beinhalten Intel-Prozessoren mit integrierten Grafikchips anstatt dedizierten Grafikkarten. Diese Chips haben meistens eine schreckliche OpenGL-Implementation, welche sich auf diverse Extensions konzentriert anstatt alle Features der höheren Versionen zu implementieren.
Posts by Corvus
-
-
Glaube mir King, es gibt eine ganze Menge von Leuten, dessen Laptops nichteinmal OpenGL Version 2.0 unterstützen. Das letzte Mal, als eine OpenGL-Anwendung herausgebracht habe musste ich das mit Schrecken feststellen.
-
Sicher, dass du dich auf OpenGL 4 beschränken willst? Es ist leider noch nicht so weit verbreitet, wie man es sich wünschen würde, vor allem auf Laptops und anderen mobilen Geräten wirst du wohl auf wenig Zugang stoßen.
-
At the very beginning there was also an english version available.
But if memory serves me right there have not been any translations of the most recent versions.
I dont know if the older english releases are still available for download somewhere, maybe TheKing has some backup files. -
Ich habe immernoch meinen originalen Super Nintendo und die dazugehörige Terranigma Cartridge, beides vollkommen funktionstüchtig, zuhause.
Das waren schöne Zeiten damals. -
Auf Windows-basierten Computern sollte es generell möglich sein mit einem Druck auf die "Print"-Taste eine Kopie des Bildschirmbildes in die Zwischenablage zu speichern und in einem Grafikprogramm deiner Wahl einfügen zu können.
Falls das zu umständlich ist kann man auch immerzu auf Software von Drittanbietern zurückgreifen wie zum Beispiel SimpleScreenShot oder ähnliche.
Ein Link falls Interesse daran besteht: http://simplescreenshot.rbytes.de/Was dein Problem angeht; es wird wahrscheinlich als bald keine weiteren Fixes für die auf dem RPG-Maker basierte Fassung geben, da King die Entwicklung auf eine neue Engine verschoben hat.
Falls du noch nicht die neueste Version für die RPG-Maker Fassung verwendest solltest du einmal probieren diese herunterzuladen und zu patchen. Falls du bereits die neueste Version verwendest stehst du wohl fürs erste vor einem kleinen Problem. Da hilft dann nur ausprobieren und hoffen. -
Entschuldige bitte die Frage, aber hast du das Bild mit einer Kamera von deinem Bildschirm aufgenommen?
-
Die Mipmaps sind nicht wirklich nötig für 2D, da hast du recht, ich verwende sie auch nur in diesem kleinen Test. Einfach nur um die Engine zu testen.
Ob deine Grafikkarte wirklich 100 Mipmap Stufen erstellen wird liegt nicht in meiner Hand. Die Dokumentation sagt aus, dass es nicht nötig ist Mipmaps mit einer Größe von weniger als 2x2 Pixel zu erstellen. -
Jede Mipmap wird um die Hälfte kleiner, 100 sind zwar nicht nötig wie du sagst, ich habe aber dennoch für den Test 100 Mipmap Stufen eingestellt. Es geht maximal in die Tausender, weitere Stufen kosten nichts mehr ab einem gewissen Punkt. Und bei einem einzigen Bild auf dem Bildschirm kümmert es sowieso recht wenig.
-
Ich habe auch einen kleinen Feature-Test erstellt. Vielen möchtest du es dir einmal ansehen.
Das interessanteste dabei wären wohl die Unterschiede zwischen den Texturfiltern. Mit der Taste T kann man im Programm die verwendete Textur umstellen. Die erste Textur benutzt einen linearen Texturfilter und 100 Mipmap Stufen, während die zweite Textur einen Nächster-Nachbar-Filter verwendet und keine Mipmaps benutzt.Man kann das angezeigte Bild außerdem frei drehen, skalieren, bewegen, die Farbe beeinträchtigen und den Shader zu einem Schwarz-Weiß-Shader wechseln.
Hier der Downloadlink: http://www.file-upload.net/download-81466…ndows-.zip.html -
Den Buffer auf Softwareseite benötige ich sowieso um die Daten zu übertragen. Anstatt den Buffer jedesmal neu zu erstellen wenn er benötigt wird halte ich einfach jederzeit einen Buffer bereit. Dieser Buffer kann dann natürlich auch noch für andere positive Effekte eingesetzt werden.
In OpenGL kann man die Buffer ebenfalls markieren, dass man sie nicht lesen will, oder, dass sie nichtmehr verändert werden. Allerdings bedeutet das nicht, dass es auch wirklich so ist. Immerhin sind die Regeln von OpenGL nur Empfehlungen. Jeder Hardwarehersteller kann sich entscheiden sie umzusetzen oder nicht. Ganz allgemein wird oft gesagt, dass man diesen Flags nicht ganz trauen sollte in OpenGL. Aber natürlich kann es nicht schaden sie trotzdem zu verwenden.
-
OpenGL übernimmt nicht direkt die alten Werte aus dem Buffer. Du kannst natürlich die alten Werte mit einem entsprechenden Befehl selbst lesen und dann in den neuen hineinschreiben.
Ich habe aber jederzeit einen Buffer auf Anwendungsseite, welcher ebenfalls alle Daten nocheinmal speichert. -
Mit DirectX kenne ich mich überhaupt nicht aus. Wie du gesagt hast, hier scheint es sich um ziemliche Unterschiede zu halten. In OpenGL ist es überhaupt kein Problem einfach neuen Speicherplatz zu beantragen.
In dem hochgeladenen Testprogramm, zum Beispiel, beginne ich mit Platz für nur 200 Dreiecke und arbeite mich langsam vorwärts indem der Speicherplatz verdoppelt wird. Auf 1 000 000 sind das eine ganze Menge Neu-allokationen. -
Mein erster Rat bei soetwas ist immer einmal im Internet danach zu suchen. Du bist sicher nicht der erste, welcher solch ein Problem hat. Es gibt auch sicher ein Support-Forum für DirectX fragen. Ich habe sehr viele Fragen in diversen OpenGL Support-Foren gestellt bis ich zu meinem derzeitigen Engine-Stand kam.
-
Der Buffer bei mir wächst dynamisch mit dem Bedarf.
Ich kann eine Anfangsgröße und ein Vergrößerungsverhalten definieren. Es gibt aber auch Standardwerte dafür falls man nichts definiert. Im Moment lasse ich den Buffer jeweils auf die doppelte Menge wachsen und neuen Platz auf der Grafikkarte anfordern.
Das ist kein Problem, da es in OpenGL sogar empfohlen wird komplett neuen Platz anzufordern anstatt die alten Werte zu überschreiben, da somit die Grafikkarte noch mit den alten Werten zuende arbeiten kann und man selbst gleichzeitig neue Daten einspeist. Orphaning nennt man dieses Prozedere. Allerdings verwende ich es im Moment nur um neuen Platz zu allokieren, nicht um die eigentlichen Daten periodisch zu übertragen.Außerdem blickt man in OpenGL normalerweise (im 3D Bereich) die negative Z-Achse herab.
-
Jetzt habe ich das gleiche Problem wie realPhoenix. MSVCP110.dll fehlt auf dem Computer.
-
In OpenGL geht das standard Koordinatensystem von -1 bis 1 auf allen Achsen. Der Punkt (0, 0, 0) ist die Mitte des Fensters. Außerdem habe ich vorher falsche Informationen gegeben. Die Z-Koordinaten für die Dreiecke generiere ich über random.nextFloat() was in Java einen Wert aus dem Intervall [0.0, 1.0) zurück gibt.
-
Ich bin auch noch auf etwas draufgekommen, nämlich kam meine "schlechte" Performance doch nicht alleine vom fehlenden z-buffer. Bis jetzt hatte ich nämlich keine Z-Koordinate übermittelt, sondern diese im Shader lediglich einheitlich auf 0.5 gesetzt. Und da scheint DirectX tatsächlich ein Problem zu haben, das ist mir schon früher mal aufgefallen beim Partikelsystem, aber dachte nicht dass es tatsächlich um so etwas triviales handelt. Auch jetzt, wenn alle Dreiecke auf der selben Position sind, egal ob mit oder ohne Z-Buffer, sinkt die Performance rapide ab. Kannst du ein ähnliches Verhalten auch feststellen (probier mal alle dreiecke auf exakt derselben z-position zu zeichnen), oder ist das ein DX-relatives Problem?
Interessanterweise, ja. Wenn ich die Z-Koordinate aller Dreiecke fest auf 0.5 setze dann sinkt die Performance sogar ein ganzes Stück. Ich komme nurnoch auf ca. 600 000 Dreiecke. (Mit Depth-Buffer Funktion GL_LESS und Framerate limitiert auf 60 FPS)
Eventuell ein Fehler in deiner Software-Frameschranke, welche die Gameloop unter bestimmten vorraussetzungen stalled? Ein exzellenter Artikel zu diesem Thema mit einer guten Implemententierung ist der Artikel "Fix your timestep", falls es dich interessiert und du ihn noch nicht kennst.
Die Framerate wird nicht von mir limitiert. Ich verwende eine Implementierung der zugrundeliegenden Bibliothek LWJGL. Das ist die selbe Bibliothek, welche auch die OpenGL- und OpenAL-Aufrufe ermöglicht. Wie genau der Code dahinter ist weis ich nur grob.
Ich werde aber einmal in dem entsprechenden Support-Forum von LWJGL danach fragen ob jemand eine Lösung zu diesem Verhalten kennt.Ich denke das kommt eher daher weil ich deine OpenGL-libary nicht installiert habe. Was mich aber immer noch verwundert, warum er dann überhaupt danach sucht, die dlls liegen ja bei...
EDIT: Übrigens, ich weiß nicht ob das in Java auch so einfach geht, aber in c++ kannst du eine zusätzliche Konsole öffnen lassen und den output auf diese umleiten, dass macht die Handhabung IMHO etwas einfacher...
Leider geht das in Java nicht so einfach. Es ist wirklich eine ganze Schwierigkeit eine native Konsole mit java zu öffnen und den Output darauf zu verlinken. Das hat etwas mit Sicherheit und Plattformunabhängigkeit zu tun. Normalerweise sollte jedes Java-Programm generell über die Konsole gestartet werden; dass die .jar Pakete mit dem Doppelklick gestartet werden können ist ein Luxus den es erst seit kurzem gibt und auch, soweit ich weis, nur auf Windows.
Die Bibliotheken müssen nicht installiert werden. Die .dll Dateien werden direkt über JNI aufgerufen. Ich habe die Bibliothek bereits in dem Java-Code verlinkt, daher verwundert es mich, dass bei dir die Bibliotheken nicht gefunden werden können.
Du könntest auch einmal probieren, ob es funktioniert die .dll Dateien einfach in das selbe Verzeichnis wie Exe.jar zu stecken. Standardmäßig sucht Java immer zuerst im selben Verzeichnis.EDIT2: Wegen der plötzliche erhöhten Performance, du schiebst eh nicht aus versehen Dreiecke aus dem darstellenbaren z-bereich? Das kann einiges an anscheinlicher Leistung erzeugen, wenn du z.B. den z-Wert inkrementiert und irgendwann über 1.01f kommst...
Ich bewege die Bilder in dem Benchmark überhaupt nicht. Sie befinden sich immer im Bereich zwischen -1 und 1 auf allen Achsen. -
Ja natürlich, VSYNC lässt sich deaktivieren. Ich weis im Moment auch nicht ob es bei der Applikation aktiviert ist, ich kenne die Standardwerte noch nicht ganz auswendig, aber ich würde glauben, dass es standardmäßig deaktiviert sei. Ich könnte mich aber auch irren.
Die Framerate wird bei diesem Testprogramm allerdings durch eine Softwareimplementation auf 60 frames pro Sekunde limitiert.
Ich habe auch ein paar weitere Tests durchgeführt. So wie es scheint ist standardmäßig der Depth-Buffer aktiviert. Bei deaktiviertem Depth-Buffer komme ich nurnoch auf ca 250 000 Dreiecke bevor die Framerate zu fallen beginnt.
Wenn ich die Framerate nichtmehr auf einen festen Wert zu beschränken versuche verbessert sich die Performance sogar noch bei weitem (bei aktiviertem Depth-Buffer). Bei 2000 Dreiecken (zu Beginn der Benchmark-Applikation) komme ich auf 1200 frames pro Sekunde.
Die 60 frames pro Sekunde Marke wird erreicht bei 2 000 000 Dreiecken. Wieso die Performance sich so stark verbessert hat kann ich im Moment nicht wirklich sagen. Ich werde einige weitere Nachforschungen benötigen um dem Ganzen auf den Grund zu gehen.Edit: ich weis nicht recht weshalb du das Programm nicht über die Kommandozeile starten kannst. Bei mir funktioniert es nämlich. Die Fehlermeldung, welche du bekommst, deutet jedoch darauf hin, dass die OS-spezifischen Bibliotheken nicht gefunden werden können. Du kannst den Pfad zu den Bibliotheken selbst angeben wenn du das Programm über die Kommandozeile startest. Dafür musst du den Befehl "-Djava.library.path=<PATH>" verwenden. Es sollte aber eigentlich auch ohne funktionieren.
Bei mir funktioniert der einfache Aufruf: "java -jar Exe.jar" -
Nun, OpenGL könnte wohl den standard Depth-Buffer aktiviert haben. Ich kann mich nicht errinern ob ich ihn explizit in der Applikation ausgeschaltet habe. Ich kann nocheinmal eine Version mit manuell deaktiviertem Depth-Buffer hochladen wenn du die Werte vergleichen willst.
Edit: Du musst übrigens bei der Applikation ein wenig warten wenn du die Framerate beobachtest. Er berechnet die aktuelle Framerate immer direkt aus dem Zeit unterschied zwischen dem aktuellen und dem letzten Frame. Das bedeutet, dass es immer wieder kleine Fluktuationen geben kann wenn gerade das Fenster verschoben wird, neue Bilder erstellt werden oder der Garbage-Kollektor seine Arbeit erledigt.