A Blag About Graphics and Programming and Stuff

I'm a Microsoft fanboy: I use Visual Studio, DirectX, Windows Media Player, I like Vista and I think that C# and .NET are great.
But there's a geek in me who wants to see how the latest and greatest Linux distributions look like. I have a 10GB partition just for that. I install Linux, play around with it for a couple of hours and never boot it up again for the next half a year until a newer and greater version comes out.

My latest evaluation checklist looks something like this:

• How difficult is it to access my NTFS partition;
  
• Connecting to my home wireless network;
  
• Setting up proper(1280x800) screen resolution;
  
• Does the headphone jack work;
  
• How hard is it to play "evil" (mp3, etc) multimedia files;
  
• Hardware graphics acceleration;
  

Naturally I want all of this "out of the box" (or at least with a couple of clicks of a button), without having to google stuff and type alien mumbojumbo in the console.
And it just so happens that this checklist is nearly impossible to pass (at least on my laptop)!

Old(7.10) ubuntu/kubuntu versions used to fail miserably, the only thing that worked was reading NTFS and sometimes- wireless. Yes, I couldn't even change the screen resolution to 1280x800!
Mandriva One 2008 and Linux Mint 4.0 looked half decent- headphone jack and hardware acceleration were the only things that didn't work, the default resolution was messed up, but it was quite simple to change it.

Mandriva Linux 2008.1
The new version came out a couple of weeks ago. I boot up the live CD and as it is loading, I sense that something is different: zomg! The resolution is 1280x800! I couldn't believe my eyes, and then the most incredible thing happened: a window popped up and asked if I wanted to enable Compiz! Whoa, it supports hardware acceleration for my cutting edge, super new HD2600 card! And the magic didn't end there- sound was coming out of the headphones, and no sound was coming out of the built-in speakers while the headphones were plugged-in.
The only problem was "glsl shaders not supported". But at least I can run Tux Racer at 50fps...

That was a historic day- not only a Linux distribution passed my entire checklist but it did it straight "out of the box".
Mandriva Linux 2008.1- certified by me.

I expect the next version to support multiple displays and maybe even the volume control thingy on the side of my laptop.

[rant]

Ubuntu 8.04 (<adjective> <noun>)
Yes, this is the one that came out today. The most beloved and popular linux distribution. It should give Mandriva a run for it's money!
No, not really.
No hardware graphics acceleration, no compiz, no sound from the headphones (uses the built-in speaker even when the headphones are plugged-in), half of teh internets is broken because "requires additional plugin" or "your Flash version is out of date", no mp3 playback without doing "stuff". And the fun thing: "your (graphics) hardware doesn't require proprietary drivers". OH RLY? Then how come it doesn't work?

I can understand not playing mp3 files, not including Flash and other hippie "free" software nonsense. I can understand when they don't support shaders or a webcam or an sd card reader, because, hey, writing drivers is hard.
But the thing that gets me, is when the dirty, tree loving hippies behind Ubuntu and other "free" software choose not to support my hardware just because they have personal issues with ATI or some other hardware vendor, I take that as a personal "fuck you".
"Humanity towards others" my ass.

And this bring me to my main point: the way I see it, there are two types of linux:

1. Corporate Linux: Mandriva, SuSe, Fedora. This is the good kind, because they have a corporation behind them and that means that they actually care about quality (and money);
   
2. Everything else: it sucks. An exception is Linux Mint. I have no idea how did this happen. Will have to investigate more.
   

[/rant]

Directly Mapping Texels to Pixels.
The main problem is, that when texels are not aligned to pixels, Linear filtering blurs the texture and it ends up looking ugly(a bit more info than the msdn article).

Another problem is that the is image is slightly offset. By 0.5 texels to be exact. This isn't really a problem if the resolution is high. But what happens if you want to stretch a low res texture on the entire screen?
Bloom is a perfect example: render something a small texture (128x128), blur it vertically (render to another 128x128 texture), blur the result horizontally (render to a 128x128 texture), stretch the result over the screen.

If you aren't aligning texels to pixels, the image is "slightly" offset three times. But surely that can't add up to anything noticeble?!
O RLY..? ("And don't call me Shirley" )
Without alignment:
With alignment:(Yes, the red circle thingy is blooming green, it's just to make the problem more visible)

As the articles state, all you have to do, is offset the vertices (or texture coordinates) by half a texel:
Pos-= 1.0/ textureSize* 0.5;

So if your render target is 800x600 and your texture is 128x128 you need to do

Pos-= 1.0/ 128.0* 0.5;

Have a nice day.

The algorithm for generating the Mandelbrot set looks like this:

for each pixel
{
  C= (x,y);
  Z= (0,0);
  i= 0;
  while i<MAX_NUMBER_OF_ITERATIONS and Z distance to origin< 2 
  { 
     Z= Z^2 + C;
     i++;
  }
  Color= ColorTable[i];
  DrawPixel(x,y, Color);
}

Where C and Z are complex numbers.

When MAX_NUMBER_OF_ITERATIONS= 256, generating this(1280x1024) image takes about 20 seconds.

But, as you can see, the algorithm is very easy to parallelize: the pixels are independent of each other, there's no writing to the same memory locations etc.
So, for example, you could run it with two threads (one thread generates one half, the second- the other half of the image). And on a dual core machine it should run two times faster (on quad core- four times, etc.)

Now if only I had access to some kind of processor that had more that two cores, much more. A processor that would be built to run parallel code. Maybe those cores could be called, I don't know, "stream processing units"? And there could be a 100, no, 120 of them!

Oh... wait...

Wrote a little program that generates the same image (1280x1024, 256 iterations, the color table is in a 256x1 texture) in the pixel shader.
It runs on 17fps. That is 20 seconds on the CPU and 0.06 seconds on the GPU! w00t?

The shader is a perfect test to see how dynamic and static branching/looping performs in different situations.

I should be posting a demo in a couple of days.

P.S. Updated a very old post with info how to use 3dmax sdk's IGame to export animations.

Happy New Year.
Better late than never

The exams at the university are finally over and I have a chance to get some proper work done on the thing that I work on.

Without going into to much detail, the "\data" directory of the last "official build" was 80mb and 145 files. Currently it's cranking at 319 files and 418mb (but there's some duplicated junk).

All of the data has to pass the "content pipeline" (slice up, export the models, resize, convert the textures to a DXT format, pack them, etc.)
The problem is that my "content pipeline" looks something like this:

1. Take data;
   
2. wtf?!
   
3. Load it;
   
4. Spot that something is terribly wrong;
   
5. Goto 2;
   

Finally the content is at a stable state (read: doesn't change frequently). So the amount of me contemplating stabbing myself in the eye with a corkscrew has gone down dramatically. Still, I wish I could figure out how to optimize the second step...

The moral is: kids, remember, if you are planning to make anything more complex than a pacman clone, think about all the shit that will have to be moved around.

That is all.