[Projekt] StoneQuestCPP

Hier könnt ihr euch selbst, eure Homepage, euren Entwicklerstammtisch, Termine oder eure Projekte vorstellen.
Forumsregeln
Bitte Präfixe benutzen. Das Präfix "[Projekt]" bewirkt die Aufnahme von Bildern aus den Beiträgen des Themenerstellers in den Showroom. Alle Bilder aus dem Thema Showroom erscheinen ebenfalls im Showroom auf der Frontpage. Es werden nur Bilder berücksichtigt, die entweder mit dem attachement- oder dem img-BBCode im Beitrag angezeigt werden.

Die Bildersammelfunktion muss manuell ausgeführt werden, die URL dazu und weitere Details zum Showroom sind hier zu finden.

This forum is primarily intended for German-language video game developers. Please don't post promotional information targeted at end users.
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

[Projekt] StoneQuestCPP

Beitrag von Zudomon »

Ich fang neu an... :D

Hallo Welt!
SQcpp.png
Mirror
Establishment
Beiträge: 248
Registriert: 25.08.2019, 05:00
Alter Benutzername: gdsWizard
Kontaktdaten:

Re: [Projekt] StoneQuestCPP

Beitrag von Mirror »

Tröste Dich, ich fange auch neu an, allerdings nur mit DirectX12 und DXR (Bestandteil von DX12).
Hat den StormWizard 1.0 und 2.0 verbrochen. http://www.mirrorcad.com
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: [Projekt] StoneQuestCPP

Beitrag von Zudomon »

Mirror hat geschrieben: 07.03.2021, 16:56 Tröste Dich, ich fange auch neu an, allerdings nur mit DirectX12 und DXR (Bestandteil von DX12).
Ehrlich gesagt ist das keine Trauerentscheidung bei mir. Ich denke, mit Turbo Delphi 2006 laufe ich immer weiter in eine Sackgasse. Das neue Delphi könnte man sich holen, aber vom hörensagen her ist die Community Lizenz auf 5000€ Umsatz im Jahr beschränkt. Nicht dass ich auch nur entfernt da ran käme, aber ich habe auch keine Lust, wenn es dann mal etwas mehr werden sollte mich da gleich bei Embarcadero zu rechtfertigen. Ich hatte eine Jahreslizenz bekommen, die ich aber jetzt nicht genutzt hatte. Ich bekäme die sogar jährlich erneuert aber trotzdem hätte ich dann doch das Gefühl, dass ich sehr Abhängig bin, weil ich die ja immer neu erfragen müsste. Und eine Permanente-Lizenz bekomme ich, so wie es aussieht, nicht gesponsort.
Ehrlich gesagt hat mich die Showcase Geschichte jetzt auch mehr als abgeturnt. Dass da im Endeffekt die Leistung keine Rolle spielt, sondern man theoretisch mit einem Hello World Programm und genug Follower den ersten Platz bekommen könnte...
C++ ist Industriestandard und ich mache ja eigentlich nur Delphi, weil ich denke, damit besser klar zu kommen. Und momentan habe ich den Drang, einfach nochmal alles ein bisschen zu überarbeiten und wenn ich das noch mit einem Umstieg auf die Gegenwart verbinden kann, ist das sicher nicht verkehrt. Also auf zu neuen Ufern... :D

Ich zieh mir jetzt erstmal das C++ Tutorial von Pilzschaf rein... es ist nicht so, dass ich nicht schon Erfahrungen in C++ gesammelt habe, aber so zum nochmal ganz bei Null anfangen schaue ich auch gerne nochmal die Grundlagen. Vielleicht gibt es ja dann doch das ein oder andere, was neu ist.
Und so ganz ein Neuanfang ist es ab einer gewissen Ebene sicher auch nicht, zumal ich ja später z.B. sämtliche Shader übernehmen kann.
Aber sicher auch nicht verkehrt, diesen neu Anfang auch zu nutzen um das Voxelzeugs meiner Engine nochmal neu zu schreiben. Naja. Jetzt erstmal klein starten... :D
Benutzeravatar
Jonathan
Establishment
Beiträge: 2353
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: [Projekt] StoneQuestCPP

Beitrag von Jonathan »

Wenn du auf C++ umsteigst, dürfte das hier ziemlich relevant sein:

https://isocpp.github.io/CppCoreGuideli ... Guidelines
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
Benutzeravatar
Chromanoid
Moderator
Beiträge: 4254
Registriert: 16.10.2002, 19:39
Echter Name: Christian Kulenkampff
Wohnort: Lüneburg

Re: [Projekt] StoneQuestCPP

Beitrag von Chromanoid »

Schon mal an Rust gedacht? Ist bezüglich Spieleentw. noch in den Kinderschuhen, aber es würde alleine deswegen sicher einige Follower bekommen und Du kannst mithelfen das Ökosystem der Sprache voranzutreiben https://www.rust-lang.org/ https://docs.microsoft.com/en-us/window ... ment/rust/ https://arewegameyet.rs/
Benutzeravatar
Jonathan
Establishment
Beiträge: 2353
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: [Projekt] StoneQuestCPP

Beitrag von Jonathan »

