Also man könnte die Bilder in ein Bildformat was sich mit der GRöße beschränkt also gif oder png.
Du solltest weniger Objekte und zu große Raume meiden da dies besonders bei schwächeren Rechnern das Spiel verlangsamt.
Lösche Objekte nach dem du sie nicht mehr brauchst.
Verwende für längere Texte lieber das Draw event als Texte als bilder zu machen da der Code sich nocht so sehr auf die größe aus wirkt.
Packe deine Datei in eine Archievierungs Datei wei zip, rar, cad oder so was.

Noch ein Tip zum Archivieren:
Bilder lassen sich besser Kompromieren in Archivierungsprogrammen als reiner Code.

Ja das stimmt, der Gm konvertiert die Bilder automatisch in ein einheitliches Format, insofern spielt das Dateiformat keine wesentliche Rolle.
Viel wichtiger hingegen sind die Farben: Glaub mir, das hat mir schon n Haufn Speicherplatz gespart: Bevor Du die Bilder in Dein Spiel einfügst, benutze ein geeignetes Programm zum reduzieren der Farben!Ich benutze hierfür Irfanview, was für den Vorgang wirklich sehr geeignet ist. Einfach das Bild in nem beliebigen Format öffnen und dann die Farben soweit reduzieren, dass die bilder qualitativ zwar kaum vom Original zu unterscheiden sind, durch das geringere Farbspektrum jedoch viel keliner sind, vor allem auch im Spiel.

Das Format ist dem Gm egal, aber auf die Farben kommts an.
Mehr Farben in Deinen Bilddateien-->Größere Datei
Weniger Farben in Deinen Bilddateien-->Kleinere Datei

Hoffe ich konnte Dir n bisschen weiterhelfen, dieses Wissen hat mir nämlich auch schon sehr geholfen.

Na siehste :] !

Freut mich, dass ich Dir helfen konnte.

wenn du die v6 benutzt gibts noch einen trick um sprites zu verkleinern. wenn du animierte sprites hast die sich drehen (im oder gegen den uhrzeigersinn ist egel) brauchst du nur 1 bild nämlich eins was nach rechts zeigt anstadt 36 bilder die immer um 10° versetzt sind.
der code ist dan image_angle+=10 (dreht sich gegen den uhrzeigersinn) oder image_angle-=10 (im uzs). dadurch spart man 35 bilder pro sprite.

das habe ich dir doch auch schon ma gesagt
nur du sagtest das du das schon gemacht hast :O

Edit:
und du kannst alle sprites in eine bildanimation reinsetzten
und dann die bildanimation im selben ordner abspeichern und diese animation als animation.dll abspeichern
dann musst du nur noch im spiel NUR EIN LEERES BILD machen und dieses leere bld mit der animation.dll am spielanfang umtauschen
dann wird es aber etwas schwerer animationen zu laden da diese alle in einer datei sind und mit subimage geladen werden müssen

es gibt 2 vorraussetungen
1) du must die v.6 des gamemakers haben
2) die version muss registriert sein.

zum ausprobieren:
mache einen viereckigen sprite in dem du volgenten code ins step event schreibst:
nun starte das game, und drücke mal die linke oder rechte pfeiltaste. es sieht dann so aus wie die spielfigur in gtaII
achtung:
der sprite dreht sich imer um seinen nullpunkt. setzt du ihn center drecht er sich um die eigene achse, ist der nullpunkt links oben (standart einstellung) drecht er sich um sine linke obere ecke.

Original von Nobody-86
mache einen viereckigen sprite in dem du volgenten code ins step event schreibst:

viereckige Sprites? Gibt es denn andere? Wartet nur, der Gamemaker 7 hat bestimmt fünfeckige und dreieckige Sprites, und der darauf "volgente" 8er sicher auch siebeneckige...

So, genug des Unfugs, klar war quadratisch gemeint, aber Defmasters Frage bezieht sich auf folgenden Effekt: Wenn man ein Sprite im Spiel mittels image_angle dreht, dann wird kein Anti-Aliasing durchgeführt, dagegen wenn man die Sprites im internen Editor mit der Funktion Rotation dreht, dann werden die Pixel (nicht die am Rand !) schön anti-aliased...

Meines Wissens bringt der Gamemaker das in Echtzeit nicht hin, sondern muss mit der image_angle-Methode auskommen...

