Auf dem Weg von DDraw nach OpenGL ..

[HeinzK]

operator += habe ich schon in der o.a. Schreibweise in Verwendung.

Code: Alles auswählen

sKa = sKb + "A" + "B" + "C";  //> OK:
sKa = "A" + sKb + "B" + "C";  //> Funktioniert nicht:

[Schrompf]

Die zweite Zeile verlangt zuerst nach einem operator + (const char*, const kstring&) - hast Du einen solchen Operator definiert?

[HeinzK]

Aha, einen operator + mit zwei Argumenten! .. Hab' ich noch nicht .. aber gleich ... Danke!

[Aramis]

Sollte nicht notwendig sein solange der Konversionskonstruktor KCString(const char*) existiert, erreichbar ist und nicht als explizit deklariert wird. Siehe mein Beispiel, der darin aufgeführte operator+ genügt.

Code: Alles auswählen

CKString operator+ (const CKString& a, const CKString& b) {}

Wichtig! Dieser Operator darf *nicht* als gebundene Memberfunktion deklariert sein, weil sonst keine implizite Konversion fuer den impliziten this-Parameter zum Einsatz kommt.

[Schrompf]

Alle + Operatoren und Artverwandte haben zwei Operanden. Aber wenn Du den Operator innerhalb der Klasse definierst, wird der erste Operand automatisch als die Klasse selbst angenommen. Sowas hier:

Code: Alles auswählen

// Variante 1
class Bla
{
  Bla operator + (const Bla& dasAndereBla) const;
}

// ist gleichwertig mit einem freien Operator der Art
Bla operator + (const Bla& dasEineBla, const Bla& dasAndereBla);

Wenn Du jetzt einen operator + (const char*, const Bla&) brauchst, müsstest Du den als Variante 1 in der Klasse char* definieren... das geht natürlich nicht. Daher musst Du den als Variante 2, nämlich als freien Operator, definieren.

[HeinzK]

Ich meinte es verstanden zu haben, aber es geht noch nicht ..

Code: Alles auswählen

//> *.h, nach der Klassendeklaration:
//> Freie operatoren:
CKString operator + (const char *cStr, const CKString &sKStr) const;
//> *.cpp, nach der Klassenimplementation:
//> Freie Operatoren:
CKString operator + (const char *cStr, const CKString &sKStr) const
{
  string sS(cStr);
  sS.append(sKStr.GetcStr());
  return sS;
}

Fehlermeldung:
error C2270: '+': Modifizierer für Funktionen, die keine Memberfunktionen sind, nicht zulässig

[Biolunar]

Da es sich um globale Funktionen handelt macht das 'const' am Ende nach der eigentlichen Funktions-Deklaration/Definition keinen Sinn.

[HeinzK]

Super, das war's, nun funktioniert alles wie gewollt .. Danke.

[HeinzK]

Noch ein Rätsel ..

Code: Alles auswählen

string k_sStr;
const char *CKString::GetcStr(void) const
{
  return k_sStr.c_str();
}
string CKString::Format(const CKString &sKStr, ...)
{
  const char *pFrm = sKStr.GetcStr();
  va_list Argm;
  va_start(Argm, pFrm);
  k_sStr = KFormatArgmList(pFrm, Argm);
  k_iStrLen = k_sStr.length();
  va_end(Argm);
  return k_sStr;
}
string CKString::Format(const char *pFrm, ...)
{
  va_list Argm;
  va_start(Argm, pFrm);
  k_sStr = KFormatArgmList(pFrm, Argm);
  k_iStrLen = k_sStr.length();
  va_end(Argm);
  return k_sStr;
}
//> Einsatz:
CKString sK1;
CKString sK2 = "\nTest: %0.2f";
sK1.Format(sK2, 100.0);   //> Fall1:
sK1.Format(sK2.GetcStr(), 100.0); //> Fall2:
sK1.Format("\nTest: %0.2f", 100.0); //> Fall3

Nur Fall1 funktioniert nicht. Kann es sein, das in

k_sStr = KFormatArgmList(pFrm, Argm);

pFrm und Argm unbedingt Funktionsparameter sein müssen?
Also das pFrm nicht innerhalb der Funktion definiert werden kann?

