Two New Songs

YES!

Two new songs of mine at soundclick.

One from the dark side:
http://www.soundclick.com/bands/songInfo.cfm?bandID=441088&songID=3418396

And one for the dance site:
http://www.soundclick.com/bands/songInfo.cfm?bandID=459773&songID=3418306

ENJOY!

__NOT __to __hack DirectInput

Little updated concerning my previous post.

I decided to go with /clr:oldSyntax and the old C++ with managed extensions syntax, known for it's double __underscores.

This way, it really works to create a decent wrapper of DirectInput without PInvoke.

Besides back-acclimatization to the old __syntax, this little project is steadily progressing.

I am asking myself how to distribute the project. I think I will choose SourceForge, because of it's simplified project hosting abilities and audience. So I will have to make it open source, what might not really be too bad for me.

So, which license to choose? I have in mind, that the compiled assembly should be shared freely, as long as I remain the copyright holder. In case somebody modifies the source code, he has to distribute the modified source code. Not sure, I think it was the LGPL matching my needs!? Any suggestions?

to hack DirectInput OR NOT to hack DirectInput

Target: Find a possibility to have a fully assignable joystick in a .NET² flight simulator, i.e. you can pick any available joystick-axis for any lever in the game.

Pass No1: Managed DirectInput V2.0 lacks buffered device data retrieval, so there is no way to extract abitrary axes from the device state. It is simply not possible except hard-coded device state look-ups.

Pass No2: It is obvious, that mixing managed DirectInput V1.0 with the other managed DirectX V2.0 components is a bad idea.

=> Write my own managed version of DirectInput. CODENAME DirectlyInput ;).

Pass No3: Include the native DInput.h. C++/CLI should be capable of handling native C/C++ code. However, due to the new syntax, C++/CLI cannot handle some constructs like "typedef interface ..." which is definied in some sub-headers that are related to COM. Unfortunately, the DirectInput header relies on the COM definitions in order to expose the DirectInput interfaces to COM. To make it short: I am unable to include DInput.h without tons of compiler errors. However, I think I can use the switch "/clr:oldSyntax" - with this switch, DInput.h seems to compile flawless. But I am not sure, if I am willing to go back to the __syntax. Maybe I give this a try later.

Pass No4: Go with PInvoke/COM. Well, it was unexpectedly difficult to find helpful information. After hours of searching, I found out about useful stuff such as ComImportAttribute, GuidAttribute, and InterfaceTypeAttribute, and that I could utilize GUIDs from the DInput.h header. After even more hours of painful trying and looking at freakin' error codes from the deepest deepness of kernel32, I even managed it to create an instance of the DirectInput8 class and cast it to the DirectInput8 interface using reflection. However, I never managed it to call any methods of this interface. After even more hours of trying and testing some modifications, I gave up.

Pass No5: What I personally don't understand - DirectX is said to be based on COM. A look at the header files seems to confirm this. But why can't I simply insert any DX-DLL as COM-Component in the VS-References page?

Pass No6: #import DInput8.dll should work perfectly, but for some reason, it produces the same kind of errors like including DInput.h

Pass No7: The 7th approach seemed to be promising at first, but it didn't work out. Maybe you find it amusing:
So, how to get access to a COM-API, that is not really exposed as a COM-DLL? Well, I talk about DirectInput, and DirectInput has not been updated since DirectX8. DirectX8 *HAS* a type-libarary for the ancient VB6, when there was no such thing such as MDX.
This type-library looked like the rescue for me. I could convert this type-library using "tlbimp.exe" to a *real* .NET-assembly. Then, I could disassemble this .NET-assembly back to IL-code using "ildasm.exe". This actually worked; I had a buch of class definitions in my .NET-wonderland. This IL-code file was something like 16k lines long. I removed something like 3/4 non-DirectInput stuff from this file, and after re-inserting the assembly-info, DxGUID, POINT, and RECT - which have been accidentally deleted ;) - this file - with DirectInput only definitions - truly compiled back to a .NET-assembly using "ilasm.exe". This .NET-assembly could seriously be added as reference in the VS-References without any problem, and this assembly only contained DirectInput definitions - I could see that in the class browser. Honestly, that made me proud ;).
Well, in the end, .NET could not really use these classes without throwing exceptions - I guess it was still nothing more than ancient VB6 class definitions. So this approach didn't work out as well.

