Friday, March 20, 2009

To API or not to API... THAT is the question....

I was reading an old post on a form from Tim Sweeney about how all graphics cards will go the way of the dodo, and how no one will be able to write an engine and they'll all have to buy his. He was claiming (back in 2007) that the GPU will become extict abd we'll just be left with massively parallel CPU's that do everything, and that API's like DirectX or OpenGL won't be needed because everyone will simply code their own engine.....

wow.... while a pile of crap. While things are heading towards being able to do more and more with a GPU - or many CPU's like intel's larrabee, the API won't ever become extinct and theres a damn fine reason for that. Developers simply dont have the time to make the huge number of features that directX (or openGL) already has. Who really wants to write full perspective correct, tri-linear, multi-texture stage texture mappers? Not to mention that it'll probably only work on a single platform and you'll have to do it all again. Nope, its total rubbish. Whith will probably happen, is that DX/OGL will continue to deal with new graphics cards and tech and allow game developers to carry on writing games without having to worry about all the low level crap, while a (very) few middleware folk decide to implement their own custom code. It may well even be that normal developers use DX23 for most of the normal stuff, but then implement a really cool voxel rendering system to do some special features.

This makes sense, of course it does. DirectX/OpenGL aren't just about drawing triangle, they're about taking some of the development cost away from developers and allowing their code to run on almost any hardware without any real code change. For those that remember the good-old-days where you had to write versions for every card out there, you'll shudder at the thought that it'll return. I did my fair share of software/DirectX/Glide/PowerVR/S3 ports and it was horrible. True I prefered Glide as it was about 3 times the speed of DirectX, but graphics cards are fast today, and it doesn't take a coding god to make a pretty looking game. In fact most games these days are written by what I'd call normal programmers. Folk that don't really know what the hardwares doing, but its going fast enough so why should I care - that time. And thats fine, it means the games industry grows, you can let normal coders in, its easier to find people and the world is a happier place.

I also find it ammusing that Tim seems to thing API's like DX will go away. The only platform in the world without an API are old systems like the SNES/Megadrive etc. (and older). Everything else you have an underlying OS with...wait for it... an API!!

Theres always gonna be an API, and interfaces like DX and open GL will simply evolve to meet the demands of the programmer - whatever that is. It'll implement common features so we don't have to, and only if your really interested (and think you can do better) will you have to write you own VERY low level bit of code.

I can't wait for larrabee, not from a graphics point of view, but for the ability to run normal code on it. I really don't want to have to write another 100 triangle rasterisers for a single game because I can make each a cycle per pixel faster.... machines are fast enough to not worry too much about that, and if the Wii has proved anything, its pretty graphics isn't what makes a great game - Mr Sweeney should really buy one have have a look.

Thursday, March 19, 2009

DO.EXE V1.2

okay.... VERY quick update. I've quickly added C/C++ hex support. So now you can specify HEX numbers as 0x186abb etc. I meant to do this ages ago but never got round to it, and since the solution file was still open this morning, I've quickly added it. Find it in the same place as before....


http://www.javalemmings.com/blog/do.zip

Wednesday, March 18, 2009

DO.EXE V1.1

I've fixed a minor bug in my DO.EXE program. It wasn't recognising lower case "c", only the uppercase one. This made entering HEX very annoying. If you use it, get the new one here. Its in C# (.NET) so is cross-platform ready using mono.

http://www.javalemmings.com/blog/do.zip

C# JIT

I was speaking the other day about the C# JIT and how it sucks sometimes... well, heres some real code to prove the point...

            m_ArrayAccess[0].m_Pos.Y = 2.0f;
00000022 lea edx,[ecx+8]
00000025 cmp byte ptr [edx],al
00000027 mov dword ptr [edx+4],40000000h
m_ArrayAccess[0].m_Pos.Z = 3.0f;
0000002e lea edx,[ecx+8]
00000031 cmp ecx,dword ptr [edx]
00000033 cmp byte ptr [edx],al
00000035 mov dword ptr [edx+8],40400000h
m_ArrayAccess[0].m_Pos.W = 4.25f;
0000003c lea edx,[ecx+8]
0000003f cmp ecx,dword ptr [edx]
00000041 cmp byte ptr [edx],al
00000043 mov dword ptr [edx+0Ch],40880000h


As you can see it not only continually reloads the base address of the array+type, but appears to insert pointless CMP instructions all over the place. The only reason I can figure for this is to attempt to prefetch the destination; however since its about to access it on the next instruction, this is pointless - Not only that but since its sequential chances are its in the cache alrady! And even is by some mirricle that it DID matter, why the hell is it doing it TWICE!!!



Man I find that annoying....

Tuesday, March 17, 2009

More C# woes....

The more I look into C# the more I wonder how it manages to run as fast as it does. Even the simplest things it appears to double up on code, put in random meaningless opcodes etc. For example a simpel series of load/store operators like below resolves itself into a reasonable ugly mess of asm...

   Vector.X = InVec.X;
Vector.Y = InVec.Y;
Vector.Z = InVec.Z;


The problem is that it simply can't track registers properly and that means it has to continually reload the base address of the object which ends up making the code twice the size.

It also insists on loading then storing floats even though its just transfering bits. You can obviously just use integer registers to transfer data and this could pipline much better than series of FPU load/stores. It's frustrating as if this was C++ I could just drop to ASM and do it myself, but in managed code your at the mercy of the JIT.

Now the JIT gets better each itteration but it doesn't appear to get better where it counts sometimes. For normal code, this simply doesn't matter, you lose around 5-10% speed max. But for code that needs to be highly optimal, this can be a real issue.

Sunday, March 15, 2009

C# and Ants

Since it's been a little while I thought I'd tell you what I've been up to lately at home and work. I've been playing with ANT4.0 which is a profiling tool for C# (and .NET in general). The last one was pretty good but had some issues, while the new one is excellent. Profilers can always get better but the leap from the last version is pretty huge. For a start profiling is almost realtime which is very impressive, normally apps crawl when they're being profiled. You can also play with results while the application is running, which is damn impressive!

I bought ANTS3.0 last year and its pretty expensive but I thought that since I do lots of C# at home I would get the use out of it... trouble is, the stuff I do at home simply doesn't need profiled! Not that V4.0 is here I dont really want to spend huge sums of cash on it again, bnut its such a nice app I'm a little torn... Oh well.

Anyway, I've been profiling some of my work and doing some optimisation at home. It's actually been years since I've done any serious optimising and I'm having a bit of fun with it. C# is pretty cool in that you can do real managed code, or unsafe C++ style code if you really want to. When you're optimising you tend to fall back to unmanaged code as its still quicker.

We've also been getting some little shocks at work as some of the C# collections just aren't as quick or optimal as we were expecting, this has meant we've been starting to write our own set just to make sure its doing what we think it should be doing. Games programmers are funny like that, we hate slow code and will happily sacrifce readability for speed (within reason of course). Anyhooo.. I'm having a blast playing with peep-hole optimising, although its hard to say how this will affect the app overall just now, but I'm pretty happy with the main loop now as its very tight.

It reminds me that optimising is great fun, and thats why I got into games in the first place!!