Seite 2 von 9

Re: Auf dem Weg von DDraw nach OpenGL ..

Verfasst: 11.05.2010, 11:02
von HeinzK
Ok .. glu.h und GLU eingebaut und es funktioniert.
Wo liegen unter Linux eigentlich die Lib's und h-Dateien (also glu.h bzw. glu.lib)?

Re: Auf dem Weg von DDraw nach OpenGL ..

Verfasst: 11.05.2010, 11:05
von Psycho
Oder aber glOrtho():
gluOrtho2D sets up a two-dimensional orthographic viewing region. This is equivalent to calling glOrtho with near=-1 and far=1.

Re: Auf dem Weg von DDraw nach OpenGL ..

Verfasst: 11.05.2010, 11:07
von HeinzK
Danke für den Hinweis.

Re: Auf dem Weg von DDraw nach OpenGL ..

Verfasst: 11.05.2010, 12:40
von Tobiking
HeinzK hat geschrieben:Wo liegen unter Linux eigentlich die Lib's und h-Dateien (also glu.h bzw. glu.lib)?
Das ist nicht immer ganz einheitlich. Nach dem FHS (Filesystem Hierarchy Standard) befinden sich die Header und Libs für das System selber unter /usr/include und /usr/lib (oft auch /usr/lib64). Manchmal wird aber auch /usr/TARGET/lib usw. für das Standardtarget genutzt. Das Target das st so etwas wie i386-linux-gnu. Wenn man Libs selber compiliert haben diese auch oft als Ziel /usr/local/lib. Eine Distribution kann das allerdings auch ganz anders machen.

Re: Auf dem Weg von DDraw nach OpenGL ..

Verfasst: 11.05.2010, 13:45
von HeinzK
Ok, dann werde ich diese auf finden .. und weiter im Text:
Linux/Ubuntu/OpenGL: Ist es richtig, dass am Programmende keine Resourcen (Window, OpenGL) freigegeben werden müssen?

Re: Auf dem Weg von DDraw nach OpenGL ..

Verfasst: 11.05.2010, 13:50
von Aramis
hmm ja, Resourcen muesstest du eigentlich schon freigeben. Fuer die ganzen X11–Objekte gibt es meist entsprechende Loesch-Funktionen, z.B. XFreeColormap, XDestroyWindow, XCloseDisplay

Re: Auf dem Weg von DDraw nach OpenGL ..

Verfasst: 11.05.2010, 13:53
von HeinzK
Gut zu wissen, in meinem vorliegenden Beispiel hat sich keiner darum gekümmert.

Re: Auf dem Weg von DDraw nach OpenGL ..

Verfasst: 11.05.2010, 19:36
von HeinzK
Ich habe versucht meine erste Klasse unter Linux/C++ entwerfen:

Code: Alles auswählen

class CKOpenDisplay : public CObject
{
  public:
    CKOpenDisplay(void);
    virtual ~CKOpenDisplay(void);

