4. WPF viele Tiles darstellen

WPF viele Tiles darstellen

  • N

    Benutzt Du einfach nur die GDI+-Funktionen? Dann vergiß es am besten wieder. GDI+ ist arschlangsam für Spiele. Das normale GDI ist ja schon nicht optimal, aber GDI+ kannst Du wirklich vergessen.

    P.S.: 256 x 256 Felder mit je 16 x 16 Pixel? Das heißt, Dein Spielfeld is 4096 x 4096 Pixel groß? Realisierst Du das mit Scrolling oder soll das gesamte Bild mit einem Mal auf dem Bildschirm erscheinen?

    0
  • R

    NES-Spieler schrieb:

    Benutzt Du einfach nur die GDI+-Funktionen? Dann vergiß es am besten wieder. GDI+ ist arschlangsam für Spiele. Das normale GDI ist ja schon nicht optimal, aber GDI+ kannst Du wirklich vergessen.

    P.S.: 256 x 256 Felder mit je 16 x 16 Pixel? Das heißt, Dein Spielfeld is 4096 x 4096 Pixel groß? Realisierst Du das mit Scrolling oder soll das gesamte Bild mit einem Mal auf dem Bildschirm erscheinen?

    Natürlich WPF ~(wie im Titel)~ und ja Scrolling.

    0
  • N

    Und das gesamte Bild, jedes Tile, ist veränderbar? Wie genau muß man sich Dein Spielfeld vorstellen?

    0
  • R

    NES-Spieler schrieb:

    Und das gesamte Bild, jedes Tile, ist veränderbar? Wie genau muß man sich Dein Spielfeld vorstellen?

    Ja alle 256 * 256 Tiles haben die gleiche Größe, einen Typ (Leer, Wand, Tür, etc.) und können alle können ihren Typ ändern.

    CSL schrieb:

    Das Performanteste was mir einfällt wären Horizontale und Vertikale Linien die sich Kreuzen ausgerichtet auf ein Margin..

    KAnnst du das mal genauer erklären?

    0
  • N

    Pobier es doch einfach so: Du erstellst am Anfang ein großes Bild, das das ganze Spielfeld darstellt. Also ein 4096 x 4096 Pixel großes Bild. Und auf dieses kopierst Du nur das Leer-Tile. Also ungefähr so (Pseudocode):

    for (int x = 0; i < 256; x++)
    for (y = 0; y < 256; y++)
        background.Draw(empty, x * 16, y * 16);

    Das machst Du nur einmal ganz am Anfang.
    Und auf das Spielfeld (bzw. den Backbuffer) zeichnest Du dann pro Animationsphase folgendes:
    - den Hintergrund
    - alle Türen
    - alle Wände
    Wenn Du also x Leerstellen hast, y Wände und z Türen, müßtest Du ja x + y + z Zeichenvorgänge durchführen. Wenn aber ein komplettes Bild, auf das am Anfang einmal überall die Leer-Tiles gezeichnet wurden, da ist, ist die Anzahl der Zeichenvorgänge nur noch 1 + y + z. Hinzu kommt, daß Du natürlich nur den Bereich des Hintergrundes zeichnest, der gerade sichtbar ist, und auch nur die Wände und Türen, die gerade sichtbar sind.

    Alternative:
    Du hast ein großes Bild, auf dem das gesamte Spielfeld korrekt abgebildet ist. Vor jeder Animationsphase übermalst Du auf diesem Spielfeld alle Tiles, die sich geändert haben, und nur die. Dann malst Du das Bild auf den Bildschirm. Also so:
    - Auf dem Spielfeld alle Türen, die eben noch keine Türen waren, mit dem Türtile übermalen.
    - Auf dem Spielfeld alle Wände, die eben noch keine Wände waren, mit dem Wandtile übermalen.
    - Auf dem Spielfeld alle Leerstellen, die eben noch keine Leerstellen waren, mit dem Leerstellentile übermalen.
    - Auf dem Fenster den sichtbaren Bereich des Spielfeldes malen.
    Dürfte auch schneller gehen, als jedes Mal die gesamten Tiles zu aktualisieren.

    0
  • S

    Hm, für das 256*256 Felder-Spielfeld (Basis-Layout) bietet sich das (sehr mächtige) Grid Layout-Steuerelement an. Die einzelnen Spielfelder würde ich als Kind-Elemente implementieren - deren Funktionalität in der dazugehörigen Klasse.

    Um die Geschwindigkeit würde ich mir indes keinen allzu großen Kopf machen: 2D-Primitive mit vordefinierten Transformationen, Texturen, usw. und die 3D-Funktionalitäten sind ein Unterteil von Direct3D. Auch wenn damit keine DirectX-Performance erreichbar ist, für dein Spiel wird es - geeignete 3D-Hardware vorausgesetzt - völlig ausreichen.

    0
  • E

    Um diese Steuerelemente im Grid an zu ordnen müsste er 256 Columns und 256 Rows definieren.
    Und dann noch die einzelnen Items selber, ich denke nicht das man das in WPF Performant über die Bühne bringt, da muss man schon etwas mehr tun.

    Das einfachste wäre es aber tatsächlich, denn dann kann WPF auf seine Templates zurück greifen und so Wände und Türen selbstständig erstellen und Zeichnen.

    Man müsste das erst einmal Testen.

    0
  • S

    CSL schrieb:

    Um diese Steuerelemente im Grid an zu ordnen müsste er 256 Columns und 256 Rows definieren.
    Und dann noch die einzelnen Items selber, ich denke nicht das man das in WPF Performant über die Bühne bringt, da muss man schon etwas mehr tun.

    Das einfachste wäre es aber tatsächlich, denn dann kann WPF auf seine Templates zurück greifen und so Wände und Türen selbstständig erstellen und Zeichnen.

    Man müsste das erst einmal Testen.

    Einfach 'mal 100 x 100 - per (Pseudo) Zufallsgenerator - animierte Steuerelemente im Grid anordnen ... und staunen. Auf einem nicht ganz neuen Core2Duo-System rennt das ruckelfrei.

    0
  • E

    Stell die Test app mal online, das wir das auch Testen können.
    Erweiter es am besten auf die gewünschten 256x256 Felder, du hast in deinem Test weniger als die hälfte.

    0
  • R

    So habe jetzt mal was ausgetestet:
    Selbst mit 200200 Images ist ein Canvas hoffnungslos überfordert (bzw. startete gar nicht)
    Habe jetzt ein Image mit einem RenderTargetBitmap als Source erstellt und das Speilfeld darauf vorendern lassen. Dadurch startet das ganze auf einem leeren Spielfeld sofort, dauert aber einige Sekunden. Jeodch verbraucht mehr als 300M RAM. Sonst muss ich mit halt eine komplexere Methode ausdenken mit mehreren Images (8x8 Tiles die jeweils immer einen Teilbereich vollzeichnen und "verschieben", wenn diese außerhalb des Scrollfensters     liegen.
    Das mit den Animationen werde ich schon hinkriegen.
    Aber wenigstens scrollt flüsser als in GDI+.
    🙄

    Wie bestimmt man eigentlich den Scrollbereich?

    0

  • Hat es einen bestimmten Grund dass du WPF verwenden willst, und nicht XNA oder dergleichen?

    0
Anmelden zum Antworten