+1 für Rust. Ich habe damit mal ein paar Konsolenanwendungen gemacht und würde damit gerne mein nächstes Spiel machen. Was mich derzeit hauptsächlich davon abhält ist das große C++ Framework, das ich über die letzten Jahre aufgebaut habe und jetzt nicht einfach so wegschmeißen mag. Insbesondere auch da die Bibliotheken noch nicht sehr etabliert sind würde ich mich aber sehr über jeden zusätzlichen Rust-Spieleentwickler freuen.
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
Benutzeravatar
Schrompf
Moderator
Beiträge: 4838
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: [Projekt] StoneQuestCPP

Beitrag von Schrompf »

In meiner Bubble wandern die Leute schon wieder von Rust ab, weil die Sprache anscheinend ziemlich kompliziert ist und konzeptionell sehr übergriffig einschränkt. Aber da ich es nie ausprobiert habe, kann ich keine eigene Erfahrung beitragen.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
joeydee
Establishment
Beiträge: 1039
Registriert: 23.04.2003, 15:29
Kontaktdaten:

Re: [Projekt] StoneQuestCPP

Beitrag von joeydee »

Viel Glück dabei. Bin gespannt.
Mein Weg war ähnlich von "einfache Sprache, mit welcher ich ohne Nachdenken zurechtkomme, sollte für ein paar private Spielereien reichen" (aber zu abhängig vom Hersteller) über "C++ ist ja Industriestandard" (kannte/"konnte" ich auch noch von früher, aber das Doppeln in Header/Source, Kümmern um alle möglichen Kleinfäkalien, für mich teils kryptische Codekonstrukte für eigentlich einfache Operationen etc. fühlten sich insgesamt dann doch zu unbequem und kreativitätslähmend an) und bin nun erstmal bei C# mit der OpenTK-Lib (OpenGL-Wrapper) gelandet.
Benutzeravatar
Chromanoid
Moderator
Beiträge: 4254
Registriert: 16.10.2002, 19:39
Echter Name: Christian Kulenkampff
Wohnort: Lüneburg

Re: [Projekt] StoneQuestCPP

Beitrag von Chromanoid »

@Schrompf: Ich glaube "Hacker" mögen Rust wahrscheinlich nicht - gerade Spieleentwickler sind ja oft eher Hacker :). Viele andere Entwicklertypen werden von Rust glaube ich magisch angezogen. Und Unternehmen sowieso... Mich schrecken die wohl recht langen Compile-Zeiten ab, aber da wird wohl dran gearbeitet. Wahrscheinlich wird es durch die vielen compile-time Prüfungen aber nie super schnell sein. Ich finde das Sprach-Konzept eigentlich ziemlich gut, habe bisher aber nur wenig Erfahrungen gesammelt. Die empfundene Kompliziertheit scheint mir eher von Leuten verbreitet zu werden, die wenig bis gar nicht mit manuellem Speichermanagement zu tun hatten oder das ganze meist mit dem Holzhammer lösen - aber da würden mich tatsächlich die Stimmen in Deiner Bubble interessieren.
Benutzeravatar
Tiles
Establishment
Beiträge: 1990
Registriert: 11.01.2003, 13:21
Kontaktdaten:

Re: [Projekt] StoneQuestCPP

Beitrag von Tiles »

Mh, wenn du eh neu anfängst, was spräche denn gegen eine der grossen Engines statt alles wieder selber zu häkeln? Unreal zum Beispiel. Ich denke halt das dürfte die Entwicklung deutlichst beschleunigen.
Free Gamegraphics, Freeware Games https://www.reinerstilesets.de
Die deutsche 3D Community: https://www.3d-ring.de
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: [Projekt] StoneQuestCPP

Beitrag von Zudomon »

Hey, danke für euer zahlreiches Feedback.

@Rust
Das mag eine gute Idee sein, für jemanden, der gerne mit verschiedenen Sprachen rumspielt. Sich da reinfuchsen möchte. Neue Programmierfunktionen testen will. Aber mich kann man damit nicht begeistern(, außer es wäre meine eigene Programmiersprache). Ich möchte auch nicht zu den Versuchskaninchen gehören. Bei C++ ist alles da was man braucht. Als ich vor 21 von VisualBasic weg bin, wollte ich auch auf C. Aber damit bin ich nicht zurecht gekommen. Und dann wurde mir Delphi nahegebracht. Das sollte C++ eigentlich in nichts nachstehen. Von der Geschwindigkeit her sollte es ähnlich sein und zur Not kann man Assembler einbinden. Es gab schon diesen VCL Editor. Strings und Arrays waren da keine große Sache. Hörte sich gut an und ich war auch immer zufrieden. Nur so langsam hab ich einfach das Gefühl, dass ich an die Grenzen komme. Was nicht unbedingt an Delphi an sich liegt, sondern eher, dass ich noch in der Vergangenheit fest stecke. Das fängt mit Win32-Anwendungen an und geht bis zu Header Files für Oculus, die aber nur für die neueren Delphi Versionen sind. Und VR reizt mich sehr. Also dass für C++ direkt alles verfügbar ist, ist für mich ein großer Pluspunkt. Systemnähe, Geschwindigkeit, Industriestandard, viele Hilfen/Tuts/Code... ich denke, das Gesamtpaket ist schon echt super. Und durch Berufsschule, Studium und auch ein paar Arbeitseinsätze hab ich mittlerweile auch genug Grunderfahrung damit gesammelt, um damit auch für StoneQuest los zu legen. Man sollte auch bedenken, dass ich eben immer auf Delphi geblieben bin, lag in erster Linie daran, dass ich mich da so sicher gefühlt habe.

