[OpenSource] GameUtils

    • Beta
    • Open Source

    Es gibt 152 Antworten in diesem Thema. Der letzte Beitrag () ist von Artentus.

      ich würd nur dann einen eigenen Destruktor coden, wenn ich auch selbst iwelches unmanaged Zeugs in die Klasse hineinbringe.
      Da FileStream bereits ein managed Dispose hat, gehe ich davon aus, es hat auch den geeigneten Destruktor - oder überseh ich was?

      zum Schließen fällt mir noch ein, man könnte doch das RenderWindow ganz normal im Application.Run(mainWindow) angeben.
      Dann braucht man halt ieinen Input, der "Schließen" beauftragt, und da wird dann aufgeräumt, und am Schluß auch das RenderWindow zu, und fertig - wäre das nicht möglich?

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „ErfinderDesRades“ ()

      ErfinderDesRades schrieb:

      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 reagieren kann. Der Schließen-Button im Fenstertitel funktioniert jetzt also wieder.
      Außerdem hatte ich bei TowerDefense (siehe Signatur) das Problem, dass das Spiel abstürzen konnte, wenn man Objekte zur Auflistung der SPieleObjekte hinzufügte oder entfernte, während gerade da durch enumeriert wurde. Dies möchte ich bei meiner Engine gleich im Keim ersticken und habe deswegen für diese Auflistung eine spezielle Klasse geschrieben. Diese wartet immer auf das Ende eine Loop-Durchgangs und wendet dann alle Änderungen an, die während dem Durchgang geschehen sind.
      Zu guter letzt habe ich noch bei allen Klassen, die IDisposable implementieren, das richtige Pattern verwendet (danke @thefiloe:).



      Edit by LaMa5:
      - Bitte keine Doppelpost's, es gibt eine 'Bearbeiten' Funktion (Boardregeln §4.1e)
      - (nach nur 1,5h und das mitten in der Nacht)
      --> Beiträge zusammengefügt.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „LaMa5“ ()

      Artentus schrieb:

      Es gibt da übrigens nen Bug in deinem Snippet.
      Nennen wir es ein Feature ;). Nein eigentlich habe ich nur nicht wie man automatisch den Klassennamen einfüllt. Somit habe ich einfach ein Feld zur Eingabe erstellt. Wie auch immer. Gestern ist mir eingefallen, dass das das ctor Snippet auch kann und somit werde ich dies wohl in nächster Zeit mal ändern.
      EDIT: So habs geändert.


      Opensource Audio-Bibliothek auf github: KLICK, im Showroom oder auf NuGet.

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „thefiloe“ ()

      Bevor hier noch weiter über IDisposable und Destruktoren philosophiert wird, kann man auch einfach die Guidelines lesen. Da steht, wie man es machen sollte.
      msdn.microsoft.com/en-us/library/ms244737.aspx
      Da der GC ja auch von MS ist, wird das wohl auch nicht falsch sein.

      Die Codeanalyse hilft dabei übrigens auch.
      Von meinem iPhone gesendet

      Artentus schrieb:

      Nein, denn das Fenster wird ja vom Renderer erstellt und kommt mit dem Rest des Programmes gar nicht in Kontakt.


      Meinst du nicht, dass das zu unflexibel ist? Was, wenn jemand deine Engine dazu verwenden will, um einen Mapeditor zu schreiben? Dann hätte derjenige vermutlich viel zu wenig Zugriff, um z.B. in ein Panel rendern zu lassen ;)

      Freut mich übrigens, dass die XGL dich inspiriert hat. Ich habe mir deinen Code mal angeschaut und sehe hier und da ein paar Inspirationen, allerdings ist nichts davon aus der XGL geklaut! Weiter so :)

      MfG
      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-/InvalidOperationExceptions oder mit Deadlocks rumärgern, aber jetzt funktioniert zum Glück alles.
      Wozu die zusätzliche Abstraktionsebene? Gibt es einen anderen Fall, als einfach in ein Control zu rendern?

      MfG
      @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 ich es noch nicht. Jedenfalls, solange ich das nicht behoben habe ist der GDI-Renderer leider unbrauchbar.

      Artentus schrieb:

      @Krissel095
      Ich hab schon mit dem Direct2D-Renderer angefangen, und der braucht nur das Handle. Außerdem brauche ich diese "IsDestroyed"-Eigenschaft.


      Das Handle könnte sich der Direct2D Renderer doch aus dem Control ziehen, bzw. könntest du auch wie in der XGL ein Handle weiterreichen, aus dem man sich wiederum ein Control ziehen kann ;) Wäre vermutlich einfacher, als ein ISurface interface.

      MfG
      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.
      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).