A.R.G.H.H.!.!.!.

Lighbox

This posting is no big deal ;).

I created a so called lightbox at a photo-community called Photocase. A lightbox is a collection of photos related to some topic.

I created a lightbox called City 17. In case you don't knew it: City 17 is the place, where the successful game Half Life 2 takes place. It has a unique atmosphere - maybe you should check out some imagesearch, if you don't know what I am talking about.

Well, my lightbox tries to resemble some of the elements of this atmosphere. From the description:

I tried to resemble the mood from the Half Life 2 world - City 17. This includes industrial influences, a somehow strange city, warm/sunset-like light, a river, railways, highways, etc.. Hope you like it.

Just in case you are interested: http://www.photocase.com/collection.asp?l=48303

As I said - no big deal ;)

Building Cliffs

Fortunately, I have worked hard to get a little bit ahead of the University's stream of weekly tasks, so I still had some spare hours left for the FSNG substitute.



The problem in my previous post was the terrain-slope, which was not interpolated, thus resulting in blocky terrain overlay layer coverage. Now you probably want to say: hey, a little interpolation is not hard.
IT IS ... it is - at least if you want to do it efficiently.

Imagine you have an arbitrary floating point location, and you want to know the terrain's slope at that location. It can't be that hard: take the 4 neighbors's slope-values of the heightmap's grid-cell-rectangle-vertices where the location lies in, and do a bilinear interpolation.
So how do you get the slope value at such a neighbor-slope at a grid-cell-rectangle-vertex (<-- nice word, isn't it?). Well, take the 4 neighbor vertices of this vertex and do a little algebra.
Can you follow? For each of the 4 neighbors, look up the 4 neighbors and do algebra ... for each of the 4096*4096 texels of the terrain overlay texture!!! Look ups are said to be fast, but when reaching a certain number of look ups, it is obviously not.

I ended up creating a little terrain-slope cache, so I could reduce the amount of look ups by a factor 4. The amount of slope look ups is now bound to the heightmap resolution, and not the terrain overlay texture resolution, which is of course an improvement.

However, I admit that this factor 4 is not very much noticable when doing an 4096*4096 compile. (but I did not try yet the release-build).

Another problem that botherd me was the definition of slope in 2.5 dimensional space. I mean, we all know slope in 1.5 dimensional space when drawings graphs or deriving algebra. But honestly, I have no idea how to do it in 2.5 dimensional space, i.e. with the terrain.
I solved this provisionally by calculating the slope for each x/y-axis, and then let be slope=max(slope.x, slope.y) - it works more or less this way. I don't have the CPU cycles for more complicated stuff anyway.

Ok, more to come soon ... hopefully.

THEY ARE EVERYWHERE

...screens of upcoming sims.

So, I finally wanted to drop some further progress of my upcoming FSNG subsitute.

Here are the screens:


What I have basically done is to make the terrain overlay texture editable. As the first editable feature, I introduced a layer system.

Layers are basically textures, which are rendered on the terrain overlay, when some clauses are fulfilled. The available clauses at the moment are terrain-elevation and terrain-slope. In the above example, I applied following layers and clauses:

• Elevation 0-1: Water
• Elevation 1-25: Beach
• Elevation 25-Inf: Grass
• Slope 15-Inf: Canyon

I have not yet implemented slope interpolation, that is why the transition to the canyon-texture looks a bit blocky.

All in all, this system is great to give a map a basic look with just a few mouse clicks.

More to come soon.

Programming: FSNG Substitute

I had some free days during the XMas::Holidays (yeah yeah, lazy students), so I spent a few days on the top secret FSNG substitute.

Well OK, to make it short, some early pics:


What you see is basically the ingame editor. The only thing that currently works is heightmap loading and cell subdivision, some basic stuff such as config-files, as well as fancy mouse movement (a little bit like UnrealEd).
At first, I was quite disappointed when looking at the framerates, however when switching to wireframe, I saw that 1024*1024 looks like much more in polys than in pixels. With this resolution, I could even leave the texture away and use vertex colors only.

Some technical notes: like in FSNG, I use MDX2.0 and C++/CLI with .NET² again, as this is my environment of choice (and I love it ;) ).

More to come soon, hopefully (university/time!). I will use this blog for screenshot-updates and not my homepage, as I am not 100% sure, if I really want to *replace* FSNG. I will update the website, when my decision is final.