@Tiles
Als es mich '98/'99 damals gepackt hat, da war für mich die Überlegung, Unreal Engine oder Quake oder doch ganz was anderes. Jede Engine hatte ihre Vor- und Nachteile. Mal abgesehen davon, das Lizenzen damals unbezahlbar waren. Ich hatte bis dahin nur ein paar QuickBasic/VisualBasic 3D Sternenhimmel und Linienkonstrukte programmiert, was die 3D-Geschichte angeht. Das Dreiecke pro Pixel gemalt werden, konnte ich mir gar nicht wirklich vorstellen, weil QuickBasic halt so endlos langsam war. Und dann kam ich zu DirectX auf VB. Das ich auf einmal texturierte Dreiecke malen konnte, hat mich angestachelt, eine eigene Engine bauen zu wollen, die dann genau das kann, was ich gerne hätte.
Seitdem ist eigentlich meine ganze Programmiererei in Engine Entwicklung geflossen. Das möchte ich nicht alles weg werfen. Mal abgesehen davon, dass meine Motivation mich in anderen Engines einzuarbeiten bei Null liegt.
Früher gehörte die Engine zum Spiel dazu... Duke, Quake, Unreal, Doom3, die haben mich auch geflashed, weil die Engine immer so viel drauf gelegt hat. Ne, ich will kein Baukasten, nicht ein paar Module zusammenstecken und dann den gleichen Einheitsbrei haben, wie jeder andere. Womöglich noch Assets dazu kaufen. Den ein oder anderen Effekt kann man dann noch selbst dazu programmieren und sich vielleicht ein bisschen abheben.
Nein danke. Da geht für mich viel Kunst verloren. Kommt mir so vor, als ob ich ein Gemälde malen möchte, mir dafür aber zum größten Teil Bilder aus Zeitschriften ausschneide, zusammenklebe und die ein oder andere Ecke dann per Hand dazu male. Mag sein, das sich andere dabei gut fühlen. Oder eben das Ziel haben, möglichst schnell ein Spiel zu bauen, was heutigen Standards gerecht wird.
Aber bevor ich diese Schiene fahre, lasse ich es lieber ganz bleiben.

@Jonathan
Danke für die Guidelines. Mal sehen in wie weit ich mich da rein arbeite und vielleicht was davon mitnehmen werde. Einführung hab ich gelesen und mal kurz unter Source Files geschaut, weil ich da zumindest direkt ein bisschen nachvollziehen konnte. So wie es aussieht, hält man sich wahrscheinlich auch schon an ein paar Dinge... z.B. Header .h, Implementation .c bei C und .cpp bei C++. Die nächsten Dinge, die da standen kamen mir auch schon bekannt vor.
Benutzeravatar
marcgfx
Establishment
Beiträge: 2050
Registriert: 18.10.2010, 23:26

Re: [Projekt] StoneQuestCPP

Beitrag von marcgfx »

Unreal würde ich mir an deiner Stelle schon etwas genauer überlegen. Glaubst du nicht, dass all deine prozeduralen Ansätze extrem von einer stabilen Engine profitieren könnten, ohne dass dabei Kunst verloren geht? Prozedurale Bäume, Pflanzen, Drachen etc sind ja alle nicht schon in Unreal vorhanden. Eine Engine ist schlussendlich auch nur ein Werkzeug, was du damit machst ist deine Sache. Jedes Mal das Rad neu erfinden ist eine grosse Investition.
Benutzeravatar
Tiles
Establishment
Beiträge: 1990
Registriert: 11.01.2003, 13:21
Kontaktdaten:

Re: [Projekt] StoneQuestCPP

Beitrag von Tiles »

Und bei Unreal gibts noch den Source Code oben drauf. Also eigentlich ohne Limits. Und wenn nicht Unreal, dann vielleicht Godot. Die würden sich auch sicher über Verstärkung im Team freuen :)

Ich sehe da halt ein Manpower Problem wenn du wirklich alles selber machen willst. An der Unreal Engine arbeiten glaube ich inzwischen 200 Leute, Fulltime. Bei Unity sinds glaube ich weit über 1000. Und das seit vielen Jahren. Da kann man als Teilzeit Lone Wolf einfach nicht gegen ankommen. Wer soll deine Engine denn noch nutzen bei so einer Konkurenz? Du entwickelst ja im Grunde auch diese Version schon wieder nur für den Papierkorb, was ich unglaublich schade finde. Denn das was du schon hattest sah doch schon super aus. Es war halt kein nutzbares Produkt.

