qtforum.de

Hallo zusammen

Weil ich mich schon immer mal mit OpenGL beschäftigen wollte, arbeite ich an einem kleinen "1990er-Jahre-Style" FPS. Ich recycle dafür die DukeNukem3D Daten (Shareware-Version) (die Idee kam mir, nachdem ich über Ken Silverman's Seite gestolpert bin: http://advsys.net/ken/).

Projektziel:
- Spiel und Spass mit OpenGL und Qt

Besonderheiten:
- Recycling der DukeNukem3D-Daten (es wird 'duke3d.grp' benoetigt!)
- starke Interaktion des Spielers mit der Umgebung
- Maps werden (analog zu "Heightmaps") mit 2D-Bitmaps und einer INI-File erstellt

Wer mithelfen möchte: ich suche
- Jemand der sich mit dem Soundkram auskennt (SDL_Mixer, fmod, ALSA, JACK oder sonst was)
- Jemand der Erfahrung mit OpenGL und Beleuchtung(!) hat

Download ab:
https://sourceforge.net/projects/qute3d/files/

Grüsse!

Benutzt du Qt3 dafür? Mit qmake in der Konsole wollte er das Qt3 Inklude Verzeichnis Verzeichnis nutzen.

Aus dem QtCreator heraus nahm er dann Qt4, fand aber QList::length() nicht, welches ab Qt 4.5 gibt. Ich hab 4.7 mit QtCreator 2.0.0. Also irgendwie ist da was durcheinander geraten bei mir o.0

Ansonst hast du mein Interesse gewecket. Gerade was OpenGL und Qt/OpenGl angeht steck ich noch in den Kinderschuhe. Werde bestimmt abundzu mal in den Quellcode schauen Hoffentlich ist es nicht so ein Wurstsalat wie von meinem Chef

Gruß

kater hat geschrieben:Benutzt du Qt3 dafür? Mit qmake in der Konsole wollte er das Qt3 Inklude Verzeichnis Verzeichnis nutzen.

Auf gar keinen Fall habe ich da Qt3 drin..
Bei mir kommen keine Qt3-Pfade im Compile-Aufruf... nur um das Projekt zu compilen würde ich evt. auf den Creator verzichten und direkt die Konsole nutzen.

kater hat geschrieben: Werde bestimmt abundzu mal in den Quellcode schauen Hoffentlich ist es nicht so ein Wurstsalat wie von meinem Chef
Gruß

Wie alle Projekte mit mehr als 2 Klassen hat auch dieses Design-Schwächen.. aber von der Übersichtlichkeit her schlage ich das original DN3D garantiert

Hm. Was dagegen wenn ich grad mal 2 Fragen stelle?

Ich seh immer, dass Leute anders Programmieren als ich. Dann frag ich mich was das für Gründe hat und finde keinen.

1) Wieso nutzt du die Endung .cc und nicht wie jede Datei die jemals von mir gesichtet wurde mit .cpp?

2) Und z.B. in main.cc Zeile 18. Der cout Aufruf. Wieso nimmst du da endl und nicht \n?
Wegen der Übersicht damit man besser sieht wann eine neue Zeile entsteht? Nee das erscheint mir übertrieben. Selbst mit Autovervollständigung ist das doch viel mehr Tipparbeit.

Na auf die Antwort bin ich mal gespannt

zu 1.
Mehrere Gründe:
- Historisch (die Solaris-Leute, mit welchen ich zusammengearbeitet habe, haben "cc" genommen)
- es gefällt mir inzwischen auch optisch besser
- ich kann mit "rm *.cpp" alle Qt-Erzeugnisse löschen, wenn "make clean" versagt..

EDIT:
Übrigens empfiehlt das auch der Google-Styleguide:
http://google-styleguide.googlecode.com ... ader_Files

zu 2.
Um den Code portabel zu halten. "\n" ist Unix. "std::endl" ergibt "\n" unter Unix und IMHO "\r\n\" unter Windows.

Ah klar *patsch* macht Sinn. An so einfache Sachen wie ein anderer Zeilenumbruch denk ich natürlich nicht. Danke

kleiner Nachtrag: mutigen Entwicklern empfehle ich eher die SVN-Version:
Diese Version ist logischerweise weiter und hat z.B. in der aktuellen Version noch das Element "Mine":

solarix hat geschrieben:Um den Code portabel zu halten. "\n" ist Unix. "std::endl" ergibt "\n" unter Unix und IMHO "\r\n" unter Windows.

Das hat mich jetzt auch interessiert Ich bin bisher davon ausgegangen, dass ein std::endl einfach ein "\n" + std::flush ist. Laut dieser Diskussion wird "\n" bei einem als text geöffneten Stream tatsächlich in die jeweilige Plattformeigene Sequenz übersetzt - also \r\n auf Windows. (wobei einem da natürlich der Compilerhersteller dazwischenfunken kann )
Wenn man also auf Persormance angewiesen ist, sollte man auf "\n" setzen, und bei Bedarf (z.B. am Ende einer Funktion) ein std::flush(stream); machen.

Das Projekt werd ich mir bei Gelegenheit mal genauer anschauen, vllt. klappts ja diesmal mit dem Einstieg in OpenGL