Wiimote support

[Funto]

Hi all,

I am posting here as a continuation of this thread : http://oldforum.freegamedev.net/index.php?t=msg&th=3024&start=0&S=7b964f4b7ce90d4d2530c6fca6836dba

As stated there, I would like to add support for the wiimote to STK (Irrlicht SVN version), and I plan to use Wiiuse for this (only portable Wiimote library, though it does not handle MacOS X).

This requires adding Wiiuse to the build system, and I think the best option would be to provide its sources in the SVN, as is done with Bullet for example.

I would like also to have a discussion about the GUI for integrating this stuff.
Currently, I have seen that we can "add keyboards", but not remove them (or maybe I haven't found how to do so ?). Where is the association between the "keyboards" and the players done ? I suppose this should be done in the "Players" tab in the "Options" screen ? If this is the case, I think the "using wiimote N" option should be set in this screen too. Maybe you already handle this kind of stuff with joysticks, but I do not have any joystick to test, and I do not have so much time for looking at the code in depth...

I think the wiimote's controls should be standard and not customisable, as is on every Wii game. What do you think about this ?

Yet another thing about the GUI : for the wiimotes, there is a need for a "discovery" phase, where every player using a wiimote presses "1+2" on the remote control. I suggest there should be a button for this in the "Controls" tab in the "Options" screen. Again, what is your opinion about this ?

Last question : would you like me to create patches for the code, or could I have write access to the SVN ? I understand if you do not want to give write access to a complete stranger ^^. I could also have my own branch for wiimote support in the SVN...

I will try to conform as much as possible to the coding style of STK of course ^^

Thank you for your answers, STK developers and others

[Auria]

Hi,

thanks for coming back

I am posting here as a continuation of this thread : http://oldforum.freegamedev.net/index.php?t=msg&th=3024&start=0&S=7b964f4b7ce90d4d2530c6fca6836dba

As stated there, I would like to add support for the wiimote to STK (Irrlicht SVN version), and I plan to use Wiiuse for this (only portable Wiimote library, though it does not handle MacOS X).

This requires adding Wiiuse to the build system, and I think the best option would be to provide its sources in the SVN, as is done with Bullet for example.

Maybe we could; though, for instance, irrLicht remains a separate library. Since WiiMote support should be optional, my personnal take on this is that the library would simply be installed externally by the packager, then if present during configure, STK would enable WiiMote support

I would like also to have a discussion about the GUI for integrating this stuff.
Currently, I have seen that we can "add keyboards", but not remove them (or maybe I haven't found how to do so ?). Where is the association between the "keyboards" and the players done ? I suppose this should be done in the "Players" tab in the "Options" screen ? If this is the case, I think the "using wiimote N" option should be set in this screen too. Maybe you already handle this kind of stuff with joysticks, but I do not have any joystick to test, and I do not have so much time for looking at the code in depth...

Yes, this part of the GUI is not complete yet, removing keyboard configs is to come.
The association between players and device is done at the kart selection screen, where you can see "Press fire to join". Depending on which fire key you press, among the different configs, you're assigned one of them

I think the wiimote's controls should be standard and not customisable, as is on every Wii game. What do you think about this ?

Not sure, for now the easiest way is to just integrate it as any other gamepad; making a custom GUI and/or a custom logic for them would complicate the code with little gain, IMO

Yet another thing about the GUI : for the wiimotes, there is a need for a "discovery" phase, where every player using a wiimote presses "1+2" on the remote control. I suggest there should be a button for this in the "Controls" tab in the "Options" screen. Again, what is your opinion about this ?

Maybe that's only because I never used a wiimote, but I have no idea what you mean there, sorry

Last question : would you like me to create patches for the code, or could I have write access to the SVN ? I understand if you do not want to give write access to a complete stranger ^^. I could also have my own branch for wiimote support in the SVN...

Well yeah, initially I guess it might be better if you could provide a few patches for us to review; if the quality is good, I think you can get commit access quite quickly

Keep up the good work

[hiker]

Hi,

I am posting here as a continuation of this thread : http://oldforum.freegamedev.net/index.php?t=msg&th=3024&start=0&S=7b964f4b7ce90d4d2530c6fca6836dba

As stated there, I would like to add support for the wiimote to STK (Irrlicht SVN version), and I plan to use Wiiuse for this (only portable Wiimote library, though it does not handle MacOS X).

This requires adding Wiiuse to the build system, and I think the best option would be to provide its sources in the SVN, as is done with Bullet for example.

Maybe we could; though, for instance, irrLicht remains a separate library. Since WiiMote support should be optional, my personnal take on this is that the library would simply be installed externally by the packager, then if present during configure, STK would enable WiiMote support

Hmm - on one hand I would prefer to be a somewhat 'small' and uncommon lib to be part of sdk, but since it will always be optional, and I am not sure about the dependencies at this stage I'd say for now leave it as an external lib, add a --with-wiiuse to configure (we can help with that probably) to configure, and we add the same to the other build systems. Later we can always decide to include it (e.g. that might depend on feedback we get from packager, ...).

BTW, what system are you developing on? Linux, Windows, Mac ?

...

I think the wiimote's controls should be standard and not customisable, as is on every Wii game. What do you think about this ?

Not sure, for now the easiest way is to just integrate it as any other gamepad; making a custom GUI and/or a custom logic for them would complicate the code with little gain, IMO

I totally agree - but still try not to hardcode too many things (and if so, at least with some nice constants or so). I am somewhat certain that sooner or later someone will turn up who really really does not want to use our default, and might make things configurable

Yet another thing about the GUI : for the wiimotes, there is a need for a "discovery" phase, where every player using a wiimote presses "1+2" on the remote control. I suggest there should be a button for this in the "Controls" tab in the "Options" screen. Again, what is your opinion about this ?

Maybe that's only because I never used a wiimote, but I have no idea what you mean there, sorry

It's basically connecting the bluetooth device. I don't know the wiiuse api, but I see two options: if the discovery can be done non-blocking, it could be added to the kart select screen - similar to someone pressing fire to register that this device is being used now, on the wiimote you could press 1+2 to register the device. But that obviously would only work if registering is non-blocking (or done on a separate thread). Otherwise I'd suggest to add it to an existing tab somewhere. We have to find out later how we are going to package this version - i.e. if we have only one (say) windows binary with wiimote support, or different executables, ...

Last question : would you like me to create patches for the code, or could I have write access to the SVN ? I understand if you do not want to give write access to a complete stranger ^^. I could also have my own branch for wiimote support in the SVN...

Well yeah, initially I guess it might be better if you could provide a few patches for us to review; if the quality is good, I think you can get commit access quite quickly

Yes, send us patches for now, and we should be able to give you write access soon. Just have a look at the style guide in the wiki.

Looking forward to wiimote support!

Cheers,
Joerg

[Funto]

Hmm - on one hand I would prefer to be a somewhat 'small' and uncommon lib to be part of sdk, but since it will always be optional, and I am not sure about the dependencies at this stage I'd say for now leave it as an external lib, add a --with-wiiuse to configure (we can help with that probably) to configure, and we add the same to the other build systems. Later we can always decide to include it (e.g. that might depend on feedback we get from packager, ...).

BTW, what system are you developing on? Linux, Windows, Mac ?

As you say, it's a small and uncommon lib, but ok, for the moment I will just add a "--with-wiiuse" to the "configure" build system.
BTW I am far from being an expert with this system, so maybe I will need some advice on this part, I will ask here if it's the case ^^ (I usually use SCons ^^).

I am developing on Linux, but if necessary, I have access to a Windows or a Mac.

I totally agree - but still try not to hardcode too many things (and if so, at least with some nice constants or so). I am somewhat certain that sooner or later someone will turn up who really really does not want to use our default, and might make things configurable

Ok, I will have a look at how gamepads are integrated. Are they totally supported now ?
And yes, if I need to hardcode something, sure I will use constants ^^

It's basically connecting the bluetooth device. I don't know the wiiuse api, but I see two options: if the discovery can be done non-blocking, it could be added to the kart select screen - similar to someone pressing fire to register that this device is being used now, on the wiimote you could press 1+2 to register the device. But that obviously would only work if registering is non-blocking (or done on a separate thread). Otherwise I'd suggest to add it to an existing tab somewhere. We have to find out later how we are going to package this version - i.e. if we have only one (say) windows binary with wiimote support, or different executables, ...

Discovering the wiimotes is blocking ( wiiuse_find() ), however, as you say, I think there would be no problem in creating a thread for this.
Nevertheless, I think discovering the wiimotes when we select the karts is a bad idea, because discovering is not immediate (it usually takes some seconds). If several players want to use wiimotes, they would need to synchronize their wiimotes each time they choose their karts, which could be very frustrating.
It's like plugging your gamepad each time you start a new race ^^
I would go for adding 2 buttons "Connect wiimote(s)" and "Disconnect wiimote" "to the "Controls" tab, what do you think about ?

As for Windows packaging, no idea, it's up to you ^^ In fact I even never used bluetooth or wiimotes with Windows. I know there are several "bluetooth stacks" (wiiuse supports 4 of them : http://www.wiiuse.net/?nav=docs ), and I think we need to launch a special program for using the BlueSoleil stack, but I have no idea if this is still relevant (are they all 4 still used ?), or if there are special dependencies for this...

Thank you both for your precise answers

EDIT : ah, I forgot : until now, I have mainly used the libcwiimote library (Linux only), and discovery was not necessary : if I knew the bluetooth address of the wiimote, I could connect to it, probably in a faster way than first discovering, and then connecting to it. Maybe I should add support for this, but I think I would do this later on ^^

[Auria]

As you say, it's a small and uncommon lib, but ok, for the moment I will just add a "--with-wiiuse" to the "configure" build system.
BTW I am far from being an expert with this system, so maybe I will need some advice on this part, I will ask here if it's the case ^^ (I usually use SCons ^^).

So am I, but it should not be too hard to guess how it works by looking at configure.ac Maybe Hiker can help more precisely than I do

Discovering the wiimotes is blocking ( wiiuse_find() ), however, as you say, I think there would be no problem in creating a thread for this.
Nevertheless, I think discovering the wiimotes when we select the karts is a bad idea, because discovering is not immediate (it usually takes some seconds). If several players want to use wiimotes, they would need to synchronize their wiimotes each time they choose their karts, which could be very frustrating.
It's like plugging your gamepad each time you start a new race ^^
I would go for adding 2 buttons "Connect wiimote(s)" and "Disconnect wiimote" "to the "Controls" tab, what do you think about ?

Hum, might it not be annoying to need to go to the controls preferences everytime you open the game? But sure that'd work
EDIT: maybe we could use the "Add Device" button that's already there; then people could add a wiimote there

[Funto]

So am I, but it should not be too hard to guess how it works by looking at configure.ac Maybe Hiker can help more precisely than I do

Yes, in fact I have already added the --with-wiiuse support for Linux ^^ For the moment, I will keep with this platform, and try to add others after, except if you do it yourself before ^^

Hum, might it not be annoying to need to go to the controls preferences everytime you open the game? But sure that'd work
EDIT: maybe we could use the "Add Device" button that's already there; then people could add a wiimote there

Sure it can be annoying to need to go to the controls preferences everytime we start the game, but I do not see any better alternative.
At least, it's less annoying than having to synchronize the wiimotes at the beginning of each race...

I use the French language version of STK, so I suppose "Add device" is the "Ajouter une configuration" button (I suppose you already know of the problem that the size of the buttons does not vary according to the language ?).
So, what you propose is to add a button to the dialog box which opens after clicking on this button (right after "Add a keyboard" for example) ?
I think this is the good way to go...

Here is my first patch : it's just adding the --with-wiiuse option to configure.ac, which does not generate an error only in the Linux platform.
I took the freedom to replace the "dnl"-starting comments by "#"-starting comments because my editor did not like them, sorry if this is a problem, you can just use the interesting part of the patch ^^

[Funto]

Hum, in fact forget this patch, I will post another one when my current modifications are done...

EDIT : I attached a patch containing all my current modifications. Please tell me what you think about, if I am doing something wrong or no...etc.
I added a "WiimoteDevice" class, as I would prefer separating wiimote configuration from other gamepads configuration. Wiimotes can use or not the nunchuk, and can use accelerometers or not.
I am thinking of doing as with MarioKart Wii's of input handling : there are 2 modes : one using the wiimote's accelerometers, as a wheel, and another using the nunchuk, more classical.

As I am new to STK's source code, it's simpler to proceed this way, but if it's not ok for you, I can try to change this...

Thank you.

[Auria]

Hi,

the patch in general is a bit hard to read since there are many white space changes, which adds many more lines than were actually changed. But here we go :

{l Code}: {l Select All Code}

+#ifdef WIIUSE_SUPPORT
+    wiimote_t** m_wiimotes;
+#endif


I guess that works, but we usually use vectors, making stuff more dynamic, and less bug-prone. Especially, in the utils folder, you can find ptr_vector, a vector of pointers than can automatically delete all items of the array when going away.

Otherwise, what is "wiimote_t"? In your patch, it appears only twice, the libe above, and the forwards declaration "struct wiimote_t". I guess we'll get undefined symbols there

{l Code}: {l Select All Code}

 enum DeviceType
 {
     DT_KEYBOARD,
-    DT_GAMEPAD
+    DT_GAMEPAD,
+#ifdef WIIUSE_SUPPORT
+    DT_WIIMOTE
+#endif
 };

I guess this part won't work when WIIUSE_SUPPORT if off

Otherwise, this looks quite promising When you have something working, do tell me, I will look at integrating this into the code (I'm not sure about integrating code that does not yet work)

[Auria]

Forgot a bit :

{l Code}: {l Select All Code}

I use the French language version of STK, so I suppose "Add device" is the "Ajouter une configuration" button (I suppose you already know of the problem that the size of the buttons does not vary according to the language ?).

support for scaling buttons is somewhat inside, but more work might be needed indeed

[Funto]

the patch in general is a bit hard to read since there are many white space changes, which adds many more lines than were actually changed.

Yes I know, sorry, this is done automatically by Qt Creator when saving a file, it automatically deletes all unnecessary spaces...

I guess that works, but we usually use vectors, making stuff more dynamic, and less bug-prone. Especially, in the utils folder, you can find ptr_vector, a vector of pointers than can automatically delete all items of the array when going away.

Yes I know you are usually using vectors, but in this case, the Wiiuse library requires to use this type of array, and as the library allocates / deallocates them by itself, I can not use vectors instead.
Plus, there would be no need to use a vector in this particular case, because the array has a fixed size of NB_MAX_WIIMOTES (I suppose we will not use more than this number of wiimotes, which is 4 for the moment).

Otherwise, what is "wiimote_t"? In your patch, it appears only twice, the libe above, and the forwards declaration "struct wiimote_t". I guess we'll get undefined symbols there

This is a symbol defined in wiiuse.h. I only do a "struct wiimote_t" declaration for not including wiiuse.h in the header file, for not slowing down compilation time. This is suggested in your coding style guidelines (and I totally agree with this)
Maybe I should add a comment to explain this ?

Ah and about coding style : you recommend to use "my_variable" style of naming variables, but I have seen very often "myVariable". Can you confirm that we are supposed to use the 1st style everywhere in the code ?

I guess this part won't work when WIIUSE_SUPPORT if off

C supports this syntax :

{l Code}: {l Select All Code}

enum MyEnum
{
    VAL_A,
    VAL_B,
};


I think this feature of C is especially here for this kind of problem

I just noticed, your "make clean" target only cleans *.o in the src/ directory, but nothing in the subdirectories of src/

Otherwise, this looks quite promising When you have something working, do tell me, I will look at integrating this into the code (I'm not sure about integrating code that does not yet work)

Thank you
Well, for the moment it just initializes / cleans the wiimote API stuff and adds a dialog, and everything can be removed by not definig WIIUSE_SUPPORT.
Sure I will notice here when there is a new advance ^^

support for scaling buttons is somewhat inside, but more work might be needed indeed

Ok.

Thank you Auria for reviewing my patch

[hiker]

Hi,

So am I, but it should not be too hard to guess how it works by looking at configure.ac Maybe Hiker can help more precisely than I do

Yes, in fact I have already added the --with-wiiuse support for Linux ^^ For the moment, I will keep with this platform, and try to add others after, except if you do it yourself before ^^

That's fine - I'll add windows support, and can at least see how we go with Mac - perhaps with some help from Auria

Hum, might it not be annoying to need to go to the controls preferences everytime you open the game? But sure that'd work
EDIT: maybe we could use the "Add Device" button that's already there; then people could add a wiimote there

Sure it can be annoying to need to go to the controls preferences everytime we start the game, but I do not see any better alternative.
At least, it's less annoying than having to synchronize the wiimotes at the beginning of each race...

Agreed, if the delay is that long it is rather annoying. Suggestion: we add a command line flag (--wii or so). If this is specified there will be a separate title screen, asking people to connect the wiimotes. Before I forget this: we should add some kind of loading screen, and this screen could be re-used here, so it wouldn't be that much work. Then we could add a simple startup script to the packages to start with wiimote support, or without (and perhaps additionally we could also have the option of connecting them in the option menu). For now I'd say add whatever is easiest for you (even if it's without gui) - once people can test this, we can come up with the best approach.

...
Next posting:

I am thinking of doing as with MarioKart Wii's of input handling : there are 2 modes : one using the wiimote's accelerometers, as a wheel, and another using the nunchuk, more classical.

Sounds good!

And next posting:

Yes I know, sorry, this is done automatically by Qt Creator when saving a file, it automatically deletes all unnecessary spaces...

Hmm - this is a bit annoying. Can this somehow be disabled? I know that there are plenty of unnecessary spaces (e.g. at the end of a line, or in an empty line), but it really makes it very difficult to read a patch. Alternatively you should be able to use "svn diff -x -w ..." - which should ignore white spaces.

...

This is a symbol defined in wiiuse.h. I only do a "struct wiimote_t" declaration for not including wiiuse.h in the header file, for not slowing down compilation time. This is suggested in your coding style guidelines (and I totally agree with this)
Maybe I should add a comment to explain this ?

Feel free to add a comment, but it should be sufficient if it's just done at the right location (after #include before the actual declaration, i.e. where the class XYZ; declarations are).

Ah and about coding style : you recommend to use "my_variable" style of naming variables, but I have seen very often "myVariable". Can you confirm that we are supposed to use the 1st style everywhere in the code

Yes, we would like to have the 1st style everywhere, I just guess that we missed that in several places (or didn't pick it up when committing changes). I think there are also member variables that do not start with m_ If you see any inconsistencies, feel free to fix them, too

C supports this syntax :

{l Code}: {l Select All Code}

enum MyEnum
{
    VAL_A,
    VAL_B,
};


Gee, didn't know that. Just leave it in - if we get problems with what certain compilers accept, we can just include the "," in the #ifdef.

I just noticed, your "make clean" target only cleans *.o in the src/ directory, but nothing in the subdirectories of src/

The way the makefiles are created by autoconf/make all .o files are actually in the src directories. So this is the expected behaviour.

Thanks a lot for your support so far - having recently played Wii Mario Kart for the first time I am really looking forward to wiimote support

Cheers,
Joerg

[Funto]

That's fine - I'll add windows support, and can at least see how we go with Mac - perhaps with some help from Auria

Ok good

The --wii flag is a good idea However I will first try to make a working implementation, and add this kind of thing later

Hmm - this is a bit annoying. Can this somehow be disabled? I know that there are plenty of unnecessary spaces (e.g. at the end of a line, or in an empty line), but it really makes it very difficult to read a patch. Alternatively you should be able to use "svn diff -x -w ..." - which should ignore white spaces.

I did not know about "svn diff -x -w". In fact, I learned how to use "svn diff" when making these patches ^^. Thanks for the advice
Anyway, I think it can be disabled from Qt Creator, so I will remove this feature for the moment.

Yes, we would like to have the 1st style everywhere, I just guess that we missed that in several places (or didn't pick it up when committing changes). I think there are also member variables that do not start with m_ If you see any inconsistencies, feel free to fix them, too

Ok.

The way the makefiles are created by autoconf/make all .o files are actually in the src directories. So this is the expected behaviour

Oh ok, sorry. So if you can choose which directory the .o files go into, why not use a dedicated "obj" directory instead of polluting "src" ?

Thanks a lot for your support so far - having recently played Wii Mario Kart for the first time I am really looking forward to wiimote support

Well, thank you for letting me adding my small contribution to one of the best Tux-related games so far

[Auria]

Didn't know that enum thing either
But, you know, the easiest is not even to include the , in the #ifdef, the easiest is to not #ifdef the Wii enum entry at all

About mac port, well I can help, but I don't have a WiiMote, so hard to test ^^

[Funto]

About mac port, well I can help, but I don't have a WiiMote, so hard to test ^^

For it to work on Mac, it would first be necessary to port Wiiuse to the Mac, so at the beginning, Wiimote support will not be Mac-compatible anyway, sorry ^^

[Funto]

Hmm, I need to use multithreading for the GUI not to freeze when connecting the wiimotes.

Problem is I do not see any multithreading in STK, nor does it link with any multithreading library.
I know you are reluctant to add yet another new dependency, so I would like to know what is the preferred way to follow.
I see several possibilities :
- have the GUI freezing for 5 seconds, time of the synchronization ^^
- use pthread on Linux and Mac (Mac supports this, right ?), and pthread-win32 on Windows
- use pthread on Linux and Mac and the Windows API on Windows (I think this might be a good solution...)
- use another threads library, like OpenThreads (or...Boost, which I do not like, personal taste ^^).

[Auria]

Hmm, I need to use multithreading for the GUI not to freeze when connecting the wiimotes.

Problem is I do not see any multithreading in STK, nor does it link with any multithreading library.
I know you are reluctant to add yet another new dependency, so I would like to know what is the preferred way to follow.
I see several possibilities :
- have the GUI freezing for 5 seconds, time of the synchronization ^^
- use pthread on Linux and Mac (Mac supports this, right ?), and pthread-win32 on Windows
- use pthread on Linux and Mac and the Windows API on Windows (I think this might be a good solution...)
- use another threads library, like OpenThreads (or...Boost, which I do not like, personal taste ^^).

pthread sounds good. Yes, macs support it But anyway, since initially only Linux will be supported, I don't think we need to care about non-linux threads yet

[hiker]

Hmm, I need to use multithreading for the GUI not to freeze when connecting the wiimotes.

Problem is I do not see any multithreading in STK, nor does it link with any multithreading library.

That's correct. So far there was/is(?) no real need for multithreading, since the graphics were the bottle neck. Besides multithreading can be pretty hard to use it correctly, esp. with a program that 'evolved naturally' like STK - we risk wasting a lot of time chasing bugs, which only happen very infrequently.

I know you are reluctant to add yet another new dependency, so I would like to know what is the preferred way to follow.
I see several possibilities :
- have the GUI freezing for 5 seconds, time of the synchronization ^^
- use pthread on Linux and Mac (Mac supports this, right ?), and pthread-win32 on Windows
- use pthread on Linux and Mac and the Windows API on Windows (I think this might be a good solution...)
- use another threads library, like OpenThreads (or...Boost, which I do not like, personal taste ^^).

pthread sounds good. Yes, macs support it But anyway, since initially only Linux will be supported, I don't think we need to care about non-linux threads yet

We could actually add SDL back in - but I am not seriously suggesting that My preferred solution would be using OpenMP (http://en.wikipedia.org/wiki/OpenMP). It would mean that the code is portable, no additional dependencies are introduced and a rather easy programming API. Only problem: what free compilers support this? Apparently (see wiki link before and also http://openmp.org/wp/openmp-compilers/) Gnu CC since version 4.2, Visual Studio (and the SunStudio Compilers, which are available for free for Linux). While this should be verified (I can do this since I have access to all OS's), I think this should take care of all platforms we need. I am just not sure how well the programming model would fit the structure we need: OpenMP is a 'fork-join' programming model, e.g.:

{l Code}: {l Select All Code}

#pragma omp parallel
{
  #pragma omp sections
  {
    #pragma section
    handle_wii_connections();
    #pragma omp section
    do normal_gui_stuff();
  }   // end of sections
}   // end of parallel


(not really verified - sorry, I usually use Fortran *blush*). This code will use two threads, one executing the handle_wii_connections call, the 2nd the do_normal_gui_stuiff call. So if we can use this kind of code structure, we are fine with openMP.

Otherwise I am happy with pthread. Suggestion: for now make it blocking, since it would make sense to first get the wiimote running to see if it actually fits the game (e.g. we might need too many buttons or whatever ... unlikely admittedly, I am just trying to be careful ). Once we are happy with the way it works, we add the threads in. By then I should have more time (too busy working on the track exporter atm) and will be able to take care of this.

Cheers,
Joerg

[Pixel]

Hello.

My preferred solution would be using OpenMP (http://en.wikipedia.org/wiki/OpenMP). It would mean that the code is portable, no additional dependencies are introduced and a rather easy programming API. Only problem: what free compilers support this? Apparently (see wiki link before and also http://openmp.org/wp/openmp-compilers/) Gnu CC since version 4.2, Visual Studio (and the SunStudio Compilers, which are available for free for Linux).

This FAQ indicates that STK might have some sort of problem with GCC 4.2. Is that still the case?

Also, an "automated" mingw install would have to be updated for OpenMP. The default installs come with GCC 3.4.5 . IIRC, stable GCC 4 releases were only recently added, and I've not tried them yet.

The Blender website says that the ABI for I think C++ was changed from GCC 3 to GCC 4. I do not know if that will cause a problem. It could mean that STK's dependencies
would have to be rebuilt with GCC 4. I don't think an issue of this sort would be limited to just MinGW, though I supsect most recent Linux platforms have GCC 4 already installed.

Otherwise I am happy with pthread.

I've had some success running Blender on Windows, and it uses pthreads.

About the GUI freeze, can it be unfrozen if there's a problem (failure to connect to Wii-mote, etc)?

The GUI could just throw up a dialog that says "Connecting to Wii-mote(s), please wait...", right before trying to connect. Would save the trouble of dealing with a threading library. On the other hand, a total GUI freeze might make some users think something went wrong. Of course, they could be warned of the freeze before attempting to connect the Wii-motes.

@Funto: I don't actually write code for STK, but I sometimes build newer (and developmental) versions of it with MinGW, instead of Visual Studio. Wii-mote support for STK
sounds interesting. I've only played MarioKart Wii one time, and I like the idea of a Wii 'Wheel'-like interface for STK.

[Funto]

Thank you all for your answers

pthread sounds good. Yes, macs support it But anyway, since initially only Linux will be supported, I don't think we need to care about non-linux threads yet

Good, this is the easiest solution for me, and the one I prefer actually

That's correct. So far there was/is(?) no real need for multithreading, since the graphics were the bottle neck. Besides multithreading can be pretty hard to use it correctly, esp. with a program that 'evolved naturally' like STK - we risk wasting a lot of time chasing bugs, which only happen very infrequently.

I don't know of the current status of Bullet, but maybe now there is support for multithreaded broadphase interface, or something similar ? This way, maybe you could add multithreading for free But if really graphics is the bottleneck (well, depends on the GPU, the CPU, the track... no ?), I suppose it is not necessary to worry about this ^^

My preferred solution would be using OpenMP (http://en.wikipedia.org/wiki/OpenMP).

I have heard bad things about OpenMP (something from a friend like "never ever use OpenMP !!" ), but I never tested by myself. Nevertheless, I do not need to use such a powerful tool for just launching one poor thread for 5 seconds of wiimote synchronization, particularly if it is not supported by all compilers.

Otherwise I am happy with pthread. Suggestion: for now make it blocking, since it would make sense to first get the wiimote running to see if it actually fits the game (e.g. we might need too many buttons or whatever ... unlikely admittedly, I am just trying to be careful ). Once we are happy with the way it works, we add the threads in. By then I should have more time (too busy working on the track exporter atm) and will be able to take care of this.

Sure, first I will make it blocky, simpler and sufficient ^^

About the GUI freeze, can it be unfrozen if there's a problem (failure to connect to Wii-mote, etc)?

Basically, it would be :
- click on "synchronize"
- message : "please wait 5 seconds"
- 5 seconds later, you get the result ; if there has been a failure, it is reported, that's it.

@Funto: I don't actually write code for STK, but I sometimes build newer (and developmental) versions of it with MinGW, instead of Visual Studio. Wii-mote support for STK sounds interesting. I've only played MarioKart Wii one time, and I like the idea of a Wii 'Wheel'-like interface for STK.

Thanks

[hiker]

Hi,

I don't know of the current status of Bullet, but maybe now there is support for multithreaded broadphase interface, or something similar ? This way, maybe you could add multithreading for free But if really graphics is the bottleneck (well, depends on the GPU, the CPU, the track... no ?), I suppose it is not necessary to worry about this ^^

At this stage it's probably still the GPU (I haven't done any real performance tests with irrlicht yet) - and it's mostly the karts that are a problem. Usually the frame rate depends on how many karts you see. Level-of-details for karts would most likely help.

My preferred solution would be using OpenMP (http://en.wikipedia.org/wiki/OpenMP).

I have heard bad things about OpenMP (something from a friend like "never ever use OpenMP !!" ), but I never tested by myself. Nevertheless, I do not need to use such a powerful tool for just launching one poor thread for 5 seconds of wiimote synchronization, particularly if it is not supported by all compilers.

I've been using OpenMP for years, but admittedly in a more commercial environment, so no idea how good the free compilers are (I know the Sun compiler which is free for linux is fine).

Ideally I would like to postpone the threading discussion till after 0.7, when we had time to look at performance, and see if we need multithreading, and then add one library (or openmp or ...). But if we need it earlier, and the gui would be a prime example, we might go ahead with pthreads for now.

Otherwise I am happy with pthread. Suggestion: for now make it blocking, since it would make sense to first get the wiimote running to see if it actually fits the game (e.g. we might need too many buttons or whatever ... unlikely admittedly, I am just trying to be careful ). Once we are happy with the way it works, we add the threads in. By then I should have more time (too busy working on the track exporter atm) and will be able to take care of this.

Sure, first I will make it blocky, simpler and sufficient ^^

Great.

About the GUI freeze, can it be unfrozen if there's a problem (failure to connect to Wii-mote, etc)?

Basically, it would be :
- click on "synchronize"
- message : "please wait 5 seconds"
- 5 seconds later, you get the result ; if there has been a failure, it is reported, that's it.

I think that would be perfectly acceptable. If we support a command line option for wii, this needs to be done once during startup only.

Cheers,
Joerg

[ChemBroTron]

I know, it is a really old thread, but I didn't know, if I either create a new one or use this old one.

Anyway, I connected my Wiimote via Bluetooth, now that the Wiimote driver is in the Linux kernel, I wanted to test it. Only problem is: I can't assign the digipad (the cross: left, right, up, down) in the settings menu. Also Supertuxkart doesn't recognizes any buttons from addons (like the classic controller). Is there a way, to get it recognized? The digipad works, I could drive left, right and so on, but I can't assign the right axis in the menu. Though, the digipad worked only for player 1, as if they were arrow keys and player 2 had the shoot, nitro, rescue (and so on) buttons assigned. Was a little bit confusing (player 1 should have been keyboard only).

Well, maybe that's a little confusing, I'm a bit tired. :-D

[hiker]

Hi,

Anyway, I connected my Wiimote via Bluetooth, now that the Wiimote driver is in the Linux kernel, I wanted to test it. Only problem is: I can't assign the digipad (the cross: left, right, up, down) in the settings menu.

I don't know much about the wiimote driver support, but I'd guess that it doesn't emulate a gamepad, and therefore irrlicht would not recognise it. Till someone adds support for wiimote to STK, I doubt that it will work out of the box.

Cheers,
Joerg

[Funto]

A quick & dirty way to get the wiimote to work with STK is to use wminput (from the CWiid project), but I just managed to get it to emulate keyboard presses.

I didn't know about that native Linux wiimote driver I have no idea how it is exposed to client applications, so I can't tell much more...

[ChemBroTron]

So, after 2 days with an unstable internet connection (...), here are 2 screenshot about how the Wiimote in the STK options menu actually looks like (and yes, there is a gamepad symbol):

http://dl.dropbox.com/u/4950273/wiimotestk1.jpg

http://dl.dropbox.com/u/4950273/wiimotestk2.jpg

[Funto]

Hey, remember how there was no available portable (Linux/Windows/Mac) wiimote library?

Up to recently, wiiuse was the only one supporting Linux and Windows, which was a barrier in its possible adoption for STK.
Wiiuse is also the library used as a backend for libogc (part of DevkitPro, the framework for homebrew console development), and apparently it's also used in the GameCube/Wii emulator Dolphin-emu.

Well, the project seems to have been abandonned in 2008, but improved as part of the fWIIne project, and I found out the release of version 0.13, with MacOS X support
See this blog post: http://fwiineur.blogspot.com/search?upd ... -results=3

So my opinion is that in case one want to add proper wiimote support to STK (who knows ), Wiiuse would be the way to go