GM 1.4.9999 Fast collision system und Persistent rooms

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

  • GM 1.4.9999 Fast collision system und Persistent rooms

    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 :sauf:

    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...
    132 little bugs in the code. 132 little bugs. Fix a few, set the compiler to stew, 172 little bugs in the code... :vogel:

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Rhazul ()

  • Hi, ich nehme an, dass Du den Speicherbedarf Deiner Anwendung gecheckt hast, um ein Speicherleck
    auszuschließen, daher kann ich Dir nur folgendes empfehlen......

    Hier ist ein User aus dem englischen Board, der selbiges festgestellt hat:

    forum.yoyogames.com/index.php?…ry-leak-empty-room.58192/

    Und hier bist Du besser aufgehoben, mit Deinem Anliegen, da V1.4 ja nicht mehr weiter entwickelt
    wird, gibt es einen Legacy-Abschnitt, wo man sich mit seinen Problemen hinwenden kann:

    forum.yoyogames.com/index.php?…ommunity-tech-support.12/


    Also zwei zusätzliche Ansätze für Dich, die Du unabhängig von hier, verfolgen kannst, um zu einer
    Lösung zu gelangen. Solltest Du fündig werden, dann poste doch Deine Lösung auch hier, um allen
    Anderen das Suchen zu ersparen :)


    Miradur
  • 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.
    132 little bugs in the code. 132 little bugs. Fix a few, set the compiler to stew, 172 little bugs in the code... :vogel:
  • Sorry, dann fällt mir nichts mehr dazu ein, ich habe auch nie mit 1.4 gearbeitet(nur gekauft :P ),
    weil nur ein paar Monate später 2.0 raus kam.
    Das Einzige, was mir noch dazu einfällt, ist ein Fehler, der diesen Kollisionsbaum nicht aktualisiert
    hat, wenn man mit persistent einen Raum gewechselt hat, aber der sollte eigentlich behoben sein.
    Der ist locker ein Jahr alt, daher bleibt Dir wohl nur noch der Legacy Thread, ob Dir vielleicht dort
    jemand helfen kann.


    Miradur
  • Benutzer online 1

    1 Besucher