Suchergebnisse
Suchergebnisse 1-20 von insgesamt 1 000. Es gibt noch weitere Suchergebnisse, bitte verfeinere deine Suche.
Ich verwende dafür seit einiger Zeit so ein Makro: C-/C++-Quelltext 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 #define BITOPS_ENUM(T) \ static_assert(static_cast<::std::underlying_type<T>::type>(T::None) == 0, "Enum " #T " must have \"None\" entry."); \ FORCEINLINE static constexpr bool Has(T Value, T Requirement) noexcept { return (static_cast<::std::underlying_type<T>::type>(Value) & static_cast<::std::underlying_type<T>::type>(Requirement)) != 0; } \ FORCEINLINE static constexpr T operator |(T...
Früher gab es wohl etwas, das sich Pixel Buffer nannte: https://wiki.delphigl.com/index.php/Tutorial_Pixelbuffer Naja, DirectX 9 konnte das scheinbar auch 2002 schon. OpenGL war da einfach etwas langsam. Gibt es eigentlich einen speziellen Grund warum du dafür noch Extensions verwendest und nicht zB. OpenGL 3.3 voraussetzt?
IDA Pro ist ein bisschen teuer. Ich würde x64dbg (32 und 64 Bit Anwendungen) und OllyDbg (etwas altmodische GUI und nur 32 Bit) empfehlen.
Zitat Und Funktionen aus Extensions müssten das doch im Namen tragen - glBlaBlaEXT() oder glBlaBlaARB(). Ne, neue OpenGL-Versionen sind prinzipiell bloß eine Gruppe von Extensions und seit ungefähr OpenGL 3.0 gibt es auch für die meisten Änderung Neuheit in OpenGL eine passende ARB-Extension. Die Funktionen dieser Extensions haben kein "ARB" im Namen. Die glClearBufferfv-Funktion leert wohl einen Teil des Framebuffers. Es scheint mir daher naheliegend, dass die Funktion aus einer Framebuffer-Ex...
Das ursprünhliche Beispiel hat ein noch ein anderes Problem: Const. L"hallo" ist vom Typ wchar_t const*, nicht wchar_t*. Die Zuweisung ist deshalb nicht erlaubt. Manche Compiler akzeptieren das zwar trotzdem, allerdings ist es trotzdem falsch.
Performance ist natürlich ein sehr schwieriges Thema. Nach meiner persönlichen praktischen Erfahrung sind hier Branches zu vermeiden. Aber ich gebe dir recht, dass es theoretisch Situationen geben kann, in dem das nicht so ist. Spontaner Gedanke: Eine Lookup-Table kann auch Inline sein. Ein 64 Bit Immediate aus dem mittels einem Shifts und einem And die Werte auswählt werden. Ich habe aber noch nie beobachtet, dass das vom Compiler generiert wird.
Das mit dem Profiler ist ja richtig - aber es beantwortet die Frage nicht. Eine Wertetabelle ist in dem Fall effizienter, weil es keinen Control Flow benötigt und dadurch keine Pipeline Stalls verursacht. Das heißt: Der Compiler führt diese Optimierungen einfach nicht durch. Der Einwand von Dot ist nicht zutreffend, weil der Compiler auch hier eine Tabelle anlegt. Der Code von LukasBanana war leider nicht vollständig, um das eindeutig zu zeigen. Hier mal der vollständige Code (x64, Release, Stan...
Zitat Statische Konstruktoren gibt es aber in jeder Sprache Um mal ein Gegenbeispiel zu bringen: Standard C Ein etwas moderneres Beispiel: Rust Ich finde diese Entscheidung gut. Die Tatsache, das beliebiger Code noch vor main laufen kann, weil eine Bibliothek eingebunden wurde, finde ich gruselig und unsinnig. Man kann bestimmte Dinge ja bei der ersten Verwendung initialisieren. Andernfalls sind damit auch verschiedene Probleme verbunden, zB. die undefinierte Initialisierungsreihenfolge. Veränd...
Bei kleineren Texturen würde ich denken, dass das Erstellen eines FBOs und die State Changes die Sache teuer machen.
Ich meinte damit auch, schneller als manuell die Daten mit glTexImage bzw. glTexSubImage hochladen. Für den Fall, das ARB_clear_texture bzw. OpenGL 4.4 also nicht unterstützt werden. http://delphigl.de/glcapsviewer/listrepo…B_clear_texture
Wenn OpenGL Compute Shader unterstützt, kann man auch gleich glClearTexImage verwenden. Andernfalls könnte man ein FBO erstellen und mittels glClear leeren. Ob das schneller ist will ich aber mal stark bezweifeln. Bei sehr großen Texturen aber vielleicht schon.
Gibt es eine Warnung? Um welche Warnung handelt es sich? Mal #pragma warning disable ausprobiert? Warnungen sind wahnsinnig nützlich um viele Fehler zu finden. Es gibt auch auch viele, die allgemein, für bestimmte Anwendungen oder einzelne Methoden keinen Sinn ergeben und kontraproduktiv sind. Dann einfach abstellen. Deshalb sind es Warnungen und keine Fehler.
Das ist richtig, aber hast du schonmal versucht eine eigene Streamquelle zu implementieren? Zum Beispiel um einen Hash zu berechnen oder für einen Kompressionlayer. Ich habe die Erfahrung gemacht, dass dies mit einem anderen Stream-Interface wesentlich einfacher ist.
Zitat von »BlueCobold« Es ist übrigens \r\n und \n und nicht /r/n oder /n. Tatsache - habe es irgendwie geschaft die zu verwechseln. Ich finde die Windows-Konvention auch unsinnig, allerdings ist daran inzwischen kaum mehr was zu ändern. Mein Ärger richtet sich eher an das Design der iostreams. Diesen Fehler sieht man sehr oft. Er ist eigentlich darauf zurückzuführen, dass die Stream-Funktionen mit den Formatierungsfunktionen völlig vermischt sind.
Nun unter Windows ist der Standardzeilenumbruch /r/n. Also muss dieser beim Lesen in den C++ /n umgewandelt werden. Wenn ein Binärblock zufällig /r/n enthält, kracht es. (Sehr persönliche Anmerkung: iostreams mit diesen und den vielen anderen Eigenheiten sind der größte Schrott in der ganzen STL. Ich würde dir empfehlen, dass du etwas anderes verwendest, falls du die Möglichkeit dazu hast.)
Zitat realistisch aussehenden Pfad, wie in ein Flugzeug fliegen würde Kannst du das ein wenig konkreter beschreiben? Dein Bild sieht ehrlich gesagt nicht sehr realistisch aus. Ich würde annehmen, dass in der Realität würde das Flugzeug auf einer Kreisbahn um einen Punkt kreisen würde. Das sollte man relativ einfach hinbekommen können, in dem man das Flugzeug immer in die Richtung des Punktes lenkt. Mit einem bestimmten minimalen Kurvenradius und maximaler Lenkgeschwindigkeit.
Zitat Hier sagt mir mein Instinkt, dass ein Eindimensionales Array schneller geht Nun dein Instinkt liegt falsch. ;-) Erstmal sind solche Kleinigkeiten wirklich echte Kleinigkeiten. Selbst wirklich performancekritischen Applikationen würde sich da nicht unterscheiden. Und zum Anderen ist das eher Zufall. Wenn du deinem PC/Compiler was gutes tun willst, kompilier für x64. Dann gibt es mehr Register und die Werte werden nicht ständig vom Speicher gelesen. Das ist nämlich der überwiegende Teil der...
new halte ich nicht gerade für ein "modernes C++ Paradigma". Auf einem Mikrocontroller würde ich an deiner Stelle einfach jede dynamische Allokation sein lassen. Lege ein statisches Array an und gut ist. Es gibt schließlich keine Programme im Hintergrund oder Paging von Speicher, falls der knapp wird. Den Speicher dynamisch zu allokieren, hat dann eigentlich kaum Vorteile. Dafür bekommst du erst zur Laufzeit mit, wenn der der Speicher ausgeht, hast potentiell Memory Leaks und die Implementierung...
Zitat Also sobald pushback im Spiel ist ist es ein Vektor? push_back heißt die Methode und die gibt es bei vielen Containern. Zum Beispiel auch bei der std::deque oder der von mir verachteten std::list die wegen ihres verführerischen Namens und der theoretischen Laufzeitkomplexität häufig unnötigerweise verwendet wird. Ich rate dazu in 99% der Fälle einfach einen std::vector zu verwenden, wenn man eine Liste von Objekten speichern möchte. Das ist im Prinzip wie einfaches dynamisch wachsendes Ar...
Zitat von »Techel« Yeah, habe es hinbekommen, den msvc-compiler zu crashen Das ist keine große Kunst. Es passiert einfach viel zu oft. Bug Reports werden leider häufig einfach ignoriert.
19.04.2024, 21:47
Zum Seitenanfang
