Since yesterday I have been playing around on the WII controller integration on my PATRIA 3D engine.
This is required in order to have a fully working accelerometer support for our games testing since it is quite an effort to perform real testings on the smartphones especially when you are still in the middle of the caos of code development.
I have been trying the libwiimote on my ubuntu 64 bit but unfortunately, for some reasons, it does not look like the best solution for me (thought the library is well done). In fact it has a lot of sleep/wait time in the implementation which cause the frame reate of the game Fantasy Racing to drop to 15/18 FPS on my laptop. It looks like that, if no input is made on the device, the wiimote_update function freezes my process.
I have then decided to go for libwiiuse and I find it fantastic though I have not yet completed the integration.
To cut a long story short, I have compiled the library, using the well done documentation, I have done all the required configuration steps in my eclipse environment but every time I have run a compiled program using the shared object library libwiiuse.so I used to get this error message:
error while loading shared libraries: libwiiuse.so: cannot open shared object file: No such file or directory
This problem has kiled me since I spent a lot of time looking for an explanation to the root causes of it.
After I while I thought.....holy crap Maurizio, can you be such a stupid? The new library is a shared library which links other shared libraries, let's try to refresh the dynamic linker cache by running the command ldconfig
.
And....it actually solved it.
Lesson learnt, whenever you have problems linkind shared libraries, always remember to update the linker cache!!!
Thursday, April 3, 2014
Android and HW differences
"This article was created on my old blog in 2012"
Since the release of the first game on the Android Market I have faced the usual problems on the HW differences of the different Android devices on the market.
I think this is the actual limitation of the Android platform, a lack in the HW standards.
This limitation forces every developer to perform endless sessions of quality testing on a multitude of devices that ofter represent a serious limitation for and indie team.
Not all the people of starting teams can afford to have tens of devices for testing and, even if they can, no one can guarantee that the application won't crash on a specific sub version of the HW or a specific version of Android.
As if it was not enough the presence of a multitude of custom Roms, custom access levels (root access), anti virus and anti spy-wares make the situation out of control and almost impossible to be handled by simple human beings.
Besides, if you decide to go for a custom code written in C, eventually using the Android NDK, things gets harder and harder.
Just to report an example of this, when we released the version 1.7 of Fantasy Racing, we started received bad reviews (four one star in one day, terrible!) and we didn't know how to react.
In the comments our users reported things like "always crashes" or "does not start" while on our devices the game was rock solid and very stable.
We realized that all the users reporting the errors were running the game either on Galaxy SII or Galaxy Note which are 2 very common devices in the Android market.
We started digging around and we found many forums talking about bugs specific for these devices. Bugs were pointing to ADMOB compatibility or the soundpool bug. We released fixes for these problems but apparently nothing changed, we continued to receive bad reviews from our users.
We decided then to procure some devices having the same specs and we found out that on a Galaxy SII of a friend of ours, the game went very smoothly while on a Galaxy SII of another friend it constantly crashed.
To cut a long story short, we found out that the problem was depending on our PATRIA3D Engine which used to ask the GPU to draw an "not existing" Vertex Buffer Object in some game conditions and that the GPU on these devices (Mali 400) raised an error blocking the game.
The same problem didn't happen on our testing devices using different GPU families such as PowerVR, Adreno or NVidia.
In simple words, the problem was caused by a bug in our code but we had different behaviors depending on the GPU installed on the devices (though I think it is mostly related to the OpenGL driver implementation of the device).
We have now fixed the problem and the game is rock solid on those devices but unfortunately the bad reviews remains like a stain we cannot remove.
We still cannot explain why on same Galaxy S2 devices the game worked fine but start thinking about them as mysteries of the Android World.
Since the release of the first game on the Android Market I have faced the usual problems on the HW differences of the different Android devices on the market.
I think this is the actual limitation of the Android platform, a lack in the HW standards.
This limitation forces every developer to perform endless sessions of quality testing on a multitude of devices that ofter represent a serious limitation for and indie team.
Not all the people of starting teams can afford to have tens of devices for testing and, even if they can, no one can guarantee that the application won't crash on a specific sub version of the HW or a specific version of Android.
As if it was not enough the presence of a multitude of custom Roms, custom access levels (root access), anti virus and anti spy-wares make the situation out of control and almost impossible to be handled by simple human beings.
Besides, if you decide to go for a custom code written in C, eventually using the Android NDK, things gets harder and harder.
Just to report an example of this, when we released the version 1.7 of Fantasy Racing, we started received bad reviews (four one star in one day, terrible!) and we didn't know how to react.
In the comments our users reported things like "always crashes" or "does not start" while on our devices the game was rock solid and very stable.
We realized that all the users reporting the errors were running the game either on Galaxy SII or Galaxy Note which are 2 very common devices in the Android market.
We started digging around and we found many forums talking about bugs specific for these devices. Bugs were pointing to ADMOB compatibility or the soundpool bug. We released fixes for these problems but apparently nothing changed, we continued to receive bad reviews from our users.
We decided then to procure some devices having the same specs and we found out that on a Galaxy SII of a friend of ours, the game went very smoothly while on a Galaxy SII of another friend it constantly crashed.
To cut a long story short, we found out that the problem was depending on our PATRIA3D Engine which used to ask the GPU to draw an "not existing" Vertex Buffer Object in some game conditions and that the GPU on these devices (Mali 400) raised an error blocking the game.
The same problem didn't happen on our testing devices using different GPU families such as PowerVR, Adreno or NVidia.
In simple words, the problem was caused by a bug in our code but we had different behaviors depending on the GPU installed on the devices (though I think it is mostly related to the OpenGL driver implementation of the device).
We have now fixed the problem and the game is rock solid on those devices but unfortunately the bad reviews remains like a stain we cannot remove.
We still cannot explain why on same Galaxy S2 devices the game worked fine but start thinking about them as mysteries of the Android World.
I am preparing the code I have to use for the Global Game Jam 2013 which will occur next week end, 25-27 of January 2013.
The idea is to use my 3D Engine, PATRIA for the development of the game but I would like to avoid to share the last 2 years efforts with everyone in the world. This considering as well that PATRIA3D is not only the results of my efforts but the result of the efforts of all the team members of the Team Novasoft.
Considering that PATRIA is a modular system where each component of the engine has its own .c and .h, the best solution is to compile the .c files of the core engine which most probably won't be altered during the JAM is static libraries.
In this way I will use just the .a (static library) and the header file .h
In order to do this operation, the following steps are required:
1. Compile the .c file you want to create the library
2. Once the file is compiled, you have the .o, the object file compiled by the GNU C Compiler.
3. Now, to create the static library, you need to use the ar command. Remember that a static library must start with the prefix lib and must end as ".a"
.png)
The idea is to use my 3D Engine, PATRIA for the development of the game but I would like to avoid to share the last 2 years efforts with everyone in the world. This considering as well that PATRIA3D is not only the results of my efforts but the result of the efforts of all the team members of the Team Novasoft.
Considering that PATRIA is a modular system where each component of the engine has its own .c and .h, the best solution is to compile the .c files of the core engine which most probably won't be altered during the JAM is static libraries.
In this way I will use just the .a (static library) and the header file .h
In order to do this operation, the following steps are required:
1. Compile the .c file you want to create the library
2. Once the file is compiled, you have the .o, the object file compiled by the GNU C Compiler.
3. Now, to create the static library, you need to use the ar command. Remember that a static library must start with the prefix lib and must end as ".a"
4. At this point you have your library. The best choice in my humble opinion is to copy it into the OS /usr/lib so that it will be usable at system level. Copy it over there.
5. Include the library into the Eclipse project (if using eclipse. Otherwise just include the -llibname in the linker instructions
N.B. remember to remove in the eclipse library reference the lib and the extension!
Now you can build your project with your libraries and the code is safe!
Subscribe to:
Posts (Atom)