I don't know about billyboy himself... but microsoft
do have some of the best programmers in the world.
Too bad they also have a lot of stupid f**ks that mess
up the whole thing with all the extra bloat included in
windows... and office... and all that. Now, let's not get
win9x into this discussion, it's a pile of sh1t that was
NOT written with stability in mind. It had a place to
fill, and it did this perfectly. It stayed too long, though.
The NT kernel is written for stability, and as long as your
drivers are stable, you wont have a kernel crash. Quite a fun
thing, microsoft written drivers are often more stable than
the drivers other manufacturers write. Like Creative... I've
had three BSODs under win2k, and two of them were because of
creative. A guy once called creative support to bitch about
his SMP system being *very* unstable with their crap products.
And the first thing the techie said? "WOW, you got a SMP system
to boot with our drivers?!". So don't blame microsoft for every
little fault. I don't like them and their bullying tactics,
but I know something good when I see it: windows 2000.
HAL and DDI access is ring0-only. Furthermore, DDI access is
not too easy to get your hands on unless you're writing a *video*
driver. Video drivers run in their own little "sandbox" and only
have access to a subset of the "API" that normal drivers have.
In fact, if you have imports from other (ring0) DLLs than what
you're supposed to (win32k.sys as far as I remember), your video
driver will not load.
So, what does this mean? You'll have to code "a few" KMDs,
possibly including a video "proxy" driver. You'll have to write
an interface between your ring3 part and the ring0 drivers, and
this will have to be written *very* well, otherwise you speed
will suck utterly. You'll also have to be *very* careful, as a
ring0 crash is a pretty mean thing. And worse under NT kernels
than 9x. Also, people will need Administrator privileges to run
your stuff... quite a bit annoying, really.
I have never seen in my life crappier code than Microsoft's one.
Take a look at some GNU software, and in particular, the linux
kernel. Oooooh boy ;).
As for no direct pointer access in DX8... your statements seem
to be at least partly guesswork, so I will take the liberty to
guess a bit as well :). In a 2D application, I can see no reason
why Lock should have been removed (although I remember something
about it being renamed...) However, it makes *perfect* sense that
a front/backbuffer lock is slow in 3D accelerated mode, since you
have to sync up with the accelerator hardware. You wouldn't want
the accelerator to overwrite the pretty pixels you have just doodled,
would you? ;-).
As for "proprietary texture formats to allow greater speed" - naw.
You still need to load your textures, and procedural textures are
popular enough that people like nvidia will *NOT* be stupid enough
to make this impossible/infeasible.
but I'd rather say that if one knows asm well, and knows why he
wants to use it, he most probably will be incline and experienced
enough to use or invent good algorithms *as well*.
That is true. The problem is just that there's a lot of people who
don't seem to know why they use asm... who don't know it well...
who use it just to use it. I'm not pointing at you, and I won't
mention any names. But they're there, and there's lots of them.
Quite fine with me, as long as such people don't start attacking
other things they don't really know anything about ;).
CoffeeDrinker,
Lock your surface only once, save the pointer to the surface. Use the pointer/handle to the surface and never Lock/Unlock again.
Bad bad bad. This can lead to some pretty nasty lockups. Might work
well on most machines, but... uh-oh. No go :). While you certainly
shouldn't lock/unlock per pixel, there's not much point in locking
only once. Lock screen before a screen update, unlock it when you're
done (before your AI code / whatever runs). As long as you do it this
way, Lock is sufficiently fast that a good old pentium can run a fullscreen
320x200x32bpp plasma synced to the screen refresh.