MN|6 - xy Koordinatensystem ... ein Ansatz

  • Hallo,


    das Folgende ist ein Versuch, etwas Licht in das Koordinatensystem zu bringen. für die Test eignen sich gut die NavigonWaitCursorIntro.dat (Introanimation) und Keyboard-Layout_ABC.dat. Das animierte NavigonLogo bzw. das ButtonTemplate des ABC-keyboards habe ich einfach durch ein rotes Rechteck ersetzt. Mittels screenshots konnte man gut erkennen, wo die obere-linke Ecke letztlich tatsächlich gelandet ist. Der Test lief auf einem PDA mit VGA-Display (Portrait), die Erkenntnisse dürften jedoch aber auf QVGA und Querformat übertragbar sein (für QVGA dürften es jeweils die halbierten Werte sein). Die Koordinaten für das NavigonLogo beim Intro befinden sich in NavigonWaitCursorIntro.dat an der Stelle 10h, im Original stehen hier die Werte:


    0000 5041 0000 8242


    Wie schon in mehreren Beiträgen erwähnt sind die Zahlen 40h, 41h, 42h, 43h offensichtlich immer Bestandteil einer Koordinate. Um zu schauen, was es damit auf sich hat, habe ich die Werte nacheinander ausprobiert und bin dann mit der linken oberen Ecke des roten Rechtecks hier gelandet (die VorNullen laß ich ab jetzt der Einfachheit wegen weg):


    x,y in DAT -> x,y in dezimal
    -------------------------------
    0000h,0000h -> 0,0
    0040h,0040h -> 4,4
    0041h,0041h -> 16,16
    0042h,0042h -> 64,64
    0043h,0043h -> 256,256


    Ein Test mit 0044h ergab nix (noch nicht mal einen Absturz). Den Mathematikern unter uns springt gleich ein gewisser Zusammenhang ins Auge:


    4^(0+1) -> 4
    4^(1+1) -> 16
    4^(2+1) -> 64
    4^(3+1) -> 256


    Zu erwähnen sei noch, daß ich mir die screenshots mit dem normalen Windows Paint angeschaut habe. Dessen Zählweise beginnt mit 0, d.h. die Ecke links oben ist hier "0,0". Andere Programme zeigen hier evtl. "1,1", spielt letztlich aber keine Rolle. Desweitern ist nicht zwingend die linke obere Ecke des PDA-displays der Ursprung "0,0". dieser kann sich auch woanders befinden (z.B. für das ABC-keyboard ist der Ursprung bei "4,354" (VGA) und die Angaben in der Keyboard-Layout_ABC.dat sind relativ zu diesem Punkt).


    Die Zahlen 00h, 40h, 41h, 42h, 43h sind anscheinend also nix anderes als die Basis mehrerer Koordinatensysteme und einer darauf basierenden Vektorlogik, die hier offensichtlich verwendet wird. Die Ziffern vor diesen Zahlen scheinen ein Art "displacement" zu sein. Soweit ich herausgefunden habe, ist dieses auch linear aber für jeden der 40er Bereiche unterschiedlich. Ein Beispiel mit 0Ah (ist dezimal 10) ergab:


    0A41h -> 17 = 16+1 = 4^(1+1)+1 bin mir nicht sicher ... es werden aber wohl die (VGA-)Koordinaten 16 bis 63 abgedeckt (QVGA entsprechend die Hälfte: 8 bis 31)
    0A42h -> 69 = 64+5 = 4^(2+1)+5 scheinbar immer die Hälfte des displacements
    0A43h -> 276 = 256+20 = 4^(3+1)+20 scheinbar immer das Doppelte des displacements


    Ein paar mehr Tests konnte die Regeln soweit bestätigen. Der 40er Bereich dürfte die Koordinaten 4 bis 15 abdecken (habe ich nicht getestet). Das "displacement" ist also nur ein relativer Wert. Vielleicht kann das jemand nachtesten, ggf. auch unter QVGA.


    der Form halber: Das Ganze ist nur ein Ansatz und noch nicht schlußendlich ausgetestet, d.h. KEINE GARANTIE für das oben Geschriebene !!


    Viele Grüße ... Rene

    Einmal editiert, zuletzt von Rene_72 ()

  • Hi Rene_72,


    ...danke für diese saubere Arbeit. Zu ähnlichen Erkenntnissen war ich nach den "Ermittlungen" von usi ebenfalls gekommen, ohne diese natürlich mathematisch ausformuliert zu haben. Leider können wir aber mit diesen Koordinaten im Moment nur begrenzt umgehen, da Du ja auch richtig schreibst, Zitat: "Desweitern ist nicht zwingend die linke obere Ecke des PDA-displays der Ursprung "0,0". dieser kann sich auch woanders befinden (z.B. für das ABC-keyboard ist der Ursprung bei "4,354" (VGA) und die Angaben in der Keyboard-Layout_ABC.dat sind relativ zu diesem Punkt)." . Und wir wissen leider noch nicht, welche Feldvereinbarungen bzw. Fenstervereinbarungen zu den einzelnen Anordnungen von Navigon getroffen worden sind. Es wäre also doch mal sinnvoll, die Einsprungspunkte (Koordinaten) der einzelnen Felder mit deren Bedeutung zu sammeln, um etwas zielstrebiger aus der "try and error"-Methodik herauszufinden.


    THX und Gruß germie1

  • Hallo germie1,


    stimmt ... vielleicht komme ich noch zu ein paar weiteren Tests. Die keyboard-Layout....dat lassen ja scheinbar "beliebig" viele Tasten zu, die man für den Test "mißbrauchen"kann.


    Die Einsprungspunkte der Dialoge (popups) oder "container" dürften sich an den meisten png-files orientieren. Abgesehen davon macht es IMHO i.d.R. wenig Sinn die Elemente in den meisten Dialogen zu verschieben - ausgenommen natürlich das Keyboard-Layout für eine QWERTZ-Tastatur (gibt's ja schon) und die Dialog_map.dat ... Für letztere dürfte der gesamte PDA screen der container sein, sprich der Ursprung ist oben links ... hoffentlich ;o)


    Gruß ... Rene_72


  • Hi Rene_72,


    ...ich gebe Dir völlig recht, dass es wenig Sinn macht die Elemente in den Dialogen wahllos hin und her zu schieben. Es sollte aber versucht werden durch geringe Vergrößerung von Elementen und/oder durch Verschieben von Inhalten in den "containern" evtl. etwas mehr Platz für größere Schriften zu schaffen. Z.B. "field_info-x.png`s" und darin befindliche Zielankunftsflagge o.ä. Ich weiß, "Font-ID" etc., es wird schwierig sein, aber vielleicht doch machbar. Der Platz für die Kartenansicht sollte aber nicht wesentlich verkleinert werden.


    Gruß germie1

  • Hi Rene_72


    No speek Deutch and little English
    Thanks for your approach (base for me)
    My theory position keyboard base VGA 640x480


    Horizontal (480)


    Second byte = Offset_Ref Ref0 X<----->X Refx


    Ref0 =0 (left)
    (3F) Ref1 = 4^(0+0) =1
    (40) Ref2 = 4^(0+1) = 4
    (41) Ref3 = 4^(1+1) = 16
    (42) Ref4 = 4^(2+1) = 64
    (43) Ref5 = 4^(3+1) = 256


    3FH :
    Fist byte < 80H
    offset = Ref1 + First byte /128
    First byte >= 80H
    offset = Ref0 + First byte /64


    40H :
    Fist byte < 80H
    offset = Ref2 + First byte /32
    First byte >= 80H
    offset = Ref0 + First byte /16


    41H :
    Fist byte < 80H
    offset = Ref3 + First byte /8
    First byte >= 80H
    offset = Ref0 + First byte /4


    42H :
    Fist byte < 80H
    offset = Ref4 + First byte /2
    First byte >= 80H
    offset = Ref0 + First byte


    43H :
    Fist byte < 80H
    offset = Ref5 + First byte x2
    First byte >=80H
    offset = First byte x4


    Verification correct on 25 values (+/- 1 pt)


    Example keyboard 10 columns (key 46 pts) horizontal position:
    BC41 = 47
    3C42 = 94
    8E42 = 142
    BE42 = 190
    EE42 = 238
    0F43 = 286
    2743 = 334
    3F43 = 382
    5743 = 430


    For 40H no test for /8 ,uniquement theory


    Example keyboard 4 lines (key 56 pts) vertical position
    E841 = 58
    6842 = 116
    AE42 = 174


    For position on screen :


    Détermined displacement " Dep" by réference at 0,0 H/L .


    If Dep 0 at 3
    Dep < 2
    1er byt = (Dep - 1) x 64
    Dep >= 2
    1er byt = Dep x 64
    2e byt = 3FH


    If Dep 4 at 15
    Dep < 8
    1er byt = (Dep - 4) x 8
    Dep > =8
    1er byt = Dep x 8
    2e byt = 40H


    If dep 16 at 63
    Dep < 32
    1er byt = (Dep - 16) x 4
    Dep > =32
    1er byt = Dep x 4
    2e byt = 41H


    If Dep 64 at 255
    Dep < 128
    1 er byt = (Dep - 64) x 2
    Dep >= 128
    1 er byt = Dep
    2e byt = 42H


    If Dep 256 at 1023
    1er byt = (dep - 256) / 2
    2e byt = 43H


    [Blockierte Grafik: http://gardemanger.perso.cegetel.net/images/Format.jpg]


    By

    17 Mal editiert, zuletzt von camomille ()

  • Nur mal so ne Frage:
    wird daran weiter geforscht/gearbeitet oder bleibt das jetz mal so im Raum stehen?


    lg
    bit2bit