[Caml-list] Two severe limitations in Graphics module

[Caml-list] Two severe limitations in Graphics module

[Berke Durak]

Hello everyone,

I was wondering how many hours would coding Tetris using the Graphics
module require when I noticed that the Graphics module lacks two
important constructs :

1) The Graphics.wait_next_event doesn't allow you to wait for an event
with a timeout, à la select(). Since in Tetris things might happen
even if you don't press any key, you can't wait indefinitely.

Workarounds include :
	-- continuously calling wait_next_event [Poll;...]  and doing a
small delay between each call. I think I will do this. Not very
efficient, since the delay must be of the order of the screen refresh
interval.
	-- do a horrible hack by getting the X11 file descriptor -- but
then how will Microsoft-sequestrated people enjoy your delightful
MLtris ?

2) There is no way to get the cursor keys. Sure that's no problem to
h,j,k,l-people. Might I suggest the following bindings :

	-- left : '\002' (Ctrl-b)
	-- right : '\006' (Ctrl-f)
	-- up : '\011' (Ctrl-k)
	-- down : '\010' (Ctrl-j)

or a supplementary keysym type like

	type keysym = Latin1 of char | Left | Right | Up | Down | ...

3) It would further be nice to be able to select() another FD plus
the graphical interface, portably if possible. I know, under UNIX,
simply adding a function to the Graphics module that returns the
descriptor of the X11 connection would solve problems 1 and 3.
That would be non portable.

Has anyone managed to solve these issues cleanly (i.e. without
patching the compiler) ?
--
Berke
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Re: Two severe limitations in Graphics module

[Michaël Grünewald]

Berke Durak <berke@altern.org> writes:

> Hello everyone,
> 
> I was wondering how many hours would coding Tetris using the Graphics
> module require when I noticed that the Graphics module lacks two
> important constructs :
> 
> 1) The Graphics.wait_next_event doesn't allow you to wait for an event
> with a timeout, à la select(). Since in Tetris things might happen
> even if you don't press any key, you can't wait indefinitely.
> 
> Workarounds include :
> 	-- continuously calling wait_next_event [Poll;...]  and doing a
> small delay between each call. I think I will do this. Not very
> efficient, since the delay must be of the order of the screen refresh
> interval.
> 	-- do a horrible hack by getting the X11 file descriptor -- but
> then how will Microsoft-sequestrated people enjoy your delightful
> MLtris ?

1/You may have two threads, the first will watch the keyboard
(wait_next_event), the second will update puzzle tiles positions, both will
send events to your main loop, that will process these events.

2/Why don't use alarm signam or something like ?

> 2) There is no way to get the cursor keys. Sure that's no problem to
> h,j,k,l-people. Might I suggest the following bindings :
> 
> 	-- left : '\002' (Ctrl-b)
> 	-- right : '\006' (Ctrl-f)
> 	-- up : '\011' (Ctrl-k)
> 	-- down : '\010' (Ctrl-j)
> 
> or a supplementary keysym type like
> 
> 	type keysym = Latin1 of char | Left | Right | Up | Down | ...
> 
> 3) It would further be nice to be able to select() another FD plus
> the graphical interface, portably if possible. I know, under UNIX,
> simply adding a function to the Graphics module that returns the
> descriptor of the X11 connection would solve problems 1 and 3.
> That would be non portable.
> 
> Has anyone managed to solve these issues cleanly (i.e. without
> patching the compiler) ?
> --
> Berke
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
> Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> 

-- 
Michaël Grünewald <michael-grunewald@wanadoo.fr>  - RSA PGP Key ID: 0x20D90C12
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: Two severe limitations in Graphics module

[Berke Durak]

On Wed, Aug 28, 2002 at 08:06:42AM +0200, Michaël Grünewald wrote:
> 1/You may have two threads, the first will watch the keyboard
> (wait_next_event), the second will update puzzle tiles positions, both will
> send events to your main loop, that will process these events.

I will try to do this, thanks. I just tried ocamlsdl (I get a weird
relocation error at exit) and ocamlsvga (my S3 card isn't fully
supported), so I have no other choice.

I don't like threads very much because they are hard to debug with
ocamldebug, and native threads are not supported under every OS (for
ex. OpenBSD).

> 2/Why don't use alarm signam or something like ?

Alarm has only a single-second resolution and is not implemented under
MS-Windows. Plus the Graphics module uses the alarm signal, I think.
--
Berke
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: Two severe limitations in Graphics module

[Michaël Grünewald]

Berke Durak <berke@altern.org> writes:

> On Wed, Aug 28, 2002 at 08:06:42AM +0200, Michaël Grünewald wrote:
> > 1/You may have two threads, the first will watch the keyboard
> > (wait_next_event), the second will update puzzle tiles positions, both will
> > send events to your main loop, that will process these events.
> 
> I will try to do this, thanks. I just tried ocamlsdl (I get a weird
> relocation error at exit) and ocamlsvga (my S3 card isn't fully
> supported), so I have no other choice.

This is just an idea :)
 
> I don't like threads very much because they are hard to debug with
> ocamldebug, and native threads are not supported under every OS (for
> ex. OpenBSD).

Humm, isn't *everything* hard to debug with a debugger ? I never did use
one, and had ever been happy with `printf' and `flush', and according to
many people, the debugger is to be reserved for `critical' bugs.

Bye !
-- 
Michaël Grünewald <michael-grunewald@wanadoo.fr>  - RSA PGP Key ID: 0x20D90C12
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Graphics and Thread (was: Two severe limitations in Graphics module)

[Berke Durak]

On Thu, Aug 29, 2002 at 08:55:17PM +0200, Michaël Grünewald wrote:
> Berke Durak <berke@altern.org> writes:
> 
> > On Wed, Aug 28, 2002 at 08:06:42AM +0200, Michaël Grünewald wrote:
> > > 1/You may have two threads, the first will watch the keyboard
> > > (wait_next_event), the second will update puzzle tiles positions, both will
> > > send events to your main loop, that will process these events.
> > 
> > I will try to do this, thanks. I just tried ocamlsdl (I get a weird
> > relocation error at exit) and ocamlsvga (my S3 card isn't fully
> > supported), so I have no other choice.
> 
> This is just an idea :)

Hmm, I've just tried it, it doesn't work, seems that Thread and Graphics
don't mix very well, if one thread calls Graphics.wait_next_event, others
get blocked too. I'm recomping Ocaml with native threads now to see if
that will help !
--
Berke

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners