Heute so gecodet...

Es gibt 2.379 Antworten in diesem Thema, welches 480.646 mal aufgerufen wurde. Der letzte Beitrag (1. November 2025 um 13:53) ist von Unseen.

  • Weiter an meinem 1. Sprite Multiplexer gecoded. Das Thema ist wirklich nicht so ganz trivial. Zumindest nicht für alte Leute.

  • Weiter an meinem 1. Sprite Multiplexer gecoded. Das Thema ist wirklich nicht so ganz trivial. Zumindest nicht für alte Leute.

    Was genau hast Du vor? Spritesäulen à la MM? Hab's nicht verfolgt; geht's um C64?

    Habe ich eigentlich schon erwähnt, dass ich es höchst suboptimal finde, dass hier in diesem Thread Retro-Programming und aktuelle PCs durcheinandergewürfelt werden? Man sollte "heute so gecodet" genauso trennen wie "heute so gespielt". Bei "heute so gepixelt" ergibt sich das von selbst, weil in modernen Auflösungen wohl kaum noch einer pixellt.

  • Ich bastel gelegentlich an einem Ballerspiel und brauch mehr als 8 Sprites für die Gegner und Schüsse.

    Ist für c64 in cc65 und Asm geschrieben.

  • Ach sorry, ich hatte falsch gelesen (wird letzte Zeit immer schlimmer mit mir ;(). Ich hatte 1-Sprite-Multiplexer gelesen oder verstanden, also eben diese Spritesäulen. Dein *erster* Multiplexer steht da aber.:facepalm:

    Schüsse würde ich immer mit Zeichen oder Bitmap-Pixel machen. Sprites sind mir dafür zu "wertvoll". Vor allem mag ich nicht diesen Wizard-Of-Wor-Effekt, dass man noch nicht wieder schießen kann, nur weil noch ein Schuss unterwegs ist.

    Aber auch ich muss für mein Ballerspiel noch einen eigenen Multiplexer bauen. Die Sprites brauche ich hauptsächlich als Overlay für Softwaresprites/Shapes, um die Bodentextur an den Rändern der Figuren zu vervollständigen, denn sonst hat man immer ein schwarzes Quadrat drumherum, so wie man es auch bei PETSCII Robots oder Ultima-Likes wie Unknown Realm sieht.

    Es soll ein effizienter Bucket-Sorting-Algorithmus eingesetzt werden, inspiriert durch Bitte melde dich an, um diesen Link zu sehen.. Bietet sich für Labyrinthspiele an, aber weniger für Scroller oder Jump&Run.

  • Bisserl weiter gemacht am Multiplexer und da passieren Sachen die ich nur staunend beobachten kann.

    Ich hab jetzt 3x 8 Sprites übereinander angezeigt und die ersten 2 Reihen werden nicht immer angezeigt. Wenn ich nun aber die 3. Reihe horizontal auseinander ziehe, also den Abstand zwischen den Sprites erhöhe, tauchen plötzlich die Sprites darüber teilweise auf.

    Da muss ich noch einiges lernen, bis ich durch den Code steige.

  • Da muss ich noch einiges lernen, bis ich durch den Code steige.

    Mit CPC wäre das nicht passiert, der kennt keine Sprites. :prof: :D

    Bitte melde dich an, um diesen Anhang zu sehen. :verehr: .: Mit Bitte melde dich an, um dieses Bild zu sehen.wäre das nicht passiert! :. :prof:  Bitte melde dich an, um diesen Anhang zu sehen.

    :syshack: .: Meine 3D-Drucker Teile auf :. Bitte melde dich an, um diesen Link zu sehen. :strom:

  • Wenn ich mal mehr Zeit hab, muss ich mal wieder Software Sprites coden. Ich find das spannend. Aber gerade freu ich mich, dass ich 3 Reihen mit 8 Sprites sehe... :lol23:

    Dieser Artikel war sehr hilfreich:

    Bitte melde dich an, um diesen Link zu sehen.

    Damit hab ich nämlich verstanden, dass ich die Y Koordinate zu spät gesetzt hab. Muss auch mal konsequent die Taktzyklen in meinem Code zählen.

    Aber das wird mit den Jahren schon noch werden... :alt:

    • Offizieller Beitrag
    • Interessanter Beitrag

    Da muss ich noch einiges lernen, bis ich durch den Code steige.

    Mit CPC wäre das nicht passiert, der kennt keine Sprites. :prof: :D


    Da gebe ich Dir ausnahmsweise mal 101% Recht :bgdev

    Bitte melde dich an, um diesen Anhang zu sehen.

    ___________________________________________________________
    Meine Kreationen: Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.
    | Bitte melde dich an, um diesen Link zu sehen.
    Avatar: Copyright 2017 by Saiki

  • Muss auch mal konsequent die Taktzyklen in meinem Code zählen.

    Ja, das ist für Sprite-Multiplexing nahezu unvermeidlich. Wenn Sprites nah übereinander dargestellt werden sollen und noch Badlines ins Spiel kommen wird das alles schnell sauknapp.

    ────────────────────────────────────────────────────────────
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    ────────────────────────────────────────────────────────────

  • Was das Multiplexen von großen Endgegnern entspannen kann: Nicht mit dem Schachbrett in Sprites zerlegen, also alle genau nebeneinander auf gleicher Höhe liegen lassen. Stattdessen Treppchen machen, jede Spalte 1 Pixel weiter nach unten schieben. So musst Du je Rasterzeile nur 1 Sprite aufhübschen. Und die Y-Pos so früh wie möglich setzen, aber das steht bestimmt schon in dem Artikel.

  • Ich bin letztens durch den Sprite Multiplexer von Cadaver vom Spiel Hessian durch und habe den kommentiert und die Label-Namen verlängert, damit der src etwas lesbarer ist (fuer mich jedenfalls).

    Falls Du rein schauen willst: Bitte melde dich an, um diesen Link zu sehen.
    Basiert auf dem code hier: Bitte melde dich an, um diesen Link zu sehen.

    Alleine das kommentieren hat mir sehr viel geholfen das Thema zu verstehen. Ansonsten hatte ich vorher das hier gut gefunden als Einstieg Bitte melde dich an, um dieses Medienelement zu sehen.

  • Mein Ansatz ist ja viel einfacher als eure Multiplexer, wo man x Sprites wahlfrei positionieren kann. Ich habe den Bildschirm vertikal einfach in Bereiche unterteilt und habe quasi einen virtuellen VIC für jeden Bereich. Wenn der Rasterstrahl den Bereich erreicht hat, werden die Register des virtuellen VIC in den physikalischen VIC kopiert.

    Was ich programmieren möchte ist ja so ein ganz einfacher Shooter. Das Raumschiff des Spielers ist im unteren Bereich, die Feinde sind im oberen Bereich, so dass diese 2 Bereiche sich nie überlappen werden. Nur die Schüsse sollen von unten nach oben fliegen und kommen daher in beide Bereiche.

    Ist nur so ein kleines Spassprojekt, um ein wenig c64 coden zu können.

  • So....u.a. bisserl weitergecoded an dem Plexer. Heute hab ich angefangen, eine Idee umzusetzen, an der ich schon eine Weile brüte. Und zwar hab ich mal in einem Jahn Carmack Interview gehört, dass sie auf dem Apple 2 die Sprites nicht an den Zielort kopiert haben, sondern das Sprite mit einem Programm gemalt wurde, weil das schneller war.

    Diese Idee wollte ich auch für meine virtuellen VICs verwenden, indem ich den Code zum Kopieren der VIC Register einfach mit in die Struktur mit den VIC Daten packe. Ich hab das jetzt mal als ca65 Macro gelöst, indem ich also eine Abfolge von

    lda Bitte melde dich an, um diesen Link zu sehen.

    sta $d001

    lda Bitte melde dich an, um diesen Link zu sehen.

    sta $d003

    lda Bitte melde dich an, um diesen Link zu sehen.

    sta #d005

    ... usw hab.

    Jeder der Bitte melde dich an, um diesen Link zu sehen. Werte wird überschrieben mit dem Wert des jeweiligen VIC Registers. Dafür hab ich mir einige C-Funktionen zum Testen geschrieben. Im Raster IRQ wird dann einfach die Adresse der Struktur eingetragen, und der virtuelle VIC kopiert sich in den physikalischen VIC. Der Hauptvorteil ist die Ersparnis von einem Taktzyklus pro Registerwert, weil man halt nicht mehr

    lda <virtueller VIC Register Adr>

    sta <physikalisches Register Adr>

    machen muss, sondern

    lda #<wert>

    sta <physikalisches Register Adr>

    machen kann.

    Im Moment seh ich mal wieder nur 2 Reihen Sprites auf dem Bildschirm, aber das Timing ist jetzt halt auch etwas anders, und mein Code ist nicht wirklich getestet. Braucht halt noch einiges an Arbeit.

  • Mein Ansatz ist ja viel einfacher als eure Multiplexer, wo man x Sprites wahlfrei positionieren kann. Ich habe den Bildschirm vertikal einfach in Bereiche unterteilt und habe quasi einen virtuellen VIC für jeden Bereich. Wenn der Rasterstrahl den Bereich erreicht hat, werden die Register des virtuellen VIC in den physikalischen VIC kopiert.

    Das ist das sogenannte Bucket-Multiplexing, das ich auch benutze. Diese Bereiche, von denen Du sprichst, werden dabei laut Cadaver als Eimer bezeichnet; Kind braucht halt 'nen Namen. ;) Es ist aber eben nicht für alle Situationen geeignet. Bei Spielen, wo wirklich alles durcheinander fliegt, kommt es an den Übergängen der Bereiche zu Problemen. Bei Labyrinthspielen mit orthogonalen Gängen oder auch bei Space-Invader-Likes mit entsprechenden Formationen funktioniert das ganz gut. Sofern das einsetzbar ist und funktioniert, ist es auf jeden Fall ein ordentlicher CPU-Zeitgewinn ggü. richtig flexiblen Multiplexern. Ich habe übrigens (max.) 16 Sprites und 8 Bereiche (weil 8 Labyrinthzeilen à 24px Höhe).

  • Mein Ansatz ist ja viel einfacher als eure Multiplexer, wo man x Sprites wahlfrei positionieren kann. Ich habe den Bildschirm vertikal einfach in Bereiche unterteilt und habe quasi einen virtuellen VIC für jeden Bereich. Wenn der Rasterstrahl den Bereich erreicht hat, werden die Register des virtuellen VIC in den physikalischen VIC kopiert.

    Das ist das sogenannte Bucket-Multiplexing, das ich auch benutze.

    Das habe ich auch beim Startmenü von WinGames (siehe Signatur) verwendet. Wie du schon schreibst, eignet sich die Technik vor allem für (relativ) statische Sprites. Wenn die Bereiche groß (d.h. hoch) genug sind, braucht man sich auch um Badlines nicht zu scheren.

    Bitte melde dich an, um diesen Link zu sehen. (Bitte melde dich an, um diesen Link zu sehen.)Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.
  • Nach viel Arbeit hat mein Nebenprojekt endlich funktioniert. :lol23:

    Nach 12 Minuten waren die Berechnungen durch und der AMD 9950X3D war mit ParallelFor in VB.net zu knapp 100 Prozent ausgelastet bzw. ich hatte max. 31 Thread zugelassen.

    Wenn die Benchmarks im Web stimmen, dann hätte der alte Threadripper 2950X die doppelte Zeit benötigt. :)

    Am Wochenende werde ich schauen was sich noch optimieren lässt. Sollte dabei zuwenig rauskommen, dann habe ich noch Ideen wie sich das mit einem Cache beschleunigen lassen sollte. :)

    :lol23:

    Bitte melde dich an, um diesen Anhang zu sehen. :verehr: .: Mit Bitte melde dich an, um dieses Bild zu sehen.wäre das nicht passiert! :. :prof:  Bitte melde dich an, um diesen Anhang zu sehen.

    :syshack: .: Meine 3D-Drucker Teile auf :. Bitte melde dich an, um diesen Link zu sehen. :strom:

  • mit ParallelFor in VB.net zu knapp 100 Prozent ausgelastet bzw. ich hatte max. 31 Thread zugelassen.

    Ich dachte Parallel.For macht das automatisch? Wie kann man da steuern, wie viele Freds da starten?

    Früher waren 64k unglaublich viel, heute reicht es nicht mal mehr für "Hello, world!".

  • mit ParallelFor in VB.net zu knapp 100 Prozent ausgelastet bzw. ich hatte max. 31 Thread zugelassen.

    Ich dachte Parallel.For macht das automatisch? Wie kann man da steuern, wie viele Freds da starten?

    Ich habe folgenden Code davor gesetzt.

    Dim MaxThreads As New ParallelOptions

    MaxThreads.MaxDegreeOfParallelism =31

    Mit einem Wert von 3 sieht es rechts unten im Taskmanager auch fast immer nach 100% aus. Schaut man aber direkt die Leistung der einzelnen Thread im TM an, dann sind einige Lücken zu sehen.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Das war auch schonmal ganz anders die Tage, da war alles auf Volllast, da stotterte sogar XMPlay ganz kurz.

    Möglich das man mit einzelnen gestarteten Threads anders steuern kann. Damit hatte ich auch experimentiert.

    Da liefen aber mehr verschachtelte For-Schleifen als jetzt.

    Bitte melde dich an, um diesen Anhang zu sehen. :verehr: .: Mit Bitte melde dich an, um dieses Bild zu sehen.wäre das nicht passiert! :. :prof:  Bitte melde dich an, um diesen Anhang zu sehen.

    :syshack: .: Meine 3D-Drucker Teile auf :. Bitte melde dich an, um diesen Link zu sehen. :strom: