Suchergebnisse

ich bin ja immer sehr mißtrauisch gegenüber dem Interface-Kult, den c#-ler so gerne treiben. Nach meiner Erfahrung meist ein Verstoß gegen das Kiss-Prinzip, also eine unnötige Verkomplizierung. ZB solange es nur eine einzige Implementierung eines Interfaces gibt, darf es ühaupt kein Interface geben. Ein Interface darf man erst extrahieren, wenn tatsächlich eine alternative Strategie für dieselbe Funktionalität implementiert wird (etwa, wenn einer hergeht, und einen DirectX- oder OpenGL-Renderer …

Abstrahieren ist kein Selbstzweck. Zum Abstrahieren muß man mehrere Strategien haben, die man betrachtet. Und dann findet man gleiche Strukturen, sodass man Code schreiben kann, der diese Gleichheiten über einen Kamm schert. Das Herausarbeiten dieser Gleich-Strukturen kann aber erst erfolgen, wenn man mehrere Strategien hat, die man vergleichen kann. Du kennst derzeit scheinbar nur die GDI-Strategie, wie gezeichnet wird, und denkst dir, DirectX wird iwie schon genauso ticken. Damit wirst du aber…

jetzt nochmal im Detail. sowas ist pseudoPolymorph:C#-Quellcode (10 Zeilen)scheinbar wird gegen ein Interface geproggt, aber praktisch wird auf die konkrete Klasse getestet und gecastet, und am schlimmsten ist vlt. noch, dass wenn der cast gelingt, dass dann zusätzlich auch noch das gewrapperte Objekt ausgepuhlt wird. Da kannst du wirklich gleich von Anfang an eine Drawing.Bitmap reingeben, und alles ist ganz klar, unds gibt nur eine einzige Zeile. richtige Polymorphie wäre, wenn die IBitmap sic…

und RenderTarget, Bitmap und Rectangle sind alles DirectX2D-spezifische Datentypen? jaja, ein Umdrehen der Logik wäre kein Gewinn, dann hätteste PseudoPolymorphie nur aus der Renderer-Klasse in die GDIBitmap-Klasse verlegt.

wassis mit Drawing.Drawing2D.Matrix und Drawing.Drawing2D.GraphicsPath? Gibts dergleichen auch in DirectX2D? Bei meinen Zeichnungs-Übungen hat sich ergeben, dassich nix anneres brauche: Nur .DrawImage(Bitmap) und .DrawPath(GraphicsPath) Keine Rectangles, Lines, Texts - das kannich alles mit GraphicsPath darstellen. gugge Gezieltes OwnerDrawing Ansonsten - wie gesagt: nix inkompatibles zusammenrühren. Da würdich eher immer 2 Überladungen proggen, eine für GDI, eine für DirectX2D, und jeweils auf …

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…

Zitat von Artentus: „Nein, denn das Fenster wird ja vom Renderer erstellt und kommt mit dem Rest des Programmes gar nicht in Kontakt.“Erstells halt in Sub Main, und gibs dem Renderer, und ab in den Application.Run() damit.

bewegt sich denn schoma was, oder noch die schwarze Oberfläche?

Hab jetzt mal die TestApp ausprobiert - immerhin ein Rechteck zu sehen. Nu wollte ich machen, dass es sich auch bewegt, und finde, die Engine unterstützt einen ühaupt nicht darin. Also von einer Engine täte ich mindestens erwarten, dass ich mit Tastatur die Richtung und Geschwindigkeit bewegter Objekte beeinflussen kann. Gerne auch, dass ich Objekte selektieren kann, drehen, oder auch ein Kollisionens-Ereignis bekomme.

Ah - jetzt habichs erfolgreich auf 2010 runterschrauben - nun kann man ja schon was sehen Und dann kannman auch den Plan dahinter verstehen, und versuchen zu erklären: Also Kern eines Spiels ist das GameLoop - Objekt. Da hinein tut der SpieleEntwickler seine SpielObjekte. Der Gameloop tut nix als vonne SpielObjekte immer .Update() und .Render(IRenderer renderer) aufzurufen, also ein SpielObjekt, was sichtbar sein soll, muß IRenderable implementieren, und wenns auch noch beweglich ist, oder sonst…

