Jammer-Thread

Hier kann über allgemeine Themen diskutiert werden, die sonst in kein Forum passen.
Insbesondere über Szene, Games, Kultur, Weltgeschehen, Persönliches, Recht, Hard- und Software.

Re: Jammer-Thread

Beitragvon Jonathan » 16.03.2017, 22:51

Krishty hat geschrieben:Ich habe die Levels schön extrahiert, aber halt mit einem Objekt für jede Kachel der Landschaft. Macht fast 100.000 Objekte pro Level. Mein Tool lädt alles in einen Win32-Tree View (wie jedes Modeling-Tool, das es gibt), und der ist … langsam.

Ja ok, aber wie es im Artikel schon so schön heißt: The treeview isn't optimized for this case because you don't optimize for the case where somebody is mis-using your system. Ich meine, auf welche Art ist ein Tree-View mit so vielen Elementen denn sinnvoll?
Und wenn man dann sagt "der Benutzer soll sich ja nicht alles ansehen, sondern sich durch die einzelnen Ebenen zu einem ganz bestimmten Node klicken können", könnte man dann nicht den Treeview dynamisch befüllen? Es müsste da doch eigentlich ein OnExpand Event oder ähnliches geben (Soetwas habe ich mal in Qt für ein Menü gemacht, das halt die zuletzt geöffneten Dateien angezeigt hat - das wurde dann bei jedem Öffnen neu befüllt).
Lieber dumm fragen, als dumm bleiben!
Benutzeravatar
Jonathan
 
Beiträge: 1130
Registriert: 04.08.2004, 20:06

Re: Jammer-Thread

Beitragvon Krishty » 16.03.2017, 22:55

Man kann ihn nur in die Tiefe virtualisieren, nicht in die Länge. Um die 200×200 Grundkacheln komme ich also nicht herum.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
 
Beiträge: 5874
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Jammer-Thread

Beitragvon Krishty » 20.03.2017, 12:25

Montaaaag! Guten Morgen, Jammer-Thread! Fuck Microsoooooft!

Habe auf die neuen PDB-Formate von Visual Studio 2015 umgestellt (/DEBUG:FASTLINK), die ja so viel schneller sein sollen. Ich weiß nicht ob sie’s sind, aber die ganze DbgHelp API (SymGetLineFromAddrW64() usw.) hört auf zu funktionieren (im Sinne von „vier Access Violations pro Aufruf“). Meine Debug-Hilfsfunktionen sind alle kaputt. PIECE OF SHIT, also alles reverten
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
 
Beiträge: 5874
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Jammer-Thread

Beitragvon MasterQ32 » 20.03.2017, 15:08

Javascript-basierte Seiten sind scheiße zu automatisieren....
Duct tape is like the force. It has a light side, a dark side, and it holds the world together.
MasterQ32
Felix Queißner
 
Beiträge: 893
Registriert: 07.10.2012, 14:56

Re: Jammer-Thread

Beitragvon Krishty » 20.03.2017, 22:24

MasterQ32 hat geschrieben:Javascript-basierte Seiten sind scheiße
fixed that for you

————

Boah hab’ ich wieder ’nen Kragen:
ltcg.png

LTCG:incremental ist bei Visual C++ seit einiger Zeit Standardeinstellung in Release Builds. FUCK. FUCK FUCK FUCK FUCK FUCK.

Zwei Gründe, das auf keinen Fall zu benutzen:
  1. Es ist keine volle Optimierung. Der Optimizer hält sich in dem Modus mit Inlining und Constant Propagation zurück, damit möglichst wenig neu optimiert werden muss, wenn man den Code nochmal ändert. Ihr liefert also keine voll optimierte EXE an die Kunden aus.
  2. Ohne Rebuild ist die EXE voller Müll. Der Linker hängt einfach alle Änderungen immer wieder hinten dran bis man Clean oder Rebuild aufruft. Wer also vor der Auslieferung 20 Mal was ändert und weder Clean noch Rebuild aufruft, liefert eine sechs Mal so große EXE aus, in der die 19 letzten Änderungen tot herumliegen.
Boah ist das zum Kotzen. Diese scheiß Mother Fuckers haben mir mit ihrer stillen Änderung das letzte Dutzend ausgelieferter Programme verhagelt.

