Acknowledgement

• Kate Keahey (Argnonne National Laboratory/The Globus Alliance/Nimbus team).
  She offered me a fabulous mentorship. I assess this at its true worth by looking at what I’ve learned throughout the summer just because of these great conversations . Thank you for all your support and dedication and for pushing me and the project forwards!

• Tim Freeman and David LaBissoniere (Argnonne National Laboratory/The Globus Alliance/Nimbus team).
  Wonderful, extensive and patient extra-premium-support-with-special-treatment regarding Nimbus/Workspace in the MUD. Thank you so much! You smoothed my technical way through the project.

• Ian Ward (creator of urwid, a console user interface library for Python).
  He supported me so great while I was implementing the user interface for Clobi’s Resource Manager using urwid‘s new SelectEventLoop technology. Talking to him saved so much valuable time. Thank you!

• Mitchell Garnaat (the creator of boto, a Python interface to Amazon Web Services) and the boto users mailinglist.
  Great and essential support since almost one year now. Thank you very much for answering many questions!

• Predrag Buncic (CernVM) and Artem Harutyunyan (ALICE@LHC).
  Thank you for your support regarding CernVM on Nimbus!

• Jakub Moscicki, Ulrik Egede, Johannes Elmsheuser and the rest of the Ganga crew.
  Thanks a lot for very important, effective and efficient support concerning the system behind Clobi and Clobi’s Ganga backend. You are great!

• Stefan Kluth and Stefan Stonjek (ATLAS@LHC, Max-Planck-Institut für Physik, Munich)
  Thank you for many helpful discussions, support and beautiful times in Munich!

• Borja Sotomayor (University of Chicago, Globus Alliance).
  He made a great job as GSoC mentoring organization administrator. Thank you for this and for introducing the MUD .

• Paul D Marshall.
  Thank you for discussions regarding dynamical deployment of computing resources.

• Xiaoming Gao.
  Thank you for the exciting cooperation regarding Virtual Block Stores for Nimbus.

• Alex Martelli.
  He answered an important Python question that most people could not answer. Smoothed my way to implement inter thread communication in Clobi’s Resource Manager.

Clobi @ Google Code

In this blog post I introduced Clobi, the result of this Google Summer of Code project. Today, I created a new project page for Clobi on Google Code: http://code.google.com/p/clobi/

As a first action, I pushed my local mercurial code repository into the online repository. You can browse the code here and you can look through the development history (the commits I’ve made) here.

Then I prepared a test release of all Clobi components. You can get it in the download section.

That’s all about Clobi for the next time. From tomorrow on, I will go on with my master thesis project in Physics (about Magnetic Particle Imaging). Next week, the ICMRM conference in Montanta starts and I’ve to make a poster for my contribution (abstract here).

I will go on with Clobi, when there is more free time .

Method

I’ve modified my mouse pad with some steering elements, so that I can make the same mouse movement with only right/left component with always the same distance-of-mouse-movement. It’s quite accurate.

Ingame I stand right in front of a wall and shoot to mark a point on this wall. I then go “some steps” backwards, stand still and aim at this marked point on the wall. This guarantees that I really look straightforward (and not a bit up/down). Starting at this marked point, I perform the special right/left movement of a certain distance. Then I simply measure the distance D between the crosshair position and the marked point directly on the screen using a ruler. The result of this measurement is the quantity D [cm] I base my conclusions on: I take this value under certain different conditions and compare them.

Of course this method brings along a measurement error of about some millimeters, but it’s negligible in comparison with the distances I’m measuring and with the differences of the distances I’m comparing.

Experiment, results and discussion

The following table shows the relevant configuration that is valid throughout the whole test:

General configuration

Okay, now let’s see the results of the tests with Counterstrike 1.6

Counterstrike 1.6

D=19 cm. This was measured at least 20 times on different maps and on different positions. Now I’ve changed the resolution (and the aspect ratio):

19 cm, again. I somehow remembered that changing the aspect ratio in Halflife 1 results in another real sensitivity while keeping the same sensitivity setting. I’ve just measured that I remembered wrong: In Counterstrike 1.6, the real sensitivity is independent of the aspect ratio (while keeping the same sensitivity setting)!

Now let’s see what’s up with Day of Defeat: Source.

Day of Defeat: Source

Regarding Halflife 2 / the Source engine, I only consider DoD:S — I think the results should be the same as for TF2; at least I hope

Again D = 19 cm. It seems that you can keep the same sensitivity setting in Hl1 and Hl2 without any worry; at least for a 4/3 aspect ratio in Hl2. Let’s change the aspect ratio here, too.

Err.. okay now we’ve seen an essential difference between Halflife 1 and Halflife 2 based games: In DoD:S the real sensitivity depends on the aspect ratio! And what now? You *want* to have the same real sensitivity as in Hl1/Counterstrike 1.6? I tried to calculate it, assuming linearity:

s1/s2 = a1/a2
s1=1.0, a1=1600/1200, a2=1920/1200
s2=1.2

Let’s see:

D=19 cm would have been desired, but I got 21 cm. When we assume linearity and calculate 16 cm*1.2=19.2 cm and compare that to the result D=21 cm, we see that the assumption of linearity is wrong.

There is a nonlinearity between the sensitivity setting and the distance-of-crosshair-movement-on-the-screen. I did not expect this nonlinearity and I don’t think that it makes any sense. It means that when you change your sensitivity setting from 1 to 2, you won’t get double speed! In this case, you will get more!

The dumb thing now is that we don’t know and I don’t want to do many measurements to find out the almost-exact form of this nonlinearity. Hence, because of this nonlinearity, we cannot calculate the sensitivity setting for DoD:S in widescreen mode to get exactly the same real sensitivty as in 4/3 mode of DoD:S or as in widescreen/normal mode of Counterstrike 1.6. Since it is a matter of fact that we cannot set it more exactly than to one digit (DoD rounds it then), an exact calculation would even not help much in many cases. With this widescreen aspect ratio, you’re simply not able to get the same real sensitivity as in CS 1.6 or as in DoD:S 4/3 screen mode

Conclusion

Counterstrike 1.6, which is based on Halflife 1, produces the same real sensitivity for normal or widescreen aspect ratios, while keeping the same sensitivity setting. Day of Defeat: Source, which is based on Halflife 2, produces the same real sensitivity as Counterstrike 1.6, while keeping the same sensitivity setting and playing in 4/3 aspect ratio mode.

If you play Day of Defeat: Source in widescreen mode, you have to adjust your sensitivity setting to get the same real sensitivity as in 4/3 mode of DoD:S or as on widescreen/normal mode of Counterstrike 1.6. But:

• it cannot be calculated easily, because of an unknown nonlinear relation
• if you find it out by “trying”, you often cannot set it exactly, because only one digit is allowed

I want to have the same real sensitivity on both, Counterstrike 1.6 and DoD:S. Hence, I have to play DoD:S in a 4/3 mode on a wide screen. Urks.

If you have more information about this problem, then please let me know. Any feedback is appreciated.