Thanks for all the comments.

shrapnel - Yes, it's GM. I think the problem must be about copying surfaces, since the two times that happens is when the paper moves up and when the high scores are rearranged. Maybe it's a graphics driver thing. I've got a laptop, so Ins and Del and suchlike are crammed in together in the top right.

Crackerblocks - are you sure there's a difference in speed between windowed and full screen? I guess I've mostly been playing fullscreen, and it's been okay. I also originally had some code in to stop you typing too fast, to make it more like an old typewriter. I took most of this out, but didn't rewrite it properly so there's a trace left which might feel like missing a key now and then.

Game Maker wizards,


Is it possible to take the sprite on the left and draw it as the sprite on the right?

I'm no wizard, but I've messed around a bit with blend modes in GM. Still, wouldn't the quickest solution be to make a copy of the sprite sheet with just silhouettes?

Or you could automate this - draw the sprite sheet (or a particular sprite) onto a clear surface. Then draw an opaque red surface over it, using draw_set_blend_mode_ext(bm_dest_alpha, bm_zero). This should give the colour and alpha from the source (the red surface), multiplied by the alpha of the destination (the sprite) and then add it to zero times the destination (giving no change).

The quickest and dirtiest thing might be: draw the sprite once, tinted black; then do draw_set_blend_mode(bm_add) and draw the sprite again ten times, tinted red.

There should be various other things like this possible using the blend modes, although I'm not absolutely sure how well they work alongside transparency.

This is really cool.  Very smooth, nice atmosphere.  The sound didn't work for me, but that's probably because I'm emulating.

Thanks! What are you running it on?

The emulation might also be the reason for the weird things you are seeing. It should be like typing on an infinite sheet of paper, with the typed words never moving back down the page. But I'm moving the paper up by copying the texture over itself, moved a few lines up, which maybe doesn't agree with your emulator. (As I write this now, I realize this is not the most sensible way to do it.)

On my keyboard Del is just above Backspace, so it felt like a reasonable compromise to have del go back one space and backspace go back one tab. So for overlapping words you can press down and then backspace a couple of times.

The enemies make thoughts go faster when they bump into them. You can get rid of them by matching them in the normal way.

I'm happy the notations turned out well. I spent hours worrying about an algorithm to place them in a suitable spot, but eventually decided that the kludgy thing I had would work fine 75% of the time, so left it as it was.

I love the animation in this. Your guy feels solid and heavy, and its great to see and feel him growing stronger.

The repeated corpse chewing did get old, especially on the second or third play-through of a level. I felt like I always had to stop and get the five or six chews out of everyone.

Great style, and the 3d effect is inspiring .

Finished, kind of. I wish I had had time to do the sound properly . The clock doesn't even tick, it only tocks.

The numbers are just for debugging. The bottom right-hand one is milliseconds per frame.

All the game stuff that I'm going to get in is probably in now, except for the time limit. Score more points by making combos; watch out for enemies; try pressing DEL. I've made the typing much easier since it got pretty much universal complaints before. But now it looks like the type-striking-thing is just flickering, rather than hitting the paper with any force. Bah. It's looking like any deepening of the textual part of the game is not going to make the cut.

Current priorities: drawing a clock; start and end of game stuff; scoring and pacing.

Edit: Clock is in. It looks odd, but in a good way.

I think vsync does work, in that it keeps you in synch with the screen's refresh cycle. It just seems to put you at the wrong place in the cycle. But it can still be made to work -- see the other thread: http://forums.tigsource.com/index.php?topic=3711.msg109620#msg109620

Sorry to hear it won't make it. I was looking forward to doing the funky spaceman.

From a general point of view, sleep() is better, since it allows the CPU to handle other tasks meanwhile. If the sleep() command in GM does not work well, you're out of luck, though.

Some people mentioned timer DLLs, maybe there is also a wrapper DLL for a short-term sleep command. Particularly if GM's inbuild sleep() has problems, I'm sure someone already made such.

I've got it working with GM's sleep now. It turns out the problem was that the function to check whether a key had been pressed or released recently wasn't working with sleep. I switched to checking the keys' current status, and now sleep works fine. I still don't get quite what's going on with vsync, but my tearing has gone for now. Thanks for all the advice.

I have some questions:

1. Are lots of instances a problem if they aren't doing anything on screen, and don't have any step events, but are just being used as data storage somewhere in the background?

