spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Wenn man den Code so einfach in C++ schreiben koennte, dann muesste man ja nicht explizit ASM in den C++ einbetten

Kannst du den code ordentlich formatieren, dann kann man dir hier sicher helfen zu verstehen was da passiert.

ASM-zu-C++-Konverter gibt es sehr wenige und kosten auch meistens ne Stange Geld. Den Code, den du zeigst, wirst du auch nicht von Hand nach C++ bekommen können, da viele Konstrukte vorkommen, die es in C++ eigentlich gar nicht gibt (außer vielleicht die Funktion Sys_SnapVector). Der Code macht eigentlich nichts außer mit ein paar kleinen Tricks herauszufinden, ob er auf einem Pentium läuft.

Assembler setzte man im Highlevelbereich eigentlich nicht mehr ein.

Zitat von »Zanix«

Kann es sein das der Code ausschnitt zu lang ist und es ihn deshalb die ganze Zeit so anzeigt ?

Das liegt am Editor-Modus. Verwende zum Verfassen deiner Beiträge besser den Quellcode-Modus (im Beitragseditor oben umschalten), dann sollte es mit der Formatierung klappen...

Zitat von »Zanix«

Also darf ich daraus schließen, dass man sowas heutzutage gar nicht mehr benötigt oder ?

Abgesehen davon, dass inline Assembler unter MSVC nur für 32-Bit Programme unterstützt wird, verwendet der von dir gepostete Code die x87 FPU, die man auf aktuellen CPUs eigentlich besser nicht mehr verwendet und erscheint mir zumindest auf den ersten Blick insgesamt alles andere als effizient (effektiv passiert da nix anderes als ein floor()!?). Was genau versprichst du dir denn von dem Code? Statt inline Assembler generell besser Compiler Intrinsics verwenden...

Ich hoffe nicht, dass er diesen Code verwenden will. Der Schnipsel ist aus Return to Castle Wolfenstein.

Mir scheint das hier mal wieder ein grundlegend falsches Verständnis von Performance auf "moderneren" Prozessoren vorliegt.
Eine derartige Methode wäre so umgesetzt sehr ineffizient. Und so sollte man die Dinge heute tatsächlich nicht mehr verwenden. Intrinsics wären ganz besonders mit dem MSVC definitiv eine wesentlich bessere Idee. Außerdem wäre bei zeitgemäßeren Vorgehensweisen zur Optimierung höhere Geschwindigkeitsvorteile zu erwarten.

Deine Idee die CPU-Taktfrequenz auszulesen ist ebenfalls eine sehr schlechte Idee. Die Leistung kann unabhängig von der Taktfrequenz sehr stark variieren. Das reicht von unterschiedlicher Anzahl an Takten die die gleichen Befehle auf verschiedenen Prozessoren brauchen, über unterschiedlich parallele Ausführung in der Prozessorpipline zu Unterschieden in verschiedenen Caches, Anzahl Cores oder schlicht Hintergrundprozessen die die Leistung beeinflussen. Kurz, von der Taktfrequenz kannst du so gut wie gar nicht auf die Rechenleistung schließen und unterscheidet sich heutzutage auch nicht mehr stark. Zusätzlich dazu, sollte aus Sicht der Benutzerfreundlichkeit die Entscheidung, ob das Programm für den Benutzer "schnell genug" läuft, ihm nicht diktiert werden. Nichts wäre so ärgerlich, wie wenn das Programm wegen so etwas den Dienst verweigert, obwohl es schnell genug gelaufen wäre.