Anti-Jammer-Thread

[SunCross]

Hab grad meine Raketenwerfer erstmals durch mein Programm Feuern lassen! Ich bin jetzt endgültig und komplett unabhängig von der Standardsoftware des Gerätes!


Und wenn morgen oder übermorgen mein 4. Raketenwerfer ankommt, geht die ganze Kiste von vorne los, weils n anderes Modell ist...

[eXile]

Die Tage werden wieder kürzer

Die Tage werden wieder länger

[Andre]

Ich wollte schon fast in den Jammer-Thread posten, da mein PC mir heute nur noch Bluescreens direkt nach dem Hochfahren zeigte, und memtest mir nicht gerade wenige Fehler im RAM anzeigte.
Nach guter alter Gameboy-manier die Module mal raus gezogen, reingepustet und in die anderen beiden Slots verfrachtet. Und siehe da, es funktioniert sogar :lol:

[Krishty]

Ich habe XNA Math bzw. DirectX Math rausgeschmissen, und die Engine ist dadurch sogar schneller geworden. Ich hätte früher erkennen müssen, dass diese Bibliothek bloß ein Brute Force-Ansatz ist und gegen maßgeschneiderte Datenstrukturen und Algorithmen von vornherein verliert.

Beispiel der Matrixmultiplikation: Wenn man statt 4×4- 4×3-Matrizen miteinander multipliziert, braucht man 25 % weniger Skalare (Register) und 44 % weniger Multiplikationen und Additionen. Mit der relativ sauberen x64-Texterzeugung scheint das schneller zu sein als die SSE-optimierte 4×4-Multiplikation von XNA Math; jedenfalls hat es meine multiplikationslastige Anwendung von hakeligen 50 (V-Sync!) auf flüssige 60 fps gehievt.

[Krishty]

Mit dem Visual C++ 11 Developer Preview hat sich die Leistung meiner Debug-Builds verdreifacht (9 Hz statt 3). (Da ich aber noch nicht weiß, wo dieser Sprung herkommt, ist das aber nur ein vorläufiges Anti-jammern)
Die Größe meiner x64-Exes ist gegenüber VS 2010 im Schnitt um 5 % gesunken, was wohl nur auf aggressiveres Inlining oder höhere Verarbeitungstiefe hindeutet; aber ich greife ja nach jedem Strohhalm.
Alles für’n Arsch. Das Scheißteil hat mir x86 kompiliert. (Ich naives Ding hatte mich schon gefreut, dass sich die Lösungen ohne Konvertierung nutzen lassen …) Die x64-Version ist ein Prozent größer und langsamer als mit VS 2010.

Aber die Suche ist erheblich schneller.

Und IntelliSense versteht x64.

[Krishty]

Warum kommt Visual Studio bloß immer mit sooo viel Müll … nach der Deinstallation vom VS 11 Developer Preview hatte ich einen SQL Server zu viel deinstalliert und VS 2010 ging nicht mehr. Nach fünf Stunden Setup-Wühlerei, manuellem Suchen von fehlenden Komponenten und unzähligen Rollbacks, die länger dauern als die eigentliche Installation, kann ich nun aber endlich wieder programmieren.

[CodingCat]

Der Grund für etliche Style-Fehler im Nostalgia-Theme in manchen Browsern (z.B. Chrome) war ein Komma zu viel:

Code: Alles auswählen

.content h2, .panel h2, .content h3, .panel h3, { ... }

[eXile]

Code: Alles auswählen

/*++

Copyright (c) Microsoft Corporation.  All rights reserved.

    THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY
    KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
    IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR
    PURPOSE.

Module Name: Sauron.cpp


Abstract: Implementation of CSauron, Windows Media Player Visualization
          that communicates with Firefly to blink the mouse light to
          the beat of music.


Environment:

    User mode only.

--*/

wtfamireading

[antisteo]

Mal so eben 700 BMP-Dateien umbenannt, alle Leerzeichen raus, außerdem eine gewisse Farbe transparent gesetzt und das ganze nach PNG mit Alpha-Kanal konvertiert.

Arbeitszeit: Na ratet mal ;)

[kaiserludi]

