Nat Pryce wrote:

> I had the same problem writing a game in Eiffel, also using the SDL. 
> Here's the steps I took:
> 
> 1) Explicitly invoked the GC each frame.  That ensured that there was
> about the same amount of delay for GC every frame, instead of sudden
> lurches every few seconds.

This is what happens:

02-05-22 16:47:13:823326 ./game/lib/overlay.rb:356:in `poll' | GC took 22
02-05-22 16:47:13:847979 ./game/lib/overlay.rb:356:in `poll' | GC took 21
02-05-22 16:47:13:869757 ./game/lib/overlay.rb:356:in `poll' | GC took 21
02-05-22 16:47:13:891188 ./game/lib/overlay.rb:356:in `poll' | GC took 20
02-05-22 16:47:13:912836 ./game/lib/overlay.rb:356:in `poll' | GC took 21
02-05-22 16:47:13:940630 ./game/lib/overlay.rb:356:in `poll' | GC took 27
02-05-22 16:47:14:128456 ./game/lib/overlay.rb:356:in `poll' | GC took 188
02-05-22 16:47:14:152023 ./game/lib/overlay.rb:356:in `poll' | GC took 23
02-05-22 16:47:14:173605 ./game/lib/overlay.rb:356:in `poll' | GC took 21
02-05-22 16:47:14:195064 ./game/lib/overlay.rb:356:in `poll' | GC took 21
02-05-22 16:47:14:216440 ./game/lib/overlay.rb:356:in `poll' | GC took 21
02-05-22 16:47:14:375268 ./game/lib/overlay.rb:356:in `poll' | GC took 159
02-05-22 16:47:14:405899 ./game/lib/overlay.rb:356:in `poll' | GC took 30
02-05-22 16:47:14:427822 ./game/lib/overlay.rb:356:in `poll' | GC took 21
02-05-22 16:47:14:647790 ./game/lib/overlay.rb:356:in `poll' | GC took 219
02-05-22 16:47:14:693069 ./game/lib/overlay.rb:356:in `poll' | GC took 45
02-05-22 16:47:14:722121 ./game/lib/overlay.rb:356:in `poll' | GC took 28
02-05-22 16:47:14:743437 ./game/lib/overlay.rb:356:in `poll' | GC took 21

So even when I call GC.start before EventQueue.poll (since null events 
drive the animation), I get these totally unpredictable delays.  I think 
(unless I'm misinterpreting this) that I'm going to have to lump it for now 
and do something with Ruby's garbage collector for another release.

Damn.

> 2) Ran the animation loop as fast as possible (with a tiny delay to allow
> the OS to collect events), rather than using a delay to force a fixed fps.
> Fed the length of each frame into the simulation as the duration of the
> next frame.

There's no delay in it currently, and all the animation elements have their 
own idea of time from SDL_TimerTicks.  The frame-rate smoothing would be a 
nice addition, I'll probably do that later too, since the game is built on 
a basic GUI / animation toolkit, but the system load is reasonably 
predictable on the terminals so it's not really necessary for this release.

-- 
Matthew