C++ lernen...


2004-03-02 17:17 #1
Ich möchte mich mal etwas näher mit C++ beschäftigen. Mit C hat's ja ganz gut geklappt, aber da jetzt C++ streikt.🙄 Das Problem finde ich bei C++, das der Anfänger dieser komplexen Programmiersprache ohne Hilfe ausgesetzt wird😰 :
1. Welcher Compiler ist am besten?
2. Wo bekommt man Lernstoff her?
3. Wie komplex muss eine Anwendung (Spiel) sein, dass DirectX oder OpenGL nötig wird?
Ich weiß nie, wo ich anfangen soll. Kann mir hier jemand empfehlen, was ich als erstes machen soll?
Grüße,
LordEverything
PS: Dieser Thread ist jetzt natürlich an die Programmierkundigen wie herc oder autofahrn gerichtet.
PS 2: Wenn das zusehr OffTopic ist, löscht diesen Thread einfach, und denkt mal über ein OffTopic-Forum nach.😉
2004-03-02 19:15 #2
Also für den Einstieg fand ich "C++ in 21 Tagen ganz gut".
Die Frage ist natürlich auf welche Technologie du aufsetzen willst.
Auf das veraltete MFC oder COM? Oder doch gleich auf Microsoft's neue
.NET-Technologie. Dann würde ich die C++.NET empfehlen.

Wenn es dir ausschließlich um die Spieleprogrammierung geht: Es gibt ein paar
gute Bücher über das Thema Spieleprogrammierung mit C++ und DirectX.
Such mal bißchen bei Amazon.de danach.

Webmaster Game-of-Robot.de

2004-03-02 21:23 #3
Ich denke, ob du OpenGL bzw. Direct3D benutzt, muss nich von der Komplexität deines Spiels abhängen. Das wird einfach dann nötig, wenn du mit 3D Grafiken arbeiten willst, die von der Grafikkarte beschleunigt werden sollen.

Ansonsten gibts einige Seiten mit Tutorials und auch Handbüchern:

www.programmersheaven.com
www.robsite.de

www.windowsclone.de.vu

  • games & progs for casio cfx-calculators
  • some old games coded in QBasic

Linux is for people who want to know why it works.
Mac is for people who don't want to know why it works.
DOS is for people who want to know why it does not work.
Windows is for people who don't want to know why it does not work.

2004-03-02 22:32 #4
Quote:
Auf das veraltete MFC oder COM?


Wo der Anfänger (wie ich) schon wieder total verlassen ist.👽
Das Tu schau ich mir aber nochmal an, scheint sehr gut zu sein.😃

Grüße,
LordEverything
2004-03-02 23:03 #5
Danke! Diese programmers-heaven-Seite hab ich mir noch nicht angeschaut, aber die Robsite kenne ich ziemlich gut.

Robert (von der Robsite 😉 ) programmiert nämlich auch überwiegend in BlitzBasic, mit dem anderen Zeugs hat er glaube ich garnicht so viel am Hut wie man denkt.

Grüße,
LordEverything
2004-03-02 23:19 #6
Ok, dann kommt jetzt mein ziemlich langes Statement zu dem Thema... 😉

Ich denke, es ist erst einmal ein wenig Aufklärung notwendig, bevor wir hier Begriffe wie OpenGL, OLE und .net mit C++ vermischen.

Zunächst: C und C++ hat absolut nichts Zwingendes mit den anderen, hier erwähnten Techniken zu tun. Wir können uns sicher darauf einigen, dass C++ sich zunächst auf einen erweiterten Sprachumfang von C reduzieren lässt. Das wesentliche Element hierbei ist der Übergang von der prozeduralen zur objektbasierten Implementation.

Letzteres lässt sich auch wunderbar über C realisieren, nur eben nicht so schön gekapselt. Die meisten Programmierer, die ich kenne, und die von sich behaupten C++ zu programmieren, implementieren ganz ordinär prozedural. Lediglich ihre Datei-Extension ist .cpp und sie verwenden // für Zeilenkommentare.