[Aramis]

Davon ausgehend dass KFormatArgmList unefaehr so aussieht:

CKString KFormatArmList(const char*, va_list&);

: Nein. Aber ich wuerde va_start richtig aufrufen :-)

Code: Alles auswählen

va_start(Argm, pFrm); // sollte wohl eher sKStr anstelle von pFrm sein

Btw, das ganze ist ein wunderschoenes Beispiel fuer Copy'n'Paste-Fehler :-)

[HeinzK]

Genau waren es zwei Probleme. Ich hatte den Mechanismus von va noch nicht verstanden.
Also, erstens hast du Recht (sKStr statt pFrm) und zweites darf es nicht &sKStr heissen.
Danke für die Infos .. nun läufts ...

[HeinzK]

Mir fehlt die Erfahrung um folgendes richtig zu entscheiden:

Code: Alles auswählen

class CKString
{
  public:
    CKString(void);
    CKString(const CKString &sKStr);
    CKString(const string &sStr);
    CKString(const char *cStr);
    virtual ~CKString(void);
    // ...
    int Compare(const CKString &sKStr) const;
    //> int Compare(const string &sStr) const;
    //> int Compare(const char *cStr) const;
    // oder
    bool operator == (const CKString &sKStr) const;
    //> bool operator == (const string &sStr) const;
    //> bool operator == (const char *cStr) const;
    // ...
};

Ist es sinnvoll die zusätzlichen Funktionen (string, char) zu definieren, oder nicht?

[Aramis]

Ja und Nein. Notwendig sind sie nicht! Fuer's Protokoll, die genaue Vorgehensweise des Compilers beim Aufruf einer Funktion ('overload resolution'):

Der Compiler ermittelt beim Aufruf einer Funktion (also auch eines Operators) erstmal alle moeglichen Kandidaten (d.h. alle gleich benannten Funktionen im aktuellen Namensraum sowie den via ADL erreichbaren). Danach versucht er, fuer jede dieser Funktionen moegliche Konversionen fuer die Parameter zu finden: er geht alle Parameter von links nach rechts durch und ermittelt eine Art "Rang", der angibt wie muehsam die Konversion ist. Danach nimmt er die Funktion mit dem niedrigsten Rang - gibt es davon 2 oder mehr, ist der Aufruf mehrdeutig. Auf die gefundene Funktion wendet er dann Zugriffskontrolle an, sie muss erreichbar sein.

Jetzt auf deinen Fall bezogen:

Code: Alles auswählen

CKString s;
bool b = s == "Hi!"; 

Falls er existiert wird hier der genau passende bool CKString :: operator == (const char *cStr) const; aufgerufen (Rang 0, keine Konversion notwendig). Existiert er nicht, so wird bool CKString :: operator == (const CKString &sKStr) const; aufgerufen, wobei der const char* implizit nach CKString konvertiert wird - dies ist moeglich, da der sog. Konversionskonstruktor CKString(const char *cStr); existiert, erreichbar ist und nicht als explicit deklariert ist (ein relativ hoher Rang, benutzerdefinierte Konversionen aufzurufen versucht der Compiler zu vermeiden, aber es gibt keine andere Alternative in dem Fall).

Dennoch kann es sinnvoll sein solche, eigentlich unnoetigen Operatoren zu implementieren: ich nehme an dein CKString erstellt eine Kopie des Strings in einem neuen Speicherbereich, der via malloc,new,… alloziert wird. Dementsprechend würde im obigen Beispiel - wenn der CKString == const char*-Operator nicht definiert ist voellig umsonst eine temporaerer CKString erstellt.

Durch die 'Spezialisierung' der bereits fuer die meisten Faelle implementierten Vergleichsfunktion fuer diese Spezialfaelle erreichst du also deutlich hoehere Performance. Bei einer String-Klasse haette ich daher dazu tendiert diese Operatoren tatsaechlich zu implementieren.