Mal so eben 700 BMP-Dateien umbenannt, alle Leerzeichen raus, außerdem eine gewisse Farbe transparent gesetzt und das ganze nach PNG mit Alpha-Kanal konvertiert.

Arbeitszeit: Na ratet mal ;)

Da es in diesem Thread steht: Sehr deutlich unter 1min.

[CodingCat]

Nach einem weiteren Abstecher in die Metaprogrammierung habe ich nun endlich die Möglichkeit, für jede Klasse (wohlgemerkt Klasse, nicht Objekt!) komfortabel Reflection-Eigenschaften zu definieren:

Code: Alles auswählen

const beCore::ReflectionProperties EntityProperties = beCore::ReflectionProperties::construct_inplace()
	<< beCore::MakeReflectionProperty<int[3]>("cell", beCore::Widget::Raw)
		.set_setter( BE_CORE_PROPERTY_SETTER_UNION(&Entity::SetCell, int) )
		.set_getter( BE_CORE_PROPERTY_GETTER_UNION(&Entity::GetCell, int) )
	<< beCore::MakeReflectionProperty<float[3]>("position", beCore::Widget::Raw)
		.set_setter( BE_CORE_PROPERTY_SETTER_UNION(&Entity::SetPosition, float) )
		.set_getter( BE_CORE_PROPERTY_GETTER_UNION(&Entity::GetPosition, float) )
	<< beCore::MakeReflectionProperty<float[9]>("orientation", beCore::Widget::Orientation)
		.set_setter( BE_CORE_PROPERTY_SETTER_UNION(&Entity::SetOrientation, float) )
		.set_getter( BE_CORE_PROPERTY_GETTER_UNION(&Entity::GetOrientation, float) )
	<< beCore::MakeReflectionProperty<float[3]>("scaling", beCore::Widget::Raw)
		.set_setter( BE_CORE_PROPERTY_SETTER_UNION(&Entity::SetScaling, float) )
		.set_getter( BE_CORE_PROPERTY_GETTER_UNION(&Entity::GetScaling, float) );

Den Objekten selbst wird dabei absolut nichts hinzugefügt, was mir sowohl in Bezug auf Speichereffizienz als auch in Bezug auf Einheitlichkeit (normale Methoden ohne vorgeschriebene Art der Speicherung) sehr wichtig war. Die Union-Erweiterung mit expliziter Spezifikation des Komponententyps erlaubt eine typsichere Reinterpretation der in diesem Beispiel kollektiv vektorwertigen Eigenschaften zu Komponentenarrays. Diese Erweiterung ist optional, das System ist typsicher und kann auch mit komplexen Typen wie beispielsweise Strings, Vektoren oder anderen Container-Klassen (inklusive deren Konstruktion und Destruktion) umgehen.

Die Makros werde ich leider nicht vollends los, solange ich nicht mit C++03 breche. So expandiert BE_CORE_PROPERTY_SETTER_UNION() beispielsweise zu ...

Code: Alles auswählen

::lean::properties::deduce_accessor_binder(setter)
	.set_base<::beCore::ReflectionPropertyProvider>()
	.set_value<value_type>().bind_setter<setter>()

..., was ich nur ungerne mehrmals im Quelltext haben will. Interessierte können sich hier in den Template-Jungle wagen. ;)

[SunCross]

Ich hab mir heut ne neue USB-Interface-Platine geholt.
Mit analogen und digitalen Ein- und Ausgängen. Die ersten 4 Taster sind schon angeschlossen. Die Taster werden später in meiner eigenen Heimversion von MissileControl die Raketenwerfer steuern.
Wird geil, demnächst eigene Wohnung, schön das Tastergehäuse an den Schreibtisch geschraubt und die Raketenwerfer irgendwo in der Nähe der Tür aufstellen.
8-)

[Krishty]

Es ist so weit

Ich importiere Win32-Funktionen ohne <Windows.h>


Hey, WinAPI

du bist fett und hässlich

und stinkst nach Fisch

[Jonathan]

Wie geht das denn?

[eXile]

Wie geht das denn?

Einfach eine eigene, abgespeckte Windows.h schreiben? Die z.B. mal nicht min/max umdefiniert, und auch sonst keine Geschichten macht, von denen man meinen könnte, man säße noch in den 80er-Jahren fest?

