999999*999999
Wie wärs mit ausprobieren? Hat keine 10 sekunden gebraucht das rauszufinden
Höhere Werte akzeptiert der GM nicht. Kann allerdings durchaus sein, das er bei so großen Räumen enorme Performance probleme bekommt. Auch hier gilt einfach ausprobieren.

theoretisch gesehen is ein raum sogar unendlich groß,
da der "Raum " ja nur die mit dem Gm belegbare fläche ist
man ber instanzen beliebig in den negativen bereich bewegen kann

performance hängt also nicht von der raumgröße ab

ich glaube (weiß aber nicht) dass der GM nur eine begrenzte raumgröße hat, weil es ja so ist, das beim rechnen mit großen zahlen ja schon fehler auftreten, dass man ab und zu wirres zeug rausbekommt
und wenn der GM so aufgebaut ist und mit großen zahlen einfach durcheinander kommt, dann ist es doch logisch das die raumgröße nicht zu groß sein darf

es könnte deswegen vllt auch sein das sogar gegenstände im GM fehler machen könnten wenn sie kurz vor raumende sind

natürlich ist es möglich, objecte einfach im step event oder so auserhalb des raumes zu befördern, aber bei zu großen zahlen bin ich mir fast sicher, dass der GM so wie beim mathematischen rechnen fehler macht... nur das man sie nicht sehen kann, weil das objekt ja auserhalb des raumes ist^^ :happy:

Ich hab das hier probiert:

room_set_width(bigroom,99999999999);
room_set_height(bigroom,99999999999);
room_goto(bigroom);

und in das create event von bigroom:

show_message("width: "+string(room_width));
show_message("heigth: "+string(room_height));

jezt ist der room 1215750144x1215750144 px ist.

Must da das hier probieren:
9999999999999999

dan wirst da ein -1215750144 wert zuruck bekommen.

und mit
999999999999999999999999999999
ist der room_width und room_height ... 0.

Das ist bei mein pc, also vielleicht ist das anders bei du.

Die größ eines Raumes mit einer seulchen größe ist dumm, wenn es viele Objecte enthaletn soll

Ich gib zu, bei Hankana (RPG PRojekt) ist der raum 20000x20000 groß und voll zu 75% bebaut, und es ist ruckelfrei.

Ligt aber auch n bissel am PC würd ich sagen

Aonsonsten, macht man mehrer räume, und macht einen Übergang zum nächsten, das es wie einer aussieht.

Aber, wozu so ein großen raum

In PBO (Was übrigens noch weiterentwickelt wird ) habe ich einen Raum mit 12000*8000 und keine bekannten Performance Probleme. Das hängt eher von Objekt & Sprite Anzahl ab und wieviele Alphamaps usw. du benutzt. In die Richtung solltest du keine Probleme haben

Ich habe und hatte ja schon öfters das Raum-Instanzen-Performance Problem. Da ist mir in der Nacht eine ganz simple idee gekommen: Einfach alle verwendeten Sprites, bgs, tiles etc. auf zB. 50% verkleinern, sodass sich das (fast) gleiche Leveldesign auf viel weniger Platz ausgeht.
meine standard räume bei meinem rts sind etwa 5.000 - 10.000 px groß. Wobei dies natürlich von den darin enthaltenen Umgebungstiles&bgs abhängt.

-gn

Man nehme, tolle sachen won Dr. Schnöttger



So müsste man das beheben können, auch wenn ich das noch net getestet hab, aber logischer weise.


€dit:
Was am code verändert.Das andere ging net

Aber das geht bestimmt noch einfacher , ich komm bloss net drauf.Iergend was war da doch oder?

Habe ich gearde gefunden, dass ist denke ich, noch einfacher und macht keinen komischen Kreiseffekt.
(Bei dir würde doch alles außerhalb eines Kreises weg sein, oder?)
woku

^^nur müsste man die 'Region' bei jeder View-bewegung neu definieren - und zwar sind das mehr als nur eine Region, da der view nich deaktiviert werden soll. Da ist die circle-methode sicherlich einfacher. Wobei bei einem zB. rts sicher auch nicht gut, wenn man mal kurz weg schaut und alles hört auf^^
-gn

bei instance_deactovate() ist ja klar, das jedes Objekt da einzelnt eingetragen werden muss.

Ist es bei solchen Dimensionen nicht naheliegend, lieber die Level- und Objektdaten woanders (z.B. in einem ds_grid) abzulegen? Der room wäre dann nur einen oder wenige Bildschirme groß, und man würde vielleicht von der klassischen GM-Objektstruktur abweichen (z.B. ein Objekt zeichnet alle Sprites, ein weiteres verwaltet alle Kollisionen, etc.) oder alle Objekte würden beim Programmstart erstellt und ggfls. deaktiviert (wenn outside room)
Gerade bei großen 3D-Welten (siehe WOW) ist das Programm darauf angewiesen, die Leveldaten abschnittsweise in den sichtbaren Bereich zu laden - bzw. sichtbar zu machen. Dieses Room-System finde ich für sowas ungeeignet weil man quasi nie flüssige Übergänge hat... z.B. Neverwinter oder Half-Life sind so aufgebaut, und da wird das Spiel immer durch lästige Ladezeiten unterbrochen.

Ich bevorzuge folgende Variante auch mit instance_activate...









Das ist meiner Meinung nach schon recht optimal, so dass es auch bei großen Räumen mit vielen instancen keine Probleme geben dürfte.

@Melancor
Mit dem Nachladen liegst du schon richtig, aber instance_activate/deactivate ist im Grunde nichts anderes. Denn es geht bei dem entfernen und Nachladen von Objekten nur darum, dass sie nicht dargestellt werden müssen und deren code nicht ausgeführt werden muss, und genau das macht das eingebaute instance_de/activate System vom GameMaker. Das ist schon optimal so.

Diese Ladezeit bei großen Spielen entstehen durch das Nachladen von Texturen, Sound usw.
Bei recht großen Räumen im GM mit vielen Grafiken und Sounds lob ich mir die Funktionen:



Um sound aus dem Speicher zu werfen und wieder zu laden.



Um Grafiken aus dem Speicher zu entfernen und wieder neu zu laden, allerdings nur möglich wenn die Grafik auch extern gelagert ist.
Entsprechende Funktionen gibts auch noch für den Background.



Wendet man diese Funktionen geschickt an den richtigen Stellen an, kann man viel Performance auch bei großen Räumen rausholen.