Was mich aergert ist aber folgendes: 2 Leute (Schrompf und Ich) haben dir in zusammen mindestens 4 Postings geschrieben, dass Operatoren wie operator== ausserhalb der Klasse gehoeren, weil sonst keine implizite Konversion fuer den ersten Parameter stattfinden kann (bool CKString :: operator == (const CKString &sKStr) const sieht der Compiler ja intern als bool operator == (const CKString* const this, const CKString &sKStr), d.h. der this-Pointer ist einfach der implizite erste Parameter. Fuer diesen wird aber *keine* implizite Konversion durchgefuehrt. Mit deiner String-Klasse wuerde also CKString s ;"hi!" == s in Wahrheit wieder den CKString-Konversionskonstruktor auf "hi" aufrufen anstelle die optimierte Variante fuer const char* == CKString - und das, ohne dass du es bemerken wuerdest).

[HeinzK]

Was mich aergert ..

Tschuldigung, aber ich verstehe jetzt erst die Zusammenhänge .. der Worte hab' ich wohl vernommen, aber der Sinn ist nicht vorbeigekommen ..
Ich habe bisher noch nie mit Operatoren gearbeitet. Zwar habe ich eine Menge darüber gelesen, aber man muss
damit arbeiten (testen, spielen), um die ganze Wahrheit zu erkennen. Vielen Dank für die ausführliche Info (s.o.)!

[HeinzK]

:D .. Mädels und Jungs .. :D .. Hurra .. :D
====================================
Ich habe gerade das 1. ZwiAner-Level unter SDL-Grafik (Fullsreen) gespielt! Läuft super .. später mehr .. (02.08.2010 20:44) ..
PS:
Weiteres Hurra .. gerade das 1. ZwiAner-Level unter OpenGL (800/600) gespielt (02.08.2010 21:11).
Es ist 21:48 02.08.2010, auch das 'alte', bewährte DDraw (Fullscreen) läuft im neuen Gewand .. puuhhh!

[HeinzK]

Meine momentane Lösung für drei unterschiedliche Grafikmethoden:

Code: Alles auswählen

//.. aus der stdafx.h:
//>
//> Grafik-Methoden:
//> 
#define ZWIANER_DDRAW "DirectXDDraw"
//> #define ZWIANER_WIN32OPENGL "Win32OpengGL"
//> #define ZWIANER_WIN32SDL "Win32SDL"
//.. aus der main.cpp:
CKDDraw *g_pKDDraw = (CKDDraw *)NULL;
CKOpenGL *g_pKOpenGL = (CKOpenGL *)NULL;
CKSDL *g_pKSDL = (CKSDL *)NULL;
#ifdef ZWIANER_DDRAW
  CKDDraw *GetgpKGrafik(void)
  {
    return g_pKDDraw;
  }
  void DeleteKGrafik(void)
  {
    delete g_pKDDraw;
    g_pKDDraw = NULL;
    
  }
#else
  #ifdef ZWIANER_WIN32OPENGL
    CKOpenGL *GetgpKGrafik(void)
    {
      return g_pKOpenGL;
    }
    void DeleteKGrafik(void)
    {
      delete g_pKOpenGL;
      g_pKOpenGL = NULL;
      
    }
  #else
    #ifdef ZWIANER_WIN32SDL
      CKSDL *GetgpKGrafik(void)
      {
        return g_pKSDL;
      }
      void DeleteKGrafik(void)
      {
        delete g_pKSDL;
        g_pKSDL = NULL;
        
      }
   #endif
 #endif