5. & 7. What is the difference between sprites, surfaces and backgrounds? And aren't they all done as textures through 3d cards, these days? If so, it seems to me they should be drawn quickly, even if they are big; but what limits you will be the texture memory on the graphics card and how long it takes to copy to it. But maybe I'm misunderstanding things here. This question has come up for me in the game I am working on for the commonplace competition. It has a typewriter ribbon in it, which is quite big on the screen (maybe 100*200), but which is simple and only has two frames of animation. At the moment I am drawing it as a two-frame sprite; but would it be better to do it as two backgrounds? Or to draw it from primitives?

Also - it's probably a good idea to use low-colour images rather than 24 bit ones, since the game will be smaller and load faster; but does it make any difference to drawing speed?

@agj & increpare: The annoying to type thing is bad. It should be... interesting and fun to type. Hopefully I can tune this somehow.

The game doesn't have a lot of point at the moment. It's meant (eventually) to be an arcadey typing game about lining things up, made more interesting -- hopefully interesting enough for someone to enjoy a couple of five-minute sessions -- by three things, which I hope to have in by Friday:

1. A fun interface;
2. The feeling that you're constructing shapes on the page and doing things in 2d space, and a scoring system that rewards this;
3. The feeling that you are participating somehow in a Lovecraft story.

Originally I was thinking of a game more about stringing together phrases and constructing a proper story, but that seemed too hard for the time available to me. So I'm going for something very simple and arcadey instead, i.e. 2 above. Rather than constructing phrases you just try to catch ideas; you aren't really even trying to combine ideas together, or at least there's nothing in the gameplay to reflect this (unless I have some brainwave this evening, say, something about having to match ideas that are the same colour).

For 3, I am hoping that the progression of ideas in the words that come down will be enough to hint at some kind of story to the player, and that I can use an appeal to "stream of consciousness" or "free association" to avoid having to do any actual work of stringing together coherent sentences or plots.

The way it's meant to work in the current alpha is this. I went through a Lovecraft story picking out phrases, and noticed that the story fell into some natural levels: home, exploration (here wandering around a city), lore (hearing rumours and doing research about a cult), an evil place (a haunted church), and encounters with alien beings. The story moved through these levels in roughly this order, but after the first encounter the guy gets scared, goes home, does more research, and eventually encounters the monster again and dies. At the moment the game gives you phrases from the level appropriate to your current weirdness score, which goes up when you match words and goes down when you miss them. So the idea is that you go through the levels, getting closer to the encounter; but as you do this the game gets harder, so you are likely to miss some words and slip back; but you will eventually recover and reach a final, high-scoring, encounter.

This doesn't come through in the current alpha, hopefully only because the scoring isn't tuned right and you currently get too many words too fast, so don't have time to dwell on anything. Or maybe the idea just doesn't work.

Anyway, one simple refinement is to mix up the levels in sensible ways as the game goes on; the player should be paranoid after learning the scary lore, and home will seem like a less safe place. I am also hoping to make the progression through the levels more interesting than just a fixed linear order, and to have phrases available from different stories from just the one about the city. It would be good if these things could depend on what the player does; I'm thinking of simply mixing in phrases from the different options for what happens next, and going in whichever direction the player has got most of his score from. I don't at the moment see how to reconcile this choice between different stories with the game being themed around free association or recovering memories.

Alpha 26/11/08

This should be in a better shape than the last one. Instructions are the same as before, use keys to type, tab, delete, return, space and cursors to move. In particular holding down delete goes back to the start of the line, and cursor-left goes back one tab. Score points by lining up with and typing the words coming down to you. (Although I'm currently missing anything displaying points.)

I've spent the last couple of days getting the graphics into something reasonable. Tomorrow I want to do scoring, enemies and red ink mode. Thursday is sound and front end. My plans for a dynamic narrative generation engine will have to wait until, er, Friday.

Maybe instead of timing/waiting, use some kind of lock and not flip the buffer while a write operation is going on?

The for() loop really will be CPU unfriendly, particularly for people who have other programs running in parallel.

I'm worried that the for() loop is going to cause some problem like that, but the only alternative I know in GM is the sleep command (I'm pretty new to programming). I don't know if that's any better, and it's screwing up keyboard input.

[Start Date:]

Sorry if this has already been answered somewhere, but:

Start Date: Friday, October 17th

End Date: Friday, November 27th (Around Midnight)

November 27th is a Thursday. Can we take it that the finishing time is actually the end of Friday, November 28th, US West Coast time? Pretty please?

Couldn't just blit a low-alpha glow image over it?

That's what I'm doing, kind of. I think the trouble is that I tried to be fancy and put in one glowing rotating sprite for each letter of each word, and it looks like gamemaker thinks this is too many. Also I didn't want to look up how to get gamemaker to do sprites with proper levels of transparency, so messed around with blend modes instead - is there any chance that this is slowing things down?

Prototype 24/11/08