Alle unsere Spiele (mit Ausnahme der Windows-Engine) sind in reinem C geschrieben, haben aber auch schon eine objektorientierte Idee dahinter.

Das Problem, als C-Programmierer auf C++ ohne gute Anleitung umzusteigen, ist ein ziemlich heikles Thema, da man sich am Anfang sehr schwert tut, die Objekt-Idee zu verstehen und überhaupt zu kapieren, warum das nun alles besser ist.

Wenn Du also noch wenig oder gar keine Erfahrung mit C++ hast, vergiss erst einmal alles Andere und schliesse Dich mit Deinem Rechner, einem guten C++-Buch (z.B. Stroustrup, Strasser oder Johonsonbaugh) und etwas Nahrung für eine Woche in einer Kammer ein.

Komme erst wieder heraus, wenn Du Begriffe wie protected, dynamic_cast, Mehrfachvererbung, rein virtuelle Basisklasse, Standard-Copy-Construktor und virtuelle Destruktoren im Schlaf beherrschst.

Wenn Du nun glaubst, alles begriffen zu haben, solltest Du Dich unbedingt ein wenig mit Templates auseinandersetzen, um die elementaren Dinge der Standard Template Library zu begreifen. Weiter geht es hier erst, wenn Du weisst, was ein Iterator oder ein Prädikat ist.

Diesen Stoff vermittle ich in meinem C++-Basis-Kurs in einer knallharten Woche, und trotz persönlichem Coaching zeigt sich immer ziemlich deutlich, dass man viel mehr Zeit braucht, um diese Dinge in Fleisch und Blut übergehen zu lassen.

Erst jetzt solltest Du Dich mit den anderen Begriffen auseinandersetzen. (Sorry RobinSword) Begriffe wie .net, OLE und COM kannst Du zumindest für Deine ersten Spiele komplett ignorieren (weil man sie dafür einfach nicht braucht).

Mit der MFC stehe ich prinzipbedingt ein wenig auf Kriegsfuss. Einmal, weil sie der Standard-Windows-API einfach nur ein Klassenmodell überstülpt, dabei aber das eigentlich notwendige Know-How unter den Tisch fallen lässt. Eine MFC-Hello-World-Applikation hat man in wenigen Sekunden zusammengeklickt, den dämlichen Toolbar bekommt man anschließend nur mit Mühen wieder weg.

Für die eigentlichen, für Spiele-Programmierer notwendigen APIs brauchst Du ohnehin keine MFC, nicht einmal für DirectX.

Apropos DirectX: DirectX ist keine einzelne Schnittstelle, sondern ein ganzes Sammelsurium von Schnittstellen, da gibt es:

- DirectDraw: Für schnelle Bitmap-Grafiken (verwendet in der Windows-Robot-Version)
- Direct3D: Für die Darstellung echter 3D-Welten (die man aber auch erst einmal definieren muss)
- DirectSound: Für die Sound-Ausgabe
- DirectInput: Für Maus-, Joystick- usw. Eingabe
- DirectPlay: Für Netzwerk-Spiele
- DirectMusic: Für MIDI-Ausgabe

um einmal die wichtigsten zu nennen. Alleine um sein Spiel in den Vollbildmodus zu schalten oder mehrere WAV-Streams abzuspielen kommt man kaum um DirectX herum. Da DirectX eine objektbasierte Schnittstelle aufweist, kommt man daher auch kaum um C++ herum, obwohl man Dinge wie Vererbung definitiv nicht braucht.

Und dann ist da noch OpenGL, eine Alternative zu Direct3D. Mir persönlich fiel die Einarbeitung in OpenGL deutlich einfacher, als in Direct3D, da es einfach ein paar wirklich gute Tutorials gibt.

So, das war es von meiner Seite in der notwendigen Kürze. Weitere Fragen sind immer willkommen. 😉

waiting www.tom-productions.de - www.tofahrn-foto.de - www.tofahrn.de

2004-03-03 08:31 #7
... mit 15 MB benötigen DLL-Files pro Programm...

