Jammer-Thread

[Krishty]

Warum sollte ich das machen? In Funktionen schreibt man nur Dinge rein, die sich wiederholen. Jede Funktion, die nur einmal aufgerufen wird, muss __forceinline gemacht werden, damit man sich nicht völlig sinnlos den Overhead eines Funktionsaufrufs einhandelt.

Klar ist ein überflüssiger Funktionsaufruf was anderes als 60 MiB Speicherunkosten, aber so oder so baut der Compiler da unnötig scheiße.

[antisteo]

Reden wir über Javascript: The World's Most Misunderstood Programming Language

Code: Alles auswählen

var status = {};
status.foo = {}; // soweit so gut..
status.foo.bar = 3; // Uncaught TypeError: Cannot set property 'bar' of undefined - ouch

Und, den Fehler schon gefunden? Vermutlich nicht. Tipp: Globale Variablen und keywords

Code: Alles auswählen

$ node
> var status = {};
undefined
> status
{}
> status.foo = {}
{}
> status
{ foo: {} }
> status.foo.bar = 3;
3
> status
{ foo: { bar: 3 } }
> 

[kaiserludi]

Warum sollte ich das machen? In Funktionen schreibt man nur Dinge rein, die sich wiederholen. Jede Funktion, die nur einmal aufgerufen wird, muss __forceinline gemacht werden, damit man sich nicht völlig sinnlos den Overhead eines Funktionsaufrufs einhandelt.

Klar ist ein überflüssiger Funktionsaufruf was anderes als 60 MiB Speicherunkosten, aber so oder so baut der Compiler da unnötig scheiße.

Warum du das machen solltest? Weil man manchmal nun mal einfach das kleinere Übel wählen sollte, um sich das große zu ersparen. Ist quasi ein Workaround.

[Krishty]

AUA

Visual C++ hat wieder eine verpasste Optimierung: switches, bei denen nur eine einziger Möglichkeit angesteuert wird, werden nicht zu ifs optimiert:

    switch(type) {
        case 0:
            assert(is_really_type_0());
            break;
        case 1:
            assert(is_really_type_1());
            break;
        case 2:
            assert(is_really_type_2());
            break;
        default:
            __debugbreak();
    }
    foo();

Da assert() im Release-Build verschwindet, steht dann dort:

    switch(type) {
        case 0:
        case 1:
        case 2:
            break;
        default:
            __debugbreak();
    }
    foo();

und das entspricht:

    if(2 < type) {
            __debugbreak();
    }
    foo();

Dummerweise behandelt Visual C++ das weiter als switch und legt – noch viel schlimmer – eine Sprungtabelle an, bei der alle Einträge auf die Zeile foo(); verweisen:

    movsxd rax,type
    cmp    eax,2
    ja     0140001941h ; __debugbreak()
    lea    rbx,[__ImageBase]
    mov    eax,dword ptr [rbx+rax*4+196Ch]
   Ratet, was dort liegt:
        13d50000
        13d50000
        13d50000
    add    rax,rbx
    jmp    rax ; Kennt nur eine Möglichkeit: die Zeile mit foo()

Wir halten also fest: Ein völlig nutzloser Sprung an eine extra dafür ausgerechnete Adresse, um dort dann die Adresse zu laden, die zur Quelle zeigt, und dorthin zurück zu springen. Und eine nutzlose Sprungtabelle gratis obendrein.

Und WTF warum wird die Sprungtabellenadresse eigentlich nicht beim Laden an __ImageBase ausgerichtet sondern zur Laufzeit ausgerechnet?! UND DIE SPRUNGTABELLE SELBER AUCH?! ICH BENUTZE NIE MEHR switch

[Krishty]

Mir wird gerade klar, dass ich mit fester Basisadresse kompiliere. Das bedeutet für mich, dass die Sprungtabelle so viel rumrechnet, weil sie auf Größe optimiert wird. Mir wird schwarz vor Augen

[spobat]

Mal wieder als webdev unterwegs, und was ich mir beim IE ansehen muss, ist alles andere als schoen.

