Auf dem Weg von DDraw nach OpenGL ..

[Krishty]

Das const hinter der Deklaration von CKString::operator [] bedeutet, dass diese Funktion ihr Objekt nicht verändern darf (und damit ausschließlich auf const-deklarierte Strings aufgerufen werden darf). Würde diese Funktion eine Referenz zu einem nicht const-deklarierten char zurückgeben, könnte man sie missbrauchen, um das Objekt (nämlich einen einzelnen Buchstaben darin) zu verändern. (Technischer: Das const hinter der Memberfunktion bedeutet, dass der this-Zeiger innerhalb der Funktion ebenfalls const deklariert ist, die Member also alle const sind. Ein const char kann nicht zu char & konvertiert werden.)

Native Datentypen wie char kannst du by-Value zurückgeben, falls sie nicht veränderbar sein sollen, also char operator [] (long const lIdx) const;.

[HeinzK]

Da werd' ich noch ein wenig hin un her probieren .. aber Danke für die tolle Info ..

[Krishty]

Im Grunde geht es darum, das hier zu verhindern:

Code: Alles auswählen

void Bad(CKString const & String) { // "String" ist "const", darf also nicht verändert werden
    String[0] = 'x'; // Zuweisung unmöglich, wenn "CKString::operator []" eine "const"-Referenz zurückgibt.
                     // Aufruf unmöglich, wenn "CKString::operator []" nicht "const" deklariert ist.
}

Arbeite dich endlich in const-Correctness ein …

[HeinzK]

Ok, inzwischen habe ich meinen Denkfehler gefunden. Nicht ändern wollen bedeutet ja nicht es irgendwann doch zu können.

[HeinzK]

Das erste Test-Programm unter OpenGL ist fertig 8-) !
Zum Vergleich habe ich das gleiche Programm auch für DDraw bereitgestellt:
http://www.zwianer.de/$PCSpiel$/Download/TestOpenGL.exe
http://www.zwianer.de/$PCSpiel$/Download/TestDDraw.exe
Unterschiede und Bedienung:
OpenGL: ESC= Programmende; F1=Vollbild/Fenster; F2=Neustart(Zeitberechnung).
Das Programm startet mit einem Fenster 800/600.
Zeichnen, Objekt-Daten werden in einer Datenbank, getrennt nach Ebenen und Layern, gespeichert.
Malen, Datenbank ins Pixel-Array.
DrawPixels, Pixel-Array mit Hilfe von glDrawPixels() nach OpenGL und 'Flip' zur Anzeige.
DDraw: ESC=Programmende; F2=Neustart; F3=32bit/8bit.
Das Programm läuft nur im Vollbild.
Zeichnen, Objekt-Daten werden in einer Datenbank, getrennt nach Ebenen und Layern, gespeichert.
Malen, von der Datenbank direkt in das BackSurface und 'Flip' zur Anzeige.
Näheres siehe http://www.zwianer.de/$PCSpiel$/Downloa ... OpenGL.htm
PS:
Ich habe eine Bitte: TestOpenGL.exe ausführen und wenn es Probleme gibt bitte hier melden.

[HeinzK]

Zum Thema glDrawPixels, schnell oder langsam ..
Das schlimmste ist, das es beides zur gleichen Zeit ist! Auf den ATI Radeon's unterm i7 ist
es verdammt schnell (1.0 .. 2.7 ms). Aber unter der NVIDIA ist es sehr, sehr wackelig. Da
schwankt es ständig zwischen 11.4 .. 122.9. Es kann aber auch an den AMD's liegen?
Wertetabelle siehe http://www.zwianer.de/$PCSpiel$/Downloa ... OpenGL.htm
Ich bin mal gespannt wie das ganze dann unter Linux/Ubuntu läuft ..

[Zudomon]

Warum gehst du nicht den nächsten Schritt und verwendest Dreiecke und Texturen?

[HeinzK]

Warum? Das liegt an der Art und Weise wie ich mein Spiel entwickelt habe.
Ich wollte es von der 'Picke' auf anpacken! :)
Also begann ich mit einem Pixel (auf das ich heute noch Stolz bin) und habe dann
die Routinen für Linien, Bögen, Kreise, Ellipsen, Polylinien, Dreiecke, Rechtecke, Sechsecke (mit
und ohne Füllung, gestrichelt oder ausgezogen) und für Text, aufbauend auf dem einen Pixel, selbst entwickelt.
Danach habe ich eine Datenbank organisiert, in der die Objekte nach Gruppen, Ebenen und Layer geordnet werden können.
Aus dieser Datenbank fülle ich mit einem Rutsch (Pixel für Pixel) das Backsurface .. und Flip. 8-)
Die Methode war für meine Zwecke gut und vor allem sehr schnell! (Allein bei den Texten bis zu 50 mal schneller
als alles was DDraw bieten konnte.) Und genau diese Methode übertrage ich nun auf OpenGL.
Um meine Ordnung beizubehalten, schreibe ich hier die Daten zuerst in ein Pixel-Array. Das ist zwar
nur etwa halb so schnell, wie wenn ich direkt ins VRAM schreibe, aber es ist nur ein kleiner Teil der Gesamtberechnungzeit.
Das einzige was ich wirklich an Rechenzeit verlieren ist das zusätzliche glDrawPixels(). Und da gibt es leider
von Rechner zu Rechner gewaltige Unterschiede von 1 ms bis zu 100derten von ms.
Siehe: http://www.zwianer.de/$PCSpiel$/Downloa ... OpenGL.htm

