Create a small RAM disk for ultra fast I/O

In this simple guide I will explain how to create a virtual ram disk based on ext3 file system to be used for very fast I/O.

This example is very useful though it has important limitations, for example:

• It does not allow big ram drives, as far as I know, the limit is 64 MB
• Whatever is stored in the ram drive, is destroyed as soon as your system is restarted

In this example, we create a ram drive of 64 MB, we mount and set permissions so that your current user is the owner of the newly created file system.

Step 1: create the new file system, based on memory:

sudo mkfs -t ext3 -q /dev/ram1 65536

As you can see, the disk size is 64 MB, we use as device the /dev/ram1 (you can use by default up to ram15) and the file system used is ext3.



Step 2: Create the directory to be used to mount the new file system

sudo mkdir -p /ramdrive

Step3: Mount the file system

sudo mount /dev/ram1 /ramdrive -o defaults,rw

Step4: take the ownership of the new file system

sudo chown [USERNAME] /ramdrive -R

Replace the [USERNAME] part with your actual user name.....if you don't know who you are, try to check it with the whoami command.


This article, very simple, has a lot of limitations due to the small size of the disks you can create.
Planning to write an article on how to create bigger volumes with  tmpfs.

Side Note: Nowadays, using a 64bit OS, having a lot of RAM on your PC allows you to create quite big ram drives having incredible performances during read/write operations, sometimes it is useful to leverage on this to have ultra fast user experience.

Lenovo Thinkpad T410 and Ubuntu 12.10

(This article is rather old and was posted on another personal blog, I think it could help people anyway). Just as a side note, I stopped using Ubuntu since a while due to Unity. Now I work on Fedora 20 and Gnome 3, I love it.



 I have upgraded my laptop, a Lenovo T410 mounting integrated intel graphics, to Ubuntu 12.10.

As soon as the OS started I started getting errors on the xorg server about the drivers installed. The only option was to start the PC in low resolution. In addition to that many other problems were there like support for external monitors and so on.

Checking the ubuntu unity support utility the "Unity 3D supported"  was reported as No and the overall system performances were very bad.

I have luckily solved the problem in very long manner and therefore I want to write here what I have done to solve my problems hoping to help anyone having the same isse.

To start with, the drivers installed by UBUNTU (the gallium one) are not the right one, they doe their job but don't cover all the aspects of the system configuration.

To solve the issue I have done the following.



1. Install the required packages for the next steps:

Run in a terminal the following command:

 


sudo apt-get install build-essential libtool xutils-dev bison flex libx11-dev x11proto-gl-dev x11proto-dri2-dev libxext-dev libxdamage-dev libxdamage-dev libxfixes-dev libx11-xcb-dev libxcb-glx0-dev libxcb-dri2-0-dev libudev-dev libxcb-xfixes0-dev llvm-dev

This step is required in order to prepare the environment for the actual compile of the other components.



2. Go the intel OpenSource Technology website

https://01.org/linuxgraphics/downloads



3. In the download page, download the packages MESA, libdrm and xf86-video-intel - 2.20.12.

4. extract the content of the 3 files into separate directories.

5. Build and install of the libdrm package

 

    sudo ./configure
    sudo make
    sudo make install

6. Build and install the video intel (the 3rd package you downloaded)

 

    sudo ./configure
    sudo make
    sudo make install

7. Do the same for MESA (last one), it will take a very long time

 
   
    sudo ./configure
    sudo make
    sudo make install

8. Restart your ubuntu machine. At this point, going into the system settings/details applet of your ubuntu client you will notice that ubuntu will use a new driver (and you should notice the new look and feel too!)

If everything is OK, you should have something like this:

The love and hate for shared libraries

 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!!!

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.

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"

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!