NATÜRLICH war ich zu faul, die Ursache für den Größen- und Leistungsunterschied (grundsätzlich kleiner weil weniger Inlining; grundsätzlich langsamer aus dem selben Grund) zu ermitteln, weil, fuck, ich kann ja nicht den ganzen Tag optimieren und muss was fertigkriegen und sie haben halt einfach was am Compiler geändert, oder? NEIN SIE HABEN EINFACH ALLES KAPUTTGEMACHT DIE SCHWEINE

Nach Windows-Update sind Compiler-Updates also das nächste, was ich nicht mehr installieren darf. FUCK THIS SHIT

Nachtrag: Sie wollten es für Update 2 beheben, aber es ist immernoch drin?!
Zuletzt geändert von Krishty am 26.03.2017, 03:41, insgesamt 1-mal geändert.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
 
Beiträge: 5874
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Jammer-Thread

Beitragvon MasterQ32 » 21.03.2017, 02:35

fixed that for you

Danke, Recht hast du!

und ich bin grade irgendwie echt froh, hier mit gcc/clang rumzuwerkeln, da rantest du nicht so drüber rum
Duct tape is like the force. It has a light side, a dark side, and it holds the world together.
MasterQ32
Felix Queißner
 
Beiträge: 893
Registriert: 07.10.2012, 14:56

Re: Jammer-Thread

Beitragvon Krishty » 21.03.2017, 10:46

Die benutze ich ja auch garnicht ;)
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
 
Beiträge: 5874
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Jammer-Thread

Beitragvon kaiserludi » 21.03.2017, 17:03

Krishty hat geschrieben:Es ist keine volle Optimierung. Der Optimizer hält sich in dem Modus mit Inlining und Constant Propagation zurück, damit möglichst wenig neu optimiert werden muss, wenn man den Code nochmal ändert. Ihr liefert also keine voll optimierte EXE an die Kunden aus.

Das macht das als Default für Releasebuilds reichlich dämlich, denn Releasebuilds sind ja gerade dazu gedacht, erst gebaut zu werden, wenn der Code releasefertig ist und man nicht noch mitten in der Entwicklung eines neuen Features ist.
Auf Entwicklungsrechners sollte man eigentlich nur die Debug Config bauen, außer, man muss akut was optimieren und die Performance testen, aber dann will man ja wieder die volle Optimierung haben.
Krishty hat geschrieben:Ohne Rebuild ist die EXE voller Müll. Der Linker hängt einfach alle Änderungen immer wieder hinten dran bis man Clean oder Rebuild aufruft. Wer also vor der Auslieferung 20 Mal was ändert und weder Clean noch Rebuild aufruft, liefert eine sechs Mal so große EXE aus, in der die 19 letzten Änderungen tot herumliegen.!

Und damit hast du gleich noch einen Grund mehr, warum du nicht in deiner lokalen Codebase, in der du auch entwicklelst, Releases bauen solltest, sondern diese in einem Clean Checkout durchführen solltest, idealerweise via Autaamted Build Script und ausgeführt durch eine spezialisierte Buildsoftware und auf dedizierter Hardware.
"Mir ist auch klar, dass der Tag, an dem ZFX und Developia zusammengehen werden der selbe Tag sein wird, an dem DirectGL rauskommt."
DirectGL, endlich ist es da :)

"According to the C++ standard, it's "undefined". That's a technical term that means, in theory, anything can happen: the program can crash, or keep running but generate garbage results, or send Bjarne Stroustrup an e-mail saying how ugly you are and how funny your mother dresses you." :shock:
kaiserludi
 
Beiträge: 441
Registriert: 18.04.2002, 15:31

Re: Jammer-Thread

Beitragvon Krishty » 21.03.2017, 23:22

kaiserludi hat geschrieben:Und damit hast du gleich noch einen Grund mehr, warum du nicht in deiner lokalen Codebase, in der du auch entwicklelst, Releases bauen solltest, sondern diese in einem Clean Checkout durchführen solltest, idealerweise via Autaamted Build Script und ausgeführt durch eine spezialisierte Buildsoftware und auf dedizierter Hardware.
Bei den großen Programmen wird das natürlich so gemacht; ich habe aber auch ein Dutzend kleinerer Projekte, die quasi Standalone-EXEs sind und für die es weder Source Control gibt, noch wären Build Scripts erforderlich. Und da trifft das natürlich richtig.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
 
Beiträge: 5874
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Jammer-Thread

Beitragvon Krishty » 22.03.2017, 15:00

Baue gerade Objektnamen in meinen TreeView ein – was man nicht alles in CAD-Dateien findet …