Im folgenden ist die Rede vom IE10.
<emotional>
Eine Vielzahl *gängiger* CSS(3) Regeln ist immer noch nicht unterstützt, bei allen anderen verbreiteten Browsern ist das der Fall: Chrome, FF, O, Safari.
Eine Vielzahl *gängiger* Javascript-Bibliotheken bieten für IE nur sehr schwache Unterstützung an (wer will sich schon immer um eine Extrawurst kümmern müssen?). Beispiel jQuery und Bootstrap.
Dinge, über die man sich schon seit Jahr(zehnten) aufregt.
Der Höhepunkt aber heute bei einer einfachen png-grafik. Aber seht selbst :).


Oben links Chrome 26, rechts IE10. PNG gibt es nun seit 17 Jahren, und Microsoft hat es nicht geschafft, diese ordentlichen zu rendern. Chrome, FF, Opera und Safari tun das pixelgenau und teilweise plattformunabhängig.
Ich habe jetzt den Schluss gefasst, IE gar nicht zu unterstützen. Dieses Webbrowser-Manko war nur die Krönung von vielen negativen Aspekten, die mich an Microsoft schon seit langem stark nerven. Ich versuche diesen "Konzern" in Zukunft so weit es geht zu vermeiden, denn bis auf C# (und VS) habe ich seit sehr langer Zeit keine guten Produkte mehr von denen gesehen. In 2 Monaten kommt gott sei dank das gesponsorte MacBook Pro Retina. Ich hoffe mit der "Apple Technologie" mehr Freude zu haben :)!

[Krishty]

Ich glaube, bei IE werden *alle* Bilddateien falsch gefiltert. GIFs sind dort die Katastrophe schlechthin. Ich kann es mir bis heute nicht erklären.

[anonym]

Wieso zur Hölle empfange ich die DVB-T-Frequenzen von 2DF/3sat/'noch zwei andere Sender' über eine Zimmerantenne hier im DVB-T-Zimmerantennengrenzgebiet bei sportlichen Großveranstaltungen problemlos und sonst nicht?

[Krishty]

Ich überlge, in meiner CRT bestimmte globale Variablen in eigenen Threads zu initialisieren. Anstatt dass so seriell Dateien geöffnet, Registry gelesen, und GPU-Kontext angefordert wird, geschähe das zumindest auf Makroebene parallel. Die entsprechenden Variablen wären speziell markiert.

Ich frage mich, inwieweit das überhaupt was bringen würde. Weil Windows außer dem GPU-Kontext alles cachet, ist der wahrscheinlich die eine einzige langsame Sache auf die letztendlich alles andere warten würde. Außerdem würde es RAII an sich in Frage stellen.

[Niki]

*Seufz* :evil:

Code: Alles auswählen

class SgNode
{
    protected:
        QX_INLINE void SetParentNode(SgNode * pParentNode);

    private:
        SgNode *            m_pParentNode;
};

QX_INLINE void SgNode::SetParentNode(SgNode * pParentNode)
{
    m_pParentNode = pParentNode;
}

class SgGroupNode
    : public SgNode
{
    public:
        void AppendChildNode(SgNode * pChildNode);

    private:
        typedef std::vector<SgNode *>       ChildArray;
        ChildArray                          m_children;
};

void SgGroupNode::AppendChildNode(SgNode * pChildNode)
{
    m_children.push_back(pChildNode);

    pChildNode->SetParentNode(this);
}

Natürlich gibt der Compiler die Fehlermeldung, dass SgGroupNode::AppendChildNode() nicht auf pChildNode->SetParentNode() zugreifen kann, weil pChildNode ein anderes Objekt ist. Ich verstehe ja, dass der C++ Standard das aus gewissen Sicherheitsgründen so vorgibt. In vielen Fällen ist das auch gut so. Aber es gibt auch Fälle in denen mir das so richtig auf die Nerven geht, wie z.B. im obigen Fall. Nun sehe ich zwei Lösungen:

(1) SgNode::SetParentNode() public machen. Nein, danke! Ich würde mit public gerne klar definieren auf welche Methoden der "User", ohne abzuleiten, zugreifen darf, und nicht notwendigerweise worauf eine abgeleitete Klasse zugreifen darf.

(2) SgGroupNode wird friend von SgNode. Nein danke! Wenn nun der "User" einen neuen Container-Knoten von SgNode ableitet, dann braucht er Zugriff auf SgNode::SetParentNode(). Den kriegt er aber nur wenn die abgeleitete Klasse friend von SgNode wird. Ohne Verändern der Bibliotheks-Klassendeklaration von SgNode nicht machbar.

