Hallo, ich möchte ein Windowsprogramm erstellen, bei dem sich ein Ball in einem Fenster zufällig hin und her bewegt und sich, wenn man ihn anklickt, verfärbt. Das ist ein Trainer für Computerspiele.
Ich habe das vor Jahren schon mal mit Qt realisiert, aber meine Festplatte ist kaputt gegangen und ich komme mit dem heutigen Qt irgendwie nicht mehr zurecht und möchte auch mal was anderes probieren.
Dafür habe ich mir Visual Studio 2022 C++ installiert und mir dazu das Buch von Richard Kaiser gekauft und darin auch schon einiges gelesen.
Meine Frage: Ist das, was ich vorhabe mit Visual Studio 2022 C++ überhaupt machbar?
Ist das, was ich vorhabe mit Visual Studio 2022 C++
überhaupt machbar?
Natürlich.
Auf drölfzig verschiedene Arten und Weisen.
Du kannst ein reines C-Programm schreiben, das die Win32-API verwendet, Du kannst das gleiche in C++ machen, Du kannst ein C++-Programm schreiben, das eine C++-Klassenbibliothek wie die mit VC mitgelieferte MFC verwendet, oder eine andere, die Du Dir dann allerdings noch besorgen müsstest (wxWidgets, Qt etc.), Du kannst auch auf das moderne .Net-Geraffel zurückgreifen und eine der dafür vorgesehenen .Net-Sprachen wie C# oder "C++/CLI" bzw. "Managed C++" verwenden (die haben zwar C++ im Namen, sind aber kein C++), und dann heißt das ganze dann je nach Wetterlage Windows Forms, Windows Presentation Foundation (WPF), WinRT oder WinUI ...
All' das kannst Du mit Visual Studio 2022 machen. Und sicher noch mehr, die Liste erhebt keinerlei Anspruch auf Vollständigkeit.
Von Haus aus gingen noch OpenGL und Vulkan (mit diversen Programmeniersprachen). Mit externen Frameworks wie SDL, Cairo, und natürlich auch Qt ginge es ebenso.
C# + WinUI wäre die modernste Variante, die dann auch nahtlos sowohl Touchscreens also auch Mausbedienung unterstützt und auch Integration in den Microsoft Store ermöglicht. Allerdings ist das noch nicht sehr ausgereift.
Hallo, ich möchte ein Windowsprogramm erstellen, bei dem sich ein Ball
in einem Fenster zufällig hin und her bewegt und sich, wenn man ihn
anklickt, verfärbt. Das ist ein Trainer für Computerspiele.
So was hat mein Sohn in Klasse 7 gemacht, mit Scratch...
Die beste Programmiersprache ist die, die man bereits kennt. Der Threadstarter hat bereits C++-Erfahrung, sonst hätte er vor seinem Festplattendefekt nicht schon erfolgreich mit Qt arbeiten können.
In so einem Fall grenzt es an Unfug, zu einer anderen Programmiersprache zu raten.
Wenn ich die Aufgabe des TEs lösen wollte, wäre C++ trotzdem
meine allerletzte Wahl.
Aha. Und was mögen Deine Beweggründe dafür sein? Daß die Aufgabe aus einem Bereich kommt, mit dem Du in Deinen bisherigen Jahrzehnten noch nie zu tun hattest?
Wenn Du beispielsweise als Embedded-Entwickler arbeitest, und jetzt Erstkontakt zur Windows-GUI-Programmierung hast, dann kann ich derartige Gedanken nachvollziehen.
Mir fallen aus dem Stegreif gleich mehrere andere Programmiersprachen ein, mit denen ich die Aufgabe noch weniger lösen wollen würde als in C++ - dazu gehören C, Assembler, Pascal, Basic, Cobol, Fortran und auch Forth. Was C betrifft - ich habe schon Windows-GUI-Programmierung in C betrieben. Ich kenne das, und ich weiß, daß ich das mir nich nochmal antun muss. Allerdings: Mir hat das damals geholfen, das Nachrichtenkonzept der Windows-GUI zu verstehen, das war also keine verlorene Zeit, sondern Grundlagenwissen, das mir verstehen hilft, was die eine oder andere C++-Klassenbibliothek zu abstrahieren versucht.
In anderen Bereichen fühle ich mich mit C aber auch heute noch sehr wohl - ich setze es halt da ein, wo es für mich passt.
Und was mögen Deine Beweggründe dafür sein? Daß die Aufgabe aus
einem Bereich kommt, mit dem Du in Deinen bisherigen Jahrzehnten noch
nie zu tun hattest?
Hast es erkannt. Und obwohl ich eben gaaaanz viel C++ Erfahrung habe, aber fast keinerlei Erfahrung mit GUI-Programmierung, ich also auf diesem Gebiet blutiger Laie bin, würde ich niemals auf die Idee kommen, deinen Leitspruch
Die beste Programmiersprache ist die, die man bereits kennt.
Visual Studio 2022 kann ja bestimmt auch openGL. Danach würde ich
zuerst suchen. Da hast du deinen Ball, bzw. Kugel (Sphere) und
klatscht die entsprechende Tapete (Textur) drauf. Und das alles noch
im 3D - Raum. Das Verfärben kann man dann über verschiedenfarbige
Texturen machen. Und Rotieren geht natürlich auch.
Ich denke, das das noch leichter ist, als über GDI bzw. Win-API selber zu malen.
Wenn es nicht unbedingt C++ sein muss, dann wäre vielleicht Python
War ja klar, dass in einem Thread in dem explizit nach C++ gefragt wird nicht noch irgendein Honk daher kommt der genau das nicht verstanden hat und unbedingt verlautbaren lassen muss dass er eine andere Sprache empfiehlt.
War ja klar, dass in einem Thread in dem explizit nach C++ gefragt wird
nicht noch irgendein Honk daher kommt der genau das nicht verstanden hat
und unbedingt verlautbaren lassen muss dass er eine andere Sprache
empfiehlt.
Wenn also in einem anderen Thread jemand fragen würde, ob ein HSS-Spiralbohrer dazu geeignet ist, sich ins Knie zu bohren, wäre deine Antwort vermutlich: Ja, geht.
Mir fallen aus dem Stegreif gleich mehrere andere Programmiersprachen
ein, mit denen ich die Aufgabe noch weniger lösen wollen würde als in
C++ - dazu gehören C, Assembler, Pascal, Basic, Cobol, Fortran und auch
Forth.
Wieso nicht Basic? Zumindest in der Form von VB(.net) ist GUI-Programmierung damit überhaupt kein Problem. Lauft exakt genauso ab wie in C#. Was natürlich erwartbar ist, da das darunter liegende Framework dasselbe ist.
Allerdings: Mir hat das damals geholfen, das
Nachrichtenkonzept der Windows-GUI zu verstehen
Dieses Wissen kannst du an sehr vielen Stellen auch bei Benutzung des .net-Framework verwenden. Viele Komponenten des Framework (insbesondere natürlich der Kram in Windows.Forms) sind mehr oder weniger nur Wrapper um die altbekannten Common Controls, zumindest in der Windows-Inkarnation des Frameworks.
Allerdings: für schnelle und flüssige Grafik ist dieses ganze Win-API-basierte Zeug nur eher notdürftig geeignet. Ja, man kann OnPaint überschreiben, also das machen, was du als Behandlung der WM_PAINT-Nachricht kennst, bloß etwas komfortabler. Aber die mögliche Zeichengeschwindigkeit ist doch eher beschränkt und viel schlimmer: es gibt keine Möglichkeit, das Geschehen mit dem Refresh des Bildschirms zu synchronisieren, was zu den bekannten Tearing-Effekten führt.
Das ist OK z.B. für das Menüsystem eines Spiels o.Ä., aber die eigentliche Spielfläche schreit nach etwas anderem, und das ist: DirectX oder OpenGL. DirectX ist etwas einfacher zu programmieren und meist auch schneller, aber wenn's möglicherweise portabel werden soll, dann ist OpenGL vorzuziehen.
Und damit ist man dann beim großen Nachteil von .net. Die dauernden Wechsel zwischen managed und unmanaged Code bremsen das gegenüber einer nativen Implementierung doch ganz erheblich aus. Klar, für einfache 2D-Spiele reicht das auf heutiger Hardware noch locker aus, aber wenn das Endergebnis mal ein Spiel mit wirklich anspruchsvoller 3D-Grafik werden soll, dann würde ich an Stelle des TO auch bei C++ bleiben. Ist zwar am Anfang erstmal viel mehr Aufwand, aber wenn's dann irgendwann an den Kern der Sache geht, deutlich einfacher als der Ansatz aus Richtung .net
ein Windowsprogramm [..], bei dem sich ein Ball
in einem Fenster zufällig hin und her bewegt und sich, wenn man ihn
anklickt, verfärbt
Ja, stimmt, die ursprüngliche Zielstellung hatte ich bei meinen Betrachtungen etwas aus den Augen verloren.
Ja klar, solch einfache Sachen kann man noch problemlos und hinreichender Darstellungsqualität mit dem .net-Framework (und dem darunter liegenden Win-API) umsetzen. Also mit Windows.Forms und C# oder VB als Sprache.
Um diese LowEnd-Grafik etwas hübscher (vor allem: ganz erheblich flackerärmer) zu bekommen kann man dann auch gleich ein eingebautes Feature des Framework verwenden, die man ansonsten erst selber hinzu programmieren müsste. Nämlich: double buffering. Kostet nur eine Zeile Quelltext, das für die Client-Zeichenfläche eines Controls zu aktivieren.
Sieh dir mal die Software von "Processig" an! Das ist eine einfache IDE, die Sprache ist halb C++, halb Java und das ganze System ist stark grafik-orientiert. Erstaunlich performant! Für den Einstieg in die Spiele- und Grafik-Programmierung m.E. sehr gut geeignet.
Das lauffähige Ergebnis ist ein Java-Jar, läuft auf allen PC-Plattformen (Win, Mac, Linux). Wahlweise mit oder ohne eingebettetes JRE.
Da es sich um eine 2D-Anwendung handelt, würde ich das mit MFC und GDI in C** lösen. Das erfordert die geringste Einarbeitungszeit. Mit OpenGL geht's schöner, aber falls man das noch nicht kennt, ist die Lernkurve zu steil für diesen Anwendungsfall.
Bitte mal erklären! Ich mache immer double-buffering. Geht's auch
anders?
Naja, echte Sprites gibt's ja auf PC-Hardware heutzutage gar nicht mehr. Bei dem, was Tim da meint, handelt es sich eher um das, was z.B. beim Amiga zur Unterscheidung von echten Sprites (die der Amiga auch hatte) "Blob" genannt wurde.
Im Prinzip funktionieren diese Dinger ebenfalls mit Double Buffering. Der Unterschied zu dem, was heutzutage üblicherweise gemacht wird, ist folgender: Heute wird der komplette Background als Bitmap vorgehalten, bei diesen Blobs (Pseudo-Sprites) wird der Background hingegen nur für die Bereiche vorgehalten, in denen sich diese Dinger aktuell befinden. Der Vorteil der Blob-Methode ist schlicht, dass man dafür weniger Grafikspeicher benötigt, denn der war damals ziemlich knapp. Der Nachteil ist auch klar: Bevor man den Backbuffer für irgendwas verwenden kann, muss er erstmal angelegt werden. Man braucht also mehr "Rechenzeit" als bei der heute üblichen Methode. Rechenzeit deshalb in Anführungsstrichen, weil das Umkopieren der Daten typisch per DMA erledigt wird (auch damals beim Amiga schon).
Der Vorteil der Blob-Methode ist schlicht, dass man dafür weniger
Grafikspeicher benötigt, denn der war damals ziemlich knapp.
Grafikspeicher war nicht so das Thema, auf dem Atari ST waren das z.B. gerade mal 32.000 Bytes, die konnte man sich bei 1MB RAM auch 2x gönnen. Der Hauptvorteil eines Blitters war die Geschwindigkeit.
Ein Grafikobjekt in den Bildschirmspeicher zu bekommen, kostet (insbesondere bei "krummen" Koordinaten) CPU-Zeit, und dem Blitter musste man nur mitteilen, wie er mit Objekt, Maske und Ziel umgehen sollte.
Noch schöner waren natürlich Hardware-Sprites wie auf dem C64, aber die kamen dann wieder mit anderen Haken (insbesondere limitierte Zahl).
Grafikspeicher war nicht so das Thema, auf dem Atari ST waren das z.B.
gerade mal 32.000 Bytes, die konnte man sich bei 1MB RAM auch 2x gönnen.
Der AtariST war ja im Bezug auf die Grafikfähigkeiten im Vergleich zum Amiga auch eher so lala...
Der Hauptvorteil eines Blitters war die Geschwindigkeit.
Ja klar. Weil halt nicht die CPU rechnen musste, sondern der Blitter sowohl den Transport der Daten per DMA als auch die nötigen logischen Verknüpfungen erledigen konnte. Das konnte er allerdings nur leisten, wenn alle Quellen (bis zu drei) und das Ziel komplett in einem Speicherbereich lagen, der überhaupt per DMA erreichbar war. Beim Amiga war das auschließlich der sog. "Chip-RAM". Wieviel Chip-RAM möglich war, hing davon ab, welche Version des AGNUS-Chip auf dem Board war. Wieviel Chip-RAM tatsächlich installiert war, hing davon ab, wie tief der Besitzer in's Portemonnaie greifen konnte...
Ein Grafikobjekt in den Bildschirmspeicher zu bekommen, kostet
(insbesondere bei "krummen" Koordinaten) CPU-Zeit
Das war damals so (unabhängig vom Speicher-Layout) und ist heute auf dem PC im Prinzip noch ganz genau so.
Noch schöner waren natürlich Hardware-Sprites wie auf dem C64
Wie schon erwähnt: der Amiga hatte auch echte Hardware-Sprites.
aber die
kamen dann wieder mit anderen Haken (insbesondere limitierte Zahl).
Das war auch beim Amiga so: eingeschränkte Zahl, eingeschränkte Größe und eingeschränkte Farbauflösung. Allerdings konnte man die Dinger auf dem Amiga zeilenweise recyclen und damit die Einschränkungen teilweise aufheben. Allerdings war dann wieder die CPU gefordert, um das möglich zu machen, was dem Sinn der Hardware-Sprites doch leicht zuwieder lief. Nichtsdestotrotz wurde das recht oft gemacht. Praktische jede Partikelwolke einer Explosion wurde auf diese Art umgesetzt.
Ich programmiere meine Windows Anwendungen normalerweise auch in C++ mit ATL/WTL. Aber für so eine Spielerei würde ich doch HTML/CSS/JScript nehmen. Versuche das mal in C++ mit ca. 60 Codezeilen hin zu bekommen ;-)
Das Beispiel habe in nach 2 min Suche gefunden und dir zu einem File zusammenkopiert. https://codepen.io/Kit_Nickson/pen/bGEKxvB
Du kannst VS2022, aber auch jeden x-beliebigen Editor verwenden.
Debugger ist dein Browser.
Die Anforderungen für das Ballspiel kann man theoretisch ab Qt5 direkt mit Qml bauen, komplett ohne C++, nur per qml_scene mit allen möglichen Effekten.
Für C++ sollte das aber mit Qt normalerweise auch bloß ne Fingerübung sein.
Aber wenn darum geht, mal nen Dialog mitm Studio zusammenzuklickern, das Paint-Event zu überschreiben - Hardcore per GDI oder per DirectX/SDL - alle Möglichkeiten sind gegeben.