Aber das ist eben wieder die Frage ob du was produzieren und entwickeln willst was dann auch benutzt wird, oder ob du wegen Self Entertainment "nur" programmieren willst. Als Entwickler suche ich mir die schnellste und bequemste Möglichkeit um mein Entwicklungsziel zu erreichen. Als Programmierer will ich eher Code schreiben, da ist die Frage wie man das Entwicklungsziel am effizientesten erreicht eher zweitrangig. Und die Entscheidung kannst natürlich nur du treffen.

Egal wie du dich entscheidest, ich wünsche dir viel Erfolg dabei :)
Free Gamegraphics, Freeware Games https://www.reinerstilesets.de
Die deutsche 3D Community: https://www.3d-ring.de
scheichs
Establishment
Beiträge: 845
Registriert: 28.07.2010, 20:18

Re: [Projekt] StoneQuestCPP

Beitrag von scheichs »

Also ich rate als Unity-Dev von einer externen Engine ab. Ganz einfach weil Du für Stonequest nicht viel davon brauchen wirst, was die Engines Dir liefern. Du musst dich bei dem prozeduralen/Chunk-Ansatz eh um das gesamte Resourcenmanagement kümmern und alles von Hand optimieren.
Ich hab damals Unity gewählt, weil ich schnell auf alle Platformen portieren wollte, aber das ist für Dich vermutlich eh uninteressant.
Aber ich habe schon etliche Monate damit verbracht, um Restriktionen und Bugs von Unity herumzuprogrammieren (z.B. konne man bis 2017 nur mit Memory Garbage VBOs erstellen, bei dynmischer Geometrie total super!).

Den Schritt "Neu Anzufangen" finde ich ganz gut. Das bringt sicher auch wieder Motivation die Ergebnisse/Fortschritte zu sehen, und gleichzeitig kannst Du Dich über "sauberen" Code freuen. Ich hoffe einfach mal drauf, dass Du Deine Problemstellen gleich mitfixst (also spannendes Terrain, LOD und keine Exceptions ;) )

Bin gespannt!
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [Projekt] StoneQuestCPP

Beitrag von Krishty »

C++, really?! Ich hätte dich eher als C-Programmierer einsortiert.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
marcgfx
Establishment
Beiträge: 2050
Registriert: 18.10.2010, 23:26

Re: [Projekt] StoneQuestCPP

Beitrag von marcgfx »

scheichs: Also ich rate als Unity-Dev von einer externen Engine ab. Ganz einfach weil Du für Stonequest nicht viel davon brauchen wirst, was die Engines Dir liefern. Du musst dich bei dem prozeduralen/Chunk-Ansatz eh um das gesamte Resourcenmanagement kümmern und alles von Hand optimieren.
Ich hab damals Unity gewählt, weil ich schnell auf alle Platformen portieren wollte, aber das ist für Dich vermutlich eh uninteressant.
Nicht portieren zu können tut ziemlich weh...
Benutzeravatar
Chromanoid
Moderator
Beiträge: 4254
Registriert: 16.10.2002, 19:39
Echter Name: Christian Kulenkampff
Wohnort: Lüneburg

Re: [Projekt] StoneQuestCPP

Beitrag von Chromanoid »

Ja, wobei man C++ mit OGL leichter portieren kann als JavaScript mit Canvas... JavaScript mit WebGL ist sicher auch noch mal besser als Canvas usw.

@Zudo: Mit Rust könntest Du, wie Du es Dir bei dem Delphi Showcase gewünscht hast, sicher einige Techies begeistern. Wenn Du das mit C++ machst, wirst Du in der Hinsicht nichts gewinnen - eher im Gegenteil.

Ich würde Dir dringend von C++ abraten :) große Code-Bases machen damit glaube ich absolut keinen Spaß. Bei Rust ist das wahrscheinlich auch kein Zuckerschlecken, aber wahrscheinlich nicht so auf rudimentärer Ebene nervig.

Bei Unity3D könnte ich mir vorstellen, dass Du einiges an Code auch im Asset-Store verkaufen kannst - also Pflanzen-Generatoren, prozedurale Animation etc. Dort gibt es mittlerweile auch schöne Low-Level APIs, siehe Burst Compiler etc. Ich habe damit noch nie was gemacht, aber das ist so mit meine einzige aktuelle Perspektive, wenn ich mal zum Spieleentwickeln käme.
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: [Projekt] StoneQuestCPP

Beitrag von Zudomon »

Chromanoid hat geschrieben: 08.03.2021, 13:18 Ich würde Dir dringend von C++ abraten :) große Code-Bases machen damit glaube ich absolut keinen Spaß.
Krishty hat geschrieben: 08.03.2021, 11:42 C++, really?! Ich hätte dich eher als C-Programmierer einsortiert.
Ihr habt mich überzeugt! :D Ich werde es mit C probieren...
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [Projekt] StoneQuestCPP

Beitrag von Krishty »

Keine falsche Panik – ich programmiere ja auch C++. Aber eben ohne Klassen, ohne Standardbibliothek, minimale Templates, usw.

Auf Operatorüberladung würde ich z. B. nicht verzichten wollen. C hat mittlerweile Generics für Überladung, aber wirklich gefallen tun die mir nicht.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Spiele Programmierer
Establishment
Beiträge: 426
Registriert: 23.01.2013, 15:55

Re: [Projekt] StoneQuestCPP

Beitrag von Spiele Programmierer »