Zitat von Artentus: „Dieses Interface ist dafür da, IRenderables und IUpdateables in ein und der selben Liste halten zu können, damit ich nicht Klassen, die beides implementieren, einmal zur Renderer-Liste und einmal zur Update-Liste hinzufügen muss.“also bei so ganz schrägen Code-Stücke, wie dem hier - da bin ich wieder ganz entschieden für bisserl Kommentation. Aber was hälste von solch Add-Methoden:C#-Quellcode (5 Zeilen)Da kannst du die Dinge sogar in verschiedene Listen räumen, was die Loop…

kapier ich nix von - scheinbar sollen gewisse Changes erst verzögert zur Wirkung kommen - k.A., ob das sinnvoll ist. ich schnall ja schon hierbei ab:C#-Quellcode (7 Zeilen)Bist du dir sicher, dass Locking so kompliziert sein muss? Und ist doch auch sinnlos, falls die Komponente garnet IUpdateable ist. Also da sehe ich keinen Grund, nicht 2 verschiedene Listen zu verwenden. Und noch genauer hingeguckt: Diese Synchronisation soll ja glaub verhindern, dass ein Objekt gerendert wird und gleichzeitig…

k.A., was du meinst - folgendes scheint jdfs. zu gehen:C#-Quellcode (20 Zeilen) und wenn ich da noch länger drauf gucke, wird daraus:C#-Quellcode (17 Zeilen)

ich kann ja nur den GDI-Renderer testen, vlt liegts daran. Und ob foreach und OfType gegenüber Monitor.Enter noch groß ins Gewicht fallen bliebe erstnoch zu testen.

ja, ich weiß. Ich find Monitor.Enter voll eigentümlich, weils doch den lock-Block gibt. Ist wie als wenn man bei Disposablen aufn Using-Block verzichten würde.

Mir gefällt das Design für den SpieleEntwickler nicht sonderlich. Dieses PhysicTester-Monstrum - da ist mir viel zuviel drin. Ich würde was bevorzugen mit ZeichenObjekten, die selbst wissen, wie sie sich zeichnen sollen. - guck: ich hab ein Polygon gemacht, was sich zeichnen kann, und auch seinen Namen schreiben:C#-Quellcode (24 Zeilen)Die Texte wabern übrigens ziemlich eigentümlich herum. Auch Verschachtelung habich reduziert - Verschachtelung ab einem bestimmten Grad erschwert ziemlich die Les…

na, dassis schon ziemlich missbräuchlich - aber wenns um praktischen Code geht, kennich keine Moral :):C#-Quellcode (17 Zeilen)Also ein überladener List<Vector2> - Indexer, was ja eiglich ein Getter ist, wird gewissermaßen als Setter missbraucht, nämlich, um aus den Indizees Vectoren zu bilden und zu adden, und Rückgabewert ist immer der Initer selbst, sodass man weitere indizierte Zugriffe treiben kann.

Tja, Microsoft hats leider noch nicht geschafft, genügend brauchbare Auflistungs-Initialisierer verfügbar zu machen. Also siehs als besonderes Feature von Indexern an Übrigens in vb ist eine Variante des From-Schlüsselwort so gemeint, aber an die Indexer-Technik kommt das immer noch nicht ganz ran.

Testprojekt runtergeladen und: vb-paradise.de/index.php/Attachment/26326/ (Vista, und Solution opened in VS2010)

was soll das? Ein Testprojekt, was nicht lauffähig ist, und FillTheRow gibts nur als Exe? Also wenn qualifiziertes Feedback dich interessiert, sollteste gucken, dass man dein Projekt auch testen kann. naja - vmtl. stell ich mich malwieder nur doof an. Also in FillTheRow finde ich kein SolutionFile, daher weiß ich nicht, wieso du das als OpenSource bezeichnest. ah - Github. Hmm - da kann ich was downloaden, aber dann fehlen alle möglichen Verweise vb-paradise.de/index.php/Attachment/26327/ also n…

Zitat von Artentus: „Du kannst jetzt nochmal probieren.“ hmm. selbes Ergebnis. Also ich klickse auf "Download Zip", und die Solution im Zip ist halt wie obiges Bildle zeigt unvollständig. @thefiloe:: "NuGet-Pakete" - wo müsste ich da klicksen?