quote: Original post by Chai Peddler

Just as DirectX handles a variety of hardware configurations, the protocol would handle a variety of processors and OS''s.

At this point, I have to wonder what you mean. A protocol simply means some sort of standard or formal method. Some of these were already listed above... are you trying to say that instead there should be just one, for everything? Why would anyone compile their C++ to conform to your protocol when they could just compile it for a target platform and have it run faster?

quote:
This might (I imagine) require hardware compliance from the hardware manufacturers. Just as Direct3D support must be built in to 3D graphics cards to allow Direct3D to do its voodoo.

Not really... although undoubtedly cards these days are built with Direct3D in mind, they are not physically built with D3D support as such, that is largely a driver issue. The driver model follows a protocol...

quote:
As far as computer vendors seeking the cheapest OS... well, if enough support is garnered for this new protocol, they would be forced to include it, right?

Sure, but you''re avoiding all the real issues. Where would this support come from? Most PC gaming companies don''t care about non-Windows versions of their games as they don''t sell nearly as many copies. So they are unlikely to want to change their system. The OS manufacturers all cater to different audiences, and will not be interested in compromising to make some neutral grey mass of an OS. So they won''t be pushing it either. Most users don''t care what they are running providing it runs their software, so they won''t drive the revolution. Hardware manufacturers will also not necessarily make it easy... when a chip maker adds new instructions, if you can''t program directly in assembly you can''t take advantage of those.

I think that a combination of a standard programming language, and a cross-platform library is as close to a ''OS-independent protocol'' as is possible, given the state of computing in general.

How about:
Bootable CD with Linux Kernel, MESA, a large set of graphics (and other )drivers and an autodetect feature, that automatically starts up your game when finished booting.

That way, it''s a Linux version, with the driver support for Linux, but it can run on any kind of PC hardware, because it boots straight off the CD.

[ call me realistic, but this is the only way I can see of getting somewhat close to what you''re trying to do... ]

Then you could build a tool that allows you to burn CDs like this, and program games for the system. The tool gets updated periodically, for new Linux kernel versions or something, and you can add new drivers as well.

The biggest problem: supporting LATER hardware. Your CD can''t be reburned for every new graphics card that comes out, so running an old CD on really new HW might cause serious compatibility problems.


Give me one more medicated peaceful moment.
~ (V)^|) |<é!t|-| ~
ERROR: Your beta-version of Life1.0 has expired. Please upgrade to the full version. All important social functions will be disabled from now on.

That''s a great idea, MadKeithV!

I was just thinking... Some have mentioned Java, and how it is one step behind machine specific code, like a compiled C++ program, in that it is abstracted from machine code and therefore slower.

I have thought of an idea from this which seems much less ambitious than my previous idea.

Currently, a programmer compiles a program for Wintel, and additionally any other OS''s desired. The programmer/manufacturer burns CD''s containing compiled, machine code applications to run on Wintel, and other versions to run on other OS''s.

Instead, burn CD''s that contain source code and a compiler that will automatically compile to the user''s OS and machine. We can take existing (free?) compilers and modify them only slightly. The programmer can handle the details with a script and hardware/OS detection code, for the technologically challenged user. When the user clicks the Install button, the install program performs the extra step of compiling the source code.

One thought occurs to me to discourage this. Some authors may not want to give away their source code. However, any determined individual can reverse engineer an executable, anyway. Also, the programmer can discourage it by encrypting the source code. Copyrighting the source code protects the programmer''s legal rights.

CP

"Can't you see it's only life! We can laugh about it!" - Seal