Als jemand der die letzten Jahre vor allem mit C++ gearbeitet hat, kann ich den Vorrednern nur zustimmen und dir von C++ abraten.

Ne ehrlich, C++ ist sehr verbreitet und flexibel. Das spricht für die Sprache und ist erstmal gut. Aber sonst, auweh... Das Leid, welches man als C+++-Programmierer alltäglich ausgesetzt ist ist groß. ;)

Rust wurde ja schon genannt. Meiner Meinung nach wäre das eine gute Wahl. Speziell nach den von dir genannten Wünschen bezüglich dem, was du dir von C(++) versprichst, möchte ich aber auch noch einen anderen Kandidaten vorschlagen: Zig.
Zig ist im Vergleich zu Rust eher wie C und weniger wie C++. Wobei es sicherlich mehr Abstraktionen anbietet als C. Diese sind oft allerdings "nützlicher" als was in C++ angeboten wird. Zum Beispiel gibt es in C++ eine komplizierte Template-Machinerie, die aber trotzdem unzählige Dinge gar nicht ermöglicht. Zum Beispiel eine Enumeration in einen String umwandeln: Unmöglich. In der Praxis stößt man andauernd zu unzähligen Limitierungen im Detail, die hässlichen Workaround-Code erfordern. Und das gleichermaßen und egal ob du Templates oder irgendeinen anderen leicht fortgeschrittenen Aspekt der Sprache C++ verwendest.

Einige der Vorteile von Zig sind:
  • Du kannst C-Code oder C-Header einbinden. Ein C und C++-Compiler (Clang) ist direkt integriert, d.h. du kannst C-Code einfach direkt inkludieren und verwenden wie in C. Keine Wrapper oder andere Zwischenwelten notwendig.
  • Absolute Kontrolle über alle Speicherallokationen.
  • Kein Ärger mit Build-Systemen. In C++/C brauchst du auf kurz oder lang jede Menge Komplikationen die sich MSBuild, CMake, Makefiles, Ninja, Meson, usw. usf. nennen.
  • Verglichen mit Rust oder ganz besonders "modernen" C++ ist die Sprache "einfach".
  • 1A-Cross-Platform-Support. Du kannst einfach von Windows für FreeBSD 64 Bit kompilieren und musst dich um nichts kümmern.
Da du ja recht low-levelig-unterwegs bist, stelle ich mir vor, dass das deinen Wünschen entsprecht.

Natürlich gibt es auch Nachteile. Zum Beispiel:
  • Wenn du bei DirectX bleiben willst, gibt es ein kleines Problem, da DirectX leider nicht einfach eine C-API ist, sodern eine Windows-COM-API. Hier könnte es sein, dass du das nicht direkt 1-1 verwenden kannst. Bei einer kurzen Recherche finde ich auch in Internet wenig dazu. Ich denke, dass liegt auch am "Cross-Platform-Spirit" der Sprache. Dadurch ist das Interesse vermutlich reduziert.
  • Natürlich gibt es viel weniger Zig spezifische Tutorials und so im Internet. Das ist ein Punkt den du extra genannt hast und bei dem Zig nicht punkten kann. Du musst bereit sein, ein bisschen zu experimentieren.
Insgesamt denke ich aber, dass diese Anfängerschweirigkeiten in begrenzter Zeit überwindbar sind und du dann langfristig viel komfortabler programmieren kannst, als jemals mit C++. Mir geht es im Prinzip genauso wie Jonathan: Wenn ich nicht schon so viel Code in C++ hätte, würde ich C++ fallen lassen wie ein heißes Eisen. In letzter Zeit gibt es viele neue Sprachen mit vielversprechenden Ansätzen, wo ich vor einigen Jahren den Eindruck hatte, dass nur VM/GC-Sprachen aus dem Boden schießen. Ich würde es zumindest mal ausprobieren.

Weißt du eigentlich schon, welche Grafik-API du verwenden willst? DIrectX9 ja wohl wahrscheinlich nicht mehr. DirectX11? Direkt Vulkan?
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: [Projekt] StoneQuestCPP

Beitrag von Zudomon »

Ich würde es wirklich erstmal gerne mit C/C++ probieren.
Spiele Programmierer hat geschrieben: 08.03.2021, 19:14 Weißt du eigentlich schon, welche Grafik-API du verwenden willst? DirectX9 ja wohl wahrscheinlich nicht mehr. DirectX11? Direkt Vulkan?
Ich bin ja letztes Jahr auf OpenGL umgestiegen und würde da auch erstmal bleiben.

Allerdings finde ich bisher kein Tutorial um OpenGL native einzubinden. Überall wird dann z.B. GLUT oder GLFW benutzt. Würde das schon gerne komplett zu Fuß haben.

EDIT: Da meine Geduld bei sowas auch immer gegen Null geht, werde ich wohl dann erstmal GLFW benutzen... das scheint noch etwas schlanker zu sein.
Benutzeravatar
Schrompf
Moderator
Beiträge: 4838
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: [Projekt] StoneQuestCPP

Beitrag von Schrompf »

