Scali wrote:

ID Software didn't do anything special though. Their GLQuake was a regular OpenGL application, and works through the regular OpenGL ICD interface that Windows provides.
3DFX simply replaced the ICD with their own implementation. Worked well enough in that era, since the target demographic either had 0 or 1 accelerator in their PC.

id Software documented very well the bare minimum functions needed for their 3D engines to work, giving birth to a variety of miniGL ICDs that allowed card manufacturers to make their cards compatible with Quake engined games without making a full OpenGL ICD. Remember, making a "real" OpenGL (I mean, with most functions being done in hardware) was so expensive that only were seen on professional workstations.

3Dfx made their own API copying only the most useful (for gaming) functions, so (although there are enough differences to consider it a new API) I guess that Glide can be considered another miniGL API.

Scali wrote:

There are exactly 0 major consoles out there that use OpenGL as their default graphics API. It's pretty obvious that Microsoft c […]
Show full quote

There are exactly 0 major consoles out there that use OpenGL as their default graphics API.
It's pretty obvious that Microsoft chose to use their own API, because they were free to modify this to suit their console and development tool needs.
Every other major console vendor does exactly the same: provide their own custom environment and development tools.

That does in no way indicate that MS 'chose a side' for the Windows platform. The fact that OpenGL is still supported to this days says enough.

I can't agree with that. Excluding OpenGL from their SDK meant that developers using OpenGL had to make another version of their games for XboX (while DirectX developers would ran their games without major changes). Although that's not enough to kill an API, it clearly may induce developers to switch from OpenGL to DirectX.

Zup wrote:

3Dfx made their own API copying only the most useful (for gaming) functions, so (although there are enough differences to consider it a new API) I guess that Glide can be considered another miniGL API.

I disagree with that. Glide is its own thing, and 3DFX had a MiniGL driver that wrapped to Glide.

Zup wrote:

I can't agree with that. Excluding OpenGL from their SDK meant that developers using OpenGL had to make another version of their games for XboX (while DirectX developers would ran their games without major changes).

And how is that different for every other console out there?
Besides, OpenGL is completely irrelevant in the games world. 99 out of 100 Windows games use DirectX.

Zup wrote:

Although that's not enough to kill an API, it clearly may induce developers to switch from OpenGL to DirectX.

Basically the only major company developing OpenGL engines is ID. Everyone else switched eons ago, long before the first Xbox.

What did developers do for API with KOTOR 1/2 and idTech 3/4 games on the XBox and 360?

On the PC, id Tech4 went to Direct3D with Wolfenstein and idTech5 is Direct3D with The Evil Within 1/2 and Dishonored 2.

swaaye wrote:

What did developers do for API with KOTOR 1/2 and idTech 3/4 games on the XBox and 360?

Well, I at least know that they outsourced the Xbox port of DOOM 3 to another company (Vicarious Visions), who basically rewrote the game with DirectX.
Probably the same for the other games.

swaaye wrote:

What did developers do for API with KOTOR 1/2 and idTech 3/4 games on the XBox and 360?

On the PC, id Tech4 went to Direct3D with Wolfenstein and idTech5 is Direct3D with The Evil Within 1/2 and Dishonored 2.

I think overall you will find that there was a lot of lower level optimizations and rewriting going on the Xbox anyway, for extracting performance, when you consider the slow CPU (relative to GPU) and limited ram it makes sense.

there is a little insight in this article I think
https://www.gamasutra.com/view/feature/131296 … the_.php?page=2

it talks about a conversion from PS2 to Xbox but it touches a little on going beyond regular DirectX to achieve better performance.

something else, I remember there was a unofficial port of Quake 3 to the Xbox once they released the source code, might be worth looking into how they've done that, the Xbox X D K leaked early on and helped a lot of people with homebrew conversions like that, I think it was probably straight forward without going deeper to optimize performance.

Thanks for the info. Yeah it makes one wonder how many Xbox games are using a custom API. It sounds like developers fairly easily reverse engineered NV's pushbuffer interface. Maybe D3D was rather uncommon in games. Kinda like with Dreamcast.

Yea, it was quite common to hack the pushbuffers back in those days. A friend of mine who used to work for Eidos and Square Enix also told me about that.
I think DreamCast is a different story though. It had a WinCE environment, but I don't think it was ever meant to be used to run Windows+D3D games. I think they wanted native PowerVR code from the start. I actually have some source code for DreamCast that I got from one of my gamedev friends. It renders an envmapped donut entirely in asm and native PVR code.
Thing with the PVR approach is that you need to sort your polys based on type (opaque, alphamask, alphablend, no ztest etc). D3D is not designed for this, so you end up buffering up all geometry for an entire frame, then sorting everything, and then rendering. Very inefficient.
So game engines were designed to just render in the correct order right away, skipping a buffering layer altogether (that's also how PowerSGL is designed).

Apparently 10 years ago when I purchased a Dreamcast to play with, I found an article at MS about optimizing Direct3D on it.
https://msdn.microsoft.com/en-us/library/ms834190.aspx

I think the only D3D game I tried was Tomb Raider. IIRC it occasionally had significant frame rate drops that seemed related to overdraw.

https://segaretro.org/Windows_CE
Reading the comments about the various WinCE ports here gives a an idea of what WinCE was good for. Making a quick buck on a sloppy port. Though some of the Japanese companies treated Windows that way in general until fairly recently.