Zumal man in den meisten Fällen eh nur eine klitzekleine Untermenge der WinAPI benutzt. Aber mit WRL wird ja alles besser. Oh, und die WRL-Doku ist anscheinend nun online. Sneak peak:

[CodingCat]

Das nenne ich mal ne hilfreiche Dokumentation. Massig Hilfsklassen, bei denen es praktisch nur auf die Details ankommt - vollkommen unkommentiert, nicht mal eine grobe Erläuterung der Referenzsemantik.

[Krishty]

Wie geht das denn?

Einfach eine eigene, abgespeckte Windows.h schreiben? Die z.B. mal nicht min/max umdefiniert, und auch sonst keine Geschichten macht, von denen man meinen könnte, man säße noch in den 80er-Jahren fest?

Richtig. Mal ein Beispiel, damit das möglichst viele Leute machen:

Code: Alles auswählen

#pragma comment(lib, "Kernel32.lib")
extern "C" {

	__declspec(dllimport) void * __stdcall GetProcessHeap();

	__declspec(dllimport) void * __stdcall HeapAlloc(
		void *		hHeap,
		UnsignedInt4B	dwFlags,
		ByteSize	dwBytes
	);

	__declspec(dllimport) int __stdcall HeapFree(
		void *		hHeap,
		UnsignedInt4B	dwFlags,
		void *		lpMem
	);

} // extern "C"

Kann man natürlich noch beliebig mit Wrappern für Handles und sowas verfeinern.

[CodingCat]

Sehr schön, dann steht Clang bei dir nun nichts mehr im Wege. ;)

[Helmut]

@Krishty
Wo ist da denn jetzt der Vorteil gegenüber windows.h?
Wenn die min/max Makros stören kann man doch NOMINMAX definen und wenn die Ansi/Unicode Defines stören packt man halt ein entsprechendes #undef hin.

[Krishty]

Sehr schön, dann steht Clang bei dir nun nichts mehr im Wege. ;)

Leider habe ich mich auch dazu hinreißen lassen, __m128 sowie die wichtigen Intrinsics mitzuwrappen :)

Wo ist da denn jetzt der Vorteil gegenüber windows.h?
Wenn die min/max Makros stören kann man doch NOMINMAX definen und wenn die Ansi/Unicode Defines stören packt man halt ein entsprechendes #undef hin.

Code: Alles auswählen

#define WIN32_LEAN_AND_MEAN	// include only minimal functionality
#define NOGDICAPMASKS		// CC_*, LC_*, PC_*, CP_*, TC_*, RC_
#define NOVIRTUALKEYCODES	// VK_*
#define NOWINMESSAGES		// WM_*, EM_*, LB_*, CB_*
// #define NOWINSTYLES			// WS_*, CS_*, ES_*, LBS_*, SBS_*, CBS_* // "WS_VISIBLE"
#define NOSYSMETRICS		// SM_*
#define NOMENUS				// MF_*
#define NOICONS				// IDI_*
#define NOKEYSTATES			// MK_*
#define NOSYSCOMMANDS		// SC_*
#define NORASTEROPS			// Binary and Tertiary raster ops
#define NOSHOWWINDOW		// SW_*
#define OEMRESOURCE			// OEM Resource values
#define NOATOM				// Atom Manager routines
#define NOCLIPBOARD			// Clipboard routines
#define NOCOLOR				// Screen colors
#define NOCTLMGR			// Control and Dialog routines
#define NODRAWTEXT			// DrawText() and DT_*
#define NOGDI				// All GDI defines and routines
#define NOKERNEL			// All KERNEL defines and routines
#define NOUSER				// All USER defines and routines
#define NONLS				// All NLS defines and routines
#define NOMB				// MB_* and MessageBox()
#define NOMEMMGR			// GMEM_*, LMEM_*, GHND, LHND, associated routines
#define NOMETAFILE			// typedef METAFILEPICT
#define NOMINMAX			// Macros min(a,b) and max(a,b)
// #define NOMSG				// typedef MSG and associated routines // "::LPMSG" is required for some D3D11 functions
#define NOOPENFILE			// OpenFile(), OemToAnsi, AnsiToOem, and OF_*
#define NOSCROLL			// SB_* and scrolling routines
#define NOSERVICE			// All Service Controller routines, SERVICE_ equates, etc.
#define NOSOUND				// Sound driver routines
#define NOTEXTMETRIC		// typedef TEXTMETRIC and associated routines
#define NOWH				// SetWindowsHook and WH_*
#define NOWINOFFSETS		// GWL_*, GCL_*, associated routines
#define NOCOMM				// COMM driver routines
#define NOKANJI				// Kanji support stuff.
#define NOHELP				// Help engine interface.
#define NOPROFILER			// Profiler interface.
#define NODEFERWINDOWPOS	// DeferWindowPos routines
#define NOMCX				// Modem Configuration Extensions
#include <Windows.h>

