Seite 147 von 254
Re: Jammer-Thread
Verfasst: 10.12.2015, 00:04
von TDK
Richtet euch darauf ein, dass es in Direct3D 12 mit der Ressourcen-Anbindung per ID3D12GraphicsCommandList::SetDescriptorHeaps() nicht erledigt ist.
Ihr müsst die Ressourcen nochmal mit ID3D12GraphicsCommandList::SetGraphicsRootDescriptorTable() und den Konsorten extra anbinden.
Diese Methode erwartet übrigens einen Parameter Index für die Root Signature...
Bei mir würfelt es jetzt die die ganze Konfiguration der ganzen Root Signaturen und Heaps durcheinander.
Und ich hab mich vorher wie ein Löffel gefreut, dass ich "nach 11 Monaten irgendetwas auf dem Monitor gerendert habe".
Oh Mann, ich hasse diesen Unity-Entwickler, der es auf der Präsentation mit diesen Spruch nur angedeutet hat.
Edit:
Habe mich nochmal gerettet. Meine Descriptor Heap Sets definieren "Slots" in den XML-Konfigurationen.
Und ich habe sogar so weit gedacht, dass die Heaps per Name ausgewählt werden und der Benutzer bestimmt, welcher Root-Parameter benutzt wird.
Re: Jammer-Thread
Verfasst: 10.12.2015, 16:48
von Schrompf
Ein Kollege hat mir vor langer Zeit mal bei der Splatter-Linux-Portierung auf die Sprünge geholfen. Er hat nicht viel geschafft neben Arbeit und Familie, aber er hat unter anderem die paar Bitschubser-Funktionen für den GCC geschrieben, die ich jetzt beim Voxelprojekt massiv brauche. Ich bin ihm dafür ja sehr dankbar, aber ich musste ne Weile debuggen, um den Fehler darin zu finden. Analog zu "Platz ist in der kleinsten Hütte" wäre die Coder-Weisheit hier "Auch Einzeiler können Bugs haben".
Immerhin: dank den Unittests ist die Dummheit sofort aufgefallen.
Re: Jammer-Thread
Verfasst: 15.12.2015, 08:54
von Schrompf
<hier angemessen emotionales Schimpfwort einfügen>
Gestern abend ist meine SSD gestorben. Seltsam verschmiertes Fontrendering im Browser, zunehmende Hänger in allen Anwendungen, dann Bluescreen 0xF4, seitdem bootet er nicht mehr und im BIOS taucht in der SATA-Geräteliste keine SSD mehr auf.
<Schimpfwort><Schimpfwort><Schimpfwort>
Ich hab zwar halbwegs frische Backups, aber z.B. nicht von meinen Mails. Und ich fürchte, dass damit auch x kleine Notizdateien in y verschiedenen "temp"-Ordnern über den Jordan sind.
<Schimpfwort>
War eine Samsung 840 Evo 1TB. August 2014 gekauft... evtl. hab ich zumindest noch Garantie drauf.
Re: Jammer-Thread
Verfasst: 15.12.2015, 09:42
von Krishty
Oh Mann … da ich mit Festplatten-Ausfällen Erfahrung habe: Mein aufrichtiges Mitgefühl!
Re: Jammer-Thread
Verfasst: 15.12.2015, 10:04
von xq
Mein Beileid! Mir ist vor einigen Wochen meine Daten-Platte verreckt. Zum Glück Festplatte, es war also noch fast alles rettbar. Das Problem ist nur: Wohin rettet man 2,5 TB Daten, wenn man nur noch 500 GB-Platten rumliegen hat?
nicht von meinen Mails.
Darum nutzt man IMAP ;)
Re: Jammer-Thread
Verfasst: 15.12.2015, 10:30
von Alexander Kornrumpf
Das erinnert mich daran, dass auf meinem Zettel noch steht ClonZilla mal wieder anzuwerfen. Schon wieder viel zu lange her.
Das Problem mit CloneZilla ist dass das Interface darauf aus ist einem Angst zu machen. Ständig Warnungen was man alles kaputt machen kann. Das macht die Hürde höher als sie sein sollte.
Re: Jammer-Thread
Verfasst: 15.12.2015, 12:52
von Krishty
Bisher hatte ich an Chrome nichts zu meckern, aber jetzt hat es eine meiner Erweiterungen deaktiviert und sagt tatsächlich
das hier:
Damit Sie beim Surfen im Internet geschützt sind, können Sie in Chrome nur Erweiterungen verwenden, die im Chrome Web Store veröffentlicht wurden.
Wat
Deaktivierte Erweiterungen verwenden
Wenn Sie eine deaktivierte Erweiterung verwenden möchten, bitten Sie den Entwickler der Erweiterung, diese im Chrome Web Store hochzuladen.
Areyoukiddingme.jpg
Also doch wieder Firefox
eigentlich sollte man ja nur noch den Tor Browser benutzen, aber da sind die meisten Erweiterungen logischerweise tabu …
Re: Jammer-Thread
Verfasst: 15.12.2015, 17:30
von Krishty
Mit Windows 8 wurde ein Intrinsic eingeführt, das es Programmen erlaubt, noch schneller abzustürzen!
__fastfail():
A fast fail request is self-contained and typically requires just two instructions to execute. Once a fast fail request has been executed the kernel then takes the appropriate action. In user-mode code, there are no memory dependencies beyond the instruction pointer itself when a fast fail event is raised. This maximizes its reliability even if there is severe memory corruption.
Ich weiß zwar nicht, wie corrupted der Memory sein muss, damit
int 3 oder
TerminateProcess() nicht mehr funktioniert, aber … sie werden ihre Gründe haben.
Re: Jammer-Thread
Verfasst: 18.12.2015, 08:56
von Tiles
Ratet mal was schon wieder als wichtiges Update getarnt auf meinen Win 7 Rechner will -.-
https://support.microsoft.com/de-de/kb/3035583
Verstehen die Kameraden eigentlich was für einen Flurschaden die da grade anrichten? Dem Windows Update ist nicht mehr zu trauen. Und genau deswegen kommt mir auch kein Win 10 mit Zwangsupdate auf Platte.
Ich verstehe es echt nicht. Da haben sie endlich mal wieder was richtig gemacht, und dann reissen sie es mit dem Arsch wieder ein ...
Re: Jammer-Thread
Verfasst: 18.12.2015, 14:12
von B.G.Michi
Auch ich werde mich mit Händen und Füßen gegen Windows 10 wehren. Obwohl mir mein 7er im Moment ganz gut gefällt wird die laufende Politik Microsofts wohl früher oder später der Grund werden, beim Hauptsystem auf Linux zu wechseln...
Re: Jammer-Thread
Verfasst: 18.12.2015, 14:36
von Krishty
Ach, wie wir das damals schon vor Windows Vista gesagt haben. Wisst ihr noch? DRM im Betriebssystem? Windows Update aktualisiert sich, ohne uns vorher zu fragen? Trusted Computing?!
Und heute haben wir’s alle in den Rechnern und benutzen trotzdem noch Windows.
Wir können’s ja anders machen. Wir organisieren uns hier und bauen zusammen das super-über-mega-AAA-Game. Sowas wie GTA trifft Call of Duty, nur mit mehr Nacktheit (wir sind ja Europäer). Das verkaufen wir für ein paar hundert Millionen. Und das Geld (und unsere Programmierexpertise) stecken wir dann komplett in die Entwicklung von
ReactOS. Und in sieben Jahren haben wir damit eine voll Windows-kompatible Alternative. Wann geht's los?
Re: Jammer-Thread
Verfasst: 18.12.2015, 15:42
von B.G.Michi
Danke für den Sarkasmus, wir haben zum Glück nicht mehr 2001. Aber im Ernst: es muss jeder für sich selbst entscheiden und seine eigenen Prioritäten setzen. Für meinen Teil war ich mit Windows 98 bis 7 zufrieden. Dagegen finde ich 8 bis 10 einfach nur ekelhaft, unintuitiv und muss jedes mal den Kopf schütteln wenn ich bei Freunden oder Familie am Rechner nur die Systemsteuerung suche... Dann lieber openSUSE. Man denke an Bash, SSH, und ach ja: GCC. Nativ und nicht mehr per MSYS. Bleibt noch das Totschlagargument der Programme, die auf Linux nicht (nativ) laufen, aus der Liste installierter Programme bleiben noch genau 3 Stück übrig (abgesehen von Spielen)
Re: Jammer-Thread
Verfasst: 18.12.2015, 18:04
von Alexander Kornrumpf
Krishty hat geschrieben:Ach, wie wir das damals schon vor Windows Vista gesagt haben. Wisst ihr noch? DRM im Betriebssystem? Windows Update aktualisiert sich, ohne uns vorher zu fragen? Trusted Computing?!
Und heute haben wir’s alle in den Rechnern und benutzen trotzdem noch Windows.
Wir können’s ja anders machen. Wir organisieren uns hier und bauen zusammen das super-über-mega-AAA-Game. Sowas wie GTA trifft Call of Duty, nur mit mehr Nacktheit (wir sind ja Europäer). Das verkaufen wir für ein paar hundert Millionen. Und das Geld (und unsere Programmierexpertise) stecken wir dann komplett in die Entwicklung von
ReactOS. Und in sieben Jahren haben wir damit eine voll Windows-kompatible Alternative. Wann geht's los?
Steam OS?!
Re: Jammer-Thread
Verfasst: 18.12.2015, 18:30
von Tiles
Das Dowe ist halt, als Grafiker bist du unter Linux der Mops, weil die benötigte Software bis auf wenige Ausnahmen nicht auf Linux läuft. Da ist Windows im Moment echt alternativlos. Bleibt nur Windows 7 bis es keinen Support mehr gibt.
Das hingegen geht wiederum auch nur wenn du keine Spiele entwickelst. Die Target Plattform brauchst du ja schon allein zum Testen. Und somit bleibt eigentlich nur das Update auf Win 10 kurz bevor der Mist doch wieder was kostet. Dann hat man zwar trotzdem den Ärger, aber wenigstens kostet der kein Geld.
Alles Mist grad :/
Re: Jammer-Thread
Verfasst: 18.12.2015, 19:21
von Krishty
Alexander Kornrumpf hat geschrieben:Steam OS?!
Ist das nicht ein auf Echtzeit modifiziertes Unix, das alle D3D-Calls in OpenGL übersetzt oder so?
***
Der Punkt bei ReactOS ist ja, dass sogar die Windows-Gerätetreiber weiter funktionieren. Es ist eben kein Unix mit Wine, sondern du kannst deine komplette Software samt Hardware-Beschleunigung rüberportieren.
Wenn’s irgendwann fertig ist. Vielleicht hätte ich zehn Jahre meines Lebens in sowas investieren sollen statt in Spiele …
*** Nachtrag: So wie ich das sehe, unterstützt SteamOS nur einen Bruchteil der Steam-Spiele, und alles, was nicht Linux-kompatibel ist, wird gestreamt. Außerdem scheint die Performance allgemein schlechter zu sein als unter Windows.
Re: Jammer-Thread
Verfasst: 18.12.2015, 23:11
von Biolunar
Krishty hat geschrieben:Alexander Kornrumpf hat geschrieben:Steam OS?!
Ist das nicht ein auf Echtzeit modifiziertes Unix, das alle D3D-Calls in OpenGL übersetzt oder so?
Steam OS ist ein Debian Derivat; kann sein, dass sie einen leicht gepatchten Linux-Kernel verwenden, keine Ahnung. Windows-only Spiele laufen auf Steam OS nicht, da man dafür Steam unter Wine installieren müsste. Es ist halt nur ein Linux.
Re: Jammer-Thread
Verfasst: 18.12.2015, 23:12
von Krishty
Vier Stunden ist’s her und wir schreiben in der selben Sekunde :D Ja, siehe Edit oben. Also ReactOS …
Re: Jammer-Thread
Verfasst: 21.12.2015, 10:25
von Alexander Kornrumpf
Schritt 1: HDMI Kabel in Laptop stecken, Bild wir übertragen, Ton nicht.
Schritt 2: Es ist ein Audio Problem, also mal bei Realtek nach Treibern schauen.
Schritt 3: Realtek empfiehlt mir dringend bei dem Hersteller, der die Hardware zusammengebaut hat nach Treibern zu schauen.
Schritt 4: Bei AsUS lässt sich nichts brauchbares finden, zurück zu Realtek.
Schritt 5: "ATI HDMI Driver" (o. ä.) sieht gut aus, aber wieso ATI? Müsste ich mit Intel und/oder Nvidia nicht durch diesen Unsinn? Wenn ja, wieso ist jede AMD/ATI Hardware die ich je hatte so furchtbar?
Schritt 6: Jetzt kann ich über den "Realtek Audio Manager" und HDMI jede Box (von 5) einzeln ansteuern (yay!). Keine Ahnung ob es Spiele gibt, die das nutzen, aber ich bin vorbereitet.
Schritt 7: Another Day. Laptop wurde zwischenzeitlich heruntergefahren, ansonsten gleiches Setup. "Audiomanager" erkennt dass was an HDMI hängt, aber gibt keinen Ton raus. What the Hell?
Schritt 8: Im Gerätemanager ein wenig herumklicken.
Schritt 9: Jetzt hat sich der Catalyst Nachfolger (Frontend zum AMD Grafik-Treiber) die Hoheit über den HDMI Port gesichert. Ich kann zwar Ton an HDMI ausgeben, aber nicht mehr über den Audiomanager (Frontend zum Audiotreiber). WHAT THE HELL? Außerdem "nur noch" in Stereo, bzw. habe ich keine Möglichkeit mehr das zu testen.
Tjo. Dass es irgenwie nicht die weltbeste Idee ist, zwei Chipsätze potentiell verschiedener Hersteller denselben Anschluss verwenden zu lassen, scheint jetzt klar zu sein. Aber wieso Windows sich herausnimmt, bei einem simplen Neustart neu zu entscheiden welcher Treiber welche Hardware steuern darf, aber mir kein Interface anbietet um diese Entscheidung zu revidieren...
Jemand Erklärungen was passiert sein könnte, bzw. wie man es "richtig" macht?
Re: Jammer-Thread
Verfasst: 21.12.2015, 10:32
von Alexander Kornrumpf
Krishty hat geschrieben:Alexander Kornrumpf hat geschrieben:Steam OS?!
Ist das nicht ein auf Echtzeit modifiziertes Unix, das alle D3D-Calls in OpenGL übersetzt oder so?
***
Der Punkt bei ReactOS ist ja, dass sogar die Windows-Gerätetreiber weiter funktionieren. Es ist eben kein Unix mit Wine, sondern du kannst deine komplette Software samt Hardware-Beschleunigung rüberportieren.
Wenn’s irgendwann fertig ist. Vielleicht hätte ich zehn Jahre meines Lebens in sowas investieren sollen statt in Spiele …
*** Nachtrag: So wie ich das sehe, unterstützt SteamOS nur einen Bruchteil der Steam-Spiele, und alles, was nicht Linux-kompatibel ist, wird gestreamt. Außerdem scheint die Performance allgemein schlechter zu sein als unter Windows.
Es war eine Anspielung auf das was in der realen Welt aus "Lass uns Millionen mit Spielen verdienen und die dann in ein OS stecken" herauskommt, kein Vorschlag für ein OS was man sich installieren sollte.
Ich hab mir die Beschreibungen von den besseren Set-Top-Boxen von Steam, Amazon, Google, Microsoft und Sony (höhö) inzwischen alle mal angeschaut. Meiner Meinung nach sind diese One-Trick Ponys alle Quatsch. Was man am Ende will ist ein PC im Wohnzimmer und nicht einen künstlich runtergeblödeten PC.
Re: Jammer-Thread
Verfasst: 21.12.2015, 21:57
von Schrompf
Auch meine noch rotierend gefertigten Platten haben Lesefehler. Ich merke es immer dann, wenn die Operation auf einer Datei plötzlich eine Minute permanent leuchtende HDDLED erzeugt, wo vorher einige Dutzend Files pro Sekunde behandelt wurden. Aber selbst die ausführlichsten Voll-Scans mit den WesternDigital- und Hitachi-Fesplattentools laufen ohne jeden Befund durch. Ein schlichtes chkdsk dagegen findet ordentlich.
Ich war wahrscheinlich naiv, zu erwarten, dass der Hersteller einer Festplatte mir auch ehrlich über die Fehler auf derselben Auskunft gibt.
Re: Jammer-Thread
Verfasst: 21.12.2015, 22:37
von Krishty
CrystalDisk Info hat auf meinen Platten alles zuverlässig diagnostiziert. Ansonsten ist das Dateisystem getrennt vom Speicher auf der Platte; chkdsk prüft das erste und S.M.A.R.T.-Tools etc. das zweite. Wenn dauernd die Dateisysteme kaputtgehen (aber nicht die Platten an sich), kann das alles mögliche sein, von losen Kabeln über kaputten Arbeitsspeicher (Master File Table ist fast die ganze Zeit im RAM) bis zu lila Feen, die Regenbogenstaub in den Dateisystemtreiber kotzen.
Re: Jammer-Thread
Verfasst: 22.12.2015, 11:19
von Krishty
The "Windows" section of every open-source project's "how to compile and install" file
Passt ja gut zum ZFX-Logo ;)
Re: Jammer-Thread
Verfasst: 22.12.2015, 22:06
von dot
:lol:
Re: Jammer-Thread
Verfasst: 24.12.2015, 15:06
von Jonathan
Es ist jedes mal das selbe. Man will am Laptop weiter programmieren, zieht sich den aktuellen Stand und muss erstmal ne ganze beschissene Stunde wieder fummeln, bis der vollkommen korrekte Code kompiliert. Weil zwischendurch eine Bibliothek aktualisiert wurde. Oder weil man einen neueren Compiler benutzt. Die Sprache ansich ist ja weitesgehenst nett, aber alles was mit Compilieren zu tun hat, fühlt sich an wie Assembler.
Und das geile ist, ich benutze ja schon CMake, weil das ja alles ganz toll und automatisch macht. Außer dass es überhaupt nichts automatisch macht und ich stattdessen erst noch CMake Skripte debuggen muss. Die man natürlich auch wieder für jede neue Version umschreiben muss. Um ehrlich zu sein, habe ich es noch nie erlebt, dass CMake bei mir auch nur irgendetwas automatisch richtig gemacht hätte, es war absolut immer eine furchtbare Fummelei.
Haben eigentlich diese neuen C++ Core-Guidlines irgendetwas nettes Neues, was das Bauen vereinfacht? Ich hatte vorhin das Problem, dass die FreeImage.lib auf einmal FreeImageLib.lib heißt. Weil man aus abstrusen Generitätsgründen in CMake keine Dateiendungen angibt (als ob alles vor der Endung plattformübergreifend gleich wäre...) ist mir das echt lange nicht aufgefallen und ich musste mich schon wieder aufregen, warum hier wieder nix gefunden wird. Obwohl ich schon ein Programm habe, das für mich sucht.
Es würde ja schon helfen, wenn man endlich mal ein Standard-Layout für Bilbiotheken hätte. Damit so such-Tools tatsächlich mal funktionieren könnten.
Re: Jammer-Thread
Verfasst: 25.12.2015, 00:30
von marcgfx
meine ki sah schon ganz gut aus als ich zum weihnachtsessen ging. kam zurück, sah definitiv noch besser aus. mach in mysql workbench ne select abfrage zum schauen wie es dort ausschaut. resultate kommen, bild flackert, keine resultate mehr. hä? mach die abfrage nochmal, nix mehr da. dumm wie ich bin, nehm ich an ich hab nen fehler gemacht. mach ne select abfrage auf meine einzigen backup eintrag. kommt, flackert, weg. ... wtf. jetzt kann ich die ki von vorne berechnen lassen :P ... workbench neu gestartet, die selbe abfrage läuft ohne probleme (mit den neuen einträgen).
Re: Jammer-Thread
Verfasst: 28.12.2015, 15:51
von Jonathan
Wollte meinem Spiel einen Splash-Screen verpassen. Aber das scheint einfach nicht zu gehen.
Momentan blockiert das Fenster halt, während das Spiel startet. Das nervt und sollte geändert werden. Die naheliegende Idee war, das ganze möglichst einfach umzusetzen, also alle Ladelogik in einen Thread packen, den Nutzer bespaßen bis dieser fertig ist und dann das Fenster umschalten.
Aber in OpenGL kann jeder Thread nur einen Kontext aktiviert haben und jeder Kontext kann nur in einem Thread aktiv sein. Ich kann also nicht ohne weiteres das Fenster öffnen, irgendwas zeichnen und in einem anderen Thread Ressourcen laden. Man kann zwar Objekte über Kontexte hinweg teilen, aber bestimmte Objekte (Framebuffer, VBA's) leider nicht - ohne mein halbes Spiel umzuschreiben kann ich also nicht mit verschiedenen Kontexten arbeiten.
Also wollte ich ein zweites Fenster erstellen, das einfach irgendetwas anzeigt (n Bild, irgendeine Animation) und dann im Hintergrund laden. Ich benutze GLFW zum Fenstermanagement, aber da sind Fenster und Kontexte unzertrennlich verbunden. Aber ich kann ein verstecktes Fenster erstellen, den Kontext zum Laden benutzen und gleichzeitig ein zweites Fenster anzeigen. Aber jetzt hat GLFW so lustige Einschränkungen wie dass alle Fenster vom Haupt-Thread verwaltet werden müssen. Und auch alle Nachrichten müssen dort behandelt werden.
Und jetzt gerade lese ich, dass Vollbildfenster nicht versteckt erstellt werden können und man auch nicht zwischen Vollbild und Fenstermodus hin und her schalten kann.
Aktuell sehe ich nicht so ganz, wie ich mit all diesen Einschränkungen mein Problem lösen soll, ohne das ganze Spiel umzubauen. Meine Güte ist das nervig :(
Re: Jammer-Thread
Verfasst: 28.12.2015, 18:36
von Krishty
Ich wollte letztes Jahr mal ein Tutorial schreiben, wie man einen vernünftigen Splash Screen entwickelt. Hätte dir mit GLFW usw. nicht geholfen, weil es nativ Win32 gewesen wäre, aber … du leidest nicht allein.
Da lernt man dann, UI und Logik strikt zu trennen. Eingabe, Fensternachrichten, und Rendering sind UI und gehören in den Haupt-Thread. Spiellogik ist keine und gehört wo anders hin. Ach wenn's immer so einfach wäre :(
Re: Jammer-Thread
Verfasst: 30.12.2015, 03:07
von dot
Jonathan hat geschrieben:Aber in OpenGL kann jeder Thread nur einen Kontext aktiviert haben und jeder Kontext kann nur in einem Thread aktiv sein. Ich kann also nicht ohne weiteres das Fenster öffnen, irgendwas zeichnen und in einem anderen Thread Ressourcen laden. Man kann zwar Objekte über Kontexte hinweg teilen, aber bestimmte Objekte (Framebuffer, VBA's) leider nicht - ohne mein halbes Spiel umzuschreiben kann ich also nicht mit verschiedenen Kontexten arbeiten.
Ja, der ganze Context-Kram mit OpenGL ist hoffnungslos kaputt. Was du anstrebtst, geht aber schon; FBOs und VAOs etc. können geshared werden. Normalerweise verwendet man heutzutage ja
WGL_ARB_create_context bzw.
GLX_ARB_create_context, wo das direkt unterstützt wird (es geht sogar per wglShareLists(), auch wenn Name und Doku der Funktion was anderes vermuten lassen, das liegt nur daran, dass die Funktion sehr, sehr viel älter ist als all diese Dinge und sich seither niemand drum geschert hat).
Unter Windows musst du sowieso erst einen Dummy-Context erzeugen, bevor du den richtigen Context machen kannst, du könntest diesen dann idealerweise gleich für den Splashscreen weiternutzen...
Jonathan hat geschrieben:Also wollte ich ein zweites Fenster erstellen, das einfach irgendetwas anzeigt (n Bild, irgendeine Animation) und dann im Hintergrund laden. Ich benutze GLFW zum Fenstermanagement, aber da sind Fenster und Kontexte unzertrennlich verbunden. Aber ich kann ein verstecktes Fenster erstellen, den Kontext zum Laden benutzen und gleichzeitig ein zweites Fenster anzeigen. Aber jetzt hat GLFW so lustige Einschränkungen wie dass alle Fenster vom Haupt-Thread verwaltet werden müssen. Und auch alle Nachrichten müssen dort behandelt werden.
Und jetzt gerade lese ich, dass Vollbildfenster nicht versteckt erstellt werden können und man auch nicht zwischen Vollbild und Fenstermodus hin und her schalten kann.
Ja, leider ist es so, dass nicht nur der OpenGL Context-Kram an sich schon völlig kaputt ist (OpenGL war halt auch nie für sowas wie eine GPU konzipiert, aber selbst nach damaligen Standards ist das Design der API imo einfach nur völlig bescheuert), praktisch alle OpenGL-Window-Management-Libraries wie GLUT und GLFW und auch GLEW und gl3w und das ganze Zeug sind alle völlig kaputt. Du bekommst entweder eine Schnittstelle, deren Abstraktionen hinten und vorne einfach nicht passen oder irgendeine C-Library, die von allen Dingen nur genau eine implizite, globale Instanz verwalten kann oder eine Library, deren ganze Implementierung auf der Annahme eines glücklichen Zufalls basiert und streng genommen einfach nur ein großes, schwarzes Loch von Undefined Behavior ist oder eine Library, die zwar rein theoretisch, über obskure Präprozessorflags, eine Krücke bietet, die das eigentlich korrekte Verhalten zumindest nicht ganz nicht supported, von der aber die wenigsten wissen, geschweige denn, irgendjemand diese ernsthaft einsetzen würde und natürlich jede beliebige Kombination all dieser Dinge. Soweit das Auge reicht, sieht man leider nur Mist am Horizont im Lande OpenGL. An so verrückte Dinge wie Multi-GPU, am Ende sogar verschiedene Hersteller im selben System, wagen wir besser gar nicht erst zu denken...
Falls du nicht weiter in diesen Abgrund vordringen willst, hier ist, was ich mir mit der Zeit so zusammengebastelt hab, weil ich es nichtmehr aushalten konnte:
Doku gibt's leider keine (die GL_platform_tools sind für das Context/Window Management, kommen mit einer mini Testanwendung; läuft atm auf Windows und Linux, eine egl Version hab ich mal angefangen, mangels Bedarf aber nie fertiggestellt)...
Re: Jammer-Thread
Verfasst: 30.12.2015, 13:22
von Krishty
dot hat geschrieben:Unter Windows musst du sowieso erst einen Dummy-Context erzeugen, bevor du den richtigen Context machen kannst, du könntest diesen dann idealerweise gleich für den Splashscreen weiternutzen...
Habe nur Halbwissen darüber, aber … warum? Bisher dachte ich: Fenster erzeugen (mit
CS_OWNDC), dann
wglCreateContext(), dann ab die Post …
Re: Jammer-Thread
Verfasst: 30.12.2015, 14:50
von dot
Ja, das funktioniert, so lange du keinen Core Profile Context willst oder einen Debug Context oder sonst irgendwas, was man im 21. Jhd normalerweise gerne hätte... ;)
Btw: CS_OWNDC braucht es nicht und sollte man generell eher vermeiden...