[mdlug] Interesting information about Windows "7"

[Aaron Kulkis]

Ingles, Raymond wrote:
>> From: Aaron Kulkis
> 
>>>  Well, the difference to the end-user is kind of academic.
>>  > Either way, you need a particular set of cards to play the
>>  > game, or you're SOL.
> 
>> But modern windows games are written against the ActiveX
>> API. .. as more cards meet the minimum PERFORMANCE
>> specifications of the game, they too can be used to
>> play the game.
> 
>  Er, sort of. It's the same game as before - on a higher level, true, but
> from a practical perspective a specific set of cards are needed for the
> games. (It's DirectX, BTW - ActiveX is the horribly insecure web browser
> plugin scheme.)

But as long as a new card meets those minimum performance
and capability standards, it can be any architecture and
GPU the designer chooses, and the game will still work --
regardless of what hardware addresses the control registers,
etc. are placed at.  The game is not written for the
specific hardware choices of these original cards, only
their abstract capabilities.

> 
>> ActiveX is hardware neutral -- if it wasn't, then Windows games from 3
>> years ago which required what was then bleeding-edge hardware would be
>> completely unplayable on a new system with today's bleeding-edge
>> hardware.
> 
> Emulation changes that somewhat. I can run Atari 2600 games on my Palm
> Pilot. I can run old DOS games without anything resembling an ISA Soundblaster
> card in the box. But yes, having an abstracted API helps a lot. The problem is,
> the DirectX API abstraction layer is paper-thin. Entirely too much dependence
> on the underlying hardware leaks through.

I won't doubt you on that point.

> 
> Consider "Hardware Transform and Lighting", a key feature of modern games;
> essentially, matrix processing to handle large numbers of vertexes and polygons.
> In OpenGL, you don't have to do anything special to get the benefit of Hardware
> T&L - you just use the standard OpenGL calls, and if they're hardware-accelerated
> they'll operate much faster.

That's true.
If there's hardware acceleration, OpenGL uses it,
it not, then it falls back to the OpenGL libraries.
                               >                              In 
DirectX, you have to have entirely different
> code paths.

Doesn't surprise me that Microsoft does something even as
simple as this the wrong way.

> 
>> the game writer is writing for specific on-card capabilities...which again, is
>> NOT the same as writing for a specific hardware implementation (such as the
>> color palette begins at memory location 0xABCDEF00)
> 
>  It's a bit higher-level than hardcoded memory addresses, yes. But the implementation
> that Microsoft did - DirectX - leaves so much to be desired.
> 
>  In a way, you're right - it's possible, for example, to implement DirectX on top
> of OpenGL, as Wine does. However, because of the hardware lumps poking up through
> the API, it's *much* tougher than the converse, implenting OpenGL on top of DirectX.
>

Interesting.


>> That's the WHOLE PURPOSE of an operating system --
>> to abstract common, mass-produced hardware, so that
>> they are roughly interchangeable, to the extent of
>> the capabilities of the hardware (Nobody would expect
>> a 360x360 dpi CMYK printer to produce output on par
>> with a 1440x720 CcMmYK printer. And nobody expects
>> a 5 ppm printer to produce output at the speed of a
>> 20 ppm printer.)
> 
> That's a decent analogy... except imagine that the call
 > to produce a red dot on the low-res printer was entirely
 > different from the call to produce a red dot on the high-res
 > printer. DirectX forces that kind of knowledge onto the
 > programmer in a rather large number of cases. It's gotten
 > much better since the days Carmack slammed it - from what
 > I hear, DirectX 9 is not half bad - but it's been a long,
 > hard road to that point and the transition isn't quite
 > complete yet.

That's amazing that they could go through 9 revisions
and still have such a developer-hostile API.

A simple execution-time initialization sequence could
fill in a function-address table (i.e. all calls are to
*funcp() instead of to func()), which is filled in
with either the "slow" way, or a short routine which
calls the hardware accelerated version.
Or even simpler, the vendor-supplied drivers could
provide the data for which functions are hardware
accelerated, and which are not.

It's not that difficult and I haven't programmed in
20 years.  What's wrong with those people that they
can't come up with a simple, reliable solution like
this?    The application/game programmer should NEVER
have to be aware of these things.

> 
>  Sincerely,
> 
>  Ray Ingles                                            (313) 227-2317
> 
>  Spammers seem to assume that you are heavily in debt, under-endowed,
>  impotent, jobless, without a college diploma, without insurance, in
>  need of prepaid legal representation, and need to investigate those
>  closest to you. In other words, they are selling to themselves!

Too true!