Henk van Lingen wrote:
Hi!
>> Actually, the chagnes to Scid were not that dramatical,
>> mainly some cleanup, but there were some changes
>> necessary in dgtdrv. So in case you want to use a DGT
>> board please make sure that you have at least V1.21 of
>> dgtdrv. It's in dgtdrv's CVS right now.
>
> Probably off-topic, but do you know whether this driver
> can or has been used to provide live games on the web with
> DGT boards?
Well, I wrote that driver, but nobody notified me of this
kind of usage. Of course nobody has to notify me about any
of it's usage ;)
> Are there open source solutions known to do live
> broadcasting?
Do you just want to feed the moves in a game to some sort of
auditorium? What way do you imagine to provide the moves?
Its not related to Scid, but we could discuss this issue by
PM e.g. In fact I think it would be pretty easy to
accomplish. Right now I'm prefectly able to record a game
into Scid and my (yet) private version here also has some
preliminary support to add time commentary to the game
within Scid, and I'm about to polish the overall
integration.
Now, from the design of this interface, well, Scid is just
one possible backend. I could feed the moves to any other
backend, and the backend does not need to be a chess GUI, it
could also be a transmission tool, or a converter to another
format, a script providing XML for a webservice ...
whatever.
The main idea behind dgtdrv is actually to act as this
interface, and to be easily embedded into whatever type of
scripting etc. Its a stand alone program that just uses
stdin/stdout. For debugging I use it on the bare console.
Hooking up some Perl e.g. with I/O routines to wherever,
well would be straight forward.
If you think of a large event with many boards and clocks
all connected to one PC, well, my possibilities are limited.
I've one DGT board and now one DGT clock, I was never able
to check if the DGTs BUS protocol works, which would allow
to hook up a bunch of boards at once.
I just know that in this case some extension would be
necessary to dgtdrv to demultiplex all the incoming moves.
Additionally, the principle protocol will need an extension
to tell which board sent which move. From the dgtdrv code I
can tell that the main event handling would definitely need
rewriting, today it is not done with many boards in mind
talking concurrently on the same file descriptor. However,
if this demultiplexing is done within dgtnix (the actual
hardware library behind it), an issue I started to discuss
with Pierre for the clock yestereve, the implementation
could probably be pretty straight forward...
Currently, dgtdrv gives output like (sending white moves
only, this is switchable)
move e2e4
info string move e7e6
move d2d4
info string move d7d5
Maybe with some infos about the clock. For many boards this
would still be valid output, but it should definitly not all
go to stdout but board 1 to some pipe, board 2 to another
and so on.
--
Kind regards, / War is Peace.
| Freedom is Slavery.
Alexander Wagner | Ignorance is Strength.
|
| Theory : G. Orwell, "1984"
/ In practice: USA, since 2001
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Scid-users mailing list
Scid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scid-users