Wie gesagt, ich seh ja irgendwo den Sinn ein. Aber einfach mal eben alles ohne Alternativen zu verbieten ist auch Dreck. Warum kann man mir da nicht wenigstens einen speziellen Zugriffs-Spezifizierer anbieten? Da vergeht mir so richtig die Lust ein sauberes Interface für den User zur Verfügung zu stellen.

[Niki]

Meine Lösung dazu ist nun folgende. Nicht ganz hübsch aber immer noch besser als friend und public.

Code: Alles auswählen

class SgNode
{
    protected:
        QX_INLINE void SetChildNodeParent(SgNode * pChildNode, SgNode * pParentNode);

    private:
        SgNode *            m_pParentNode;
};

QX_INLINE void SgNode::SetChildNodeParent(SgNode * pChildNode, SgNode * pParentNode)
{
    pChildNode->m_pParentNode = pParentNode;
}

[Schrompf]

Mach die Funktion static :-) Immerhin benutzt sie ja nix von this. Aber ich wundere mich, welcher Compiler das sein soll und welche Fehlermeldung genau Du bekommst, wenn Du den initialen Ansatz wählst. Nach meinem Wissen bezieht sich private / protected auf die Klasse, nicht auf die Instanz. Du müsstest auch von anderen Instanzen auf die Member zugreifen können, wenn Du auf die entsprechenden Member in der eigenen Instanz Zugriff hast.

[Niki]

Extra für dich nochmal eingebaut :)

1>Geometry\SgGroupNode.cpp(70): error C2248: 'SgNode::SetParentNode' : cannot access protected member declared in class 'SgNode'
1> d:\develop\chroniclesofamareth\source\amareth\geometry\SgNode.hpp(20) : see declaration of 'SgNode::SetParentNode'
1> d:\develop\chroniclesofamareth\source\amareth\geometry\SgNode.hpp(9) : see declaration of 'SgNode'

Der Compiler is VC 2010. Diese Kiste wurde vor ein paar Jahren eingeführt. Ganz früher war das kein Problem. Das nervt mich schon länger, denn auch bei SendMessage-artigem Code in einer eigenen GUI kannst du je nach Design auf dieses Problem stossen.

[Artificial Mind]

GCC 4.6 zeigt das gleiche Verhalten... Ich war eigentlich auch Schrompfs Meinung, man lernt halt nie aus ;)

[Niki]

GCC 4.6 zeigt das gleiche Verhalten... Ich war eigentlich auch Schrompfs Meinung, man lernt halt nie aus ;)

Ich bin jedes mal wieder der Meinung, und deshalb mache in den selben Fehler jedes mal :lol:

So, static gemacht, dann ist wenigstens der extra Push weg.

[Krishty]

WTF warum hat Chrome seit ein paar Tagen eine neue GUI

Wenn ich was markiere, Rechtsklick: Da, wo überall sonst auf jedem Windows-System der Welt Kopieren ist, ist jetzt … GARNICHTS



Siehe auch

Ich denke, dass jeder, der eine plattformunabhängig gleiche GUI baut, ein Vollidiot ist. Diese Kasper, die meinen, dass sich Knöpfe überall gleich bedienen lassen müssen, sind wahrscheinlich dieselbe Gattung Radikaler, die den Java-Gleitkommastandard erfunden haben, und drehen mir die Eingeweide auf links.

Ich benutze Windows. Ich will, dass sich alle Bedienelemente, die ich auf diesem System jemals befummeln muss, so anfühlen, wie ich es von Windows-Bedienelementen gewohnt bin. I'm talking Klickbereich. I'm talking Markierungsfarbe. And I'm talking Verhalten beim Wegziehen. Das gilt für GTK+, für Java-Klickibunti und alles andere da draußen auch.

Wer seine GUI so auslegt, dass sie sich überall maximal vom Rest des Systems unterscheidet und damit argumentiert, dass -1 und +1 wieder 0 ergeben, gehört öffentlich gedemütigt damit er nie wieder auf die Scheißidee kommt, sich an eine Benutzeroberfläche zu trauen.

[Schrompf]

Ich habe soeben einen kleinen Fragedialog eingebaut, der nach den ersten Schritten des Spielers aufklappt und fragt, ob man mit den Richtungstasten nun nach Himmelsrichtungen laufen will oder nach aktueller Blickrichtung des Spielers. Und um das zu testen, habe ich tatsächlich mal "Laufen nach Blickrichtung" eingestellt. Und prompt einige Minuten gebraucht, ehe ich überhaupt wieder den Trigger erwischt habe, um es zurückzustellen. Arrgh... wer bei gesundem Verstand würde in einem 2D-Spiel aus der Vogelperspektive in Charakter-Blickrichtung laufen wollen, wenn er "hoch" drückt?

