Suchergebnisse

? Behandle einfach die dspeed Variable wie die normale speedvariable. Pack einfach ins step event: GML-Quellcode (7 Zeilen) das sollte die Geschwindigkeit so lange um den Beschleunigungswert erhöhen, bis der maximale Speedwert erreicht ist.

GML-Quellcode (2 Zeilen) das sollte gehen.

Kein Problem. Nur wirst du eventuell mit diesem System Probleme mit Alarmen und Kollisionen bekommen. Ein alarm basiert ja auf den fps, bei jedem neuen Frame wird 1 abgezogen. Da müsstest du dein eigenes Alarmsystem schreiben, das pro frame die Deltazeit vom alarm abzieht, damit jemand, bei dem es flüssig läuft nicht z.b. schneller schiessen kann als jemand bei dem es ruckelt. Probleme mit Kollisionen wirst du bekommen, wenn das Spiel sehr arg ruckelt. Je langsamer das Spiel läuft, desto grösser…

@Bl@ckSp@rk: ja richtig. Wusste ich gar nicht, das der gamemaker schon einen eingebauten Millisekundenzähler hat. Jo, damit klappt's. Ich habe mal ein Beispiel angehängt. Mit den pfeiltasten rauf/ runter wird die roomspeed erhöht/ verringert. Die Bälle sollten sich dabei aber immer mit der selben Geschwindigkeit bewegen, bei roomspeed 1 wie 9999.

Bei mir werden da immer krumme Werte ausgespuckt. Z.b. bei einer roomspeed von 100 kommt 1 frame lang 1, dann 0.54, dann mal 0... Wenn ich die Roomspeed auf 9999 setze dann kommt gar immer eine deltazeit von 0 raus. Das hängt wohl damit zusammen, das der Gamemaker den Zeitunterschied wohl nur maximal auf eine 10tel genau Sekunde ausgeben kann, was nicht exakt genug für delta timing ist. Um die Zeit zwischen 2 Frames zu berechnen muss man wohl eine dll benutzen. Es gibt auch irgendwo hier eine dl…

In der ersten sekunde des Spiels weist der fps wert 0 vor. Daher kommt wahrscheinlich auch die Fehlermeldung, bei einer roomspeed von 0 geht nämlich nichts mehr. Ausserdem wird der fps Wert nur sekündlich upgedated.

Den Code/ gm6 posten oder beschreiben, wie du das überhaupt gemacht hast. Bidde

Oh man bin ich blöd. Da hätte ich selber drauf kommen müssen, das das 2er potenzen sind. Danke Das dampft 103 bytes auf 23 runter und ich bekomme noch 60 1/0er dazu

Ich benutze jetzt deine Methode mit 3 Bytes und das funktioniert tadellos. Jetzt will ich aber die restlichen 100 bytes ein wenig effizienter nutzen. In ein Byte passen ja 8 true/false Indikatoren oder einfach 1 und 0. Wie man jetzt eine Zahl in 8 Einsen und Nullen zerlegt habe ich schon rausgefunden, aber wie man z.b. 10000000 in 1 oder 01010000 in 10 umwandelt weiss ich nicht. Wie wandelt man 8 Einsen und Nullen in ein Byte um?

Also wenn du die Surface nur ein einziges mal kreieren würdest, hättest du recht un das wäre wirklich schneller als es vom screen zu nehmen. 1000 32x32 sprites vom screen zu bauen dauert 1.06 Sekunden, mit nur einer Surface dauert's 0.94 Sekunden. Jedoch wird bei deinem Code bei jedem Schritt eine neue Surface gebaut, daraus ein sprite erstellt und die surface dann freigegeben. Kreiert man nach dieser Methode 1000 32x32 Sprites, dauert der Spass auf einmal 2.37 Sekunden (im vergleich vom Screen …

Egahl.

Lies doch einfach mal die Hilfedatei... GML-Quellcode (6 Zeilen)

Durch den restlichen Code blicke ich nicht durch, aber den Teil mit den Surfaces habe ich schon verstanden. Die Surfaces sind überflüssig, zeichne einfach auf den Bildschirm und verwende dann den Bildschirmausschnitt als Sprite. Dadurch wird zwar nichts schneller laufen jedoch funktioniert das Ganze dann auch auf Maschinen mit Grafikkarten die wenig speicher haben. Der grosse Nachteil an Surfaces ist deren bedarf an Videospeicher. Wenn der sehr gering ist, hat sich's bald ausgesurfaced und es ka…

random(nummer); RTFM!

Dann fängt das Prog halt an zu hängen. Das solltest du eh nicht z.b. ins step event knallen, sondern nur EIN EINZIGES MAL ausführen und dann mit den geladenen Daten arbeiten.

Ich habe den Script überarbeitet. Da waren ein paar lengthdir und sqrt(sqr()) funktionen zuviel, vor allem im for-loop. Wo der alte script (bei ausreichend hoher Rotation und Geschwindigkeit) bei 50 fps lief, läuft der neue bei 98 fps. Die Geschwindigkeit hat sich also fast verdoppelt! Die im ersten Post verlinkte gm6 enthält bereits den neuen Script. Wer den alten script verwendet muss den neuen einfach nur kopieren und den alten damit überschreiben, die Argumente und das Ergebnis sind die selb…

Eigentlich könntest du den Teil mit den Surfaces ja auch weglassen und stattdessen auf den Bildschirm zeichnen, den Bildschirmausschnitt als Sprite speichern, alles mit schwarz übermalen usw. anstatt für jede neue Spritekreation eine Surface aufzubauen und dann wieder einzustampfen. Surfaces würde ich generell vermeiden, es sei denn sie sind unumgänglich oder geben einen GEWALTIGEN Geschwindigkeitsvorteil, was hier aber nicht der Fall ist.

Das sieht schon mal sehr fein aus. Durch den Code blicke ich nur noch nicht so ganz durch, wie errechnet sich die Anzahl der gezeichneten Sprites?

Eine Lösung wäre, das Spieler nr 2 ein Gamepad/ joystick benutzt oder das du so wenige Tasten wie möglich für dein Spiel benutzt.

Linke Taste drücken: GML-Quellcode (1 Zeile) Rechte Taste drücken: GML-Quellcode (1 Zeile)