GLFW nehme ich auch, Splatter wurde damit released. Ich kriege gelegentliche Crash-Reports vor allem von Linuxern, aber das ist normal. Bei den allermeisten Leuten läuft GLFW prima.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
xq
Establishment
Beiträge: 1581
Registriert: 07.10.2012, 14:56
Alter Benutzername: MasterQ32
Echter Name: Felix Queißner
Wohnort: Stuttgart & Region
Kontaktdaten:

Re: [Projekt] StoneQuestCPP

Beitrag von xq »

Spiele Programmierer, danke dass du mein "Nimm doch Zig"-Schreien übernommen hast, ich habe mich etwas zurückgehalten
Spiele Programmierer hat geschrieben: 08.03.2021, 19:14 Natürlich gibt es auch Nachteile. Zum Beispiel:
  • Wenn du bei DirectX bleiben willst, gibt es ein kleines Problem, da DirectX leider nicht einfach eine C-API ist, sodern eine Windows-COM-API. Hier könnte es sein, dass du das nicht direkt 1-1 verwenden kannst. Bei einer kurzen Recherche finde ich auch in Internet wenig dazu. Ich denke, dass liegt auch am "Cross-Platform-Spirit" der Sprache. Dadurch ist das Interesse vermutlich reduziert.
  • Natürlich gibt es viel weniger Zig spezifische Tutorials und so im Internet. Das ist ein Punkt den du extra genannt hast und bei dem Zig nicht punkten kann. Du musst bereit sein, ein bisschen zu experimentieren.
Dazu zwei Dinge: Es gibt mittlerweile sehr viele gut gepflegte Community-Projekte für "Learn Zig". Zum anderen bekommt man wohl auch COM-Apis relativ gut eingebunden, Michael hat das wohl hinbekommen, den netten Herrn kann man auch anschreiben und fragen.

Persönlich bin ich fast auf 100% Zig umgestiegen. C++ und C liegen hinter mir, Rust liegt irgendwo auf der Seite (as in: Hab ich mir angeschaut und nicht weiter vertieft, war mir zu komplex)
War mal MasterQ32, findet den Namen aber mittlerweile ziemlich albern…

Programmiert viel in ⚡️Zig⚡️ und nervt Leute damit.
Benutzeravatar
Tiles
Establishment
Beiträge: 1990
Registriert: 11.01.2003, 13:21
Kontaktdaten:

Re: [Projekt] StoneQuestCPP

Beitrag von Tiles »

Ich war ja immer ein Fan davon die Sprache/das Tool nach dem Entwicklungsziel auszuwählen. Und wo möglich der breiten Masse zu folgen weil es da eben die meisten Ressourcen und entsprechende Unterstützung gibt.
Free Gamegraphics, Freeware Games https://www.reinerstilesets.de
Die deutsche 3D Community: https://www.3d-ring.de
Matthias Gubisch
Establishment
Beiträge: 470
Registriert: 01.03.2009, 19:09

Re: [Projekt] StoneQuestCPP

Beitrag von Matthias Gubisch »

C++ ist halt die Sprache die man immer benutzten KANN.
Es ist sicher nicht immer das perfekte Werkzeug, aber eins das zu 99% funktioniert.
Ich kann damit halt von Assembler/Intrinsics bis hin zu OOP oder Templates alles machen. Diese Vielseitigkeit ist sicher auch verantwortlich fuer die weite Verbreitung.

Rust finde ich relativ komplex, dann kannst auch C++ nehmen, da hast du den Vorteil der groesseren Verbreitung. Zig hab ich mir noch nicht angeschaut daher kann ich nichts dazu sagen.

Bezüglich fertige Engine noch eine Anmerkung: Sowie ich Zudo aus seinen Posts einschätze liegt sein Interesse mehr an der Technik dahinter als am fertigen Spiel (ähnlich wie bei mir) deshalb hilft ihm eine fertige Engine vermutlich nicht viel.
BTW ich wuerde dir Vulkan anstatt OGL empfehlen, ist zwar erst mal etwas länglich für das erste Dreieck, aber dafür deutlich leichter zu debuggen als OGL und wenn man mal eine gewisse Abstraktionsebene in seiner Codebase erreicht hat merkt man eh nicht mehr viel davon ob jetzt OGL oder Vulkan dahinter steckt. Eine Portierung auf andere Plattformen und auch Mobile wird damit IMO auch leichter als mit OGL.

Zum Abschluss noch viel Spass und Erfolg bei deinem Neuanfang :) Ich freue mich schon auf die neuen Bilder ;)
Bevor man den Kopf schüttelt, sollte man sich vergewissern einen zu haben
Benutzeravatar
Chromanoid
Moderator
Beiträge: 4254
Registriert: 16.10.2002, 19:39
Echter Name: Christian Kulenkampff
Wohnort: Lüneburg

Re: [Projekt] StoneQuestCPP

Beitrag von Chromanoid »

Matthias Gubisch hat geschrieben: 09.03.2021, 09:17Rust finde ich relativ komplex, dann kannst auch C++ nehmen, da hast du den Vorteil der groesseren Verbreitung.
Naja Rust bringt ja etwas anders gelagerte Komplexität mit. Außerdem hat man ein funktionierendes Modul-System und Package-Management mit Cargo. Das ist sicher einer der Haupttreiber hinter Rusts Beliebtheit. Der pauschale Vergleich "komplex vs. komplex" hinkt da schon sehr finde ich.
Benutzeravatar
Schrompf
Moderator
Beiträge: 4838
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: [Projekt] StoneQuestCPP

