[Gambas-user] A fine afternoon for a good rant

[Benoît Minisini]

Le 28/02/2019 à 18:51, Cedron Dawg a écrit :
> I'm reaching frustration levels here.  This is a rant.
> 
> I wrote a nice little video game in Gambas that employs a GamePad or
> Joystick.  Good enought that I wanted to share it.  Not just for the
> playability, but to provide a starter program for others who may want
> to write their own video game, but don't know how to start.
> 
> First problem:  Gambas doesn't have Joystick/GamePad support built
> in.
> 
> Okay, I can do that in C with a shared library.  Gambas support for
> shared libraries is simple and easy.
> 
> Second problem:  How do you distribute a shared library along with
> your project?
> 
> Thorny issues like 32 bit vs 64 bit, special compilation instructions
> for the end user if just source is distributed, etc.  Better to build
> a Gambas native component.
> 
> Third problem:  How do you do that?
> 
> RTFM.  (Read the *fine* manual)  Tried, somewhat incomplete.
> 
> Two ways:  C or Gambas
> 
> Okay, to do it in C properly requires a large investment in getting a
> development environment set up.  (Economics term: "Barrier to Entry)
> 
> Fourth problem: My shared library is based on the legacy joystick
> model, it needs to be updated to the current model (evdev).
> 
> Okay, do a bunch of research, recode, and test the in a console app.
> Works great.  Upload for someone to adapt to the Gambas environment.
> 
> The sound of *fine* crickets.
> 
> Obviously nobody is interested or cares enough to do the work.
> Tobias is kind enough to convert his existing code and upload it to
> GitHub.
> 
> Fifth problem:  It is also based on the legacy model.
> 
> Okay, use Tobias' code as a template and incorporate the evdec
> GamePad code the best I can.  I know it is close, but not completely
> correct.
> 
> Sixth problem:  Tobias' code uses a GB.Watch to follow the file
> descriptor so Gambas can call when input is ready.  Evdev doesn't
> work that way, it reads the FD and makes an internal queue.
> Therefore, my component has to be called polling style from the main
> event loop.  How do you do that?
> 
> GB.Hook doesn't seem to have the right call.
> 
> GB.Post looks close, but it seems to be a one time deal.
> 
> Okay, step back a minute.  Maybe it would be better to develop a
> Gambas component, and call libevdev from there.  First thing to do is
> to figure out how to make a component in Gambas.  Great, there is a
> doc page for that:  "How To Program Components In Gambas"   Just what
> I need.  Create the project, check.  Test the stubby little component
> from within its project.  Check.  Oh no, the documentation turns to
> special "Control" implementation details.  Good if I need that, but I
> am not trying to make a control.
> 
> Okay, time to package this sucker up and install it so I can test it
> from another Gambas project, as if I were a different user.  No point
> in not trying.  Use the Project/Make/Installation Package menu
> options, go through the screens, produce a *.tar.gz.  Hey, that was
> easy, there it is.
> 
> Okay, time to install it.  Look on the internet for how to install
> tar.gz's.  Normally I use Package Manager to do everything, so this
> is new to me.
> 
> Find:
> 
> tar -xzf archive-name.tar.gz cd archive-name ./configure make sudo
> make install
> 
> The first two steps I can do easier through the File Manger window,
> but I did it both ways.
> 
> Seventh problem:  There's no ./configure file.
> 
> At this point I am going to take a break.  All I wanted to do was
> share a neat little demo program I wrote.  I am not knowledgeable
> enough to become a major contributor to the project itself, yet.  I
> do like Gambas a lot.  It is an incredible piece of work.  I have
> been doing a lot of work in Python, which I consider to be a dialect
> of BASIC.  It has some neat features of its own.  Much of the
> popularity of Python as to do with its MatplotLib and Numpy/Scipy
> libraries.  Gambas is lacking those or you would have a large client
> base ready to convert simply because of the ability to quickly and
> easily develop GUI apps in Linux.
> 
> Having GamePad support would also gain you a large base of newbie
> programmers wanting to learn how to program video games.  If you can
> program a game, a busines app is a piece of cake.  Game programming
> is more fun.
> 
> Final word:
> 
> Benoit, buy a GamePad.  It is as much a toy as BASIC is a toy
> language.  You'll see what I mean.
> 
> I'm going for a walk.
> 

Welcome to the world of programming.

Before reading "how to make components", did you read the wiki page 
"compilation and installation", where it is explained how to compile and 
install Gambas from sources? Apparently no.

You have to generate the "./configure" file first, by running 
"./reconf-all".

See that page: http://gambaswiki.org/wiki/install

As for the joystick support, I thought that SDL would be enough. You 
usually use SDL to make games.

Anyway, it could be a good idea to make a component that gives access to 
libevdev.

As for your event management problem, no, you don't have to poll.

According to what I read in the libevdec doc, you just have to watch the 
evdev file descriptor returned by libevdev_get_fd(), and then use 
libevdev_next_event() in the watch handler.

As for adding a component in the source tree, it's a boring and ugly 
work. Because it's based on autoconf & automake, and it's them that make 
the process boring and ugly.

I can do it for you.

I strongly suggest to make a component with a C part and a Gambas part. 
The C part will contain only helpers functions, and the Gambas part will 
be the actual public interface of the component.

Regards,

-- 
Benoît Minisini