Hallo zusammen,

ich bin dabei, Sprite-Koordinaten einzulesen und sogenannte "Hardware Sprites" in meinem Schneider/Amstrad CPC Emulator darzustellen.

Dabei bin ich auf ein Rechenproblem gestossen, welches die X-Koordinate betrifft.

Vielleicht kann mir hier jemand helfen, es "richtig" umzurechnen:

Die Sprite-X Koordinate wird aus dem RAM gelesen.

Dabei gilt folgende Regel:

Offset 0 	Low byte of X coordinate

Offset 1 	High byte of X coordinate

Offset 2 	Low byte of Y coordinate

Offset 3 	High byte of Y coordinate


When reading offsets 0,1,2 and 3, the following apply:


Offset 0 and 2: any written byte is readable, the same value that is written is readable!


BYTE_READ = BYTE_WRITTEN;


Offset 1: If byte written & 0x03 is 0,1 or 2, the value & 0x03 is read back. If the byte written & 0x03 is 3 then 0x0ff is read back.


if ((BYTE_WRITTEN & 0x03)==0x03) { BYTE_READ = 0x0ff; } else { BYTE_READ = BYTE_WRITTEN & 0x03; }

Soweit, so gut, das mache ich mit dieser Funktion:

        spritepos = 0x6000 + (index * 0x08);

        posbuf[0] = (byte) readFromAsic(spritepos);

        posbuf[1] = (byte) readFromAsic(spritepos + 1);

        if ((posbuf[1] & 0x03) == 3) {

            posbuf[1] = (byte) 0x0ff;

        } else {

            posbuf[1] = (byte) (posbuf[1] & 0x03);

        }

        spriteX[index] = getWord(posbuf, 0);

Nun ergibt sich ein schwierigeres Problem für mich. Regel:

The range is &000-&3FF (0-1023) or &FF00-&2FF (-256 to +767).

Dieses versuche ich so zu berechnen, aber das ist Falsch:

if ((spriteX[index] & 0x0300) == 0x0300) {

//            spriteX[index] = spriteX[index] & 0x02ff;

            spriteX[index] |= 0x0ff00;

        }


        if ((spriteX[index] & 0x08000) != 0) {

            spriteX[index] = -((0 - spriteX[index]) & 0x0ffff);

        } 

Kann mir jemand sagen, wie ich die Regel hier verwenden muss?

Ich wäre SEHR dankbar hierfür

Gruss,

Markus

siehe Bitweiser Operator

Generell kann man die Frage nicht so pauschal beantworten, denn wie die Darstellung des Bytes ist, hängt von der Zielplattform ab. Einmal die entsprechende Codierung Little- / Bigendian und dann in welchem Range das Byte ist [-128,127] oder [0,255]. Je nachdem muss das Schifting angepasst werden. Das "Low" bedeutet i. Allgm. die Bit 0..k-1 und das "high" von k..n. Bei einem Byte wäre das k eben einmal 0-7 bzw 8-15. Im Grunde kann man den Typen aus einer Addition mit Shifting aus 2 einzelnen Bytes zusammensetzen und via &-Operator wieder trennen.

In Java ist ein Byte allgemein im Bereich [-128,127] (siehe http://download.oracle.com/javase/1.4.2/docs/api/java/lang/Byte.html)

Ich empfehle bei entsprechender Hardware Simulation eine eigene Arithmetik zu implementieren, damit hier passend die Zahlen abgebildet werden können

Bearbeitet 30. Mai 201114 j von flashpixx

Also folgendes Problem taucht auf:

Werte von 0 - 0x02ff bzw 0 - 0x03ff werden korrekt dargestellt.

Werte von 0x0ff00 - 0x0ffff nicht. Die sind an falscher Position dann.

Den Fehler sieht man hier deutlich:

Erstellt von Camtasia Studio 7

Die "falsch" dargestellten Sprites haben eine X-Koordinate zwischen 0x0ff00 und 0x0ffff.

Die sind an falscher Position dann.

Wo ist der Bezug zu Java?

Das Problem liegt hier nicht bei Java, sondern in Deiner Programmierung. Du musst hier innerhalb einer Spezifikation, die Du nicht angibst, eine Zahl mit Hilfe von 2x 8 Bits darstellen, wobei sich die Bits in einen high- bzw low-Anteil aufteilen. Wie schon gesagt, die Byte-Reihenfolge muss berücksichtigt werden, ebenso wie der der Zahlenbereich der aus der Bytedarstellung resultiert. Das Byte in Java hat einen Range von [-128,127], wenn der Emulator [0,255] erwartet muss ein zusätzliches Schifting erfolgen. Dies ist aber alles Inhalt der Spezifikation !

Die Darstellung der 2 Bytes muss hier mind. als Short geschehen, wobei Java den Wertebereich [-32768,32767] dafür abbildet. In der Darstellung 0xffff würde aber der Wert in [0,65535] entsprechen

Bearbeitet 30. Mai 201114 j von flashpixx