[Schrompf]

Jupp, das ist zu erwarten. Der direkte Pixelzugriff ist heutzutage nunmal nur noch ein Relikt aus alten Tagen. Die "50 mal schneller" von damals sind heute wahrscheinlich 50x in die Gegenrichtung. Deswegen optimiert auch kein Grafiktreiber mehr für den direkten Pixelzugriff... wie es also läuft, hängt von OS, Treiber und Graka ab. Und da bist Du bei OpenGL eh im Zufallsland.

Ist jetzt alles unkritisch, finde ich. Die Grafik der Zwianer ist so minimal, da läuft alles im vernünftigem Tempo. Ist halt nur was, was man für's nächste Projekt im Auge behalten sollte.

[HeinzK]

Eine Frage, bevor ich ins Wasser gehe .. im Moment schwimme ich noch in Linux/Ubuntu.

Code: Alles auswählen

k_pDply = XOpenDisplay(NULL);
k_Win = XCreateWindow
              (
                k_pDply,
                RootWindow(k_pDply, pVi->screen),
                0,
                0,
                iWidth,
                iHeight,
                0,
                pVi->depth,
                InputOutput,
                pVi->visual,
                (CWBorderPixel | CWColormap | CWEventMask),
                &Swa
              );

Das Beispiel, von dem ich 'spicke', beendet sich, ohne irgendein 'RELEASE'.
Ist das in Ordnung?

[Biolunar]

Bist du dir sicher, dass du dir Xlib antun willst? Es wäre sinnvoller ein fertiges Toolkit zu verwenden, zur Auswahl stehen etliche...

Wenn dein Fenster vom Window Manager geschlossen wird, musst du nichts aufräumen. Wenn du selber (= im Code) dein Fenster schließen willst, verwendest du XDestroyWindow.

[HeinzK]

OK, Danke.
D.h., wenn ich OpenGL mit neuen Einstellungen starten will, schließe ich mit xDestroyWindow das Fenster und baue alles neu auf! Richtig verstanden?
Also keinerlei 'Aufräumarbeiten' erfordlich! :?
Xlib: Für mich ist alles unter Linux/Ubuntu noch Neuland, hab' wirklich keine Ahnung, was ich mir da 'Antue'.

[kimmi]

Schau dir mal SDL an, die macht dir das Leben unter Ubuntu einfacher. Das ist eine Lib, die es einem recht recht macht, einfach ein OpenGL-Fenster plattformunabhängig zu generieren. Dazu bietet sie noch Inputhandling und einiges mehr. Schau mal hier nach, wenn's dich interessieren sollte: http://www.libsdl.org/
Die Lib wird unter anderem auch von OGRE benutzt.

Gruß Kimmi

[HeinzK]

SDL: Entweder bin ich überarbeitet, oder einfach nur etwas verwirrt. Ich hab mir den Link mal angeschaut.
Vom Prinzip ist es genau das, was ich suche.

Aber ich weiss nicht, was ich alles, wie und wo, installieren muss.

OK, folgendes hab' ich nun heruntergeholt:
Source Code:
SDL-1.2.14.zip
Linux/Ubuntu-9:
SDL-1.2.14-1.x86_64.rpm
SDL-debuginfo-1.2.14-1.x86_64.rpm
Win32/Visual Studio 2008:
SDL-1.2.14-win32.zip
SDL-devel-1.2.14-VC8.zip
OK, in die ZIP-Dateien seh' ich rein, aber was ist eine rpm .. ?
Ich bräuchte ein paar Tipps, wie und wo ich das ganze am Besten installiere.
Einmal für WIN32 und einmal für Linux/Ubuntu.

[Biolunar]

Für Ubuntu ist das kinderleicht. Du öffnest mal Synaptic und suchst da einfach nach SDL und installierst das *-dev Paket (Wie das genau heißt weiß ich grad nicht, hab grad kein Ubuntu am laufen). Fertig!

Diese .rmp's die du runtergeladen hast sind für Red Hat Linux und nicht für Ubuntu. Du kannst (und solltest!) dich auch weiter über die Paketverwaltung informieren, das macht einiges klarer.
Den Sourcecode wirst du meiner Meinung nach wohl (erst mal) gar nicht benötigen, weder für Ubuntu noch für Windows.

[eXile]

Zum Entwickeln unter Windows reicht SDL-devel-1.2.14-VC8.zip vollkommen. Solltest du dein Programm als Achiv weitergeben, musst du für Windows die entsprechenden DLL-Dateien mitverteilen.

Zum Entwickeln unter Linux recht die Installation von sdl-devel in deinem Paketmanager vollkommen. Solltest du dein Programm als Archiv weitergeben, so solltest du in die Readme reinschreiben, dass dein Program vom Paket sdl abhängig ist, aber du solltest von der SDL nichts weiterverteilen.

[HeinzK]

.. als Archiv weitergeben, ..

Meinst du damit ZIP-Datei .. ?

[kimmi]

Wenn du zum Beispiel einen Installer mitlieferst, mußt du halt die SDL-Dll mitliefern, da deine Anwendung von dieser abhängt.

Gruß Kimmi

[HeinzK]

OK, eins nach dem andern .. Installer mitliefern .. da komm' ich auch noch hinter! :oops:

[HeinzK]

Installation von sdl-devel in deinem Paketmanager

Ich finde diesen Eintrag in Ubuntu-9 nicht.
Wie installiere ich nun die sdl-devel .. brauche Tipps ..

[Biolunar]

Sooo, grad mal Ubuntu gestartet. Das Paket heißt richtig "libsdl1.2-dev". Wenn du nach libsdl suchst bekommst du noch ein paar mehr Ergebnisse angezeigt, je nachdem was für Spezialzeug du von der SDL noch verwendest musst du noch die anderen "libsdl-*-dev" Pakete installieren (Halte ich aber zumindest am Anfang für unwahrscheinlich).

[Hanno]

Wie installiere ich nun die sdl-devel .. brauche Tipps ..

Ich hab keine Ahnung von SDL, aber probier vielleicht mal das Paket "libsdl1.2-dev".

[HeinzK]

OK .. das Paket ist angekommen !

[HeinzK]

gcc: warning: ignoring #pragma
Ich nutze zum großen Teil den gleichen Code (Gott sei Dank) für Windows und Linux.
Kann ich irgendwie die obige Warnung abschalten?
Leider finde ich sonst keinen 'Weg darumherum'. #pragma once muss (so viel ich weiß) in der ersten Zeile stehen.
Irgendwelche #ifdef xxx .... #endif machen sowieso keine Sinn, da man diese ja nicht verschachteln kann.
Hat jemand eine Lösung für mich?

[Aramis]

da man diese ja nicht verschachteln kann.

Man kann sie beliebig verschachteln.

Leider finde ich sonst keinen 'Weg darumherum'.

Der 'Weg drumherum' ist ein stinknormaler Include-Guard (http://en.wikipedia.org/wiki/Include_guard):

Code: Alles auswählen

#ifndef BLABLUBB_INCLUDED
#define BLABLUBB_INCLUDED

..

#endif 

#pragma once ist eine MSVC-spezifische Abkuerzung dafuer.

[HeinzK]

Das funktioniert aber nur, wenn keine weiteren #ifdef .. #endif im Code stehen und
bei mir sind halt noch ein paar #ifdef _WIN32 ... #endif dazwischen.
Klar kann ich statt #pragma once überall das 'alte' BLABLUBB_INCLUDED verwenden. Aber ich habe
nun mal eine Stange voll vorhandener *.h, die alle mit VS entworfen worden sind.
Gibt es wirklich keine andere Möglichkeit?

[Aramis]

Das funktioniert aber nur, wenn keine weiteren #ifdef .. #endif im Code stehen und
bei mir sind halt noch ein paar #ifdef _WIN32 ... #endif dazwischen.

Wieso soll es nicht funktionieren? … Du kannst sie beliebig verschachteln.

Code: Alles auswählen

#ifndef guard
#define guard

...
#ifdef b
...
#endif

#endif 

Gibt es wirklich keine andere Möglichkeit

Naja, du brauchst ja auch mit GCC funktionierende Include-Guards (sonst koenntest du sie ja auch bei MSVC komplett weglassen, benoetigt wird #pragma once nicht, jedenfalls nicht wenn jede Datei nur exakt einmal inkludiert wird). Also ja: es gibt keine andere Moeglichkeit.

[HeinzK]

Schade. Ich benötige aber #pragma once weiterhin für meine Windows-Entwicklung. Das muss ich wohl
oder übel mit dieser Warnung weiter leben (= weiter programmieren). ;)

[Krishty]

Die Guards funktionieren unter allen Compilern, auch Visual C++, vollkommen gleich gut … #pragma once an sich ist gänzlich und vollends verzichtbar, entbehrlich, austauschbar, überflüssig, abkömmlich. Du kannst es besten Gewissens austauschen.

[HeinzK]

Mit der Verschachtelung lag ich falsch. Mein VS war bei der 'Aktivmarkierung' einen Moment lang nicht auf dem Laufenden.
Ja .. die Guards .. das ist nur ne Menge 'handbetrieb' ..