Und trotzdem werden da noch zig MiB Quelltext an den Anfang jeder meiner Quelldateien gehangen; vor allem absolut schwachsinniger Kram wie SAL-Annotations. Und ich finde immernoch regelmäßig in den Dumps meiner Binaries CreateResourceA().

Ich habe es einfach satt. Ich inkludiere keine fremden Header mehr; vor allem keine, die andere #includes haben.

Da bindet man irgendeinen Windows-Scheiß ein; der bindet wiederum <math.h> ein; die <stddef>; und die <string>, und da ist dann ein KiB großes Locale static deklariert, das unweigerlich und ohne Nutzen in meinem Programm landet und jedes Mal bei Start und Ende initialisiert und wieder freigegeben wird. Selbstverständlich könnte ich da stattdessen au… ach, nö. Keinen Bock.

Außerdem sind die Header unmöglich zu #includen, sobald du einmal eine Funktion daraus überladen hast. Du willst dein eigenes abort()? Eins, das wirklich keine Destruktoren aufruft? Dann wird über die widersprüchliche Deklaration gemeckert, da abort() in <cstddef> (natürlich) __declspec(dllimport) deklariert ist. Lässt du den Header weg, musst du außerdem ein eigenes exit() und terminate() schreiben, weil die sonst nicht mehr gefunden werden. Und zack, fliegt der Müll raus.

Ich benutze keine 3rd-Party Header mehr. Ich mache jetzt alles komplett alleine. Ich bin frei.

Ups; vor lauter Rant fast vergessen:

Wo ist da denn jetzt der Vorteil gegenüber windows.h?

• 2,6 Sekunden für den Debug-Rebuild einer kompletten 3D-Engine samt minimalem Sound und Physik. <D3D9.h> und <XAudio2.h> werden nur von jeweils einer einzigen cpp-Datei eingebunden. Ich sehe gern schnell, was ich gerade tue.
• Freiheit
• weniger Stress
• Freiheit

[Krishty]

/OPT:REF und /VERBOSE:REF in cl.exe ~<3

[Krishty]

Auch den letzten Fitzelchen XNA Math, der noch aus Kompatibilitätsgründen drin war, rausgeschmissen. Wieder höhere Laufleistung.

Etwa die Hälfte der #include <Windows.h> durch eigene Deklarationen ersetzt.

Viele CRT-Funktionen durch eigene Implementierungen ersetzt. Aus Microsofts CRT referenziert bleiben Ausnahmebehandlung (werde ich wohl nie selber hinkriegen) und Matheroutinen (es ekelt mich bei dem Gedanken).

Kompilieren und Linken meiner mittlerweile 31k C++-Zeilen geschieht nun in unter 2,5 Sekunden.

Ich überlege mir fürs nächste Wochenende, wie ich Direct3D ohne #includes hinkriege – Direct3D will CRT und <Windows.h>; und die vier Dateien, die dranhängen, fressen fast die Hälfte meiner Kompilierzeit.

[dot]

Schonmal dran gedacht Precompiled Header zu verwenden?

[Krishty]

Ja. Dann bin ich aber dazu übergegangen, um das Prinzip zu kämpfen statt nur um die Kompilierzeit :)

<d3dx9.h> nur zwei- statt dreimal einbinden spart wieder 0,14 s. Oh wie ich mich darauf freue, <d3d9.h> ganz rauszuschmeißen.

[dot]

