If you were to develop a game console...

Open GL, but I don't think you would have a choice. Direct3D is exclusive to microsoft platforms.

So your saying it is illegal to use Direct3D for your console's API?

Not illegal, just unavailable unless you worked closely with them. You would also need to do similar for OpenGL, which would compel you to use the Mesa library.

well... You would need to license it, get microsoft's permission and I have a feeling they won't give it to you or anyone else. If they did let you use it you can bet there would be massive royalty fees... But if you don't license it and use it, then yes it's illeagal.

To use DX on a game console, your console would have to be running windows.
To make a games console that runs windows you'd obviously have to make a business deal with microsoft. It's not easy to become licensed as an OEM of a windows embedded system.

Quote:

Original post by blakedev You would also need to do similar for OpenGL, which would compel you to use the Mesa library.

Explain yourself.

Quote:

Original post by BrioCyrain So your saying it is illegal to use Direct3D for your console's API?

Quote:

Original post by NSDuo well... You would need to license it, get microsoft's permission and I have a feeling they won't give it to you or anyone else. If they did let you use it you can bet there would be massive royalty fees... But if you don't license it and use it, then yes it's illeagal.

No. You don't need to "license" the Direct3D API to provide it on your console. You would only need to license Microsoft's implementation, if you wanted to use it. It would be perfectly legal to use Wine's implementation of Direct3D without paying anyone for the privilege.

Quote:

Original post by Hodgman To use DX on a game console, your console would have to be running windows.

No.

Mesa is the free implementation for OpenGL.


P.S. Some people might find the imperative sentence "Explain yourself." a tad rude.

Tsk, API.
PEEK and POKE of course, with a shitload of assembler code
to make it run about a thousand times faster.

[code lang="C64"]
10 REM ENABLE POLYGON 1&2
20 POKE 53269,3
30 REM SET COLORS
40 POKE 53280,0:POKE 53281,2
50 POKE 646,15
60 REM BEGIN FRAME
70 SYS 49152



_{Scary how these numbers pop up after 25 years, like it was my own}
^{telephone number (which ironically, I don't even know by heart).}

I'd build a custom API heavily styled around Direct3D, thus providing developers with a very familiar structure, while avoiding any legal discomforts. In this day and age, it'd probably be sort of a DX reimagined...in fact, it'd pretty much be SlimDX implemented in native code, with a lot of the weirdness subtracted. (I'd also go more strongly towards D3D 10, but not all the way.)

Quote:

Original post by blakedev Mesa is the free implementation for OpenGL.

Mesa is a free implementation of OpenGL, yes. Why does this fact mean that you would be compelled to use it if you made a console which used OpenGL?

Seems like there would be a catch to using OpenGL itself if there were free implementations for it, other than making one just for fun.

I apologize for sparking the mini-debate and correct myself: OpenGl need only be licensed for hardware developers and driver developers, which is what he may need to do anyway to adapt to his particular hardware (if no drivers exist that is).

Just a side note:

Consoles are not generally designed around APIs; rather, console APIs are normally designed (or selected) around the hardware.

To my knowledge, the Dreamcast was the first console to provide a (somewhat) non-proprietary graphics API as part of the SDK, and the XBox was the second.

Wasn't the Xbox using Direct3D 8 for graphics?

1. Neither. At least not in their PC (and PC-like platform) incarnations. Through necessity, both of them in their vanilla/PC forms abstract away from the hardware a little too highly to be comfortable on a fixed console platform.

2. If I had to invent one based on existing APIs, D3D10 (the state and shader constant stuff in particular, far more sensible than separate "setBlah" calls when you look at how the underlying hardware integrates with the system) with direct command buffer access (due to having a fixed platform, most existing console 3D APIs allow this).

3. But choice of graphics API is largely irrelevent for most games for anything other than quick proof-of-concept ports. The amount of code that talks to a 3D API or the hardware is miniscule in a modern game engine. How the game and engine are tuned to specific console GPUs is where things get interesting.

4. Hardware wise I'd love micro-code control over the ROP and Z-Stencil units.

5. Direct3D was [officially] available on Dreamcast though not very widely used compared to Segas own API.

Quote:

Original post by blakedev Wasn't the Xbox using Direct3D 8 for graphics?

Yes, albeit extended to allow more direct access to the hardware in places (fixed platform - you can allow more direct access).

360 uses an extended flavour of D3D9.

Quote:

Original post by S1CA 5. Direct3D was [officially] available on Dreamcast though not very widely used compared to Segas own API.

It's the same thing on PS3 now with OpenGL.

But what I want to know is, what would you do with programmable depth-stencil and ROP units? Open my eyes to the possibilities!

Quote:

Original post by BrioCyrain What kind of API would you use(OpenGL,Direct3D)?

Console are not a PC, so they left little room for choose a API (in fact they give not choice), the best api is the used by the SDK, anyways you always can go to the hard way do to everything from scratch (usually a dead-end).

Quote:

Original post by Promit Quote: Original post by S1CA 5. Direct3D was [officially] available on Dreamcast though not very widely used compared to Segas own API. It's the same thing on PS3 now with OpenGL.

Interestingly, the recent interviews with John Carmack on iD Tech 5 reveal that the renderer is actually using the PS3's OpenGL ES implementation along with the CTM library for command-buffer writes. It would be nice if Sony would get around to PSGL 2.0 (adding extensions for direct command buffer access, perhaps) and move away from their proprietarily extended ES 1.1 implementation.


I think if I were to design a console 3D API it would resemble OpenGL Long's Peak, stripped of legacy cruft (like OpenGL ES) with a native C++ OOP API instead of the current procedural C one. Save the OOP, this seems to be the way that the next-next version of OpenGL is going, and will presumably be the direction that the ES 2.0 successor will be going.