Steinventure

Steinventure is going to be the successor of Steinkraft.

It's based on the C# port of Steinkraft I did for Windows Phone 7.

But it will be very different. Stay tuned...

C++ vs. C#

This list is by no means complete and I might correct/extend it over time.

Pro C++:

• Many reasons for C++ are collected at the C++ FAQ.
• Low memory/clock cycle overhead for atomic operations.
• Widespread. C/C++ compilers available anywhere.
• C++11 adds functional programming facilities, threading, foreach-loops, type inference and more. But this is not yet completely implemented on all platform. Each LLVM, GCC and VC++ miss various different parts of it.
• Big choice in IDEs: Eclipse CDT, Xcode, Visual Studio, ...
• Many libraries available (though not all portable).
• Big freedom in adjusting the language to personal needs by using template meta-programming.
• Also many duplications of facilities. Many many ways to achieve one thing.
• Closer code to assembly mapping.
• Compiles to native assembly. Decompilation hard by default.
• More compile time optimizations.

Pro C#:

• Many reasons against C++ are collected at the C++ FQA. 
• More runtime optimizations (JIT). Less compile time (AOT).
• Debugging seems fine on all platforms. For C++ some platforms are tricky (e.g. on Android).
• Regions! Incredibly useful for grouping code sections.
• For 2D games there is a nice portable API sparing the programmer from implementing messy boilerplate code: XNA (and its free and portable implementation MonoGame).
• Better tool support (since the language syntax itself is simpler and allows easier parsing).
• Significantly better refactoring. Comparable to Eclipse JDT. Plugins like ReSharper even go beyond.
• Almost instant compilation and edit&continue (a.k.a. hot swapping). No minute long compile times with many thousands of lines long header files being parsed over and over again for different modules.
• No include and linking madness. Using third party frameworks similar to Java: Adding a reference to the library (one .dll-assembly-file). Optional .dll.xml for library also adds documentation. Usage as simple as giving full namespace path or "using Lib;".
• Thats result of a modern build system. C/C++/ObjC are outdated in that respect.
• Also available on Windows Phone 7 and Xbox 360 (might change later).
• Base class library in scope comparable to JFC.
• No strict separation of declaration and definition. Hence less forced code redundancy since method signatures don't need to be synced between headers and actual code modules. This implies there is usually only one file per class (though C# does allow splitting classes of files using partial classes and also having more than one class per file).
• LINQ: SQL'ish data queries for arrays, collections, XML, ... shortens many game logic related functions significantly.
• Functional programming facilities. Mostly that means having lambdas. Type inference (var-keyword). Many things C++11 introduced are in C# already fully available on all relevant platforms.
• Nice and simple syntax for things like generics and object initialization.
• Properties are superior to getters/setters.
• Commercially supported Android and iOS solutions (Mono for Android respectively MonoTouch).
• No messing with abysmal NDK, JNI, Objective C crap.

MonoGame 3D bugs

MonoGame has pretty good 2D support already. Kudos at its developer team for that. Unfortunately 3D support is still in its infancy. Here's a list of issues I ran into when trying to get the C#/XNA port of my Minecraft clone "Steinkraft" (originally written in C++ using GLES) to run under iOS using MonoGame:
Graphics related:

• BasicEffect has no PreferPerPixelLighting-Property.
• BasicEffect.FogEnabled-Property throws "NotImplementedException" on set.
• Depth testing isn't working. On XNA it seems to be on by default. In MonoGame it's always off.
• Enabling depth testing doesn't help since there's no depth buffer attached to the framebuffer in IOSGameWindow.
• I fixed depth test issues by adding a depth buffer render attachment to the framebuffer, adding manual GL11.Enable(ALL11.DepthTest) and setting CullMode to CCW (which should depend on the corresponding RasterizerState.CullMode-Property).
• Setting the sampler state to "SamplerState.PointClamp" does not work. It should use nearest texture filtering in GL but always uses linear.
• Frustum culling does not seem to work.
• Matrix.CreateFromAxisAngle seems to be buggy since camera movement works perfectly fine whereas rotation around Y-Axis yields some strange translation behavior which is probably because the resulting vector is not normalized anymore. Not so sure of that one. 
• Okay CreateFromAxisAngle is probably okay. Y-Axis rotation yields to translation bug must be elsewhere.

