Hallo Besucher, der Thread wurde 13k mal aufgerufen und enthält 72 Antworten

letzter Beitrag von oobdoo am

OT: Neue C64 ASM/Basic Compo : Dreh' das Sprite [Alternative Systeme]

    Zitat von drazil


    Der Teil ist zur 3d->2d Transformation von Koordinaten.

    Drei Dimensionen? 8|


    Ich seh bei einem Sprite nur zwei Dimensionen.

    Zitat von Bytebreaker


    Der Aufbau des CPC Video RAMs ist völlig anders als bei einem C64 Sprite und völlig anders als beim C64 VideoRAM. Du hast Sprites, Player Misslies und Co alle in einen Topf geworfen als wären sie überall gleich aufgebaut. Aber das ist nicht so.

    Der Aufbau ds CPC Videospeichers ist bei der Drehung nicht wichtig. Außerdem habe ich eh nur in Mode 2 getestet. Da ist ein Bit immer ein Pixel.


    Ich vermute es gibt eine ganz einfache Formel, welche das Bit Array von 24x21 um 90° drehen kann. Aber je länger ich auf das Array draufschaue, um so größer wird scheinbar das Verständnisproblem. ?(

    oobdoo: Das was ich da aus dem alten Thread verlinkt hatte hat auch nicht wirklich was mit dieser Competition zu tun. Damals ging es um das drehen eines Sprites um einem beliebigen Winkel. Vergiss das einfach. Und ja ,ein handelsübliches Sprite hat nur zwei Dimensionen. ;-)

    @ oobdoo


    Für einen CPC General musst du wirklich nachbessern was deine Hardware Kenntnisse angeht.


    Der Video Speicher des CPC ist 16384 Bytes groß und nicht 8000 Bytes pro Bitplane wie beim C64. Daher arbeitet der CPC auch mit 640x400 Pixeln statt 320x200 wie der C64.


    Die krumme Zahl von 16384 statt 16000 kommt daher, dass alle 2000 Bytes es einen ungenutzten 48 Byte Block gibt. Ergibt in Summe 16384.


    Hinzu kommt, dass der Speicheraufbau nicht linear ist, sondern nach jeder Pixel Zeile ein "Sprung" von 8 Zeilen gemacht wird und erst dann weiter beschrieben wird wenn man linear den Speicher beschreibt. Das wiederholt sich zyklisch so lange, bis alle Zeilensprünge geschlossen sind.


    Und du willst mir erzählen das hat in Mode 2 keinen Einfluss auf die Positionsberechnungen der Drehung?!


    • Dir fehlt es momentan noch am Grundsätzlichen. Ist ja nicht schlimm. Nur sollte man das Problem erstmal hardware unabhängig lösen wenn man die Hardware erst noch verstehen muss.

    @ Meister Bacon


    Bitmap. Bitmap. Nicht Bitplane. Bin Amiga Kind, es war spät gestern. Sorry.


    Und Video Speicher kann man so auch nicht sagen es ist halt Bitmap Allokation die bei beiden Rechnern auf verschiedene Bänke zeigen kann.


    Beim CPC und C64 gibt es kein Video RAM in dem Sinne wie man etwa zum Chip RAM des Amiga sagen könnte.


    Beim C64 gibt es dafür ein festes ColorRAM, das mit der Bitmap und dem Screen RAM (poke 1024,1) das meine ich jetzt mit Screen RAM eine Art Schicht Struktur bildet. ColorRAM und Screen RAM sind je 1000 Bytes groß, die Bitmap fasst 8k.


    Hier drin das Dreh Rätsel abbilden würde wieder eigene Positionsberechnungen erfordern die nochmal anders als im CPC Bildschirmspeicher sind.

    @ Mac Bacon


    Oder meintest du dass 320x200 = 64.000 Pixel /8 = 8.000 Bytes ergibt


    Aber 640 x400 = 256.000 Pixel /8= 32.000 Bytes ergeben müssten?


    Ich weiß hier nicht besser Bescheid.
    Es sind wirklich nur 640 x 200 = 16.000 und 384 zerquetschte.


    Der CPC spricht Pixel genau im High res mode 2 aber trotzdem 400 Pixel in der Höhe an. Man sieht es beim plotten mit eigenen Augen.


    Es bleibt aber bei besagten 16.384 Bytes Bitmap Größe.


    Edit:
    Ich hab geplottet in High res und ein Pixel teilt sich dabei zwei y werte.


    Es ist also 640 x 200. Die 400 sind rein rechnerisch.

    Ich habe mal die Diskussion und Lösungsansätze für alternative Systeme (CPC, Excel etc.) ausserhalb der ASM Compo "Dreh' das Sprite", welche für den C64 gedacht ist, hierher verfrachtet.

    Wieso muss ich was nachbessern? Ich weiß durchaus wie der Speicher im CPC funktioniert. Notfalls kann ich auch direkt über die Betriebssystemfunktionen gehen, also scrCharPosition, scrDotPosition und scrNextByte.
    Wenn ich diese Compo richtige verstanden habe, dann entspricht ein Bit im Sprite genau einem Pixel. Daher auch mein Versuch in Mode 2.


    Sys, das abtrennen vom Thread war ne gute Idee.

    Zitat von Oobdoo

    Der Aufbau ds CPC Videospeichers ist bei der Drehung nicht wichtig.

    Nichts für ungut. Dieser Satz ist so wie er da steht, falsch. Kombiniert mit Deiner Pauschalaussage über Player Missile Sprites & Co. entstand eben bei mir der Eindruck, dass Du ein Verständnisdefizit bei der Hardware hast. Ein Bit entspricht ein Pixel reicht ja nicht wenn man bedenkt dass ein zu drehendes Stück Bitmap sich über mehrere Zeilen erstreckt und der Aufbau hier ganz anders ist als beim C64. Und von Deinen Betriebssystemfunktionen hattest Du zuvor nicht gesprochen.


    Hast Du meine Anregung mit dem Mühlespiel mal versucht?

    Zitat von Bytebreaker

    Nichts für ungut. Dieser Satz ist so wie er da steht, falsch. Kombiniert mit Deiner Pauschalaussage über Player Missile Sprites & Co. entstand eben bei mir der Eindruck, dass Du ein Verständnisdefizit bei der Hardware hast. Ein Bit entspricht ein Pixel reicht ja nicht wenn man bedenkt dass ein zu drehendes Stück Bitmap sich über mehrere Zeilen erstreckt und der Aufbau hier ganz anders ist als beim C64. Und von Deinen Betriebssystemfunktionen hattest Du zuvor nicht gesprochen.


    Das klingt jetzt so, als wären Sprite-Bits was anderes als CPC-Bits. 8|


    Die Daten aus https://www.c64-wiki.de/wiki/sprite ergeben bei mir folgendes Bild.



    Bis auf die Ei-Form das gleiche Bild wie auf der Seite.


    Bit gesetzt = Pixel gesetzt, bzw. 24×21 Pixel oder 3x21 Bytes.


    So habe ich das im Speicher stehen (Sprite 2):


    Und so habe ich die Daten in den Bildschirmspeicher geschrieben:



    Zitat von Bytebreaker

    Hast Du meine Anregung mit dem Mühlespiel mal versucht?


    Nö.

    Ich glaube Bytebreaker wollte nur sagen das der CPC die Spritedaten nicht ohne umzurechnen anzeigen kann.


    Wiki Ball.


    >C:0340 00 7e 00 03 ff c0 07 ff .~......
    >C:0348 e0 1f ff f8 1f ff f8 3f .......?
    >C:0350 ff fc 7f ff fe 7f ff fe ........
    >C:0358 ff ff ff ff ff ff ff ff ........
    >C:0360 ff ff ff ff ff ff ff 7f ........
    >C:0368 ff fe 7f ff fe 3f ff fc .....?..
    >C:0370 1f ff f8 1f ff f8 07 ff ........
    >C:0378 e0 03 ff c0 00 7e 00 xx .....~..


    So sollte das Zielsprite nach dem drehen im Speicher aussehen.


    >C:0380 1f ff c0 1f ff c0 3f ff ......?.
    >C:0388 e0 7f ff f0 7f ff f0 7f ........
    >C:0390 ff f0 ff ff f8 ff ff f8 ........
    >C:0398 ff ff f8 ff ff f8 ff ff ........
    >C:03a0 f8 ff ff f8 7f ff f0 7f ........
    >C:03a8 ff f0 7f ff f0 3f ff e0 .....?..
    >C:03b0 1f ff c0 1f ff c0 07 ff ........
    >C:03b8 00 03 fe 00 00 f8 00 xx ........

    Zitat von Acorn

    Ich glaube Bytebreaker wollte nur sagen das der CPC die Spritedaten nicht ohne umzurechnen anzeigen kann.

    Wenn Du Mode 0+1 meinst, dann ist das richtig.

    Und in Mode 2 muss er berücksichtigen, dass die Zeilen seines Eis nicht im Speicher so aufeinander folgenden wie es einen das Auge glauben macht.


    Bei einem c64 Sprite ist das schon eher so.
    Man muss auch an die Vertikale denken. Mehr nicht. Das kann oobdoo mit seiner Betriebssystem Funktion bestimmt super tun.


    Sobald er verstanden hat wie man das Problem auch ohne cpc löst.

    Zitat von Bytebreaker

    Und in Mode 2 muss er berücksichtigen, dass die Zeilen seines Eis nicht im Speicher so aufeinander folgenden wie es einen das Auge glauben macht.

    8|

    Es wäre wichtiger das Drehkonzept an sich zu verstehen. Über die Umsetzung auf einer spezifischen Hardware kann man danach noch reden. Wenn oobdoo das Konzept dann ohne Bugs abbildet ist diese Diskussion sowieso hinfällig denn dann hat man aneinander vorbei geredet.


    Wenn ich einfach nur die Bitmap vor mir habe, ohne spezielle compiled sprites oder dergleichen und ein Stück Bitmap in Mode 2 drehen will, dann muss ich berücksichtigen, dass das letzte Byte einer bestehenden Bit Zeile und das erste Byte einer neuen Bit Zeile im Speicher nicht direkt aufeinander folgen. Beim c64 Sprite ist das so. Beim CPC Video Speicher nicht. Das ist eben nicht egal und alles gleich. Besser kann ich es nicht wiederholen.


    Ich lasse es hier mal gut sein und Klinke mich aus. :-) Ich hab mich dazu oben schon hinreichend ausgelassen.

    Von den CPC habe ich leider keine Ahnung. Aber selbst auf dem C64 kann man ein Sprite nicht einfach in die Bitmap kopieren ohne umzurechnen, da eine Bitmapzeile viel länger ist.


    Egal solange dein Code das gleiche wie ab $0380 ausspuckt, sollte es passen.

    Zitat von Bytebreaker

    Wenn ich einfach nur die Bitmap vor mir habe, ohne spezielle compiled sprites oder dergleichen und ein Stück Bitmap in Mode 2 drehen will, dann muss ich berücksichtigen, dass das letzte Byte einer bestehenden Bit Zeile und das erste Byte einer neuen Bit Zeile im Speicher nicht direkt aufeinander folgen. Beim c64 Sprite ist das so. Beim CPC Video Speicher nicht. Das ist eben nicht egal und alles gleich. Besser kann ich es nicht wiederholen.

    Irgendwie reden wir aneinander vorbei.



    Das sind die originalen C64 Spritedaten von Impossible Mission in Mode 2, allerdings mit XOR verknüpft, damit der Arm auch dann sichtbar bleibt wenn er komplett über dem Rumpf dargestellt wird.
    Und solange man mit scrNextLine die nächste Zeile berechnet, dann kann man auch Daten 1zu1 verwenden.


    Ich kann es nicht besser erklären. Vielleicht hat M.J. jetzt am Wochenende Zeit, der kann beide Systeme erklären.


    Die angehängten Dateiein kannst Du in WinCPC verwenden, mit CALL &4000 starten, dann sollte das Männchen zu laufen anfangen.

    Dein scr next line ist denke ich der Knackpunkt.
    Ohne so etwas hätte man von Hand berechnen müssen.


    Dein Satz mit "cpc hardware Aufbau egal " kam einfach ein bisschen arg irritierend rüber. Es ist nicht egal, man muss drauf achten. Mehr sage ich doch gar nicht.


    Vielleicht kann man sich Jetzt langsam wieder auf das Konzept hinter der Umsetzung kümmern. Wenn dir mein Mühle Beispiel nicht liegt dann denk dir ein anderes aus.


    Ohne Konzept das man selber wirklich versteht gibt es keine Umsetzung. Mit String Array hättest du es einfacher gehabt und der Weg dahin wäre mein Mühle Beispiel gewesen.


    Mehr Steigbügel Halter kann ich auch nicht machen ohne vor compo Ende konkrete Lösungen zu posten.