Comment by pmjordan | Hacker News Reader

Comment by pmjordan | Hacker News Reader

Parent Full thread

All the viable gaming platforms, other than the Xbox 360, are running some OpenGL variant.

That's pushing it a little. Maybe you mean "viable for low-budget, independent developers" (no expensive devkit needed)? It's not that widespread on consoles: Nintendo still seem to be doing well, and none of their platforms support anything close to OpenGL. I'm aware that there is an OpenGL ES implementation for the PS3, but I'd be surprised if that was the only way or even the preferred method of talking to the graphics chip. In my experience, game console graphics programming is usually super low level, with the "API" consisting of a bunch of inline C functions and enum constants for twiddling GPU hardware registers, filling DMA buffers and handling interrupts.

Graphics APIs serve 2 purposes:

1. hardware and OS independence (consistent API for the same OS running on different GPU hardware, or for porting software between OSes)

2. sandboxing apps to prevent direct hardware access. The latter is useful for any multitasking platform, whether it's explicitly multi-tasking or just to shield the foreground app from accessing stuff running in the background, like on older iOS versions.

If you care about neither, or the latter is taken care of in hardware (IOMMU), then raw access to the GPU lets you do stuff that's way cooler than you could do with a driver and an API (though it's usually more work).

> low-budget, independent developers

Well sure, if you're a AAA studio developing bleeding-edge Xbox360/PS3/PC games that squeeze every drop of performance from the GPU (Carmack's area of expertise), your technical choices are going to be very different from those who are developing less graphically-intensive games for iOS/Android/PC/Mac.

I suspect the latter group is better represented on HN. And for those, OpenGL ES is almost certainly the best choice.

In case it's not clear: I wasn't passing judgement, merely explaining the situation and weighing up the advantages of the various approaches. For iOS, Android and Mac, OpenGL is pretty much the only choice, and sticking to the subset that is OpenGL ES even on the Mac is sensible if there's a chance you might want to port. That said, if your needs aren't such that you need close-to-the-metal access to the hardware, you may well be best off using one of the many inexpensive third-party engines altogether.

I would think that the PS3 supports more than just ES, as Unigine has been offering their engine for use on the console, and their benchmarks using said engine use the latest OpenGL 4 features like HW tesselation (http://unigine.com).

I don't know what the story is exactly (I quit my job at a major UK developer shortly before I was supposed to start working on a PS3 project) but there are some details here: http://en.wikipedia.org/wiki/PSGL

Since RSX is rumoured to not be that powerful, I suspect Unigine might be doing the tesselation on the Cell's SPUs.

PSGL is OpenGL ES with extras but hardly anyone uses PSGL these days, preferring to use the native GPU command buffer generation library, libgcm.

Reply on news.ycombinator.com