#endif
//.. 
int APIENTRY _tWinMain
             (
               HINSTANCE hInst,
               HINSTANCE hPrevInstance,
               LPTSTR    lpCmdLine,
               int       nCmdShow
             )
{
  //..
  #ifdef ZWIANER_WIN32SDL
    g_pKSDL = new CKSDL
                  (
	            hInst,
	            SDL_INIT_VIDEO,
	            g_bHgAlt
	          );
    if (g_pKSDL != NULL)
    {
      g_hInst = g_pKSDL->GethInst();
      g_hWnd = g_pKSDL->GethWnd(); 
    }
  #else
    #ifdef ZWIANER_WIN32OPENGL
      g_pKOpenGL = new CKOpenGL
	               (
	                 hInst,
	                 800,
	                 600,
	                 WndProc,
	                 g_bHgAlt,
	                 1
	               );
      if (g_pKOpenGL != NULL)
      {
        g_hInst = g_pKOpenGL->GethInst();
        g_hWnd = g_pKOpenGL->GethWnd();
      }
    #else
      g_pKDDraw = new CKDDraw
    	              (
    	                hInst,
    	                nCmdShow,
    	                g_iPix,
    	                g_bHgAlt,
    	                WndProc,
    	                1
    	              );
    	                
      if (g_pKDDraw != NULL)                
      {
        g_hInst = g_pKDDraw->GethInst();
        g_hWnd = g_pKDDraw->GethWnd();	                
        
      }                  
    #endif
  #endif
  if 
  (
    (GetgpKGrafik() != NULL)
    &&
    (GetgpKGrafik()->GetbAllesOK() == true)
    //..
  //..

Ab hier wird nur noch über GetgpKGrafik() zugegriffen.
Alle public-Routinen von DDraw/OpenGL/SDL bieten in der jeweiligen Klasse eine für alle konstante Schnittstelle. Was die einzelnen Grafikmethoden im Detail machen, interessiert mich bei der weiteren Spielentwicklung nicht mehr.
Hinweis für gcc/Linux Anwender:
Unter VS ist im Quelltext schön zu sehen, welcher Teil gerade aktiv ist.

[kimmi]

Ist das Device bereits ein Interface, von denen die konkreten Implementierungen dann erben? Wenn nein: das macht den Code dann noch einfacher wartbar. Die Generierung der entsprechenden Instanz könntest du dann beispielsweise von einer Factory erzeugen lassen.

Gruß Kimmi

[Schrompf]

Solche Entscheidungen (Linux/OpenGL vs Windows/DDraw) sind doch keine Laufzeitentscheidungen, sondern Buildkonfig. Das als Interface zu gestalten, von dem die Implementationen ableiten, ist nur Verschwendung von Rechenzeit. Ein wirklich abstraktes Interface zum System sollten Klassen und Schnittstellen sein, die auf allen Plattformen identisch aussehen und identisches Verhalten bieten, und sich nur intern in ihrer Implementation je nach Plattform unterscheiden.

[kimmi]

Wenn es sich wirklich nur um Build-Konfigurationen handelt, ist das richtig. Ich persönlich abstrahiere das per Interface, um die Koppelung zwischen konkreter Implementierung und dem dahinterliegenden OpenGL- / D3D- / SDL-spezifischen Code möglichst gering zu halten. Gerade wenn man zwischen OpenGL und D3D unter Windows umschalten will, kann das Sinn machen, da man in der Regel keine 2 Executables für D3D oder OpenGL ausliefern will. Und will man per Mock-Object den Kram für Testsuiten testbar machen ( was bei mir eine Anforderung ist ),ist ein Interface hilfreich. Dafür muß ich dann den Performanceverlust halt in Kauf nehmen.
Aber prinzipiell stimme ich dir da zu, da kann man was sparen!

Gruß Kimmi

[HeinzK]

Langsam, so schnell komm' ich bei euch heute morgen noch nicht mit.
Es ist gewiss keine Laufzeitentscheidung geplant. Es sind ja #define/#ifdef Konstruktionen.
Auf was ich hinaus will, ist folgendes: Sowenig Redundanz wie möglich. Und im Moment bin
ich ja noch am Testen. Unter Windows werden ich wahrscheinlich bei DDraw bleiben (solange es funktioniert) und
bei Linux werden ich vielleicht nur SDL verwenden. ??? :? ???

[kimmi]

Dann bist du gut davor. Interfaces helfen nur, wenn du zur Laufzeit entscheiden mußt, welche konkrete Implementierung du brauchst.

Gruß Kimmi

[Biolunar]

Gibt es eigentlich einen Grund warum du unter den verschiedenen Plattformen verschiedene Backends verwenden möchtest? Wie du selbst siehst hast du dadurch einen imensen Mehraufwand...

[HeinzK]

Gebranntes Kind? Vistageschädigt? Kein Vertrauen mehr in die Zukunft vorhandener Software? Reiz des Neuen?
Ich will mein Programm auf Linux portieren. Auch meine Firma 'liebäugelt' in diese Richtung. Und da will ich den
Anschluss nicht verpassen. Eigentlich wollte ich ja nur OpenGL einsetzen, aber dort wird meine Methode nicht von allen Grafikkarten unterstützt.
Warum dann der Aufwand mit SDL und OpenGL auf Windows? Hier habe ich ein Programm das bisher fehlerfrei funktioniert
(so weit man das bei Software je wissen kann). Unter Linux rechne ich noch mit vielen Überraschungen! Wenn ich das gleiche
Grafiksystem auf Windows und Linux habe (SDL/OpenGL) kann ich Fehlerquellen besser lokalisieren.

[HeinzK]

SDL:
1. Problem beim Debuggen (Remote). Das Fenster bekommt beim Öffnen nicht immer den Fokus. Im Release-Modus scheint es aber zu funktionieren. D.h. es kommt unter die anderen offenen Fenster. Gibt es da eine Lösung (SetFocus(hWnd) funkt nicht)?
2. Das Fenster öffnet sich Kaskadenartig immer an einer anderen Position. Läßt sich das schon beim Anlegen irgendwie beeinflussen?

[kimmi]

Zu 1.: Hast du schon mal SetForeGroundWindow probiert? Hier ist die Funktion dokumentiert: http://msdn.microsoft.com/en-us/library ... 85%29.aspx . Ansonsten lies dir mal die Doku der Funktion SDL_ActiveEvent durch.
zu 2.: Da würde ich ebenfalls SDL_ActiveEvent benutzen.

Gruß Kimmi

[glassbear]

2. Das Fenster öffnet sich Kaskadenartig immer an einer anderen Position. Läßt sich das schon beim Anlegen irgendwie beeinflussen?

Google - Erster und zweiter Hit.

Und unter Linux lässt sich das nicht weiter beeinflussen, da der Window Manager die Positionierung übernimmt und der sagt, wo es lang geht...

[HeinzK]

Testaufruf für DDraw, OpenGL und SDL unter Windows: http://www.zwianer.de/$PCSpiel$/Problem ... afikEn.htm
Download(Installation): http://www.zwianer.de/Download/ZwiAner4GrafikEn.exe
Download(Archiv):http://www.zwianer.de/Download/ZwiAner4GrafikEn.zip
Meine 'Grafik-Engine' ist nun so umgebaut, dass ich wahlweise DDraw, OpenGL oder SDL nutzen kann.
Die Linux-Version steht kurz vor dem Durchbruch .. nur .. leider fehlt mir im Moment die 'Freizeit' für's Hobby. Aber ich bleib dran!

Aufruf: Bitte installiert und testet den 'Download' auf möglichst vielen Windowsplattformen/Grafikkarten. Es wäre 8-) von euch, danke.


Bei den Testroutinen handelt es sich um leicht abgwandelte Bildschirmschoner (meine ganz privaten, fleißigen Programmtester).
T1(...) Alle möglichen Objekte (Astroiden, Planeten, Gravitatoren, Frachter und Co.) werden per Zufall
(Ort, Richtung, Geschwindigkeit) verteilt .. und .. die Gravitation nimmt ihren Lauf!
T2(...) Hier werden per Zufall 'Sonnensysteme' (Eine Sonne, Doppelsystem und 3 Sonnen) mit zufälligen
Planeten und Asteroiden getestet.
Als Vorbereitung für Linux sind die neuen Klassen aktiv: KString, KFile, KZeit, KZeichnen, KPixeln, KVector.
Es fehlt eigentlich nur noch als Fleißarbeit der Umbau der restlichen CPtrList, CPtrMap und Co's. Dann brauch'
ich nur noch einen Ersatz für DDInput und DDSound .. und .. ZwiAner läuft auch auf Linux!

[Gelöschter Benutzer 2]

Betriebssystem: Windows 7 64 Bit

In CPU (Core i5 Mobil) integrierte Grafikkarte:
Version 1:
DDraw: Vollbild, scheint alles richtig dargestellt zu werden aber leider flimmerts die ersten 2 bis 3 Sekunden + man sieht kurz das Gittermodell.
OpenGL: Fenster welches deutlich kleiner ist als im Vollbild, so dass die Objekte alle recht gequetscht aussehen. Und die Partikel die es bei DDraw zu sehen gibt sind praktisch fast nicht vorhanden und sind nur weiße Punkte die kurz für eine halbe Sekunde etwa aufblitzen. Auch sieht man hier kurz am Anfang wieder das Gittermodell.
SDL: Wieder ein kleines Fenster, wieder kurz das Drahtgittermodell sichtbar ansonsten keine Probleme. Hatte den Eindruck, dass das irgendwie schnellsten lief.

Version 2:
DDraw: Einziges Probleme ist dass das Objekte in der Mitte (die Sonne?) bei manchen Starts komisch aussieht und zwar dass es ein Punkt mit einem Kreis drumherum ist und nicht ausgefüllt wie normalerweise sonst. Ansonsten keine Probeleme (Kein Flimmern und kein Gittermodell).
OpenGL: Das selbe wie bei DDraw nur im Fenster und wieder das selbe Problem mit den Partikel, einige sind nur Weiße (zu große?) Kreise die kurz sichtbar sind und bei Explosionen gibt es nur kurz ein aufploppen und dann sind die Partikel sofort wieder weg und nicht so wie bei DDraw.
SDL: Wieder Fenster. Ist diese Unmenge an Partikeln verglichen zu DDraw wirklich gewollt? Das ist ja ne richtig Explosionsflut. Und wieder der Eindruck dass es am schnellsten lief.

Radeon HD5650 Mobil (Der verwendete Treiber basiert glaub auf dem 10.6 Treiber, es ist ein an Switchable mit der Intel Grafikkarte (Intel Treiber sind enthalten) angepasster Treiber):
Version 1:
DDraw: Das selbe wie mit der Intel.
OpenGL: Das selbe wie mit der Intel nur dass man nun auch Partikel zu Geschicht bekommt die nicht sofort gleich wieder verschwinden.
SDL: Das selbe wie mit der Intel nur dass es nun nicht so aussieht, dass SDL schneller wäre sondern gleich schnell wie mit den anderen beiden.

Version 2:
DDraw: Das selbe wie mit der Intel auch wieder manchmal mit diesem Punkt und Kreis als Sonne.
OpenGL: Da gibt es aber ne ganze Menge Partikel, die durch die Gegend fliegen. Bei DDraw scheinen sie von der Sonne wieder angezogen zu werden und bei OpenGl davon abgestoßen zu werden. Auch scheinen allgemein die Planeten Bewegungen bei OpenGL trotz mehrmaligem starten deutlich Träger zu sein als bei DDraw. Die Punkt / Kreis Sonne gibts hier wieder manchmal.
SDL: Wie DDraw nur in ruckelig (also bei den schnellen Bewegungen der Partikel fällt es einem auf).

Also am Besten funktioniert wohl DDraw. Kompatiblität ist bei SDL auch in Ordnung aber gerade bei richtigen (nicht Intel) Grafikkarten hinkt die Performance den anderen beiden hinterher. OpenGl mach halt vor allem bei der Intel irgendwie Probelme.

[Jonathan]

Als Vorbereitung für Linux sind die neuen Klassen aktiv: KString, KFile, KZeit, KZeichnen, KPixeln, KVector.
Es fehlt eigentlich nur noch als Fleißarbeit der Umbau der restlichen CPtrList, CPtrMap und Co's. Dann brauch'
ich nur noch einen Ersatz für DDInput und DDSound .. und .. ZwiAner läuft auch auf Linux!

Hm, wieso braucht man eine KString und KVector Klasse, um plattformunabhängig zu sein? Was ist mit den Containern aus der STL?

[Jonathan]

Bitte packt das ganze doch ein ein Archiv, ich hasse es Dinge installieren zu müssen, die ich vermutlich nicht lange nutzen werde (ich vertrau diesen Installern einfach nicht, dass mein System danach wieder sauber ist, außerdem sind zip-Dateien dann doch schneller extrahiert und anschließend wieder gelöscht).