Beitrag von Schrompf »

Jetzt lasst Zudo mal machen. So wie ich ihn kenne, hat er Spaß am Technikgebastel. Und das C++-Buildsystem ist zwar der schiere Hass, aber da Zudo ja meist alles selbst machen will, wird er damit weniger Probleme haben als andere Leute. Vermute ich.

viel Spaß, Zudo. Und zeige ein paar Bilder, wenn Du was hast. Ich würde mich drüber freuen.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [Projekt] StoneQuestCPP

Beitrag von Krishty »

Matthias Gubisch hat geschrieben: 09.03.2021, 09:17BTW ich wuerde dir Vulkan anstatt OGL empfehlen, ist zwar erst mal etwas länglich für das erste Dreieck, aber dafür deutlich leichter zu debuggen als OGL und wenn man mal eine gewisse Abstraktionsebene in seiner Codebase erreicht hat merkt man eh nicht mehr viel davon ob jetzt OGL oder Vulkan dahinter steckt. Eine Portierung auf andere Plattformen und auch Mobile wird damit IMO auch leichter als mit OGL.
Mich hat von Vulkan immer abgehalten, dass der User eine bestimmte Mindest-Treiberversion braucht. Sind die Treiber jetzt garantiert präsent, wo Windows 7 weg ist?
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: [Projekt] StoneQuestCPP

Beitrag von Zudomon »

Vielen Dank für die Anregungen, Gedanken, Diskussionen, Meinungen und auch Glückwünsche! :D
(btw. schade das Smileys hier immer noch nicht gehen, ich nutze die gerne, da waren die Posts dann immer schöner gelber Punkte)

@C/C++ Umstieg
Ja, also mein Entschluss erstmal C/C++ zu machen steht ja. Ich bin froh, dass ich da jetzt den Anfangswiderstand überwunden habe. Und wie ja hier auch schon gesagt wurde, auf die Sprache kann man sich da erstmal verlassen. Und tatsächlich spielt mir "selbst machen" sogar sehr in die Hände, denn vieles was ich selbst gemacht habe, kann man ja jetzt auch einfach von Delphi auf C++ übersetzen. Die meisten Sachen sind auch gar nicht so komplex, weil ich hauptsächlich auf Arrays arbeite, kaum mal komplexen Strukturen und Klassenhierarchien.
Erfahrung werde ich durch den Umstieg sicher sammeln und vermutlich auch die Engine sauberer bekommen. Ich bin ja immer noch auf dem Stand, dass Daten und Code durchmischt sind. Das sollte man auf jeden Fall trennen... und mehr Modularität. In Delphi war es ja auch nur ein Kopfproblem, wenn man die Units munter Zirkular voneinander abhängig macht. Ich glaube, bei C muss man sich da schon an eine gewisse Grundordnung halten.
Was mir auch direkt nochmal aufgefallen ist während ich mir das Tutorial von Pilzschaf ansehe ist ja, dass Delphi viel mehr auf Typen achtet. Also einfach mal so Funktionszeiger übergeben, geht zwar in Delphi auch, aber man muss die vorher immer fest definieren usw.
Gefällt mir gut an C. Und was mir prinzipiell an C auch gefällt ist, dass man Variablen Lokal (also nicht am Funktionsanfang) deklariert. Meine Funktionen sind manchmal sehr ausschweifend und wenn ich dann alle Variablen vorher angeben muss, entsteht da halt ne lange Liste. Und wenn man diese Variablen später nicht mehr benutzt, wegen Refactoring, bleiben die Variablendefinitionen zwecks Faulheit meist erstmal bestehen.

@ZFX
Ich habe ja lange nicht mehr wirklich hier meinen Fortschritt dokumentiert. Weil es eben auch schwer ist, immer das Ganze runter zu brechen und zu präsentieren. Wenn das Projekt klein ist, dann geht das noch relativ gut. Außerdem ist dann der Fortschritt extrem ersichtlich. Wenn das Projekt groß ist, und man an vielen Stellen ausbessert, dann ist das eigentlich nicht mehr so interessant.
Die Frage, die sich mir auch stellt ist, wie am besten präsentieren. Auf den FB-pages? Auf YT? Auf Twitter? Hier? Und meine Motivation mich überhaupt so selbst zu dokumentieren lässt eh zu wünschen übrig.
Tja, also mal sehen...
Ich bräuchte irgendwie eine zentrale Stelle... vielleicht doch die eigene Homepage? Bietet natürlich auch alles seine Vor- und Nachteile. Hier im Forum kann man lang und breit diskutieren. Auf FB ist das alles schon etwas eingeschränkter, dafür hat man aber ein Likesystem und neue Posts gehen auch nicht so schnell unter, weil die ja quasi die Threads darstellen. Und Twitter ist gut, um schnell kleine Posts raus zu hauen. Hab gelesen, dass man auf Twitter ruhig mehrmals am Tag was schreiben sollte... aber da wäre dann eben auch viel Belangloses.

