ZFX + Developia

http://www.utf8everywhere.org/ Widerspricht dies nicht genau dem, was Krishty gesagt hat? Ja und nein. Krishty's Unix-Version ist UTF-8. Und wenn sich die WinAPI da mal ändern würde (bezweifle ich), dann würde der Ansatz auch unter WinAPI zu UTF-8 werden. Der gegebene Link ist ja ganz gut und schön...

Ich bin auch kein Fan von Code der mit Makros durchzogen ist. Aber das ist in Krishty's Post ja auch nicht so. Du hast halt irgendwo eine Header-Datei wo das einmal gemacht wird. Ausnahme ist das NATIVE(x) Makro, aber da sehe ich momentan so oder so keine andere Lösung. Überall sonst hast du NativeS...

Krishty, mein Kompliment, du hast durchaus eine gewisse Genialität! Zwar brauche ich jetzt Konvertierungen an anderen Stellen (z.B. bei Sachen wie Font-Rendering mit Wortumbruch), aber ich glaube, dass die Menge der Konvertierungen drastisch sinkt. Damit meine ich jetzt nicht die Anzahl der Konverti...

Davon abgesehen musst du eh irgendwo "konvertieren", da die OS-APIs mit char*, wchar_t* usw. arbeiten und nicht mit std::basic_string<char> usw. std::basic_string<char>::c_str() gibt den null-terminierten String zurück. Ob das immer und überall so ist, das ist natürlich fraglich, aber ich...

Also zusammenfassend: Krishty bevorzugt plattformabhängige Strings überall Berserker bevorzugt plattformunabhängige Strings mit Konvertierung beim Aufruf von Systemfunktionen Niki hat noch keine klare Meinung und versucht das Für und Wider abzuwägen, hat aber momentan eine leichte Tendenz zum plattf...

Die Frage ist halt ob es dann noch sinnvoll ist plattformabhängige String-Typen außerhalb dieser Kapselung zu verwenden oder nur innerhalb der Kapselung verschiedene String-Typen zu nutzen und dann z.B. in und von std::wstring zu konvertieren, der dann von der Schnittstelle verwendet wird. Das ist ...

Ist das nicht dasselbe wie std::wstring? Auf einem Mac, z.B. ist wchar_t 32 Bits. Aber ein typedef nach NativeString is sicher trotzdem sinnvoll. Schlagt mich tot weil ich zu wenig Linux-Erfahrung habe, aber: Afaik ist auf Linux wchar_t zwar UCS-32, aber die E/A-Funktionen wollen als Dateinamen UTF...

#ifdef WIN32 typedef wchar_t NativeChar; // Die WinAPI baut auf UTF-16 #elif defined WATEVR // UTF-8; UCS-32; oder was auch immer die Laufzeitumgebung bevorzugt #endif typedef std::basic_string<NativeChar> NativeString; Dann muss man doch aber auch den ganzen File-I/O-Krams anpassen, was man ja in ...

    #ifdef WIN32         typedef wchar_t NativeChar; // Die WinAPI baut auf UTF-16     #elif defined WATEVR         // UTF-8; UCS-32; oder was auch immer die Laufzeitumgebung bevorzugt     #endif     typedef std::basic_string<NativeChar> NativeString; … und solche rumreichen. Ist das nicht dasselbe...

Also ich weiß ja nicht was du genau vor hast aber ich glaube kaum dass ein paar Dateinamen irgendwelche Performanceeinflüsse oder Speicherprobleme verursachen könnten. Ob das nun 30 oder 120 Bytes pro Dateinamen sind ist doch wirklich egal, zumal man sowas in der Regel nicht die ganze Programmlaufz...

Es scheint mir nicht so, dass das nur auf Windows laufen soll. Oder liege ich da falsch? Momentan nur Windows. Muss aber sehr viel später auf diverse mobile Plattformen (mindestens iOS) portierbar sein. Das ist dann nochmal ein zusätzlicher Schwung Arbeit. Momentan allerdings übertreibe ich es mit ...

Achso – Refactoring. Stimmt: Da komme ich mit meinem Idealismus nicht weit. Nevermind. Es ist sehr viel Refactoring, ja. Aber sag nicht das man da mit deinem Idealismus nicht weit kommt. Du hast ja bei sehr vielen Kommentaren recht. Insgesamt geht es mir, mit Ausnahmen, mehr um das Durchreichen von...

Das behandelt aber doch schon die WinAPI für dich, oder? Ja, natürlich. Ich will das Projekt aber irgendwann mal auf andere Plattformen porten. Deshalb ist der WinAPI-Kram weggekapselt. Das heißt ich habe eine Zwischenebene wo Strings übergeben werden. Wofür? Wenn ich ein Spiel direkt implementiere...

