Was ist die Maximale Raum große

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

  • de.wikipedia.org/wiki/4-GB-Grenze

    Ich weiss nicht wie der Gamemaker das ganze handled, aber irgendwann geht dir eben der speicher aus, dann stehst du auf der 2147483647, 2147483647 koordinate und wenn du dann noch ein pixel weitergehst, bist du entweder bei -2147483647 oder bei 0, oder schlimmer; memory access violation bzw absturz.

    Aber wie gesagt, ich weiss nicht ob der GM da nicht eine abfang methode eingebaut hat.

    ancient-pixel.com
    youtube.com/user/SebastianMerkl <<< ich freu mich über einen Besuch ;)
  • Aku_Ryou schrieb:

    de.wikipedia.org/wiki/4-GB-Grenze

    Ich weiss nicht wie der Gamemaker das ganze handled, aber irgendwann geht dir eben der speicher aus, dann stehst du auf der 2147483647, 2147483647 koordinate und wenn du dann noch ein pixel weitergehst, bist du entweder bei -2147483647 oder bei 0, oder schlimmer; memory access violation bzw absturz.

    Aber wie gesagt, ich weiss nicht ob der GM da nicht eine abfang methode eingebaut hat.


    Bedenke dass die 4GB grenze (welche sich aufgrund des limitierten Adressbereiches von 32 Bit ergibt) sich nicht unbedingt auf die Bit-anzahl von variablen auswirken muss.
    Die 4GB grenze wirkt sich primär auf die Ram-Größe aus die von (32 Bit-) Windows Betriebssystemen adressiert werden kann. Einzelne 32Bit Programme haben meines Wissens nach sogar eine grenze von ca 2 GB.
    Es gibt aber dennoch die möglichkeit auf 32 Bit Prozessoren mit 64 Bit Variablen (double, long,etc...) zu arbeiten.
    Von daher hat man (Auszug aus Wikipedia) einen Zahlenbereich von:
    −9.223.372.036.854.775.808 bis +9.223.372.036.854.775.807
    (Wobei es bei steigender Zahl zu Precision-problemen kommen kann. Da muss man vorsichtig sein.)

    Der GM verwendet meines Wissens nach doubles (64 Bit) zum speichern von Zahlen.

    @Knockx:
    Ich kann mich noch errrinern wie ich zu GM 8.1 Zeiten probleme mit größeren Räumen hatte. Hat aber weniger mit der Variable zu tun gehabt als mit dem GM selbst.
    Das Problem war dass der GM einige Operationen durchführt die von der raumgröße auch abhängig sind. u.a. wären da die Tiles, welche nur gezeichnet werden, sofern sie sich in der View und im Raum befinden.
    Bei größeren Räumen (ich rede hier von einer höhe und breite die in den >=6 stelligen Bereich gehen) hat der GM scheinbar mehr zeit gebraucht um Background-tasks zu erledigen.

    Du kannst aber sehrwohl ausserhalb des Raumes objekte plazieren und die sogar zeichnen. (Du bist nicht an den Raum gebunden.) Von daher ist das einzige limit dass du hast der Darstellungsbereich einer 64 Bit variable.
    Aber wie gesagt, wenn du die Raumgröße zu groß wählst, könnte es zu performanceeinbrüchen kommen.

    Ich habe schon seit geraumer Zeit aufgehört auf die Raumgröße acht zu geben. Beispielsweise kann ich bei meinem Projekt problemlos in Kilometerweiten landschaften rumlaufen, während der Raum immernoch eine Raumgröße von 640*480 Pixel besitzt.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von LEWA ()

  • LEWA schrieb:

    (Wobei es bei steigender Zahl zu Precision-problemen kommen kann. Da muss man vorsichtig sein.)

    Der GM verwendet meines Wissens nach doubles (64 Bit) zum speichern von Zahlen.


    Das kann ich bestätigen, in meinem aktuellen Projekt benutze ich Raumgrößen von bis zu 852000 Pixel (in der Höhe/Länge).
    Einerseits ist es kein Problem außerhalb des Raumes Blöcke zu setzen, ich verwende beispielsweise meine eigenen room_height- und room_width-Variablen anstatt der eingebauten,
    nur wenn dieses Maß überschritten wird (in etwa bei 1000000 Pixeln) sind bei mir Rundungsfehler bzw. Ungenauigkeiten aufgetreten, da der GM wie schon gesagt mit Fließkommazahlen arbeitet
    -> je größer die Zahl, desto ungenauer kann der Bereich hinter dem Komma dargestellt werden.
  • Ich hab zwar grad keinen GM zur Hand, aber das sollte sich doch eigentlich relativ fix überprüfen lassen.

    GML-Quellcode

    1. test = room_add();
    2. room_set_width( test, power(2,64)+1 );
    3. room_set_height( test, power(2,64)+1 );
    4. room_goto(test);


    (2^64)+1 ist auf jeden Fall größer, als es 64bit-Integer (geschweige denn double) verkraften, da sollte also entweder was negatives rauskommen und der GM nen Herzinfarkt kriegen, oder es wird ein 1x1-Pixel-room erstellt.
    Und falls power so große Zahlen gar nicht ausrechnen kann und ihr's selbst eintippen müsst: 2⁶⁴ ist ungefähr
    18446744073709551616
    (aber für die letzten 3-5 Stellen übernehm ich keine Garantie).
    Hat mal wer Lust, das auszuprobieren? ^^

    edit: 1x1 natürlich, nicht 2x2. Die größte Zahl wäre bei (2^64)-1, da noch eins drafuzuaddieren, bringt einen wieder nach 0.
  • Nachdem ich gerade eine schlaflose Nacht habe und mir fad im Kopf war habe ich mal einen "GM-Herzinfarkt-Simulator" erstellt.^^

    Zusammengefasst gesagt: Die Roomdimensionen haben sogar nur einen darstellbaren Bereich von -2^31 bis 2^31-1.
    Alles was darüber hinausgeht wird wieder negativ, wie ihr schon vermutet habt Aku_Ryou und Irrenhaus.

    In diesem Bereich können Objekte auch noch dargestellt werden, aber ordentlich verzerrt.

    Wenn man die Roomkoordinaten ignoriert kann man auch über 2^999 gehen, von der Viewposition her, Instanzen erstellen kann man dann natürlich nicht.

    Ich vermute jetzt mal aufgrund der Tests die ich gemacht habe, dass die Roomkoordinaten 32 Bit Integers sind,
    aber die Objektkoordinaten, bzw. -positionen mit doubles dargestellt werden?
    Das könnte man jetzt wahrscheinlich noch ziemlich ausweiten. :D

    Hier ist das Testprogramm:

    EXE-Datei
    GMZ-Datei