@OpenGL/Vulkan
Ja, ich würde gerne hinterher auf Vulkan umsteigen. OpenGL war für mich vor allem ein Zwischenschritt, um den Umstieg nicht direkt von DirectX9 aus machen zu müssen. Allerdings, und das habe ich mir jetzt auch mit der Engineüberabeitung gedacht, ist es sicher einfacher, erstmal wo es möglich ist, den alten Code zu übernehmen. Ist ja quasi dann wie ein Buch zu übersetzen. Wenn man da dann anfängt die Geschichte umzuschreiben, dauert es eventuell wesentlich länger als wenn man später dann nochmal entsprechend überarbeitet.

@GLFW
Nachdem ich gestern Abend noch die OpenGL Initialisierung gemacht habe, wollte ich unbedingt schon mal das Anwendungsicon ändern. 3 Stunden hab ich dafür gebraucht. Das Icon wird ja als Ressource eingebunden. Nachdem ich aus der png erstmal ein ico gemacht habe, hatte meine Anwendung auch entsprechendes Icon bekommen. Allerdings wird ja das Fenster von GLFW erzeugt und da ein Standardicon gesetzt. Und das wollte ich auch noch ändern.
Also, man kann per Funktion das Icon dynamisch ändern, braucht dann allerdings die Bilddaten. Und überhaupt war mir das etwas too much. Nachdem man dann ein paar Internetquellen abgegrast hat, wurde mir klar, dass es scheinbar reicht, wenn das Icon als id "GLFW_ICON" bekommt. Aber trotzdem war das alles sehr erfolglos und ich war schon versucht, hier nachzufragen. Doch der Gedanke, schon bei so etwas grundlegendem zu scheitern, hat mich zum rumprobieren motiviert.
Ich muss dazu sagen, ich kenn mich mit Ressourcendaten für EXE kaum aus.
Jedenfalls war das Problem, dass die RC-Datei, die ich mit Visual Studio 2019 erstellt habe da wohl irgendwas anders macht, als es GLFW erwartet. Mit einem extra Ressourceneditor, in dem ich dann das Icon entsprechend angelegt habe hat es geklappt. Dachte erst, man müsste da auch noch was zusätzlich machen, aber es reicht ja, dann die RES-Datei dem Projekt hinzuzufügen. Tja, wenn man weiß wie es geht, kann man das in 5 Minuten hinbekommen.
Hab mir vorhin noch frech den Code für das erste Dreieck kopiert (https://learnopengl.com/Getting-started/Hello-Triangle). Da spar ich dann wieder ein bisschen Zeit ein. Fühlt sich ein bisschen komisch an, weil ich normalerweise jetzt wieder alles lesen würde und vielleicht auch selbst zusammenkopieren. Da ist dann der Lerneffekt größer. Aber ich denke, so langsam weiß ich ja, wie Dreiecke auf den Bildschirm kommen und der Code ist ja letztendlich auch nur eine Starthilfe und wird dann hinterher durch das eigene Framework ausgetauscht.
(btw. alles lesen: Am Anfang bin ich motiviert, lese auch Vorwörter von Büchern usw. und nach einiger Zeit hab ich keinen Bock mehr und lass es komplett bleiben, hahaha...)
Benutzeravatar
Schrompf
Moderator
Beiträge: 4838
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: [Projekt] StoneQuestCPP

Beitrag von Schrompf »

Das AppIcon auf Windows hab ich tatsächlich auch vor ner Weile neu lösen müssen, weil mir die Magic Constants und das VisualStudio-spezifische Ressourcengebastel zünftig auf die Nerven gingen. So sieht das dann aus:

Code: Alles auswählen

  struct SomeImage { size_t width, height; uint32_t* pixel; };
  SomeImage image = getYourAppIcon();

  std::vector<uint8_t> andBitmask( (image.width * image.height + 7) / 8, 0xff);
  auto icon = CreateIcon( GetModuleHandleW(nullptr), (int) image.width, (int) image.height, 1, 32, andBitmask.data(), image.pixel);
  
  SendMessage(mWinFenster, WM_SETICON, ICON_SMALL, (LPARAM) icon);
  SendMessage(mWinFenster, WM_SETICON, ICON_BIG, (LPARAM) icon);

  //This will ensure that the application icon gets changed too.
  SendMessage(GetWindow(mWinFenster, GW_OWNER), WM_SETICON, ICON_SMALL, (LPARAM) icon);
  SendMessage(GetWindow(mWinFenster, GW_OWNER), WM_SETICON, ICON_BIG, (LPARAM) icon);
Zusammengebaut aus StackOverflow-Antworten. CreateIcon() will halt die Daten als AndBitmask und OrBitmask haben, was reichlich wirr ist, aber wahrscheinlich aus anderen Zeiten stammt. OrBitmask ist jedenfalls das PixelArray als uint32 ARGB, das sagt der Parameter 32 davor. Und die AndBitmask ist die Schablone, AnAus-Transparenz. Die hab ich pauschal auf AllesEins gestellt. Und der Rest untendran ist dann WinAPI-Magic, die ich nicht verstehe oder nachvollziehen kann. Aber es scheint zu funktionieren.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Antworten