Hopalong - Fraktal

Der UpdateLoop sorgt dafür, dass alle Objekte im Spiel regelmäßig geupdatet werden. In diesen Loop kommt die Logik.
Das zeichnen findet dann im RenderLoop statt, der ebenfalls in einer Dauerschleife läuft. Dort gibts aber keine Stopwatch, da die Renderer entweder so schnell wie möglich oder mit VSync arbeiten können (mehr dazu in der nächsten Version).

Es ging dir doch darum, Multithreading umzusetzen, oder nicht? So gehts. Versuch selbst einfach mal, GDI+ in nem Nebenthread zu benutzen, funktioniert nicht so ohne weiteres.
Außerdem will ich dir nahebringen, wie man Logik und Anzeige voneinander trennen sollte.

Hm, du hast halt alles aus meiner Lib so ineinander verwoben, es war aber durchaus meine Absicht, alles so schön voneinander loszulösen. Und vor allem ist auch wichtig, dass nicht die Form der Mittelpunkt der Anwendung ist, die Form dient nur zur Darstellung.
In dem Grundgedanken meiner Lib würde das Fraktal IGameObject implementieren.

Mir scheint, du hast nicht wirklich verstanden, wie die Lib bzw. das Prinzip der Spieleprogrammierung funktioniert.
Machs einfach so, wie du denkst, ich bin gerade beschäftigt und kann jetzt keine ausschweifenden Erklärungen liefern.

Was ist jetzt eigentlich dein Ziel: Eine schön anzusehende, schnelle und flüssige Animation, dafür halt nicht sofort, sondern mit etwas Zeitverzögerung am Anfang oder lieber ein sich direkt nach dem Button-Klick "Live" bildendes Fraktal?

Ich würds ja gerne erklären, aber dann würde ich nächstes Jahr immer noch hier sitzen. Man kann einfach kein Tutorial über eine Engine machen, man muss ganz alleine darauf kommen, wie sowas geht. Ja, das meine ich tatsächlich so. Irgend wann, wenn man lange genug am Ball bleibt und intensiv übt, kommt einem sowas dann schon von ganz allein in denn Sinn (natürlich ist meine Engine bei weitem nicht perfekt, es ist wohl immer noch eine sehr einfach gehaltene Möglichkeit, sowas zu realisieren).

Artentus schrieb:

Man kann einfach kein Tutorial über eine Engine machen, man muss ganz alleine darauf kommen, wie sowas geht.

Halte ich für totalen Unfug.
Imo, alles was man lernen kann, kann man auch erklären.
Sind ja keine mystischen Erfahrungen oder sowas

Kann sein, dass Grundlagen nachzuarbeiten sind, auch in großem Maßstab. Darauf kommt man imo recht schnell, wenn man ein lauffähiges Beispiel verfügbar hat, weil daran kann man genau die Codezeilen benennen, die man nicht versteht.
Aber viel üben, bis man von selbst drauf kommt - nope.

So hab ichs aber gemacht. Ich hab mich nicht hingesetzt und gesagt "So, jetzt lerne ich, wie man ne Engine programmiert!", ich hatte einfach irgendwann das Gefühl, dass ich nun in der Lage bin, mich an sowas ranzuwagen.

na, aber trotzdem musst du es erklären können.

stimmt natürlich schon, dass man auch Dinge lernen kann, die einem keiner erklärt - Pionier-Arbeit also. Aber sobald die Pionier-Arbeit einmal geleistet ist, kann der Pionier erklären wies geht.
Bei wissenschaftlicher Pionier-Arbeit ist das nicht nur für die Nachfolger eine enorme Vereinfachung, sondern auch der Prüfstand für die Stimmigkeit der erarbeiteten Ergebnisse.

Aber ich glaub auch garnicht, dass fürs Entwickeln einer Engine soo viel Pionier-Arbeit zu leisten ist. Engines gibts ja bereits, und also gibts auch KnowHow dazu.
Kann natürlich sein, deine Engine ist besonders originell, und daher besonders einfach zu verwenden, oder bietet neue Möglichkeiten. Aber auch dann musst du erklären können, wie sich deine Engine von anneren abhebt.

Edit: Aber das führt auch bisserl weg. Du musst ja nicht erklären, wie man eine Engine programmiert, aber zumindest solltest du erklären können, wie man deine Engine benutzt. Das kannman den Leuts nicht hinklatschen und sagen: "Nu üb man damit, bis du drauf kommst!"

Ich hab nie behauptet, dass ich ein Meisterwerk geschaffen hätte, ganz im Gegenteil. Die Engine entwickle ich deshalb, weil ich besser werden will, als Übung sozusagen. und ja, natürlich habe ich mir einiges dazu angesehen, aber das bezog sich alles nur auf Theorie, nicht auf die tatsächliche Umsetzung im Code. Die entspringt ganz und gar meiner eigenen Vorstellung.
Was ich sagen will ist, es reicht nicht bloß, ein Ziel vor Augen zu haben (das ist natürlich auch wichtig), man muss sich auch (zumindest im Groben) vorstellen können, wie man dorthingelangt. Und ein Tutorial hilft einem in diesem Fall nicht wirklich weiter, denn ich bin der Meinung, solange man ein Problem nicht selbst lösen kann, kann man auch nicht vollkommen verstehen, was ein anderer sich bei der Problemlösung gedacht hat (Problem meint hier natürlich ausschließlich im programmiertechnischen Sinne).
Da ich nun mine eigene Engine entwickelt habe (oder eigentlich noch entwickle) fällt es mir nun auch viel leichter, bei anderen Engines durchzublicken, da ich nachvollziehen kann, was sich der Ersteller bei bestimmten Dingen gedacht haben könnte. Wenn ich einfach nur nen Code hingelegt bekommen würde, dann wüsste ich nicht um die Probleme, die der Entwickler zu lösen hatte und könnte deswegen auch seine Lösungswege nicht nachvollziehen.
Ich will damit nicht sagen, dass man ohne lernen auskommt, ich selbst musste ja auch einiges lernen, bevor ich sowas machen konnte, aber imo reicht es aus, seinen Geist zu schulen in "Programmierbahnen" denken zu lassen, um ein guter Programmierer zu werden. Beim Programmieren muss man eben auf eine ganz spezielle Art und Weise denken, was man so absolut nicht gewohnt ist, aber wenn mans schafft, dann ergibt sich der Rest eigentlich von selbst. Ich muss (meistens, komplizierte Fälle ausgenommen) nicht mehr wirklich über den Code nachdenken, den ich schreibe, ich habe einfach einen Plan in meinem Kopf, wie ich das Problem lösen möchte, und der Code ergibt sich dann von selbst.

Wie man die Engine benutzt, kann man übrigens im Beispielprojekt sehen. Klar, dass das nicht funktioniert, wenn man einfach nur Teile der Engine nimmt und sie irgendwie notdürftig zusammenflickt.

Les dir mal das Buch Microsoft Visual Basic 2010 - Das Entwicklerbuch durch, da sind die wichtigsten Grundlagen genannt.

Man weiß ja nie ;).