Trust me: you want to click this link if you haven't seen it yet.

I believe I know what you yearn for. You wish to forgo the bounds of the typical behaviour of a game engine, and make your game's moving elements leave conspicuous trails as they animate - that is, to prevent the screen from refreshing after each frame, and repeatedly draw the sprites onto the same canvas. Well, Game Maker, at least from version 6 onward, is not set up to easily permit this kind of nonsense.

Let's consider the drawing sequence of Game Maker 6+ :
* First, the screen's buffer still possesses the screen image from the previous frame.
* If viewports are enabled, the buffer is blanked.
* If the background color is visible, it is drawn over the entire buffer.
* If there is a background image, it is drawn over the buffer.
* All instances and tiles are drawn, in descending order of depth.
* The buffer is refreshed to the screen, or the viewports if views are enabled.

This sequence is unalterable. So, here are some ways of allowing the previous frame to persist:

* Don't have any views, and have a static background

What causes the buffer to be obliterated in each frame is the presence of viewports, and the drawing of backgrounds. So if you eliminate these, the buffer's contents will persist.

On the first frame of the room, the background can be drawn. But from then on, it must be invisible. So, include an object with this code:

Create event:
alarm[0] = 1;

Alarm 0 event:
for(i=0; i<8; i+=1) {
background_visible[0]=0;
}
background_showcolor = 0;

The main advantage of this code is that it works in Lite and Pro versions, and, miraculously, even works in the HTML5 engine of GM Studio. But, of course, losing the use of views constrains you to a single-screen room, unless you feel apt to re-implementing scrolling and such on your own terms. So you might want a more technically strenuous solution.

* Use a surface as an alternative screen buffer

If the screen buffer cannot be preserved, devise a replacement.

You might do this by creating an object with a large negative Depth value with this code:

Create event:
s = surface_create(view_wview, view_hview);
surface_set_target(s);
screen_redraw(); // Draw the room's initial state onto the surface
surface_reset_target();

End Step event:
surface_set_target(s);
with all
if (visible && sprite_exists(sprite_index)) {
// This implies that only view 0 is being used
draw_sprite_ext(sprite_index,image_index,x-view_xview,y-view_yview, image_xscale,image_yscale,image_angle,image_blend,image_alpha);
// Replace that with event_perform(ev_draw,0) if it is necessary
}
surface_reset_target();


Draw event:
draw_surface(s,view_xview,view_yview);

What this does is create a surface, draw the first frame of the room on it, and from then on, forcibly draw all of the room's sprites onto the surface before Game Maker runs the drawing sequence, and then, at the end of the drawing sequence, draw the surface over the entire screen, obscuring the screen with your own surface.

This has a number of slight pitfalls. Firstly, there's really no way of accurately replicating GM's instance drawing without prior knowledge of how the objects are implemented. If an object has a Draw event, then that event is performed instead of drawing the sprite. But if it does not (and there is no way for the code to find this out) then it must be drawn using draw_sprite_ext(). In order to ensure that the instances are drawn ideally, you must either give each object a Draw event (one in which it simply draws its own sprite) or forgo Draw events in all of your objects.

Secondly, since this doesn't prevent every object from being drawn normally during the drawing sequence, the Draw events for the objects are still performed. If you call the Draw event for all instances in the End Step event, then they are thus made to happen twice per frame. If you were foolish enough to put game logic inside a Draw event (and you would be very foolish to do so) then you must sort that out yourself. (You could certainly prevent the objects from being drawn normally by forcing visible=0 during the loop in the End Step event, but only if you're comfortable obliterating any values for visible that were already there.)

This has an interesting effect when combined with views. The surface moves with the view, so it often provides the illusion that no motion is occurring. If the view is tracking the player's sprite as it moves to the right, the surface moves to the right at the same speed, so the player's sprite seems to leave no trail at all. This is a counterintuitive but nonetheless logical conclusion, and may well be desirable if you are interested in making your game as "authentically glitchy" as possible.

Now, you might instead want an alternative: a surface which is stationary relative to the view, and covers the span of the entire room, so that the sprites always paint a trail regardless of the view's movements. The biggest problem with this is that, if your room is, say, 12000x480, then you quite probably won't be able to make a surface large enough without running out of video RAM. Nevertheless, if you feel your game is capable of doing this within reason, then feel free to modify that example code to suit this solution.

Attached is an example program that demonstrates these methods, in the objects o_trails_basic and o_trails_surface. The included room only demonstrates the latter object, and contains a view which follows the red sprite's movements.

Game File: 

gratuitousprofanity.zip

Controls: Arrows + X

Scoring: 1 point per "fuck" heard

Voices: Evan Balster (@celluloseman)
Art: PANPOMMA

Background: Had a weird idea in 2010 to take Mafia 2 on for the Guinness World record for most profanity in a videogame. Made a TIGSource devblog. Got some awesome art from PANPOMMA and some awesome recordings from Cellulose and AGJ. Then promptly lost interest before finishing a prototype in Flash. This is a new MMF2 prototype I hacked together tonight for Glorious Trainwrecks.

Video: http://www.youtube.com/watch?v=TzebtB2WR-c (spoilers)

Game File: 

Smokat.zip

Paint in the void using the ghost of a cat.

Game File: 

thursday.zip

A brief history of video games! Use the arrow keys to do stuff.

Graphics mostly stolen from MYLONELYDAYS.COM. (Defunct!)
Sounds entirely stolen from James.

Game File: 

warningoldman.zip

Witam i zapraszam do wspaniałych maszyn konia symulatora. OSTRZEŻENIE starego podejścia MAN. nie akceptuje układ ograniczenia pomarańczy. Komputer demontować z OSTRZEŻENIE i starych atak człowieka. Skrzywić się krzyk od hotelu.

안녕하세요 그리고 아름다운 말 시뮬레이터 기계에 오신 것을 환영합니다. 경고 오래된 접근법 사람. 시스템은 오렌지의 한계를 허용하지 않습니다. 경고 컴퓨터를 분해하고 오래된 사람을 공격한다. 주춤 호텔에서 외침.

This has been sitting around unfinished for like 2 years. It's another one of those "standard sokoban... with a twist!" games.

Not very many levels.

Game File: 

leather.html

Actually made several days later for the Big Trashy Twine Jam, but it can live here too.

Game File: 

atariture.zip

A completely infringing (and very cheaty/lazy) work:
Atariture!

An evil insectoid Law-Yar has stolen Atari's Fuji symbol and with it, Atari's mojo.

You must journey to the evil black castle and rescue the Fuji symbol

This is actually a pretty detailed play-alike to Atari 2600 Adventure, written in Java processing, for another top-sekrit project of mine... it took hella longer than 2 hours, lots and lots of 20 minute subway sessions.... my 2 hour-ness was a simple sprite mod conversion, in the finest of Pirate Kart traditions!

The 1200-in-1 pirate cart is a NES multicart that contains Contra, Super Mario Bros., Tetris II, Chinese Chess, Battle City, Field Combat, Antarctic Adventure, Circus Charlie, Binary Land, Bomberman, Ice Climber, Galaxian, Ninja Jajamaru-kun, and Road Fighter, with various level-skip hacks or other permutations.

Game jam idea: make games using the titles of these entries.