Keys to type, tab, delete, return, space and cursors to move. In particular holding down delete goes back to the start of the line, and cursor-left goes back one tab. Score points by lining up with and typing the words coming down to you.

I've fixed the tearing, at least on my system. I would be interested to know how it works for anyone else.

Otherwise, there's a basic word list in there and I've got them coming in reasonable patterns, with pauses for breath inbetween. Matching is more generous than it was; you can be a space off now.

I haven't worked on fancier scoring or anything like that yet. The game was looking like a mess, with an unreadable tangle of words filling up the screen, so I've been working on fixing this. I want the ideas floating down the screen to stand out, but the player still to be aware of the things he's typed before.

Screenshot (I'm sure it was looking better in the game):


Edit: I just tried this at work, and it's giving problems. The way I am doing the glow around the words is too slow, and has brought the tearing back.

Sorry if I wasn't clear - the buffer-flipping with screen_refresh is happening very fast, what's taking 11-15ms is the process of "physically" displaying the screen. So I get the tearing when I flip the buffer while the displaying is going on.

And the tearing is horizontal, as expected. The vertical line I'm talking about is part of my game, the edge between the paper in the typewriter and the background. I mention it because it makes the horizontal tearing show up very clearly.

Thanks! I was able to use "import scripts" to load the .gml file.

Now it's working.  I've got this in my initialization script:

Code:

//set up timer
hrt_init();
hrt_set_resolution(1000);
screen_wait_vsync();
t0=hrt_time_delta();
screen_wait_vsync();
t1= hrt_time_delta();
screen_wait_vsync();
t2 = hrt_time_delta();
ms_per_frame = (t1+t2)/2;
ms_to_bottom_of_screen = ms_per_frame -2;

and this as the main loop:

Code:

screen_wait_vsync();
ms_bottom_of_screen = hrt_time_now() + ms_to_bottom_of_screen;

typewriter_step();
phrases_step();

surface_reset_target();
draw_all();

while (hrt_time_now() < ms_bottom_of_screen) {} //wait until redrawing bottom

screen_refresh();

This works nicely. I've got a feeling that the dummy loop is working my processor (and thus my noisy fan) more than it should be. Probably it is possible to use sleep instead, but then I will need to do something to fix the keyboard input.

About tearing more generally, it probably depends on how fast your screen draws itself, what kind of thing you have on the screen and how fast it's moving, and where your attention is. I've got a high-contrast vertical line, which sometimes moves across the width of the screen at 24 pixels per frame, in an area which the player will be paying attention to. So if there's tearing an inch down the screen, the first inch of line is offset 24 pixels for about half a second. I found this made the game look very flimsy and unprofessional; it looks much more solid now. I'll have a look at your GM games when I get a chance and report back.

[rounded to the nearest 16 ms]

Aha! From Yourself on the GMC forum:

You can use the current_time variable. It gives the number of milliseconds since the computer was turned on rounded to the nearest 16 ms. So with GM's built-in current_time variable, you could implement timers accurate to the nearest 1/60 of a second which should generally be good enough for a game. There are times when higher resolution is required but this doesn't sound like one of them.

edit: I've replaced the sleep(11) with

Code:

for (z=0; z<7000; z+=1) {}

and this hides the tearing and leaves the keys working. But it's boneheaded. I guess I should look into yourself's timing dll, and have the game work out the refresh rate and do its own synchronization. I hope I don't end up needing a screen at the start of the game where the user has to fiddle with the timing until the tearing goes away. Something automatic would be much better.


--------------------------------------------------------------------------------

edit: Okay, I thought about this some more. If adding 11 milliseconds of sleep moved the tear from near the top to near the bottom of the screen, I guess that means that my computer takes about 15 milliseconds to draw to the screen, from the top to the bottom. That seems like a very long time, since a frame is about the same length, if it's running at 60 fps. Anyway, if this is so, then gamemaker's screen_wait_vsync actually waits until just after the screen starts being redrawn from the top. So I need to screen_wait_vsync, then wait about 14 milliseconds (or whatever the length of a frame is, minus two or three), in which time I should run all my code, and only then update the screen. If this is timed right, the update should be just before the redrawing starts from the top of the screen again.

So I've currently got this as my main loop:

Code:

typewriter_step();
phrases_step();

surface_reset_target();
draw_all();

for (z=0; z<8000; z+=1) {}
screen_refresh();
screen_wait_vsync();

This works okay, but I imagine it would be better to use a timer rather than go through a dummy loop.

I've downloaded Yourself's timer -- http://gmc.yoyogames.com/index.php?showtopic=219736 -- but I can't work out how to install it. It comes as a .dll file and a .gml file. Any help would be appreciated.