hangs.png
hangs.png (3.75 KiB) 564-mal betrachtet
Zuletzt geändert von Krishty am 24.03.2017, 02:39, insgesamt 1-mal geändert.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
 
Beiträge: 5874
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Jammer-Thread

Beitragvon joggel » 22.03.2017, 15:40

Ich bekomm langsam ein Knoten im Kopf!!!!
SINNLOS hier, echt!!!

CSV-Dateien parsen und die Daten verwenden ist ja nicht sooo schwer.
Diese CSV-Datei hat einen Header.
Nun verändert sich der Header aber immer mal wieder zwischen den Versionen....
Ändert die Anzahl der Einträge, die Reihenfolge der Einträge und manchmal auch die Bezeichnung der Einträge!!!
Muß ich immer in der software anpassen.
Damit es aber richtig behindert wird, soll auch noch die Abwärtskompatibilität erhalten werden!!!! :x :x :x :x

ich kann und will nicht mehr....
...
Benutzeravatar
joggel
 
Beiträge: 1146
Registriert: 06.11.2007, 19:06
Wohnort: Dresden

Re: Jammer-Thread

Beitragvon Krishty » 22.03.2017, 17:47

Oh, es hat wieder jemand Probleme mit 32-Bit-BMPs. Na sowas.

Die Bilder stammen aus Photoshop, und im Zusammenhang mit BMP ist das übrigens bekannt dafür, dass ihre 32-Bit-Exporte nicht mit der Spezifikation kompatibel sind (ein DWORD zu viel im Header). Das scheint aber nicht ihre Schuld zu sein, sondern ein Microsoft-Techniker scheint ihnen vor Jahrzehnten eine falsche Spezifikation gegeben zu haben und dann konnten sie es nicht mehr korrigieren weil die ganzen Content Pipelines der Spieleentwickler auf das falsche Format zugeschnitten waren. Möglicherweise haben sie es auch mit einem Format verwechselt, das Microsoft für Windows CE 5.0 entwickelt hat (und danach wieder eingestellt hat).

Jedenfalls zähle ich in meinem Code sieben verschiedene Header-Formate und vier verschiedene Kompressionsmethoden, und nothings hat recht wenn er sagt, dass sich BMP immer sehr einfach anhört aber äktschuälly eines der furchtbarsten Formate überhaupt ist.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
 
Beiträge: 5874
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Jammer-Thread

Beitragvon Krishty » 26.03.2017, 18:43

Wenn man Visual C++ auf Größe optimieren lässt statt auf Geschwindigkeit, arbeitet der Optimizer besser. Insbesondere das alte Problem „ich lese zwei Mal aus einem Member, und der Compiler erzeugt dafür auch tatsächlich zwei Lade-Operationen, statt in einem Register zwischenzuspeichern“ tritt viel seltener auf.

Ich glaube nicht, dass das eine rationale Entscheidung war („wenn wir zwei Mal laden, lässt sich die Ausführung besser parallelisieren“ oder so).

Microsoft empfiehlt seit Jahren, gar nicht mehr auf Größe oder Geschwindigkeit zu optimieren, sondern ausschließlich Profile-Guided Optimization zu nutzen. Die wiederum optimiert nur die inneren Schleifen auf Geschwindigkeit, und den großen Rest des Programms auf Größe. Naturgemäß ist dann das meiste Disassembly, das man sieht, Ergebnis der Größenoptimierung, und vielleicht haben sie deshalb mehr Ressourcen investiert, die zu verbessern.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
 
Beiträge: 5874
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Jammer-Thread

Beitragvon Tiles » 27.03.2017, 08:25

Sommerzeit. Im Frühling. :shock:
Free Gamegraphics, Freeware Games http://www.reinerstilesets.de
Die deutsche 3D Community: http://www.3d-ring.de
Benutzeravatar
Tiles
 
Beiträge: 1032
Registriert: 11.01.2003, 14:21

Re: Jammer-Thread

Beitragvon MasterQ32 » 28.03.2017, 12:20

Krishty, das passt doch sicher perfekt in deine Sicht zu VS: https://blog.fefe.de/?ts=a6278e32
Duct tape is like the force. It has a light side, a dark side, and it holds the world together.
MasterQ32
Felix Queißner
 
Beiträge: 893
Registriert: 07.10.2012, 14:56

VorherigeNächste

Zurück zu Allgemeines Talk-Brett

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast