Suchergebnisse

Hallo liebe Community. GameUtils ist eine simple 2D-Gameengine. Mein Ziel ist es, 2D-Spieleentwicklung so einfach wie möglich zu machen und dennoch eine große Erweiterbarkeit zu schaffen, um eine möglichst große Zielgruppe zu gewinnen. Neben den Kernelementen, der elementaren Spiellogik, die für jede erdenkliche Art Spiel die Grundlage bildet, und dem abstrakten Renderingsystem, welches das Austauschen des Renderers durch nur eine Zeile Code erlaubt, werden auch noch weitere Bereiche wie Input, …

Ja, die Testanwendung zeigt nur schwarz an, weil ich keine Lust hatte noch Logik zu implementieren. Es würde aber schon funktionieren, einfach eine Klasse von IGameObject erben lassen, dort die Render-Methode überschreiben und dann dem Loop hinzufügen.

Ja, aber dass ist auch so beabsichtigt. Wenn man das Fenster über den Schließen-Button schließen könnte, dann würde man den GDI-Context löschen, was zu nem Dicken Fehler führen würde. Man muss zum Schließen erst den Gameloop anhalten und dann Application.Exit aufrufen. Dies sollte man dann wohl mit einem Button o.ä. verknüpfen,allerdings ist der UI-Teil ja noch nicht fertig.

Weil das von der Architektur her nicht so einfach geht. Schau dir mal an, wie das Fenster erzeugt wird. Das erstellt nur der GDIRenderer, um das gerenderte darzustellen, das Programm weiß gar nichts von dem Fenster, so funktioniert das nunmal bei Spielen. Das Fenster dient einzig zur Darstellung und ist nicht Teil des eigentlichen Programmes.

Ja ich weiß, aber mir ist bisher noch nichts sauberes eingefallen, wie man das lösen könnte.

Einfach ein Event bis in den Gameloop durchreichen? Könnte man machen. Dann muss ich nur irgendwie dafür sorgen, dass der Rest das auch mitbekommt, weil sonst einfach alles abgeschossen wird.

Das wäre auch ne Möglichkeit. Die Frage ist aber immer noch, wie ich dann reagieren soll. Einfach die komplette Anwendung schließen, ohne vorher "nachzufragen"?

Aber wenn ich das Programm einfach so beende, dann bleiben da ja ganz schön viele Speicherleichen zurück. Oder kümmert sich der GC auch um ungemanagedte Sachen, wenn die Anwendung beendet wird?

Die Klassen implementieren alle IDisposable, reicht das?

Das kommt mir irgendwie nicht richtig vor, so ist das Dispose-Pattern nicht gedacht. Gibt es nicht vielleicht auch einen Weg, bei dem die ganzen Objekte Zeit haben, sich ordentlich zu entsorgen?

Im Prinzip hast du ja Recht, aber wie ThuCommix schon richtig gesagt hat, wenn ich jetzt auf DirectX wechseln will, dann müsste ich auch überall im restlichen Programm die Typen ändern. So lasse ich einfach die Interfaces überall stehen, in ihnen verbirgt sich aber ein anderes Objekt. Zitat von ThuCommix: „logisch wär eine Klasse Texture, die ein Bitmap enthält“Das musst du mir jetzt nochmal genauer erklären.

Achso, ja, es ging mir auch in erster Linie mal nur ums Wrappen. Erweiterte Funktionalität ist noch nicht mit inbegriffen, soll aber noch kommen (siehe Startpost). Sowas wie "FromPath" funktioniert bei meinem System halt nicht, da ja alle Objekte von der Factory erstellt werden, und die hat auch schon ne Funktion mit Pfadangabe.

Ich werde Direct2D verwenden, und das kann ich recht gut (siehe Signatur), funktioniert fast genauso wie GDI+.

@jvbsl Würdest du denn sagen, dass ich die Interfaces gut gewählt habe, um das schön zu abstrahieren? Oder könnte ich da was besser machen? Es soll aber nicht zu kompliziert werden.

Bei Direct2D geht das so: VB.NET-Quellcode (1 Zeile)also genauso wie bei GDI, nur die Klassen sind andere. Ich könnte es natürlich leicht so machen, dass man statt Renderer.DrawBitmap(IBitmap) IBitmap.Draw() aufrufen kann, das wäre nicht das Problem. Nur machen es nunmal alle Grafik-APIs so, dass man ein Objekt hat, dass alles zeichnet, und alles andere wird nur den entsprechenden Funktionen übergeben. Bei GDI+ ist es ja auch Graphics.DrawImage(Image) und nicht Image.Draw().

Zitat von ErfinderDesRades: „und RenderTarget, Bitmap und Rectangle sind alles DirectX2D-spezifische Datentypen?“Ja, genau so ists.

Ja, Direct2D biete eine PathGeometry-Klasse an, die fast identisch mit dem GraphicsPath ist. Und außerdem will ich ja auch die Option offen lassen, auch noch weitere Renderer da einzubauen, wie z.B. OGL.

@nikeee13 Das kenne ich, hab mich auch teilweise davon inspirieren lassen. Aber ich will ja nicht einfach den ganzen Code kopieren, soll ja mein eigenes Projekt werden, also auch selbst gedacht.

@thefiloe Das sieht schonmal gut aus, bedeutet aber auch gleichzeitig, dass es so eben nicht geht. Es geht mir ja eben um genau den unmanaged Teil, der dann im Speicher bleib, wenn ich das Programm einfach beende. Vielleicht sollte ich da einfach ein Event schmeißen, in dem die Anwendung dann noch ihren "Müll" aufräumen kann.

Dann hab ich das wohl falsch verstanden. Wie funktioniert das jetzt genau mit dem "disposing"?

Zitat von ErfinderDesRades: „wäre das nicht möglich?“Nein, denn das Fenster wird ja vom Renderer erstellt und kommt mit dem Rest des Programmes gar nicht in Kontakt. @thefiloe Es gibt da übrigens nen Bug in deinem Snippet. Ich nehme mal an, dass bei Destruktor auch der Klassenname stehen sollte, aber das steht leider nur "classname". EDIT: So, das erste Update ist draußen. Sonderlich viel hat sich nicht getan. Das IRenderer-Interface hat jetzt ein Event "SurfaceDestroyed", auf das die Anwendung …

Das klingt schon irgendwie logisch. Nur ist mir leider kein einfacher Weg eingefallen, das anders zu handhaben. Im Moment hat halt nur der Renderer auf die Zeichenfläche Zugriff und damit kann niemand anders mehr daran rumpfuschen.

Ich hab jetzt mal das System mit dem Fenster überarbeitet. Es gibt nun ein weiteres Interface "ISurface", welches als Zwischenschritt zwischen IRenderer und der Zeichenfläche dient. Ich habe im Beispielprojekt auch gleich eine Standardimplementierung mit einer ganz normalen Form angelegt. Das war tatsächlich ein ganzes Stück schwieriger, als ich gedacht hätte. Bei den 3 verschiedenen Thread bekommt man schon mal ein paar Probleme. Ich musste mich die ganze Zeit entweder mit ObjectDisposed-/Inval…

@Krissel095 Ich hab schon mit dem Direct2D-Renderer angefangen, und der braucht nur das Handle. Außerdem brauche ich diese "IsDestroyed"-Eigenschaft. @all Der Direct2D-Renderer wird bald fertig sein, und ich habe auch schon einige Interfaces erweitert. Bei meinen neusten Tests ist mir jedoch aufgefallen, dass der GDI-Renderer extrem flackert, und ich weiß nicht wirklich, woran das liegt. Ich hab ja das Multithreading im Kopf, da man damit bei GDI immer nur Probleme hat, aber bestätigen konnte ic…

Damit binde ich mich aber trotzdem an WinForms. Beim GDI-Renderer mach ich das ja schon so mit dem Control, aber bei DirectX soll man halt auch irgend ein handle angeben können. Außerdem ist ISurface wohl das einfachste Interface aus der ganzen Lib. Und hast du als Expert ne Idee, warum GDI+ so start flackert? Ich weiß da momentan nämlich nicht weiter und stehe kurz davor das Bild über richtiges GDI (also PInvoke) auf das Fenster zu "zwingen".

Ja, anders würde das mit dem Threading überhaupt nicht funktionieren. Ich erstelle in BeginRender ein Bitmap, auf die ich dann bei allen Zeichenfunktionen male. In EndRender wird dann Invalidiert und das Bild wird auf das Control gezeichnet.

Ich konnte das Problem nun lösen. Das Bild wird jetzt mit BitBlt direkt auf das Control kopiert ohne irgendwelche Umwege und sogar mit kompletter Multithreading-Unterstützung. Unterdessen ist der Direct2D-Renderer auch fast fertig geworden. Ich bin allerdings immer noch daran, die Interfaces bis ins Detail auszufeilen, weshalb beide Renderer noch nicht zu 100% fertig sind.

Ich verwende SharpDX, glaube nicht, dass ich es anders hinbekommen würde.

Der Direct2D-Renderer ist fertig. Ihr braucht nur im Testprojekt die Zeilen auszutauschen, um die Renderer zu wechseln. Bitte beachtet, dass beide Renderer technisch gesehen noch nicht 100%ig fertig sind, da ich immer noch am IGeometry-Interface (das bislang komplexeste Interface aus der Lib) arbeite und dieses dementsprechend noch nicht dort implementiert ist. Alles andere sollte aber schon funktionieren (außer ich hab irgendwo nen Bug produziert).

@ErfinderDesRades Inzwischen ist ein Quadrat zu sehen. Es ist schon möglich, Logik zu implementieren, der Update-Loop läuft, aber ich will mich momentan lieber dem Entwickeln der Engine widmen, als dem eines Beispiels.