www.windowsclone.de.vu

  • games & progs for casio cfx-calculators
  • some old games coded in QBasic

Linux is for people who want to know why it works.
Mac is for people who don't want to know why it works.
DOS is for people who want to know why it does not work.
Windows is for people who don't want to know why it does not work.

2004-03-03 09:32 #8
Ich weiß schon, warum ich VB programmiere...
Wohlgemerkt VB.NET. 😉

Webmaster Game-of-Robot.de

2004-03-03 18:44 #9
Toll, super, ich komme der ganzen Sache schon ein ganzes Stück näher. Großes Dankeschon an Andreas!
Jetzt habe ich noch eine Frage: Wie ist das denn, wenn ich mit OpenGL bzw. DirectX arbeiten möchte, muss man sich da irgendeine bescheuerte Library kaufen. Bei DirectX wohl auf jeden Fall. Sch*** Microsoft.
Achja, ich möchte nämlic, wie du schon meintest endlich in den Vollbildmodus kommen. Unter C war das ja denkbar simpiel.

Grüße,
LordEverything
2004-03-03 21:00 #10
Du musst gar nichts kaufen. Die ganzen APIs sind entweder ohnehin bereits Bestandteil vom System, oder lassen sich im Falle einer aktuelleren DirectX-Version kostenlos von Microsoft herunterladen.