Hm... wenn ich so ein schwarzes Viereck auf weißem Hintergrund im Sprite Editor rotieren lasse hat das bei mir auch den Treppeneffekt.

Außen, ja aber mal mal ein rotes Kreuz in dein schwarzes Quadrat und schau was dann passiert...

Dann hab ich ein rotes Kreuz mit schwarzen Intereferenzen, also immer noch Treppchen.
Du redest doch von der Funktion "Animation -> rotation sequence", oder?

Dafür gibt es dann auch aber einen trick, der allerdings eine gereggte Version erfordert. Einfach den Ausgangssprite vergrößern on the fly (damit die drehng platz hat), dann x Mal kopieren, drehen, als Einzelbild dem ersten Sprite hinzufügen, bis x alle abgearbeitet sind. Kann auf älteren Computern ein wenig dauern, aber wenn man e sgeshcickt macht, ist das eine ganz gute Lösung. Beim GM5 furchtbar nützlich. Am besten den user entscheiden lassen, obs eher schön oder eher schnell gehen soll ^^.

btw.: Andy, was meintest du mit deiner animations-DLL? Erklär nochmal...

Das ist so meine persönliche Kopf-Checkliste:
Sprites:
- Sprites alle möglichst kleine Maße? (Mit Crop arbeiten)
- Bei allen Sprites, die nur rechteckig (nur die sichtabren Teile) sind, oder die für keine Objekte mit Kollisionsabfragen benutzt werden, "Precise Collision checking" ausgeschaltet?
- Farbentiefe überall reduziert?
- Animationen durch on the fly mit image_angle, image_blend, image_xscale = -1 etc. ersetzt, wenn möglich?
- Animationen durch on the fly mit resourcen-modifiaktion ersetzt, wenn möglich? (Drehen mit anti-aliasing, black/white effects etc.)
- Möglichkeit, einfache Sprites las Masks für andere zu verwenden? (z.B. eine komplett ausgefüllte 32*32 Mask mit einer im Spiel schon vorkommenden Wand mit gleichen Maßen und keiner Transparenz ersetzen)
- Bei z.B. Knöpfen einen unbeschrifteten Hauptknopf gemacht, und die Texte entweder ingame als draw oder als eigenen Sprite "draufschreiben"?
- Bei kürzeren Texten als Sprites nicht lieber (sprite-)fonts benutzen?
-

Sounds:
- Buffer perfekt berechnet? (Nicht mehr als nötig)
- Sounds perfekt geschnitten?
- richtige Kombination aus wav und midi (ggf. mp3)?

Backgrounds:
- (s. auch Sprites)
- Bei "Kachel-Backgrounds" kleinstmögliche Wiederholung?
- Reine Gradient Backgrounds durch on the fly gradient backgrounds ersetzt?

Scripts:
- Häufig benutze funktions-abfolgen o.ä. als Script verarbeitet?

Objects:
- Möglichst wenige Objekte? Controller evtl. zusammenlegen.
- Ähnliche Objects einem Parent unterordnen, um doppelten Code zu sparen?
- Step Events entlasten, können diverse if-Abfragen nicht in andere events gepackt werden (z.B. wenn bei 30 Kristallen der Level geschafft ist, dies nicht im Step event abfragen, sondern im coll.-Event mit dem Kristall)


Da ist natürlich noch viiieeeeeell mehr, aber das sindso kleine Auszüge. Optimieren macht mir bei kleineren spielen allerdings furchtbar Spaß, deshalb würde ich mich dafür auch anbieten. In solchen Fällen einfach PN an mich und Spiel per Mail an mich (Die PN deshalb, weil in letzter Zeit manche Emails nicht ankamen...).

Hier nochmal zur Verdeutlichung was ich meinte:
Links im Game mit image_angle rotiert, rechts im Editor mit Animation->Rotatation Sequence

Ach das... trotzdem ist das kein echtes Antialiasing, da hab ich deinen Post wohl falsch interpretiert,

Stimmt, der Begriff triffts nicht ganz, sollte man dann eher von Interpolation sprechen? Weist mich bitte mal in die Fachsprache ein :D...

Wenn man die Rotation, so wie MewX sagt, am Anfang des Spiels erstellt, hält man zwar die Größe des Spiels klein, aber dafür wird immer noch mehr VRAM benutzt, als bei der image_angle-Methode. Da gilt es wie immer abzuwägen was einem wichtiger ist: Festplattenspeicher, Arbeitsspeicher oder Rechenpower...