[Alexander Kornrumpf]

Ich habe soeben einen kleinen Fragedialog eingebaut, der nach den ersten Schritten des Spielers aufklappt und fragt, ob man mit den Richtungstasten nun nach Himmelsrichtungen laufen will oder nach aktueller Blickrichtung des Spielers. Und um das zu testen, habe ich tatsächlich mal "Laufen nach Blickrichtung" eingestellt. Und prompt einige Minuten gebraucht, ehe ich überhaupt wieder den Trigger erwischt habe, um es zurückzustellen. Arrgh... wer bei gesundem Verstand würde in einem 2D-Spiel aus der Vogelperspektive in Charakter-Blickrichtung laufen wollen, wenn er "hoch" drückt?

Niemand. Bau den Scheiß wieder aus. Nur steuerung relativ zum Bildschirm macht in diesem Fall Sinn.

[Schrompf]

Niemand. Bau den Scheiß wieder aus. Nur steuerung relativ zum Bildschirm macht in diesem Fall Sinn.

Das sagst Du so leicht... aber ich hab das ja nicht aus Spaß eingebaut, sondern weil es *mehrere* Leute gegeben hat, die so spielen wollten. Und nein, die darf ich nicht alle maßregeln, wie es sich eigentlich gehört...

Ich würde hier eigentlich gern noch ein passendes GIF einfügen, aber ich finde grad keins.

[eXile]

Niemand. Bau den Scheiß wieder aus. Nur Steuerung relativ zum Bildschirm macht in diesem Fall Sinn.

Der Meinung bin ich eigentlich auch; vielleicht sollte man umgekehrt lieber die Kamera mit der Orientierung des Spielers mitrotieren lassen, aber ob das bei euch geht und Sinn ergibt, kann ich nicht einschätzen.

Ich würde hier eigentlich gern noch ein passendes GIF einfügen, aber ich finde grad keins.

Und um das zu testen, habe ich tatsächlich mal "Laufen nach Blickrichtung" eingestellt. Und prompt einige Minuten gebraucht, ehe ich überhaupt wieder den Trigger erwischt habe, um es zurückzustellen.

[Schrompf]

Danke, Exile. Du drückst aus, was ich nur bemeckern kann. Wir haben in der Tat erwogen, die Anzeige um den Spieler zu drehen. Das wäre nur etwas zusätzliche Arbeit beim Cullen. Allerdings würden damit einige Vorgänge in den Levels herausgefordert werden, die mit viel Handarbeit auf eine FullHD-Anzeige angepasst worden. Also so banale Sachen wie das Spawnen neuer Gegner *außerhalb* des Spieler-Sichtfeldes.

[Niki]

Hmmm... ich glaube das ist alles Geschmackssache. Ich komme bei 2D Spielen mit Latschen in Blickrichtung überhaupt nicht klar, genauso wie ich früher nicht mit den Top-Down 2D Autorennen klar kam wo man in Blickrichtung fuhr. Das ist ein bisschen wie die Frage "schaut die Kamera nach oben oder nach unten wenn ich die Maus nach hinten ziehe?"
Ich kann also nur sagen, wenn die in Blickrichtung latschen wollen, dann wollen die in Blickrichtung latschen. Ob ich damit klarkomme oder nicht ist dabei ja ziemlich schnuppe. Also ich würde es weiterhin optional halten, wenn dieses Feature erwünscht wurde.
Das ist natürlich vorausgesetzt, das ein Drehen des Spielfeldes tatsächlich nicht einfach umzusetzen ist. Obwohl... auch dabei kann man dann wieder dieselbe Diskussion anfangen, denn dann bewegst du in gewissem Sinne nicht mehr den Spieler, sondern die Welt.

[kaiserludi]

Kommt sehr aufs Spielprinzip drauf an. Ich kann so normalerweise auch nicht steuern, aber das letzte größere 2D Spiel, was ich entwickelt habe, konnte ich tatsächlich so klar am besten steuern.

[Biolunar]

Habt ihr nie GTA 1 oder 2 gespielt? Dort läuft man auch in Blickrichtung! Es ist bloß eine Sache der Gewöhnung.