Vertex Buffer related:

• VertexBuffer has no (GraphicsDevice graphicsDevice, VertexDeclaration vertexDeclaration, int vertexCount, BufferUsage bufferUsage)-Constructor.
• VertexBuffer has no SetData(T[] data)-Method that works with T=float. It always requires T to implement the IVertexType-interface which float obviously doesn't.
• VertexBuffer-Class stores buffers in fixed size array _allBuffers. There should be no arbitrary limit of the number of vertex buffers.
• VertexBuffer-Class adds "GenerateBuffer"-Action to a list instead of immediately calling it. Seems like the developer wanted to defer it for some reason. BUT: the CreateFrameBuffers-method invoking each action in the list is actually NEVER called!

Here's a dirty fix for the VertexBuffer-class to work they way SteinkraftXNA uses it:

Note: I don't really get what all this _bufferPtr-crap is for. I personally never did anything else than saving the GenBuffers generated buffer id in an uint and nothing else.

Since the goal (afaik) of MonoGame is to provide a XNA compatible API pretty much all of these issues should be valid. SteinkraftXNA runs without problems on both Windows Phone 7 and Windows 7 using the reference implementations of XNA from Microsoft.

Done for this term

Results are coming in. They're very good so far. Still three missing.

Next term I'm gonna do my thesis.
Also bunch of exams and one lab.

Setting up and running DisRESTractor...

• Get Eclipse for Java EE.
• Get Tomcat 6 binary distribution, unpack in known directory.
• Create new server in Eclipse. Choose Tomcat 6 and the directory where you've downloaded it.
• Import the project directory in Eclipse.
• Create empty "classes"-folders in any WEB-INF directory inside the project directory.
• Clean everything up, just to make sure nothing goes wrong.
• Run on server using the server you just created. Now Eclipse should run the 
• Create bookmarklet "javascript:location.href='http://localhost:8080/DisRESTractor/?url='+escape(document.location.href)" and name it "DisRESTract this!" or something.
• Go to the website you want to build a web scraper service for and click on the bookmarklet we just made.
• Select resources and attributes of interest and click create service. Check Eclipse console output for irregularities. Now DisRESTractor wants to run the newly created service but fails, because it's not installed on the currently running Tomcat server.
• Go to known directory and traverse into the "bin" directory. Run startup.sh. Now use the link to the new service.

The Space In Between

New album

Professioneller gemafreier Musikkatalog

Asus T101MT Review

Using this device for about four days now. So let's try making a list of what's good and what's not so good.

Good:

• After removing a bunch of pre-installed applications, the system runs quite well under Windows 7. Yet it's responsiveness is more optimal under Linux. But more on that later.
• Both Aero under Windows and Compiz under Linux work.
• (not really specific to the T101MT) Windows 7 has some nice multitouch capabilities built-in. Unfortunately this makes Internet Explorer the browser of choice, since it has better multitouch support than other browsers. Firefox is okay too, but everything else doesn't even support iPhone-like scrolling.
• Noise is acceptable. Worse than MacBook but far better than most laptops running windows. And it doesn't start to scream when on high usage.
• Sound and wireless adapter are okay. I guess.

Bad:

• Screen brightness. Too dark in my opinion. But this might be a general issue with resistive touch-screens. Also although it's a glare display and shows some reflections when used in bright environments, it's not that crisp. Probably because of the resistiveness too.
• I would prefer 16:10 instead of 16:9 on a tablet. Because in portrait mode it is to thin in my opinion.

The touchscreen works okay. Precision is neither horrible nor perfect. Finger mode is definetly precise enough, but I would like to have some more precision when using the stylus.

Oh and this is my experience with Linux on this machine: Many things work out of the box fortunately. What doesn't work is the touchscreen. But on the forums of Ubuntu there was already a tutorial on how to get it working. You just need to put a textfile in your /etc/init.d and run a patched calibration tool. Downside: Neither multitouch nor pressure sensitivity.

What is really interesting: The device is much much faster and responsive when using Ubuntu. Good thing that they're working on a multitouch-driver for it and when some other issues are resolved Linux might be the operating system of choice for this device.