  private:

};
Ist es das, was ich fürchte .. es gibt kein CObject unter Linux .. oder was habe ich falsch gemacht?
/home/hk/TestOpenGL/KOpenGL.h|2|error: expected class-name before ‘{’ token|
||=== Build finished: 1 errors, 0 warnings ==pe

Re: Auf dem Weg von DDraw nach OpenGL ..

Verfasst: 11.05.2010, 19:47
von Aramis
CObject gehoert zu MFC. Die gibt es unter Linux nicht, und auch unter Windows wuerde ich davon abraten. Entweder ueberhaupt keine Basisklasse … oder eine selbstgebastelte, falls alle deine Klassen sich gewisse Verhaltensweisen teilen.

Re: Auf dem Weg von DDraw nach OpenGL ..

Verfasst: 11.05.2010, 19:51
von HeinzK
Das Problem ist .. ich verliere ohne CObject das Serialize .. war bisher Bequem und einfach damit alle Variablen incl. Objektzeiger zu speichern und zu laden .. jammerschade ..
PS:
Ich bin für eine LFC (Linux Foundation Classes) !

Re: Auf dem Weg von DDraw nach OpenGL ..

Verfasst: 11.05.2010, 20:02
von Aramis
Ja, Serialisierung wirst du dir wohl selber basteln muessen. boost.serialization kann dabei vielleicht helfen.

Re: Auf dem Weg von DDraw nach OpenGL ..

Verfasst: 11.05.2010, 20:27
von HeinzK
Ok, danke für den Hinweis mit dem 'serialize'. Für heute ist Schluss, das alles muss ich zuerst einmal verkraften ..

Re: Auf dem Weg von DDraw nach OpenGL ..

Verfasst: 12.05.2010, 11:06
von HeinzK
Ich hab' heut nacht im Traum 'Serialize' programmiert .. und glaub', so könnt es sogar klappen.
Frage:
Bisher habe ich CString genutzt. Als Ersatz habe ich mal mit std::string 'gespielt'.
OK, was ich nutze, ist fast alles vorhanden, außer 'Format'.
Beispiel:

Code: Alles auswählen

CString sText;
sText.Format("%s%d%0.5f", "Test", 100, 4.5);
Wie löst man das am effektivsten mit std::string?

Re: Auf dem Weg von DDraw nach OpenGL ..

Verfasst: 12.05.2010, 11:32
von Aramis
Mit std::stringstream:

Code: Alles auswählen

std::stringstream ss;
ss << 4.f << " ist eine tolle Zahl";
const std::string s = ss.str();
Das kann man auch noch geschickt wrappen um die Konstruktion des temporaeren stringstream's zu verbergen. Alternativ, wenn du naeher an CString::Format bleiben willst, boost.format. Bietet ebenso wie std::stringstream Typsicherheit.

Ansonsten gibt es noch sprintf, eine Hilfsfunktion aus der C–Standardbibliothek. Du kannst deine Strings in einem statischen Buffer zusammenbasteln und dann in einen std::string konvertieren (das ist von den Genannten die unidiomatischte Methode, und die gefaehrlichste).

Re: Auf dem Weg von DDraw nach OpenGL ..

Verfasst: 12.05.2010, 16:00
von HeinzK
Ich bin am experimentieren.
Im Moment bin ich auf gutem Weg eine Lösung zu finden.
Problem:

Code: Alles auswählen

std::stringstream ss;
Unbehandelte Ausnahme ... std::bad_alloc ..
Habe ich da ein Problem, weil ich mit 'new' und 'delete' arbeite? Oder was ist los.
Was ich eigentlich machen will:

Code: Alles auswählen

char *cBuff = new char[256];
..
std::string sFrm(cBuff);
Also einfach ein CharArray eine std::string zuordnen. Was mach ich da falsch? Oder geht auch das nicht?

Re: Auf dem Weg von DDraw nach OpenGL ..

Verfasst: 12.05.2010, 16:52
von kimmi
Der char-Array sollte NULL-terminiert sein.

Gruß Kimmi

Re: Auf dem Weg von DDraw nach OpenGL ..

Verfasst: 12.05.2010, 16:57
von HeinzK
Bin kurz vor der Lösung meines Problems (hoffe ich). Es scheint an 'new/delete' kontra 'malloc/free' zu liegen.
Ich vermute std::string arbeitet mit 'malloc/free' und ich habe den char* mit 'new/delete' angelegt. Sobald es läuft (oder auch nicht) melde ich mich wieder.

Re: Auf dem Weg von DDraw nach OpenGL ..

Verfasst: 12.05.2010, 17:05
von Aramis
Nein.

Dein Fehler ist, dass dir das RAII-Konzept (siehe Wikipedia) nicht gelaeufig ist. Dahinter steht, vereinfacht, die automatische Verwaltung von Resourcen durch den Konstruktor/Destruktor Mechanismus von C++.

Wenn du deine Objekte sauber designst, musst du so gut wie *nie* Speicher manuell erzeugen oder freigeben. Die STL, zu der std::string zaehlt, ist ein Paradebeispiel dafuer. Welchen Allokator dein String intern benutzt um seinen Buffer anzulegen, ist irrelevant – du kriegst davon gar nichts mit.

Nicht DU musst Speicher anlegen und dem String geben. Sondern der String legt fuer sich selber den Speicher an, den er benoetigt – und gibt ihn frei, sobald er selber zerstoert wird. Wenn du dem c‘tor eine Zeichenkette uebergibst, so versucht er eine Kopie davon zu erstellen und sieht diese fortan als sein Eigentum an.

(vermutlich war der Speicherbereich, den du versucht hast an den String zu ‘binden’, undefiniert – der Versuch davon eine Kopie zu machen knallt also mit hoher Wahrscheinlichkeit, da die Laenge des Strings ja von der Praesenz eines Null-Zeichens am Ende abhaengt)

Code: Alles auswählen

void foo(..)
{
// erstellt eine Kopie des Strings 'ahoi' und legt sie im Objekt ab
std::string s = "ahoi";

// erstellt eine unaebhaengige Kopie des Objektes
std::string s2 = s;

// std::string definiert den '+'–Operator um zwei Strings zu verknuepfen. 
// das Ergebnis ist ein dritter, der wieder fuer sich selber Speicher anlegt.
std::string s3 = s2+s;

// genau jetzt wird der d'tor der strings aufgerufen. Aller Speicher wird freigegeben.
}

Re: Auf dem Weg von DDraw nach OpenGL ..

Verfasst: 12.05.2010, 18:39
von HeinzK
Ja, das habe ich verstanden. Mein Problem war einen char* nach std::string zu konvertieren.
Ich habe es nun gelöst, in dem ich eine eigene String-Klasse angelegt habe. Diese wird die
von mir benutzten Methoden von CString mit Hilfe von std::string nachbilden.
Vorerst habe ich das Problem mit Visual Studio bearbeitet .. und es läuft. Nun werde
ich es auf Linux/Ubuntu portieren .. melde mich wieder.

Re: Auf dem Weg von DDraw nach OpenGL ..

Verfasst: 12.05.2010, 21:44
von HeinzK
Geschafft, ein erster Entwurf von CKString ist im 'Kasten'.

Code: Alles auswählen

  
CKString sKStr1("Test1");
 cout << "A: " << sKStr1.GetsStr() << endl;

int iLen = sKStr1.GetLength();
cout << "B: " << iLen << endl;

CKString *pKStr2 = new CKString("Test2");
CKString sKStr3;
sKStr3 = pKStr2->GetsStr();
if (pKStr2 != NULL)
{
delete pKStr2;
pKStr2 = NULL;
}
cout << "C: " << sKStr3.GetsStr() << endl;

CKString sKStr4;
sKStr4.SetsKString("Test4");
sKStr4 = sKStr4.Left(2);
cout << "D: " << sKStr4.GetsStr() << endl;

CKString sKStr5;
sKStr5.SetsKString("Test5");
sKStr5 = sKStr5.Right(3);
cout << "E: " << sKStr5.GetsStr() << endl;

CKString sKStr6("Test6");
sKStr6 = sKStr6.Mid(1, 3);
cout << "F: " << sKStr6.GetsStr() << endl;

CKString sKStr7("TestCompare");
CKString sKStr8("TestCompare");
int iCmp = sKStr7.Compare(sKStr8);
cout << "G: " << iCmp << endl;

sKStr8.SetsKString("TestCom");
iCmp = sKStr7.Compare(sKStr8);
cout << "H: " << iCmp << endl;

sKStr8.SetsKString("TestComparer");
iCmp = sKStr7.Compare(sKStr8);
cout << "I: " << iCmp << endl;

CKString sKStr9;
sKStr9.Format("%s %d %0.3f", "Test1", 100, 1.23456789);
cout << "J: " << sKStr9.GetsStr() << endl;
Ergebnis:
Bild
Für alle die es testen wollen:
http://www.zwianer.de/$PCSpiel$/Problem ... String.zip
Mt CKString kann ich CString in meinem Quelltexten für Windows und Linux ersetzen. :D

Re: Auf dem Weg von DDraw nach OpenGL ..

Verfasst: 12.05.2010, 22:25
von Krishty
::std::string::empty() ist da um zu testen, ob der String leer ist. Um den String zu leeren (was sowieso nicht nötig ist, dafür sorgt der Konstruktor) gibt es ::std::string::clear().

Gruß, Ky

Re: Auf dem Weg von DDraw nach OpenGL ..

Verfasst: 13.05.2010, 09:06
von HeinzK
Das ist ein Unterschied zu CString:
CString::Empty leert den String und gibt den Speicher frei.
Der Test auf 'Leer' wird über CString::GetLength() gemacht.
Aber danke für diesen Hinweis. Diesen Unterschied hätte ich wahrscheinlich erst beim debuggen entdeckt.
PS:
Das Freigeben des Speichers kann durchaus Sinn machen, wenn z.Bsp. der String nur vorübergehend nicht mehr benutzt wird.

Re: Auf dem Weg von DDraw nach OpenGL ..

Verfasst: 13.05.2010, 14:20
von Krishty
Du kannst den Speicher nicht mit Sicherheit freigeben – die Größe des Strings wird zwar auf 0 gesetzt, intern bleibt aber noch was allokiert (.c_str() muss ja z.B. auch für leere Strings zumindest einen Zeiger auf eine Null zurückgeben). Und im Default-Konstruktor, von dem aus du .empty() aufgerufen hast, ist der String sowieso von Anfang an in diesem Zustand.

Re: Auf dem Weg von DDraw nach OpenGL ..

Verfasst: 13.05.2010, 15:24
von HeinzK
Ok, danke für die Hinweise.

Re: Auf dem Weg von DDraw nach OpenGL ..

Verfasst: 13.05.2010, 15:37
von Aramis
Das Freigeben des Speichers kann durchaus Sinn machen, wenn z.Bsp. der String nur vorübergehend nicht mehr benutzt wird.
Genau genommen gehen die meisten std::string–Implementierungen so vor, dass fuer kleinere Strings ein statischer Buffer direkt im String–Objekt zum Einsatz kommt (MSVC veranschlagt ~16Bytes). std::string::clear() trifft keine Aussage in Bezug auf den Speicherverbrauch, sondern setzt nur die Laenge des Strings zurueck auf 0.

Re: Auf dem Weg von DDraw nach OpenGL ..

Verfasst: 13.05.2010, 17:08
von HeinzK

Code: Alles auswählen

#ifdef _WIN32
  #include "stdafx.h"
#else
 #include "/media/D_DRIVE/Kempter/VC9/ZwiAnerOpenGL/Linux/Tests/TestKString/main.h"
#endif
Ich möchte die gleichen Dateien unter Windows und Linux nutzen.
Mache ich etwas falsch, oder ist es prinzipiell nicht möglich #ifdef und #include zu mischen?
Was ist die Alternative?

Re: Auf dem Weg von DDraw nach OpenGL ..

Verfasst: 13.05.2010, 17:13
von Aramis
Mache ich etwas falsch, oder ist es prinzipiell nicht möglich #ifdef und #include zu mischen?
Doch, das ist moeglich. Dein Beispiel inkludiert stdafx.h wenn _WIN32 definiert ist, andernfalls diesen schrecklichen Absolutpfad (wieso nicht einfach den Pfad als zusaetzlichen Includepfad an den Compiler uebergeben [gcc: -I<pfad>]).

Re: Auf dem Weg von DDraw nach OpenGL ..

Verfasst: 13.05.2010, 17:18
von HeinzK
Nein, das tut es nicht. Ich erhalte unter Windows einen fatal error C1019: Unerwartetes #else!
Den 'schrecklichen Absolutpfad' brauche ich im Moment für Ubuntu.
Ich versuche ja im Moment gemeinsam von Windows und Linux auf die gleiche Datei zuzugreifen.

Re: Auf dem Weg von DDraw nach OpenGL ..

Verfasst: 13.05.2010, 17:25
von Aramis
Nein, das tut es nicht.
Doch, tut es :-) Der Fehler muss an anderer Stelle liegen.
Ich erhalte unter Windows einen fatal error C1019: Unerwartetes #else!
Vielleicht fehlt am Ende der stdafx.h etwas. Die wird ja schließlich an genau der Stelle in den Quelltext eingefuegt. Wenn sie z.B so aussieht:

Code: Alles auswählen

#endif
… waere genau so eine Fehlermeldung die Folge.

Re: Auf dem Weg von DDraw nach OpenGL ..

Verfasst: 13.05.2010, 17:25
von Krishty
Ins Blaue: Deine Line-Endings sind nicht konsistent, weil du die Datei sowohl unter Windows als auch unter Linux bearbeitet hast.