Re: interactive game demo for gnuplot

[Daniel J S. <dan...@ie...>]

On 08/25/2013 03:14 PM, sfeam (Ethan Merritt) wrote:
> On Sunday, 25 August 2013, Juhász Péter wrote:
>> On Sun, 2013-08-25 at 10:29 -0700, sfeam (Ethan Merritt) wrote:
>>> On Sunday, 25 August 2013, Juhász Péter wrote:
>>>> On Thu, 2013-08-22 at 13:39 +0200, Petr Mikulik wrote:
>>>>>> Struck by sudden inspiration (and also motivated by the feel that the
>>>>>> "new" control flow capabilities are not advertised enough in the
>>>>>> existing demos), I wrote a small game demo, in pure gnuplot. I donate it
>>>>>> for the demo suite.
>>>>>
>>>>> Really cool!
>>>
>>> The other excellent feature of such demos is that they exercise parts
>>> of the program that don't otherwise get a lot of coverage in testing.
>>> The failure of "nibbles" on qt or wxt provided a convenient diagnostic
>>> tool for identifying and repairing a fundamental limitation on our
>>> mousing implementation.  So this week's gnuplot is that much better
>>> than last weeks, and all because of nibbles :-)
>>> (which now, by the way, works fine on both qt and wxt).
>>>
>>> 	Ethan
>>>
>>
>> ... and just to underline the validity this statement, I've checked the
>> second (Xixit) demo with the latest CVS version, and found that
>> yesterday's change has the unwanted side effect that the shortest
>> possible pause interval is now 1/20 second, which effectively breaks the
>> game.
>
> Really?   With which terminal?
> The 20 per second polling only kicks in if the requested pause
> is greater than 1/20 second. It should not affect shorter pauses.
>
> ~~~~~~
>      if (term->waitforinput)             /* If the terminal supports it */
>          while (sleep_time>  0.05) {     /* we poll 20 times a second */
>              usleep(50000-1000);         /* Sleep for 49 msec */
>              check_for_mouse_events();   /* This sleeps for another 1 msec */
>              sleep_time -= 0.05;
>          }
>      usleep((useconds_t)(sleep_time * 1e6));
>      check_for_mouse_events();
> ~~~~~~
>
> I did put an explicit 1 msec timeout in the individual terminal routines
> term->waitforintput().  I am not sure that this is a good idea, but the
> only scenario that I can see it affecting is a loop that would otherwise
> be limited purely  by computation speed.   This timeout can be
> removed easily enough - I will experiment.
>
> However, running xixit here reveals a totally different problem.
> I get this after a couple of minutes when I run using the x11 terminal:
>
>    gnuplot>  load '/home/merritt/cvs/contrib/xixit.plt'
>    _XF86BigfontQueryFont: could not attach shm segment
>    XIO:  fatal IO error 12 (Cannot allocate memory) on X server ":0.0"
>        after 502085 requests (502084 known processed) with 1 events remaining.
>
> That probably indicates either a failure to release memory somewhere
> in gnuplot_x11, or an event loop that isn't keeping up with the demo.
> I.e. it loops too quickly rather than too slowly.
>
>> I don't know if pause intervals shorter than that have a real use case,
>> but perhaps this solution is not as solid as first thought.
>
> I'm more worried that the 1/20 second limit you are seeing comes
> from something totally unintended.  That would mean that checking
> for mouse events in a computational loop, which was intended to
> be essentially free, may have a noticeable cost.

That may be the case.  I just updated to the latest code to test out 
this game, but there are some things that don't look right.

The first thing noticeable on my system is that the input at the command 
line in the shell window isn't working properly.  The introductory text 
is typed on the screen, then gnuplot stops.  After typing return, I then 
see the rest of the text appear that draws the "gnuplot>" line.  Typing 
return again will shift the window contents upward but then again 
gnuplot halts and I must again type return to get "gnuplot>" to appear. 
  Summarizing, it's as though the Enter key must be typed twice to have 
the same effect as a single Enter key being pressed.

As for the game, it seems to run fine, but it is whirling away redrawing 
the cursor position at the bottom of the screen as well as the cursor 
itself.  If I move the mouse around, it's only when I get the mouse 
positioned over some graph object like text that this redrawing speed 
slows down to what I've seen in past versions.

So I think you are on the right track that somehow gnuplot is getting 
into a mode where it runs away unintentionally.

Dan