Seite 8 von 9
Re: Auf dem Weg von DDraw nach OpenGL ..
Verfasst: 29.07.2010, 15:57
von 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:
Re: Auf dem Weg von DDraw nach OpenGL ..
Verfasst: 29.07.2010, 16:06
von Schrompf
Die zweite Zeile verlangt zuerst nach einem operator + (const char*, const kstring&) - hast Du einen solchen Operator definiert?
Re: Auf dem Weg von DDraw nach OpenGL ..
Verfasst: 29.07.2010, 16:10
von HeinzK
Aha, einen operator + mit zwei Argumenten! .. Hab' ich noch nicht .. aber gleich ... Danke!
Re: Auf dem Weg von DDraw nach OpenGL ..
Verfasst: 29.07.2010, 16:14
von 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.
Re: Auf dem Weg von DDraw nach OpenGL ..
Verfasst: 29.07.2010, 16:14
von 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.
Re: Auf dem Weg von DDraw nach OpenGL ..
Verfasst: 29.07.2010, 16:32
von 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
Re: Auf dem Weg von DDraw nach OpenGL ..
Verfasst: 29.07.2010, 17:21
von Biolunar
Da es sich um globale Funktionen handelt macht das 'const' am Ende nach der eigentlichen Funktions-Deklaration/Definition keinen Sinn.
Re: Auf dem Weg von DDraw nach OpenGL ..
Verfasst: 29.07.2010, 17:36
von HeinzK
Super, das war's, nun funktioniert alles wie gewollt .. Danke.
Re: Auf dem Weg von DDraw nach OpenGL ..
Verfasst: 29.07.2010, 18:01
von 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?
Re: Auf dem Weg von DDraw nach OpenGL ..
Verfasst: 29.07.2010, 18:20
von 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 :-)
Re: Auf dem Weg von DDraw nach OpenGL ..
Verfasst: 30.07.2010, 07:01
von 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 ...
Re: Auf dem Weg von DDraw nach OpenGL ..
Verfasst: 30.07.2010, 08:41
von 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?
Re: Auf dem Weg von DDraw nach OpenGL ..
Verfasst: 30.07.2010, 11:00
von 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:
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).
Re: Auf dem Weg von DDraw nach OpenGL ..
Verfasst: 30.07.2010, 11:27
von 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.)!
Re: Auf dem Weg von DDraw nach OpenGL ..
Verfasst: 02.08.2010, 20:47
von 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!
Re: Auf dem Weg von DDraw nach OpenGL ..
Verfasst: 02.08.2010, 21:59
von 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.
Re: Auf dem Weg von DDraw nach OpenGL ..
Verfasst: 03.08.2010, 09:16
von 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
Re: Auf dem Weg von DDraw nach OpenGL ..
Verfasst: 03.08.2010, 09:26
von 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.
Re: Auf dem Weg von DDraw nach OpenGL ..
Verfasst: 03.08.2010, 09:43
von 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
Re: Auf dem Weg von DDraw nach OpenGL ..
Verfasst: 03.08.2010, 10:26
von 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. ??? :? ???
Re: Auf dem Weg von DDraw nach OpenGL ..
Verfasst: 03.08.2010, 10:29
von kimmi
Dann bist du gut davor. Interfaces helfen nur, wenn du zur Laufzeit entscheiden mußt, welche konkrete Implementierung du brauchst.
Gruß Kimmi
Re: Auf dem Weg von DDraw nach OpenGL ..
Verfasst: 03.08.2010, 15:29
von 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...
Re: Auf dem Weg von DDraw nach OpenGL ..
Verfasst: 03.08.2010, 16:58
von 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.
Re: Auf dem Weg von DDraw nach OpenGL ..
Verfasst: 03.08.2010, 17:28
von 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?
Re: Auf dem Weg von DDraw nach OpenGL ..
Verfasst: 04.08.2010, 14:43
von 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
Re: Auf dem Weg von DDraw nach OpenGL ..
Verfasst: 06.08.2010, 08:35
von glassbear
HeinzK hat geschrieben: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...
Re: Auf dem Weg von DDraw nach OpenGL ..
Verfasst: 01.10.2010, 09:48
von 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!
Re: Auf dem Weg von DDraw nach OpenGL ..
Verfasst: 02.10.2010, 12:37
von 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.
Re: Auf dem Weg von DDraw nach OpenGL ..
Verfasst: 02.10.2010, 17:05
von Jonathan
HeinzK hat geschrieben: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?
Re: Auf dem Weg von DDraw nach OpenGL ..
Verfasst: 02.10.2010, 17:10
von 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).