Danke für die Antwort Krishty, Ich arbeite für eine französische Firma, die evtl. irgendwann in das Projekt einsteigt. Aus Erfahrung weiß ich, dass die keine Scheu davor haben auch mal irgendwelche diakritischen Zeichen in Dateienamen zu benutzen. Momentan benötige ich Strings um einen Ressourcen-Ma...

Oh wow... ich sehe es gibt std::u16string. Aber wie kriege ich die Konstantenzuweisung in VC 2010 besser hin?

Mein erster Ansatz wäre nun wie folgt: typedef unsigned short QxUtf16; typedef std::basic_string<QxUtf16, std::char_traits<QxUtf16>, std::allocator<QxUtf16> > QxString16; ... QxString16 s = (const QxUtf16 *)L"Hallo Welt!"; ... aber schon die Art wie ich da den konstanten String L"Hall...

Hallo Leute! Ich wollte mich mal umhören wie ihr in heutigen Zeiten mit Unicode Strings umgeht. Am liebsten würde ich UTF-16 Strings benutzen, also fällt std::string schon mal weg. Auch std::wstring fällt weg, da man es leider nicht geschafft hat die Größe von wchar_t zu standardisieren. Eine Möglic...

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 ...

Glückwunsch! Hast du jetzt also die Extraction weggeworfen, oder habe ich das falsch verstanden? Ich benutze die momentan auch nicht, da ich gerne die 8 Eckpunkte des Frustums zur Verfügung habe. Geht natürlich auch mit Ebenen schneiden, aber muss ja nicht. Auf Extraction gehe ich erst zurück falls ...

@Schrompf, da du ja eh immer alles mitliest... hast du die Möglichkeit das Tutorial zu korrigieren? Zerbie habe ich erst einmal gesehen seit ich wieder hier bin. // Nahe Clipping Plane VFrustrum[VF_N].vNormal.x = -matViewProj._13; VFrustrum[VF_N].vNormal.y = -matViewProj._23; VFrustrum[VF_N].vNormal...

Alexander Kornrumpf hat geschrieben:Bist du eine der genannten Personen?

Klaus Hartmann. Niki ist mein Spitzname.

Das mag ich fast gar nicht annehmen... :D Die Panik kann ich dir nehmen, und zwar aus folgendem Grund. Damals habe ich eine AABB Culling Demo in D3D7 geschrieben, die auch verteilt wurde. Da war mir aber ein Fehler mit der Near-Plane unterlaufen, weshalb ziemlich viele Leute einen falschen Extracti...

Also, ich mache dir 'nen Vorschlag. Wenn du's morgen Abend immer noch nicht am Rennen hast, dann mache ich hier eine D3D11 Demo, für RH und LH. Ich muss das ganz einfach selbst sehen und machen können. Erwarte dann aber bitte keinen sauberen Code. Ich würde das halt hinhacken (mit Ausnahme der Plane...

Also, ich komme so auch nicht dahinter. Ich habe zwar die Vermutung, dass die Z-Komponenten falsch sind, aber das ist nur eine Vermutung. Ich müsste schon eine Demo-App schreiben um das hinzukriegen, denn sonst bin auch ich nur am Raten. Aber ich kann dir zumindest sagen wie ich das oft visuell über...

Jetzt wo du mich auch noch fragst ob die schon transponiert sind... ja, sind sie. Eigentlich sollten die nur vor dem einspeisen in die Shader transponiert werden, oder? Dem C++ Teil sollte das wohl recht egal sein dürfen, nicht wahr? Ja, ich persönlich finde es schöner erst beim Einspeisen in den S...

Also... angenommen das Du XMMatrixPerspective*RH nimmst, und angenommen das proj und ViewMatrix von vornherein transponiert sind, dann scheint mir der Extrahierungs-Code korrekt zu sein. Dabei gehe ich jetzt einfach mal davon aus, dass sowohl die "neue Engine" als auch XMMatrixPerspective*...

Schwierig den Fehler so zu finden. Kannst du so ungefähr formulieren was nicht zu klappen scheint? Macht die Near Plane Probleme? Und wie sieht der Code aus, der die Projektionsmatrix erstellt? Was bedeutet "die neue Engine"? Heißt das, dass die Engine nicht von dir selbst ist? Du sagst si...

Artificial Mind hat geschrieben: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.

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\chr...

Meine Lösung dazu ist nun folgende. Nicht ganz hübsch aber immer noch besser als friend und public. class SgNode { protected: QX_INLINE void SetChildNodeParent(SgNode * pChildNode, SgNode * pParentNode); private: SgNode * m_pParentNode; }; QX_INLINE void SgNode::SetChildNodeParent(SgNode * pChildNod...