Seite 126 von 254
Re: Jammer-Thread
Verfasst: 28.01.2014, 12:24
von Krishty
Zum Installieren muss man aber erstmal wissen, dass es existiert. Such in der Suchmaschine deiner Wahl nach Memory Leak Detection und gewinn einen Keks, falls es auf Seite 1 erscheint ;)
Falls du dich übergangen fühlst dass ich das vorher nicht kannte obwohl du drüber geschrieben hast: Weder lese ich hier alle Beiträge, noch erinnere ich mich an alle erwähnten Tools wenn ich Monate später vor einem Problem stehe. Und ja; in 15 Minuten selber schreiben ist für mich in vielen Fällen tatsächlich schneller als ein Microsoft-Tool zu installieren ;) Ich werde es aber mal austesten.
Re: Jammer-Thread
Verfasst: 28.01.2014, 16:52
von glassbear
Sternmull hat geschrieben:Ich verstehe echt nicht was hier für seltsame Wege gegangen werden um Memory Leaks zu finden. Ich hab hier im Forum schon mehrmals darauf hingewiesen das man mit
UMDH auch ohne speziellen Bibliothken oder sonstwie angepasstem Code oder Binaries die Leaks ohne großem Aufwand indentifizieren kann. Aber von mir aus bastelt euch den tausendsten Leak-Debugger...
Was waere denn etwas vergleichbares fuer OS X und Linux? valgrind?
Re: Jammer-Thread
Verfasst: 31.01.2014, 09:12
von Krishty
Oh Gott das verfluchte C++-Kommittee. C++11 haben sie mit ihren neuen Narrowing-Regeln schön kaputtgemacht. Das hier ist ab C++11
verboten:
int i = …;
float vec[] = { i, i, i };
stattdessen muss da jetzt stehen:
int i = …;
float vec[] = { float(i), float(i), float(i) };
Jetzt werdet ihr denken:
Wie blöd bist du denn auch, da ein int reinzustecken? Mach i doch direkt zum float!
Scheiße an der Latte!
short i = …, j = …;
short sum[] = { i + j }; // Fehler:
decltype(i + j) == int
Ich darf also an 300 unter C++03 validen Stellen explizite Casts einbauen um C++’ implizite Casts wieder auszugleichen. Und wofür? Für
nichts! Denn obwohl ich für jedes einzelne Element den selben Typ erzwingen muss, kann ich immernoch nicht
auto vor die Arrays schreiben!
Und falls ihr es bei euch ausprobiert und keine Fehler seht: Dann benutzt ihr Visual C++, das das einzig Richtige tut und
darauf scheißt.
Ich habe diese Wichser langsam satt. Ich muss unbedingt zusehen, ob ich mir via Clang C99 + Exceptions + Templates +
auto +
namespace + Operator Overloading - Promotion zusammenbauen kann und da für immer bleibe. C++ wird von Release zu Release ein größerer fetterer Haufen komplizierter Scheiße die keiner braucht.
Re: Jammer-Thread
Verfasst: 31.01.2014, 09:54
von Florian Keßeler
Hör auf zu heulen: -Wno-narrowing
Re: Jammer-Thread
Verfasst: 31.01.2014, 10:07
von Krishty
Ach so – ich wusste garnicht, dass man neuerdings Dünnschiss in den Standard kacken darf so lange große Compiler einen Schalter haben um das dann nachträglich zu umgehen! Danke!
Re: Jammer-Thread
Verfasst: 31.01.2014, 10:10
von Florian Keßeler
Stimmt. Ist viel abwegiger als sich seine eigene Sprache zusammenzubasteln.
Re: Jammer-Thread
Verfasst: 31.01.2014, 10:14
von Krishty
Ja; dann ist man sowas nämlich ein für alle Mal los und muss nicht befürchten, dass sie in der nächsten Version POD-Initialisierungslisten abschaffen oder so.
Re: Jammer-Thread
Verfasst: 31.01.2014, 10:18
von Florian Keßeler
Im Übrigen finde ich es sehr sinnvoll. Besonders in Template-Code, bei dem man unter Umständen gar nicht weiß, mit was für Typen man es tatsächlich zu tun hat. Wenn der Compiler mir sagen kann, dass das, was ich da mache zu Verlust von Informationen führen kann, wird das Ergebnis insgesamt weniger Fehleranfällig bei Wartung oder späterer Verwendung an anderer Stelle. Zugegeben, das Zusammenspiel von Narrowing- und Promotion-Regeln ist nicht besonders ausgeklügelt aber wenn du von vornherein C++11 schreibst, ist es halb so schlimm.
Zwingt dich eigentlich irgendwer C++11 zu benutzen? Bleib doch bei C++98 und gut.
Re: Jammer-Thread
Verfasst: 31.01.2014, 10:44
von Krishty
Ja – ich brauche auto. Kann ich Clang veranlassen, das einzeln zu aktivieren?
Re: Jammer-Thread
Verfasst: 31.01.2014, 10:46
von Florian Keßeler
Keine Ahnung. Vermutlich nicht. Wobei clang ja so einiges kann...
Re: Jammer-Thread
Verfasst: 31.01.2014, 11:35
von Sternmull
glassbear hat geschrieben:
Was waere denn etwas vergleichbares fuer OS X und Linux? valgrind?
Da hab ich keine Praxiserfahrung. Das müsste wahrscheinlich was auf LD_PRELOAD-Basis sein (weiß nicht obs das unter OSX auch gibt, aber sicher was vergleichbares) um ohne angepasstem Binary auszukommen. Das Teil sollte dann einfach die Stacktraces für die Speicherallokationen protokolliert, und einem sagen welche Allokationen vom Zeitpunkt A zum Zeitpunkt B dazu gekommen sind, und die der Größe nach sortiert mit Stacktrace anzeigt.
Auf die Schnelle bin ich bei
NJAMD raus gekommen. Aber es gibt bestimmt auch gepflegte Alternativen. Nach einem kurzer Blick auf die Valgrind-Doku hab ich den Eindruck das die Leak-Analyse dort etwas beschränkter ist (nur Sachen die beim Beenden des Prozessen nicht freigegeben wurden gelten als Leak, wenn Jemand versehentlich eine Liste mit Schrott befüllt, die am Ende aber sauber freigibt, wäre das für Valgrind wohl ok).
Re: Jammer-Thread
Verfasst: 31.01.2014, 16:56
von glassbear
Sternmull hat geschrieben:glassbear hat geschrieben:
Was waere denn etwas vergleichbares fuer OS X und Linux? valgrind?
Da hab ich keine Praxiserfahrung. Das müsste wahrscheinlich was auf LD_PRELOAD-Basis sein (weiß nicht obs das unter OSX auch gibt, aber sicher was vergleichbares) um ohne angepasstem Binary auszukommen. Das Teil sollte dann einfach die Stacktraces für die Speicherallokationen protokolliert, und einem sagen welche Allokationen vom Zeitpunkt A zum Zeitpunkt B dazu gekommen sind, und die der Größe nach sortiert mit Stacktrace anzeigt.
Um mal auf meine eigene Frage zu antworten: tcmalloc aus den Google Perftools. Benutz ich andauernd, funktioniert halt und ist im Hintergrund :lol: Voellig vergessen...
Re: Jammer-Thread
Verfasst: 02.02.2014, 17:34
von TDK
Grad ne episch perfekte Atmosphären-Szene aus dem Fenster gehabt, warum Wolken als Cluster betrachtet werden sollten...
aber ich war zu langsam, um ein Foto zu machen ;(
Re: Jammer-Thread
Verfasst: 03.02.2014, 12:25
von Krishty
Grrrrnnnnnngh gibt es einen Grund warum Direct3D-Texturwürfel linkshändig sind oder ist das nur um mich zu ärgern
Re: Jammer-Thread
Verfasst: 03.02.2014, 12:33
von Tiles
War da nicht was von wegen left handed und right handed coordinate system? :)
http://www.evl.uic.edu/ralph/508S98/coordinates.html
Re: Jammer-Thread
Verfasst: 03.02.2014, 12:39
von Krishty
Ja – bei Direct3D zeigt die X-Achse des Würfels nach rechts; die Y-Achse nach oben; die Z-Achse vom Betrachter weg – also linkshändig. So ein Schmarrn; eigentlich arbeitet alles rechtshändig.
Es wird noch verwirrender wenn man sich vergegenwärtigt, dass deren Textur-Achsen nach rechts und unten zeigen. Unter diesen Voraussetzungen hätte ein Texture Cube seine Z-Achse zum Betrachter hin gerichtet. Und die Krone sind Volumentexturen: Die werden nämlich plötzlich rechtshändig adressiert.
Kurz: Texturen sind linkshändig. Texturwürfel sind linkshändig aber 180° gedreht. Volumentexturen sind rechtshändig. Wer zur Hölle hat das spezifiziert?!
(Quelle:
MSDN – Einführung in Texturen in Direct3D 11 (Windows))
Nachtrag: Offenbar ist es in OpenGL genau so verwirrend:
StackOverflow: Convention of faces in OpenGL cubemapping
Re: Jammer-Thread
Verfasst: 06.02.2014, 16:46
von glassbear
Welche Visual Studio-Version nimmt man denn heutzutage am besten?
Brauche 64Bit Builds, sonst nicht wirklich irgendwas. Funktionierender Debugger waer toll, nicht so wie CDT...
Re: Jammer-Thread
Verfasst: 06.02.2014, 17:22
von dot
glassbear hat geschrieben:Welche Visual Studio-Version nimmt man denn heutzutage am besten?
Die aktuellste, das wäre im Moment 2013... ;)
Re: Jammer-Thread
Verfasst: 06.02.2014, 17:32
von glassbear
dot hat geschrieben:glassbear hat geschrieben:Welche Visual Studio-Version nimmt man denn heutzutage am besten?
Die aktuellste, das wäre im Moment 2013... ;)
Muss man die 64Bit Compiler dann noch haendisch nachinstallieren oder hat sich das mittlerweile erledigt (Express Editions)?
Naja, erstmal Internet Explorer 10 installieren. Und wer weiss, was dann noch alles :roll:
Re: Jammer-Thread
Verfasst: 06.02.2014, 17:37
von dot
glassbear hat geschrieben:Muss man die 64Bit Compiler dann noch haendisch nachinstallieren oder hat sich das mittlerweile erledigt (Express Editions)?
Das war in den ersten Express Editions (2005, 2008 iirc) so, hat sich seither aber erledigt. Visual Studio 2013 Express for Windows Desktop ist alles, was du brauchst, um glücklich zu werden. ;)
glassbear hat geschrieben:Naja, erstmal Internet Explorer 10 installieren. Und wer weiss, was dann noch alles :roll:
Das Problem sollte sich mittlerweile eigentlich erledigt haben, aber ka ob das auch für die Express Edition gilt:
http://blogs.msdn.com/b/buckh/archive/2 ... er-10.aspx
Re: Jammer-Thread
Verfasst: 06.02.2014, 17:48
von glassbear
Genau den Screen hatte ich bei der Installation auch gerade... Gefixt seit November :roll:
Re: Jammer-Thread
Verfasst: 13.02.2014, 17:12
von Schrompf
Grade mal wieder ein bisschen am Portieren meines Uralt-Spieles. Und da findet man z.B. solche Code-Stückchen:
Ich wundere mich bis heute, dass wir damals ein Spiel bis zum Release bekommen haben. Und jetzt habe ich Angst, die Zeile zu entfernen, weil sich evtl. irgendwo jemand darauf verlässt.
Re: Jammer-Thread
Verfasst: 14.02.2014, 13:15
von Krishty
Warum? Negative Indizes verwende ich auch dauernd; vor allem bei sowas wie Kompression. So lange das kein out-of-bounds-Zugriff ist, ist doch alles wohldefiniert.
Re: Jammer-Thread
Verfasst: 14.02.2014, 13:46
von Schrompf
In dem Fall ist es aber Out Of Bounds mit Anlauf :-)
Re: Jammer-Thread
Verfasst: 19.02.2014, 12:40
von Krishty
Garbage Collector + nicht-Systemspeicher-Ressourcen … m[
25 Sekunden bis der Grafikspeicher voll war. Stolze Leistung!
Re: Jammer-Thread
Verfasst: 22.02.2014, 19:51
von antisteo
Der Raspberry PI funktioniert nicht mit allen SD-Karten-Herstellern. Insbesondere nicht die ältere China-Variante. Ich muss jetzt 35 SD-Karten retour schicken und vorher wieder formatieren. Außerdem muss ich neue SD-Karten von irgendwo her zusammenkaufen und zwar noch bevor die Luft anbrennt.
Re: Jammer-Thread
Verfasst: 24.02.2014, 17:30
von Krishty
tbl->val = utf16FromInt(atoi(ansiFromUTF16(tbl->val.c_str())))
Y O U W A N N A F U C K W I T H M E
Re: Jammer-Thread
Verfasst: 27.02.2014, 10:51
von joggel
Mal jammern über mich selber.
Als ich anfing meinen Shooter zu schreiben habe ich das alles im KO-System des Screens, also in Pixel, gerechnet.
So zwischen drinnen dachte ich mir, dass es nicht schlecht sei wenn ich das Spielfeld und alles was sich darin
befindet im bereich von [0..1.0f,0..1.0f] bearbeite und dann nur beim Zeichnen auf das KO-System des Screen skaliere.
Vorteil:
Die Fenstergröße kann wärend des Spiels geändert werden... sofern ich das irgendwann mal will^^
Toll:
Jetzt habe ich hier ein gemisch von Werten die sich mal im KO-System des Screen befinden, und manche die sich im KO-System von [0..1.0f,0..1.0f] befinden.
:? :?
Re: Jammer-Thread
Verfasst: 27.02.2014, 12:58
von antisteo
Definiere dir dein eigenes Koodinatensystem und baue eine Funktion, die jede Koordinate in Pixel umrechnet. Dann kannst du den Code jederzeit austauschen, falls du dich anders entscheidest.
Re: Jammer-Thread
Verfasst: 27.02.2014, 14:08
von joggel
Ja, fürs nächste mal ziehe ich das konsequent von anfang durch...