I am also a game programmer who has written both VU microcode for the PS2 AND vertex shaders for the PC and my assertion is that the while you can certainly expose some level of platform specific features to your graphics effects programmers via extensions to a graphics API, it would be a serious mistake to expose anything on the level of assembly, which is in essence what you are suggesting. Do you force the other programmers dealing using your graphics code to set registers and build DMA chains themselves using inline assembly? Or do you attempt to encapsulate those functions in a clean interface and advise limitations on rendering and texture transfer order. Even vertex shaders have their low-level functionality encapsulated in a clean and flexible API.
I will bring up Criterion's Renderware yet again. Their system nearly completely encapsulates hardware functions, yet also exposes hardware specific features for the various consoles via extensions to the programming interface. Sure if you have a large in-house team that ONLY wants to develop for the PS2, you may have to create your own system from scratch if a system like Renderware doesn't support your wacky ideas for the IPU, but these are the rare exceptions. Take a look at the number and quality of titles Criterion's Renderware, you can get high performance out of cross-platform libraries.
Except that you DON'T use C++ to program to the PS2's hardware. The Vector Unit's use macro (VU0) or micro assembly instructions that are preloaded into their instruction memory before running. Similarly, programming the DMAC controller relies upon building a DMA chain structure in memory and then triggering an upload. What should happen is that the graphics library exposes a clean interface to the programmer, either C, C++ or Java and NOT assembly or hardware related. OpenGL could certainly have extensions added to facilitate any specific hardware requirements that a console might field. And the graphical effects programmer might have to reorder texture/model drawing and transfering commands for optimial performace, but this could certainly be done in either Java or C++.
Lets not forget that most major game companies use cross-platform graphics libraries such as their own OpenGL implementations or commercial offerings like Renderware. Sony's PS2 dev team themselves has their PS2GL project to expose a clean interface to the PS2. And to take your example of the Bezier subdivision used by SSX, well that game has been successfully ported to both the X-Box and the Gamecube with added graphical effects.
Finally, it is rather unlikely will again choose such a radically different architecture without providing a clean graphics API along the lines of OpenGL for their next consoles. It took a full year for games that made full advantage of the PS2 to come out, by which time the next gen consoles from Nintendo and Microsoft were coming out! Sony made the developer's jobs harder than it should have been and paid the price by having a lackluster game offering for the longest time. Luckily, truly excellent games such as GTA3 allowed them to triumph over their competitors last Christmas.
Slashdot Mirror
I am also a game programmer who has written both VU microcode for the PS2 AND vertex shaders for the PC and my assertion is that the while you can certainly expose some level of platform specific features to your graphics effects programmers via extensions to a graphics API, it would be a serious mistake to expose anything on the level of assembly, which is in essence what you are suggesting. Do you force the other programmers dealing using your graphics code to set registers and build DMA chains themselves using inline assembly? Or do you attempt to encapsulate those functions in a clean interface and advise limitations on rendering and texture transfer order. Even vertex shaders have their low-level functionality encapsulated in a clean and flexible API.
I will bring up Criterion's Renderware yet again. Their system nearly completely encapsulates hardware functions, yet also exposes hardware specific features for the various consoles via extensions to the programming interface. Sure if you have a large in-house team that ONLY wants to develop for the PS2, you may have to create your own system from scratch if a system like Renderware doesn't support your wacky ideas for the IPU, but these are the rare exceptions. Take a look at the number and quality of titles Criterion's Renderware, you can get high performance out of cross-platform libraries.
Except that you DON'T use C++ to program to the PS2's hardware. The Vector Unit's use macro (VU0) or micro assembly instructions that are preloaded into their instruction memory before running. Similarly, programming the DMAC controller relies upon building a DMA chain structure in memory and then triggering an upload. What should happen is that the graphics library exposes a clean interface to the programmer, either C, C++ or Java and NOT assembly or hardware related. OpenGL could certainly have extensions added to facilitate any specific hardware requirements that a console might field. And the graphical effects programmer might have to reorder texture/model drawing and transfering commands for optimial performace, but this could certainly be done in either Java or C++.
Lets not forget that most major game companies use cross-platform graphics libraries such as their own OpenGL implementations or commercial offerings like Renderware. Sony's PS2 dev team themselves has their PS2GL project to expose a clean interface to the PS2. And to take your example of the Bezier subdivision used by SSX, well that game has been successfully ported to both the X-Box and the Gamecube with added graphical effects.
Finally, it is rather unlikely will again choose such a radically different architecture without providing a clean graphics API along the lines of OpenGL for their next consoles. It took a full year for games that made full advantage of the PS2 to come out, by which time the next gen consoles from Nintendo and Microsoft were coming out! Sony made the developer's jobs harder than it should have been and paid the price by having a lackluster game offering for the longest time. Luckily, truly excellent games such as GTA3 allowed them to triumph over their competitors last Christmas.