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? Grüße Hans
Hans B. schrieb: > Ist das, was ich vorhabe mit Visual Studio 2022 C++ überhaupt machbar? Natürlich. Aber es gibt ungefähr 1 Dutzend Möglichkeiten, von GDI bis HTML5, ind du musst dir eine aussuchen die am Besten zum Test passt. DirectX ?
Hans B. schrieb: > 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.
Hans B. schrieb: > 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...
Wenn es nicht unbedingt C++ sein muss, dann wäre vielleicht Python mit pygame eine bessere Alternative. C++ hat heutzutage noch seine Anwendungsgebiete. Aber meiner Meinung nach gibt es für Desktopanwendungen mittlerweile bessere Programmiersprachen.
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.
Harald K. schrieb: > Die beste Programmiersprache ist die, die man bereits kennt. Widerspruch. Ich entwickle seit Jahrzehnten beruflich mit C++. Wenn ich die Aufgabe des TEs lösen wollte, wäre C++ trotzdem meine allerletzte Wahl.
Klaus schrieb: > 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.
Harald K. schrieb: > 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. zu beherzigen. Sondern mir etwas suchen, was einfach und schnell geht, vielleicht zB das hier als Startpunkt: https://p5js.org/examples/games-circle-clicker/
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.
:
Bearbeitet durch User
Bri schrieb: > 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.
Michael B. schrieb: > 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. Ja, kann man so sehen.
Harald K. schrieb: > 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
Ob S. schrieb: > wenn > das Endergebnis mal ein Spiel mit wirklich anspruchsvoller 3D-Grafik > werden soll dann wäre das halt was ganz anderes als Hans B. schrieb: > ein Windowsprogramm [..], bei dem sich ein Ball > in einem Fenster zufällig hin und her bewegt und sich, wenn man ihn > anklickt, verfärbt
Klaus schrieb: > dann wäre das halt was ganz anderes als > > Hans B. schrieb: >> 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.
Darf ich mal etwas (anderes) empfehlen? 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. https://processing.org/ Beispiele: https://processing.org/examples/bouncingball.html https://processing.org/examples/accelerationwithvectors.html
:
Bearbeitet durch User
Frank E. schrieb: > Darf ich mal etwas (anderes) empfehlen? Klar darfst du, ich hatte oben ähnliches schon in der Javascript-Variante empfohlen: Klaus schrieb: > das hier als Startpunkt: https://p5js.org/examples/games-circle-clicker/
Klaus schrieb: > Frank E. schrieb: >> Darf ich mal etwas (anderes) empfehlen? > > Klar darfst du, ich hatte oben ähnliches schon in der > Javascript-Variante empfohlen: > > Klaus schrieb: >> das hier als Startpunkt: https://p5js.org/examples/games-circle-clicker/ Ahhh ... da schließt sich quasi der Kreis: p5.js ist eng mit Processing verbunden, man kann wahlweise nach Java oder Javascript exportieren. :-)
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.
Leider kann Visual Studio ja keine DOS-Executables erzeugen, sonst könnte man z.B. mit VGA Mode 13h die Grafik darstellen 😉
Niklas G. schrieb: > Leider kann Visual Studio ja keine DOS-Executables erzeugen, sonst > könnte man z.B. mit VGA Mode 13h die Grafik darstellen Viele PCs haben kein CSM mehr in ihrer UEFI-Firmware. Damit ist DOS tot. Selbst wenn man einen DOS-Compiler verwenden würde (was dem Einsatz von DOSbox o.ä. voraussetzt), wäre der damit gewonnene Blumentopf leer.
Michael B. schrieb: > Tim schrieb: >> MFC und GDI > > Es gibt fertige Sprite samples. Bitte mal erklären! Ich mache immer double-buffering. Geht's auch anders?
Tim schrieb: > Michael B. schrieb: >> Tim schrieb: >>> MFC und GDI >> >> Es gibt fertige Sprite samples. > > 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).
Ob S. schrieb: > was z.B. beim Amiga zur Unterscheidung von echten Sprites (die der Amiga > auch hatte) "Blob" genannt wurde. Bobs, auch wenn es für "Blitter Objects" stand. Ob S. schrieb: > 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).
Hmmm schrieb: > 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.
Hans-Georg L. schrieb: > Das Beispiel habe in nach 2 min Suche gefunden und dir zu einem File > zusammenkopiert. https://codepen.io/Kit_Nickson/pen/bGEKxvB Also DAS kann man in VB oder C# sogar in wesentlich weniger als 60 (selbst zu schreibenden) Zeilen realisieren.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.