Also, da GM1.4 ja nun seit einiger Zeit das R-Tree collision sorting anbietet würde ich das natürlich auch gerne nutzen. Generell kann ich + 5-10% performance boost verzeichnen, grade bei über 2000 instanzen fängt man an den Unterschied zu merken.
Soweit so gut.
Ich benutze einen Persistent room um zwichen Menü/Spiel zu wechseln und gleichzeitig "pausieren" zu können. Das kann man jetzt natürlich bei einem Projekt dieser Größe als Faulheit abstempeln, aber eigentlich reicht es für meine Zwecke da ich keine Surfaces etc habe welche kritische Daten enthalten die gespeichert werden müssen und da ich keine großen Grafiken/Sounddateien habe kann ich mir leisten den Raum permanent im RAM zu haben. Nun, wenn ich mit dem "Fast collision system" (egal ob compatibilty mode an oder aus, sonst klappt ja auch alles fehlerfrei) zwichen Spielraum und menü switche gibt es nach dem 3 mal immer einen Freeze. Auch unabhängig von VM oder YYC reproduzierbar. Dachte erst es kommt vlt davon wenn man zu schnell die Räume wechselt aber damit hat es nichts zu tun, und mit dem alten collision system kann ich so schnell zum Menü switchen wie ich will.

habe keinen zusätzlichen Code, nur room_goto(rm_menu/rm_arena) im jeweiligen Event. Und wenn der Spieler stirbt und Leertaste zum respawnen drückt wird room_persistent = false gesetzt um room_restart() ausführen zu können. danach wird room_persistent direkt wieder auf true gestellt. Das sollte also auch keinerlei Einfluss haben. Ursprünglich lief das Menü langsamer als der Spielraum (40 Steps), hab ich jetzt auch auf 40 angehoben, hat aber auch keinen Unterschied gemacht. Nun sieht das alles so aus als wär das ein Compilerproblem und der Support ist ja auch eingestellt für 1.4.x ... Hat jemand schonmal sowas ähnliches erlebt und weiß vielleicht noch Rat oder hab ich einfach mal Pech gehabt? Seltsam finde ich halt das es immer nach dem dritten mal Game>Menü>Game einfriert so als wäre es in nem unendlichen loop gefangen. Das wage ich jedoch auszuschließen da ich erst Gestern/Vorgestern in anderem Zusammenhang per Suchleiste ALLE for und while loops durchgegangen und einzeln überprüft habe. Und glaubt mir das waren einige

EDIT: Also wenn man so 10 Sekunden zwichen den switches wartet scheint es doch gut zu gehen. Also denke ich das es GM intern ein Problem ist

EDIT2: Habe weitere Tests durchgeführt, wenn ich den room nicht persistent habe gibt es keinen Freeze, egal wie schnell ich switche...

Hmm also erstmal vielen Dank, der erste Link ist leider nicht so ganz mein Problem. Das Persistent rooms mehr Memory benutzen war mir schon bewusst und das das hin und her switchen ein paar kb mehr auf den RAM haut hab ich auch schon gehört. Wir reden hier aber von ca 100 MB für das Game im RAM, und ich hab 16GB verbaut. Die RAM Auslastung bleibt quasi konstant.

Um nochmal mein Problem zu definieren:
Gamemaker stellt in "preferences" eine tickbox für "Fast collision system" sowie "compatibility mode". Ist fast collisions aktiviert nutzt GM einen R- Tree um Kollisionen vorzusortieren, GM2 nutzt dies standardmäßig. Das bringt ein enormes Leistungspotential mit sich da Objekte die sich niemals berühren würden garnicht abgefragt werden. Des weiteren ändert das System Gamemakers x/y von round() zu floor() , da schneller. Das kann wiederum mit alten Projekten zu Problemen führen weshalb es den "compatibilty mode" gibt. Der ändert einfach nur das Rundungsverhalten zurück zu round().

Wenn ich also nichts am Spiel ändere ausser in Preferences zu fast collisions zu wechseln, dann gibts das Problem das beim switchen zwichen Menüraum und Spielraum(persistent) das Spiel zufällig einfriert. deaktiviere ich persistence im Raum so kann ich so schnell und oft ich will zwichen Menü und spielraum wechseln ohne einen Fehler.