Do 3d consoles run OpenGL?

Question

I am talking about the earliest days of the first generation of 3d game consoles, such as the Playstation, N64 and Sega Saturn.

Now these consoles are like a pc, the ps3 (and 4?) run OpenGL, and Xbox 360 (and one?) running directX?

But the first systems didn't run an OS like that? So how graphics were programmed to these machines?

Did the companies developed and implemented their own graphics APIs (like OpenGL)?

Answer 1

The first generation of consoles use proprietary APIs; I can speak directly as to the PS1.

In the PS1's case there's a vector coprocessor for performing 3d transformations and one is subsequently responsible for compiling and supplying list of triangles in direct screen coordinates for drawing. Usually calculated via the vector coprocessor, but it's up to you. Library functions are additionally provided for bucket sorting — the PS1 has no depth buffer — and triangle subdivision. Subdivision is particularly important on a PS1 as it's Sony's recommended solution for fine 3d polygon clipping and for reducing texture warping.

It's the fact that only screen coordinates are provided for rasterisation that prevents emulators from flawlessly avoiding the PS1's texture warping; the information necessary to do so isn't provided for rasterisation.

The specific case aside, OpenGL of the era would have been a pretty terrible fit for the 1993/1994 releases because it was a pretty terrible fit for everyone. This was OpenGL 1.0, so amongst other indiscretions:

• there's no immediate API; everything is supposed to be supplied so as to be subject to the full fixed transformation and lighting pipeline;
• there's no indirection. Every vertex is supplied in full for every single polygon it contributes to. It is therefore retransformed and reprojected for every polygon it contributes to, unless you're going to start trying to implement caching within your OpenGL driver;
• the intended solution for that is display lists. The idea is that instead of making your drawing calls every time you want to draw, you tell OpenGL to record them once, then replay them later. It optimises in between. But that's an attempt to optimise at runtime — you're adding more code and data structure heft within the actual machine;
• in fact, the original designers of OpenGL were so enamoured with the idea that somehow they'd be able to optimise these display lists that OpenGL 1.0 doesn't even yet have texture objects. I.e. each time you want to change which texture you're drawing from, you're supposed to reupload the entire thing (!). Again, the thought was that display lists would somehow optimise that away. But think about the specifics: if you have ten objects to compile into display lists with five shared textures, the OpenGL driver somehow needs to be in a position to recognise when the same texture is in use across different objects. Since there is no "I'm done now with display list generation for all time" call, it probably has to keep extra copies of all textures for all time;
• ... and, in OpenGL the list of texture formats an implementation must support is defined as part of the API. It's not a function of the underlying hardware. The API has to translate at runtime. For yet more processing and copies of things.

The extensions to fix those things weren't defined until 1995, 1996 or so, and OpenGL 1.1 didn't incorporate many of those fixes into the base API until 1997.

So: OpenGL would have been a terrible fit in the era.

Answer 2

Those companies did implement their own graphics APIs that were very light weight and didn't have too much complex functionality. This was done because their libraries could be tailored to the strengths or weaknesses of their system.

They also had very unique architectures that took different approaches to producing 3D graphics. Later on, consoles and PC video cards adopted a similar workflow for how 3D graphics are produced so they could fit better under a common API. That's why OpenGL is so widely supported today.

But in the early days it would be hard to develop a library that could be equally efficient across all three platforms, so you'd have to write your own.

Answer 3

But the first systems didn't run an OS like that?

Well, they did, some kind of proprietary OS.

So how graphics were programmed to these machines?

Using functions of said OS, or bare bone.

Did the companies developed and implemented their own graphics APIs (like OpenGL)?

Exactly. Just usually a lot less advanced than that.

It might be useful to keep in mind, that early systems didn't have as much computing or rendering power as PCs of the same time. It's only rather recent, that console CPU and GPU are for most parts on the same functional level.

Much like 3D GPUs for PCs did take quite some time to accumulate all functionality known today. At first they did only support certain steps of a rendering pipeline. Similar interfaces like DirectX did evolve in parallel to this, not only moving more and more functionality into hardware, but also adding more. By now this development has slowed down a lot and allowed consoles to catch up in hardware (CPU+GPU), thus allowing the use of 'standard' solutions.