Versteh ich, würd mir selbst auch sehr eine clean version von windows.h wünschen. Aber ehrlich gesagt isses mir dann doch wichtiger die offiziellen Header zu verwenden als irgendwas Selbstgestricktes, das dann meinen Code inkompatibel mit dem richtigen SDK macht und am Ende irgendwelche Feinheiten mit irgendeinem Service Pack unter irgendeiner Windowsversion auf irgendeiner Architektur nicht berücksichtigt...dann doch lieber einfach pch, vor allem inkludiert man die Header ja sowieso nur ganz unten irgendwo...

[Krishty]

Die bestehenden Deklarationen in den Windows-Headern werden sich nie ändern. Feinheiten mit Service Packs finde ich aus der Luft gegriffen, da du mit dem Windows SDK ja gegen eine bestimmte Mindestversion kompilierst, ab der identischer Maschinentext auf allen Gastbetriebssystemen gleich funktioniert.

Bei Direct3D tendiere ich auch dazu, die offiziellen Header zu benutzen. Aber das June 2010 SDK ist sowieso das letzte, das ich noch mit Direct3D 9 benutzen kann (ich brauche XP-Unterstützung). D.h., auch dieser Header wird sich niemals mehr ändern.

[CodingCat]

Nachdem ich neidisch auf Krishtys Compile-Zeiten geschaut habe, ist mir bei meinem Rebuild eben (2 Minuten, 20 Sekunden) aufgefallen, dass jede einzelne Quelldatei des Lean-Projekts genau so schnell (langsam) baut wie das gesamte Framework in einer einizigen Quelldatei zusammenkopiert (weniger als eine Sekunde).

Das Feature, alle Framework-Sources einfach per Define und Include in eine einzige Quelldatei falten zu können, hatte ich eingebaut, damit sich das Framework problemlos komplett in eine Dll einbetten und exportieren lässt. Das Ergebnis ist erschütternd: Das Framework hat ca. 10.000 Zeilen Code. Nun habe ich Visual Studio die gefalteten Sources nach dem Präprozessor ausgeben lassen, und heraus kommen ... 360.000 Zeilen! Davon 103.002 Zeilen reiner Quellcode! Das ist 100x mehr als aller Framework-Code zusammen!

Das heißt, auf meiner lahmen Schüssel hat der Visual C++ Compiler einen Durchsatz von > 100.000 Zeilen Quellcode pro Sekunde! Damit ließe sich fast jedes Projekt dieser Welt in wenigen Sekunden compilieren!

Für mich heißt das, dass ich die gesamte Engine genau wie Lean hätte konzipieren müssen. Wenn pro Quelldatei 99% Overhead durch System- und STL-Includes hinzukommt (und ich include sehr sehr sparsam, binde nur gezielt ein, was sich nicht vermeiden lässt), dann erscheint der einzig vernünftige Weg, ALLES in einer einzigen Cpp zu kompilieren. Womit man sich dann auch Entkopplung getrost schenken kann, weil der Compiler beim entkoppelten Projekt an einer winzigen veränderten Quelldatei genauso lange kaut wie am gesamten Projekt mit mehreren 100.000 Zeilen!

(Und ich nutze pre-compiled Headers für System-Includes.)

[dot]

Dann musst du aber doch extreme Abhängigkeiten haben. Meiner Erfahrung nach kann ich meine Buildtime für Incremental Builds mit pch um Größenordnungen reduzieren. Und die ist was für mich zählt. Ob der Release Build 10 Sekunden oder 10 Minuten dauert ist mir im Allgemeinen ziemlich egal...

[CodingCat]

Die Frage ist, was packst du in deine pchs? Besteht dann noch ein großer Unterschied zu alles in einer Datei (bzgl. externe Abhängigkeiten)? Und nein, ich habe keine extremen Abhängigkeiten, mehr als Windows und STL ist da nicht.

[dot]

Ja, der übliche Weg mit einem pch der überall inkludiert werden muss ist natürlich völliger Mist, weil damit erst recht jedes File von jedem abhängig wird. Aber zum Glück gibts ja #pragma hdrstop ;)
Hier gibts ne gute Erklärung: http://stackoverflow.com/a/293219