vb = langsam

stimmt natürlich das die schleife sinnlos is, aber es soll auch keinen praktischen nutzen haben sondern einfach etwas testen

bei 2 takten / rechnung müsste das bei 1607 mhz satte 842 530 816 additionen / sek ergeben, also +420% leistung
wie hast dus denn compiliert?

das sw-rendering der q2-ending is eh in assembler gecodet, der rest aber in c++ ... scheint also nicht immer so einen geschwindigkeitsvorteil zu bieten

Zitat von FMFlash

oje wie langsam muss dann erst ein in vb gecodetes 3d-game sein?

Das is ned unbedingt gesagt. VB in Verbindung mitn DirectX SDK is ned unbedingt so langsam. Natürlich wenns um aufwendigere Sachen geht als a einfachs Game mit ISO Sicht oda a einfachen FP-Shooter dann is sicher langsam. Aber für einfache Sachen is schon schnell genug.

Zitat von FMFlash

jo nicht die rechungen machens aus sondern die speicherzugriffe

Das außerdem, aber das eine hat mit dem anderen nix zu tun.

Bei heutigen Spielen wird man sich schwer tun, irgendwas nennenswert zu verbessern, wenn man Teile in Assembler schreibt. Ein paar optimierte Vektor/Matrix-Operationen zahlen sich für die meisten 3D-Spiele schon aus, aber da sollte man doch eher auf schon fertige Routinen zurückgreifen, als selber mit Assembler zu basteln anfangen. Ohne fundierte Erfahrung wird man sonst nämlich eher verschlimmbessern.

Richtig, bei Quake war der Texture Mapper in Assembler geschrieben, und ich hab leider nie ausprobiert, um wie viel langsamer die C-Version wirklich ist. Bei Doom war's allerdings ähnlich, dass die ganzen Render-Routinen in Assembler waren, und da hat das gegenüber der C-Version knappe 10% Performance gebracht. Also zwar nicht soo wenig, aber die Welt ist es auch nicht.