Overview of Player

 NOT FULLY OPERATIONAL

 Player is currently only partly operational. Player is in the very early stages of moving from concept to implementation and will require multiple iterations through the development cycle before it is useful for wide-spread use.

 Please consider this project a grand experiment.

The initial motivation for CODE and Player arose from the encapsulation of the 3D pipeline behind two popular APIs, OpenGL and D3D. For an ongoing debate, visit the _rec.games.programmer_,  _comp.graphics.api.opengl_, or _comp.os.ms-windows.programmer.graphics_ newsgroups.

Player will not only level the playing field between different APIs, it is designed to allow you, the programmer, to modify and optimize specific parts of the 3D graphics pipeline while sqeezing the maximum amount of performance out of 3D hardware hiding behind the 3D APIs.

Player is designed to allow software programmers to implement features and enhanced functionality into the pipeline that hardware vendors can later add to their drivers. Or vice versa, a feature that may only be available in select hardware can be transparently emulated by software programmers. The encapsulation of functionality behind a "facade" ensures that the dynamic selection of either a hardware or software implementation is hidden from the application.

The goal of the first design iteration was to structure the design such that the context interface very closely imitated OpenGL, for several reasons:

1. The OpenGL interface is intuitive and easy to understand.
2. There are many resources that describe programming to the OpenGL interface.
3. The OpenGL interface is probably the most tested and implemented API in both software and hardware available.

This only means that the context interface looks like OpenGL, it does not mean that the internals of Player must be implemented like OpenGL.

Another goal of the first iteration for me was to set up how profiling might be implemented.

The second iteration involved a different design approach with different issues than the first iteration:

1. The performance with OpenGL will obviously be faster than, say, Direct3D, if a programmer decides to use the Player OpenGL interface.
2. The ability to "on the fly" change drivers will be easier than with the first iteration. One function call can be easily redirected away from OpenGL to your own driver.
3. Profiling was left out. I was concentrating on building a performance-driven interface this time around.
4. The Player driver selection mechanism was left out of this iteration. For now, a program just creates a Player3DOpenGL interface by default.

 

Core library source. Win95/NT build.

Eric V. Powers

  The Player Project needs help with the following items: 

1. Source and/or references to research similar to _Player_, including any D3D classes that people have written. Upon request, code will be posted on or referred to by the _Player_ site. I've already looked  at Dore, Graph3D, Mesa, XSharp.

  The source code is available under the terms of the GNU LGPL.  Please read the license and then download the following file:

New Player03.tgz (53 KB) (OLDER) Player02.tgz (55 KB) (OLDER)  Player01.tgz (25 KB)

System Requirements: Windows 95/NT with OpenGL. Microsoft Visual C++ (Version 4.2 preferred). 32-bit (long filename) Tar/GZip decompression utility (use -d option). Installation: Extract .TGZ file to a project directory (such as C:\MSDEV\PLAYER).