MOIS source code on SVN

Bekas

22-05-2008 11:08:32

I've uploaded the MOIS source code on SVN.
Similar to Mogre, it contains the OIS CVS source (the more than 1 year old one, probably needs updating), and a copy of cpp2java along with a modified AutoWrapper.

Ideally, MOIS should statically link to OIS so that a self-contained MOIS.dll is produced (this also simplifies building since only one step is required).
The problem with this, at the time, was that OIS uses boost for the wiimote and boost inside a mixed managed/native DLL didn't work (threw bad format exception), so I had MOIS link dynamically to the OIS.dll.
Now, I'd suggest to go with statically linking, and if boost still is a problem for mixed DLLs, disable boost from OIS. If someone wants wiimote support he should compile it from source.

Beauty

22-05-2008 11:30:06

URL: http://mogre.svn.sourceforge.net/viewvc ... runk/MOIS/

(I repeat it, because the link is not good noticeable)

Marioko

22-05-2008 14:34:42

thanks Bekas

Ideally, MOIS should statically link to OIS so that a self-contained MOIS.dll is produced (this also simplifies building since only one step is required)

I was thinking in the same, downloading right now..

BTW OIS code is modified like Ogre??? if yes, can we have wrapper in one direction?? I mean MOIS->OIS and not MOIS <--> OIS?

Bekas

22-05-2008 17:20:51

Good question, I had forgotten about that.

OIS's sources are not changed, CLRObject is not used at all for MOIS.
MOIS classes are simple wrapper classes (MOIS->OIS).

Marioko

22-05-2008 18:09:44

oh great..

I was dreamming some day if we could have a MOGRE --> OGRE wrapper?? :lol:

drr00t

22-05-2008 20:29:47

Hi, all

I like to bring ParticleUniverse plugin to Mogre, so.
I trying reproduce the Bekas steps maded with MOIS wrapper and make the same with ParticleUniverse, I created the same directory structure like MOIS, generate xml files, with cpp2java. I have problems with functions entities, the AutoWrap not recognise this node from xml.

<type>class</type>
<definition>class ParticleUniverse::__declspec</definition>
<name>__declspec</name>
<parameters>
<parameter passedBy="value">
<type>dllimport</type>
</parameter>
</parameters>

The exception was throw in DefType CreateType(XmlElement elem) call.

You get this error any time?


Other think, the attributes.xml file, must be created by hand?

Thanks,

You are making a very good work, and i trying to help.

Thoran

23-05-2008 13:44:55

I've uploaded the MOIS source code on

Thanks a lot Bekas. Just trying to get all the stuff running in VC2008.

Thoran

Bekas

24-05-2008 13:23:50

I have problems with functions entities, the AutoWrap not recognise this node from xml.

<type>class</type>
<definition>class ParticleUniverse::__declspec</definition>
<name>__declspec</name>
<parameters>
<parameter passedBy="value">
<type>dllimport</type>
</parameter>
</parameters>

This seems messed up, there's a __declspec somewhere that confuses the all.xml -> meta.xml transformation (or maybe the problem originates in all.xml).
If the problem is in all.xml -> meta.xml you should modify "CodeGen\cpp2java\xslt\input.xslt". (I don't remember anything about xslt anymore, had to look it up back then)


the attributes.xml file, must be created by hand?
Yes.

Bekas

24-05-2008 13:50:27

I was dreamming some day if we could have a MOGRE --> OGRE wrapper?? :lol:
MOIS, in order to return the correct subclass, it checks whether it's a particular subclass (i.e. keyboard or joystick) by using dynamic_cast.
Also, for every OIS object returned, there's a new wrapper object created for it.
While this approach is inefficient, it doesn't matter because:

-OIS is very small and simple
-You don't create or manipulate lots of differenct objects, you typically get a keyboard/joystick object and use it the whole time.
-There are very few subclasses and there are no dynamically loaded extensions.

Ogre is exactly the opposite in all accounts, thus IMO the Ogre <-> Mogre way and 1-to-1 mapping between Ogre objects and Mogre objects is the most efficient way to go.

The drawback is that separate Ogre binaries need to be maintained but you have to take into account that we can't use the precompiled Ogre SDK anyway..

Marioko

24-05-2008 22:18:21

yep i know..

thats is why i say "i was dreaming" .... lol :D

dunce

15-04-2009 09:04:40

I can't build MOIS with VC2005 from the svn source. Compiler shows the folowing errors:

MOISInputManager.cpp
.\src\auto\MOISInputManager.cpp(24) : error C2352: 'OIS::InputManager::getVersionName' : illegal call of non-static member function
e:\Development\tools\MOIS\ois\includes\OISInputManager.h(55) : see declaration of 'OIS::InputManager::getVersionName'
.\src\auto\MOISInputManager.cpp(24) : error C2228: left of '.c_str' must have class/struct/union
MOISForceFeedback.cpp
MOISException.cpp
.\src\auto\MOISException.cpp(32) : error C2228: left of '.c_str' must have class/struct/union
type is 'const char *'
.\src\auto\MOISException.cpp(37) : error C2228: left of '.c_str' must have class/struct/union
type is 'const char *'
.\src\auto\MOISException.cpp(42) : error C2039: 'getIsThrown' : is not a member of 'OIS::Exception'
e:\Development\tools\MOIS\ois\includes\OISException.h(51) : see declaration of 'OIS::Exception'
.\src\auto\MOISException.cpp(42) : error C3861: 'getIsThrown': identifier not found
.\src\auto\MOISException.cpp(47) : error C2039: 'getLastException' : is not a member of 'OIS::Exception'
e:\Development\tools\MOIS\ois\includes\OISException.h(51) : see declaration of 'OIS::Exception'
.\src\auto\MOISException.cpp(47) : error C3861: 'getLastException': identifier not found


I use source of ois v.1.2 from sf.net. Maybe the source should be modified some way? Who managed to build MOIS, help please!!!

EDIT:
I tried to re-create auto wrapper code but AutoWrap utility crashes. When I ran it in the debugger I found out that it complains of some paths not being found that there are in meta.xml.

dunce

15-04-2009 12:15:22

I found the cause of the crash. There is a hard-coded path in Form1.cs. Now AutoWrap works and generates wrappers. Finally I managed to build mois.dll though there were more than 100 warnings.