Unfortunately, it is quite risky to develop and market a downloadable (under 15mb or so) Windows game using OpenGL, at least for the time being. A significant portion of the marketplace has computers that do not have working, hardware-accelerated OpenGL drivers. [1] They have decent enough video cards, ones that have reasonable OpenGL drivers written for them, however they haven't been installed. Furthermore, Windows Update does not seem to update one's OpenGL stack. This has caused a lot of downloadable developers to either use the better supported Direct3D API, or stick to software rendering (with DirectDraw, and more increasingly, with SDL.) [2]
[1] Reflexive attempted to use hardware-accelerated OpenGL in their downloadable game, "Wik: Fable of Souls", however they switched over to full software rendering after encountering numerous driver issues. More information on this can be found in the game's postmortem, available at: http://www.gamasutra.com/features/20050214/hallam_ 02.shtml . More info on using OpenGL in downloadable games can also be found on the http://indiegamer.com/ message board.
[2] PopCap's framework uses both Direct3D and DirectDraw-based software rendering.
The point would be to encourage developers to port their games to Linux, BSD, OSX, etc. Writing a good game framework, even a 2d one, takes an awful lot of work. Take window management under the Windows API as an example. Publishing a downloadable game on the major shareware sites (Real.com, Yahoo, etc.) typically requires that the game's main window be full-screenable upon double clicking on the title bar, that desktop resolution changes not crash the game, that right clicking on the app's button in the taskbar and selecting Maximize will full screen the game without showing corrupted video memory. It's stuff like this, and there's a lot of it, that game developers try to avoid, especially when they're trying to make a living.
Porting PopCap's framework would undoubtedly take a fair amount of engineering work, however their design and implementation do appear to abstract almost all of the platform-dependent calls from gameplay code. DirectDraw code is hidden away behind an abstract Image class, DirectSound code in a series of Sound* classes, etc. Still, this doesn't mean that porting would be an overnight task, at least not likely, but it gets things a good percentage of the way there, arguably less time than it would take to design and implement a stable framework from the ground up.
Slashdot Mirror
Unfortunately, it is quite risky to develop and market a downloadable (under 15mb or so) Windows game using OpenGL, at least for the time being. A significant portion of the marketplace has computers that do not have working, hardware-accelerated OpenGL drivers. [1] They have decent enough video cards, ones that have reasonable OpenGL drivers written for them, however they haven't been installed. Furthermore, Windows Update does not seem to update one's OpenGL stack. This has caused a lot of downloadable developers to either use the better supported Direct3D API, or stick to software rendering (with DirectDraw, and more increasingly, with SDL.) [2]
_ 02.shtml . More info on using OpenGL in downloadable games can also be found on the http://indiegamer.com/ message board.
[1] Reflexive attempted to use hardware-accelerated OpenGL in their downloadable game, "Wik: Fable of Souls", however they switched over to full software rendering after encountering numerous driver issues. More information on this can be found in the game's postmortem, available at: http://www.gamasutra.com/features/20050214/hallam
[2] PopCap's framework uses both Direct3D and DirectDraw-based software rendering.
The point would be to encourage developers to port their games to Linux, BSD, OSX, etc. Writing a good game framework, even a 2d one, takes an awful lot of work. Take window management under the Windows API as an example. Publishing a downloadable game on the major shareware sites (Real.com, Yahoo, etc.) typically requires that the game's main window be full-screenable upon double clicking on the title bar, that desktop resolution changes not crash the game, that right clicking on the app's button in the taskbar and selecting Maximize will full screen the game without showing corrupted video memory. It's stuff like this, and there's a lot of it, that game developers try to avoid, especially when they're trying to make a living.
Porting PopCap's framework would undoubtedly take a fair amount of engineering work, however their design and implementation do appear to abstract almost all of the platform-dependent calls from gameplay code. DirectDraw code is hidden away behind an abstract Image class, DirectSound code in a series of Sound* classes, etc. Still, this doesn't mean that porting would be an overnight task, at least not likely, but it gets things a good percentage of the way there, arguably less time than it would take to design and implement a stable framework from the ground up.