[Krishty]

Gute Güte, ist RawInput anstrengend. Ich brauche sechs Werte um aus der Zahl, die mir das Gerät ausspuckt, einen Wert zwischen 0 und 1 berechnen zu können. Sechs! Weil, wenn das Betriebssystem sich um Kalibrierung kümmern würde, hätten die Anwendungsentwickler ja nix mehr zu tun und die Steuerung wäre in allen Spielen gleich; das darf ja nicht sein!

[Schrompf]

Bei unserem Splatter-Multiplayer-Testzocken hat sich gestern herausgestellt, dass je nach Framerate verschieden viele Eingabeereignisse von XInput verloren gehen. VERLOREN! Mit 4 Spielern, drei davon an GamePads, war das Steuern nur noch eine Glückssache. Das ist mir unbegreiflich.

[Edit] Aus der XInput-Doku von der MSDN:

Code: Alles auswählen

dwResult = XInputGetState( i, &state );
if( dwResult == ERROR_SUCCESS )
{ ... }

ERROR_SUCCESS - da hatte jemand Humor.

[RazorX]

Bei unserem Splatter-Multiplayer-Testzocken hat sich gestern herausgestellt, dass je nach Framerate verschieden viele Eingabeereignisse von XInput verloren gehen. VERLOREN! Mit 4 Spielern, drei davon an GamePads, war das Steuern nur noch eine Glückssache. Das ist mir unbegreiflich.

[Edit] Aus der XInput-Doku von der MSDN:

Code: Alles auswählen

dwResult = XInputGetState( i, &state );
if( dwResult == ERROR_SUCCESS )
{ ... }

ERROR_SUCCESS - da hatte jemand Humor.

Gehe ich recht der Annahme, dass das Testzocken an einem einzelnen Rechner war? Ich hatte letztes Jahr auch so ein Phänomen mit XInput und Funkempfängern von Logitech XInput-Kompatiblen Controllern. Es hatte sich nach langem ergbenislosen Debuggen rausgestellt, dass die USB Stromversorgung mit der Menge an Controllern nicht klar kam. Drei waren okay, ab vier gingen Eingaben verloren und der letzte State blieb somit aktiv. Abhilfe hatte für uns dann ein aktiver USB-Hub geschaffen.

[Schrompf]

Hm... Die drei Pads hingen alle an einem alten passiven Hub, stimmt. Allerdings passieren die Datenverluste auch mit nur einem Pad, wenn auch seltener.

[Niki]

Solltest trotzdem mal verschiedene USB Ports mit nur einem Controller ausprobieren. Ich habe für die Firma z.B. einen Laptop bei dem nur einer von vier USB Ports genug Saft hat um z.B. eine Kommunikation mit einem Smartphone herzustellen und On-Device Debuggen zu ermöglichen. Da habe ich schon mal einem halben Tag mit verplempert weil ich dachte die Treiber funzen nicht.

[Schrompf]

Das ist mir jetzt ziemlich peinlich, aber damit passt es wohl umso besser in den Jammer-Thread: der Fehler lag in einem uralten Stück Code der Input-Lib, die ich benutzt habe. Vor langer langer Zeit hat mal ein Freund für uns OIS genommen und um Input ReMapping und sowas erweitert. Und der Code hatte nun sinngemäß eine kleine Zeitbombe drin:

Code: Alles auswählen

if( absValue > 0.5f )
{
  // broadcast event to allow interactive remapping of an action
  inputHandler->OnSignificantAnalogEvent( param);
} else
{
  // propagate input event
}

Wer findet den Fehler? War damals (2004) lieb gedacht, aber das else hat effektiv dafür gesorgt, dass alle Achsen-Aussteuerungen > 0.5f vom System geschluckt wurden. Das erklärt auch die seltsamen Todpunkte in den vier diagonalen Ecken, die ich bemerkt hatte. Und es erklärt auch die Framerate-Abhängigkeit des Ausfalls: mehr Queries pro Sekunde -> bessere Chance, den Stick auf einer Zwischenposition auf dem Weg zum Extrem zu erwischen -> bessere Chance, dass das Spiel auf die Stickbewegung reagiert.

Ich bin eigentlich verdammt froh, dass ich den gefunden habe. Aber peinlich ist das schon, vorher noch so lautstark rumgemeckert zu haben.