Wenn Du DirectX verwenden möchtest, brauchst Du den DirectX-SDK von Microsoft. Die jeweils aktuelle Version findest Du hier: DirectX SDK (http://msdn.microsoft.com/library/default.asp?url=/downloads/list/directx.asp) (sind aber immerhin 223MBytes!!!).

Überlege aber ganz genau, gegen welche DirectX-Version Du linken möchtest. Nimmst Du diese von der DirectX-Seite, muß auf dem Zielsystem auch das passende DirectX installiert sein, aktuell wäre das die Version 9.0b.

Ich binde immer gegen ein uraltes DirectX (6.0, wenn ich mich recht erinnere). Damit hast Du zwar nicht die ganzen aktuellen 3D-Möglichkeiten, aber dafür läuft Deine Applikation auf deutlich mehr und älteren Systemen. Solange Du nur DirectDraw (2D-Bitmap-Grafik) verwendest, hast Du dadurch keinerlei Nachteile, da würde sogar auch eine noch ältere Version genügen. Aber mit der 6er-Version gibt's ein paar nette neue Features bei DirectSound...

Bei Interesse, kann ich Dir das Teil, oder auch nur die Libraries, Header und Docs zukommen lassen, das ist dann deutlich weniger...

Wenn ich von Vollbild rede, meine ich natürlich, dass das Programm die Auflösung und Farbtiefe festlegt. Nur ein Fenster ohne Titelleiste ganzflächig mit der aktuellen Auflösung/Farbtiefe anzuzeigen, ist in der Tat keine große Kunst.

Vollbild in DirectX bedeutet, dass Du Herrscher der Bildschirm-Pixel wirst, also kein GDI oder ähnliche Zeitraubendes zwischen Deinen Daten und der Video-Hardware liegt. Daher auch der Name DirectX, eben direkter, exklusiver Zugriff auf die Hardware.

waiting www.tom-productions.de - www.tofahrn-foto.de - www.tofahrn.de

2004-03-03 22:25 #11
Wäre schon toll, wenn du mir dieses Zeugs zuschicken könntest. Einfach an: lord-chaos@gmx.net.

Aber wie macht man das dann mit dem Vollbild? In allen C++ Büchern, Tutorials ist mir so etwas noch nicht begegnet. Dort wird über Klassen, Vererbung und was weiß ich gesprochen... aber nicht über einen Vollbildmodus. Deshalb habe ich auch mit Basic angefangen. Einmal SCREEN 12 bzw. Graphics 640, 480, [Farbtiefe] eingeben und das wars.

Grüße,
LordEverything
2004-03-03 23:57 #12
Das klingt aber eher nach einem DOS-Programm, oder?
Unter Windows ist das alles deutlich komplexer.
Um das mit DirectDraw zu Fuß zu erreichen, musst Du in etwa diese Schritte durchführen:

- DirectDraw-Objekt erzeugen mit DirectDrawCreate
- Besitz der Grafikkarte übernehmen mit dDraw->SetCooperativeLevel
- Auflösung einstellen mit dDraw->SetDisplayMode
- Primäre Zeichenfläche erzeugen mit dDraw->CreateSurface
- ggf. Pixelformat ermitteln für High-Color-Modi über dDraw->GetPixelFormat
- Offscreen-Surface erzeugen mit dDraw->CreateSurface

Das Zeichnen erfolgt dann in etwa so:

- Zeiger auf Offscreen-Surface geben lassen mit offSurf->Lock
- Über den Zeiger direkt in die Bitmap zeichnen, Geometrie dabei nicht vegessen...
- Zeiger wieder freigeben mit offSurf->Unlock
- Offscreen-Surface auf primäres Surface kopieren mit primSurf->Blt oder primSurf->BltFast

Nun solltest Du etwas sehen. In der Praxis zieht sich der dazu notwendige Quellcode locker über 200 Zeilen, vor allem wenn Du auch zwischen Fullscreen und Fenster hin und herschalten möchtest. Aber das macht man genau einmal. Natürlich muss man nicht unbedingt selber pixeln, einige Blt-Routinen nutzen auch Hardware-Ressourcen, wenn man das denn benötigt...

Beispiele zum Anfangen gibt's im Netz eine ganze Reihe, z.B. beim CodeGuru (http://www.codeguru.com/Cpp/G-M/directx/directdraw/article.php/c1231/)

Das Dx-Paket hab' ich 'mal hochgeladen (Dx8 Libs, Header und Docs (http://www.tom-games.de/download/Dx8Develop.zip)), es sind noch immer knapp 15MB. Allerdings sind das die Libs von DX8, das 6er hatte ich gar nicht mehr installiert. Aber für DirectDraw ist das unerheblich...

waiting www.tom-productions.de - www.tofahrn-foto.de - www.tofahrn.de

2004-03-05 21:13 #13
Quote:
... mit 15 MB benötigen DLL-Files pro Programm...


Ab dem nächsten Service Pack ist das .NET-Framework sowieso bei XP dabei
und in Longhorn schon fest integriert.
Bald kommt man da sowieso nicht mehr drumrum...

Webmaster Game-of-Robot.de

2004-03-05 21:35 #14
Quote:
Ab dem nächsten Service Pack ist das .NET-Framework sowieso bei XP dabei


*g* Und wenn du eine Linix-Anwendung schreiben willst?

@autofahrn: Danke, hab's jetzt runtergeladen und werde mich damit beschäftigen. Du kannst die Dateien wieder vom Wespace nehmen 😉 Auf jeden Fall DANKE!

Grüße,
LordEverything
2004-03-06 00:10 #15
Nun, prinzipiell ist es möglich auf jedem Betriebssystem .NET-Programme auszuführen,
Voraussetzung ist lediglich das Vorhandensein einer Laufzeitumgebung wie der CLR,
die den MS IL Code verarbeiten kann.
Dazu gibt es im Internet schon einige interessante Projekte.
Den ersten Schritt in Richtung Portierung des .NET Frameworks auf alternative Plattformen hat Microsoft Ende 2001 selbst getan.
Unter dem Codenamen "Rotor" wurde eine .NET-Implementierung veröffentlicht, die tatsächlich auch unter FreeBSD und Mac OS X 10.2 lauffähig ist.
Der Quelltext von Rotor steht dabei unter einer Share-Source-Lizenz zur Verfügung, die jedermann Einblick gewährt, allerdings darf man sie nicht
weiterverwenden. Rotor enthält dabei die eigentliche CLR, Compiler für C# und JScript, einige abgespeckte Entwickluerwerkzeuge und ein paar Samples.
Damit steht einem als .NET-Entwickler eine quelloffene Implementierung all der Bestandteile von .NET zur Verfügung die Microsoft Ende 2002 durch die ECMA hat standardisieren lassen.
Dann gibt's da noch das Projekt "Mono", das eine unter Unix lauffähige Open Source Version der .NET Plattform schaffen will.
Die ganzen Projekte stehen zwar noch in den Kinderschuhen, aber ich bin mir sehr sicher,
dass früher oder später Windows-(.NET)-Programme genauso unter Linux/Unix eingesetzt werden können wie heute unter Win32 / WinCe.

So, jetzt hab ich mal bißchen ausgeholt. 😉

Webmaster Game-of-Robot.de

2004-03-06 09:58 #16
JavaScript is auch bei? Reicht das nicht schon, dass man in den Browser alle möglichen ActiveX-Objekte einbinden kann und somit alles machen kann, was eine Webseite nicht machen können sollte?

www.windowsclone.de.vu

  • games & progs for casio cfx-calculators
  • some old games coded in QBasic

Linux is for people who want to know why it works.
Mac is for people who don't want to know why it works.
DOS is for people who want to know why it does not work.
Windows is for people who don't want to know why it does not work.

2004-03-06 17:53 #17
JavaScript und ActiveX haben wirklich nichts miteinander zu tun, auch wenn es meinetwegen möglich ist, über JavaXxx (unter Windows) ein ActiveX-Control zu laden.

Java läuft technisch als Pseudo-Code in einer virtuellen Maschine, ein ActiveX-Control ist einfach eine Win32-DLL mit einer genau definierten Schnittstelle. Ein ActiveX-Control kann prinzipiell alles mit dem Rechner machen, was auch der aktuell angemeldete User kann, inklusive dem Formatieren der Festplatte. Ein JavaXxxx (Xxx=******/Script etc) kommt aus seiner virtuellen Umgebung kaum heraus, und ist mit den Standard-Einstellungen des IE prinzipiell harmlos (abgesehen von den nervigen PopUps).

Performancemässig läuft Java-Code wegen des Interpreters natürlich auch recht gemächlich, ein ActiveX-Control kann über die volle CPU-Leistung verfügen. Natürlich laufen ActiveX-Controls nur unter Windows...

waiting www.tom-productions.de - www.tofahrn-foto.de - www.tofahrn.de

2004-03-06 18:59 #18
Scripts are not allowed

www.windowsclone.de.vu

  • games & progs for casio cfx-calculators
  • some old games coded in QBasic

Linux is for people who want to know why it works.
Mac is for people who don't want to know why it works.
DOS is for people who want to know why it does not work.
Windows is for people who don't want to know why it does not work.

2004-03-07 00:18 #19
Quote:
Scripts are not allowed

Genau, und das in Verbindung mit accept any ActiveX-Control. Aus Sicht der Hacker macht das ja auch durchaus Sinn, denn mit Java kann man nichts Schlimmes anstellen, mit ActiveX allerdings schon...😉

waiting www.tom-productions.de - www.tofahrn-foto.de - www.tofahrn.de

2004-03-07 01:01 #20
lol das Scripts are not allowed kam, weil ich ein Beispielscript geschrieben habe. Sicherlich kann man mit JavaScript alleine nix schlimmes anstellen. Aber JavaScript in Verbindung mit dem IE kann schon ne ganze Menge und nich nur wegen ActiveX, sondern auch wegen einigen Sicherheitslücken. So kann man zum Beispiel überprüfen, ob bestimmte Dateien auf der Festplatte vorhanden sind, ohne ein ActiveX-Objekt anlegen zu müssen.

www.guninski.com/browsers.html

Da steht ne ganze Liste von Dingen, die gar nicht möglich sein dürften. Einige davon sind bereits gefixt, aber sehr viele funzen auch noch.

www.windowsclone.de.vu

  • games & progs for casio cfx-calculators
  • some old games coded in QBasic

Linux is for people who want to know why it works.
Mac is for people who don't want to know why it works.
DOS is for people who want to know why it does not work.
Windows is for people who don't want to know why it does not work.