Hat GM6 das Rechnen verlernt?

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Hat GM6 das Rechnen verlernt?

    Ich bin bei der Konvertierung eines Spiels von GM5 auf GM6 auf ein großes Problem gestoßen. Für die Netzwerkübertragungen habe ich es so eingerichtet, dass vier maximal dreistellige Zahlen in eine "gepackt" werden. Der ursprüngliche Code:

    GML-Quellcode

    1. temp = round(argument0) + round(argument1) * 1000 +
    2. round(argument2) * 1000000 + round(argument3) * 1000000000;

    ...und das ganze rückgängig:

    GML-Quellcode

    1. if (argument1 == 1) { temp = round(frac(argument0 / 1000) * 1000); }
    2. else if (argument1 == 2) { temp = floor(frac(argument0 / 1000000) * 1000); }
    3. else if (argument1 == 3) { temp = floor(frac(argument0 / 1000000000) * 1000); }
    4. else if (argument1 == 4) { temp = floor(frac(argument0 / 1000000000000) * 1000); }


    Das hat im GM5 IMMER einwandfrei funktioniert. Probiert das jetzt aber mal im GM6 aus:

    Beispiel:
    1. Zahl: 111
    2. Zahl: 222
    3. Zahl: 333
    4.Zahl: 444

    Nach dem 'Packen' und 'Entpacken' kommt dann folgendes raus:
    1. Zahl: 0 (Falsch!)
    2. Zahl: 218 (Wieder falsch!)
    3. Zahl: 333 (Richtig)
    4. Zahl: 444 (Richtig)

    Die falschen Zahlen entstehen übrigens schon beim Packen, nicht erst beim Entpacken.

    Hat der GM6 etwa das Rechnen verlernt?

    Mittlerweile habe ich das Problem mit Hilfe von Strings gelöst, ist allerdings nicht so elegant und braucht viel mehr Code. Deshalb die Frage - Seid ihr auch schon mal auf so was gestoßen? Oder liegt der Fehler doch nur irgendwo im Code?
    Es gibt drei Dinge, die ich wirklich hasse:
    Aufzählungen, die gar keine sind.

  • Also der GM6 macht aus 1 z.B. 0,923464 nochirgendwas war jedenfalls mal bei mir so als ich eine 1 in ner ini speicherte kann sein das es dadurch is.
    Face in the wind, we're riding the storm
    We'll stay our course whatever will come
    ~~ Stay (Running) Wild ~~

  • Genau das gleiche Problem habe ich auch!
    Wenn ich in eine INI eine 1 reinschreiben, spuckt er mir eine 0,9999987618873 raus!
    Aber es ist bei mir bis jetzt bei der INI aufgefallen und bei dem Befehl real(x) aufgefallen!
    Meine Homepage:
    www.eafoods.tk
    ---------
    Sachma!
    Ich werd noch bekloppt ( wenn ich es jetzt noch nicht bin )! :O
    Braucht ihr ein Dolmetscher für die Fäkalsprache, oda was?

  • Soweit ich mich an meine Grundlagen der EDV vor jahren zurückerinnern kann, aben auch Gleitkommazahlen kein problem eine 1 richtig darzustellen. also wenn ich einen float unter C einen wert von 1 eingebe ist der immer genau 1 wert.

    Ich würde nicht zwischen round und floor wechseln. Wenn die zahlen immer geanu seien sollten müßte es reichen floor zu benutzen. Bei so großen zahlen (1000000000000)fürs dividieren bin ich mir weiters nicht ganz sicher ob float da noch genau arbeitet (keine ahnung mehr wieviele nachkommastellen der wirklich mitspeichert). Probier das ganze mal partial zu bearbeiten (d.h. durch 1000, nachkomma speichern, das ganze von der orginalzahl * 1000 abziehen, die durch 1000 dividieren und das ganze nochal von vorne).
    ...

  • Das mit den abgedrehten Kommazahlen liegt am GM selber, der hat irgendwie in einer Entwicklungsphase zwischen 5.3 und 6 ne Ungenauigkeit bekommen, die Mark ihm nicht mehr abgewöhnen konnte. Er versucht es aber bis zu nächsten Version wieder im Griff zu haben.
    Das das aber aktiv einen Nachteil verursacht habe ich bisher aber noch nicht sehen können, aber bei dem Code oben könnte es daran liegen.
    "Die Erde ist ein Irrenhaus. Dabei könnte das bis heute erreichte Wissen der Menschheit aus ihr ein Paradies machen. Dafür müsste die weltweite Gesellschaft allerdings zur Vernunft kommen."
    - Joseph Weizenbaum

  • Benutzer online 1

    1 Besucher