Slashdot Mirror
Programming OpenGL Articles
An anonymous reader wrote in to say: "The O'Reilly Network has posted a bunch of articles about OpenGL
programming under Linux. There's an introduction
to OpenGL, and then two
related
articles detailing how to create a OpenGL application. They've even
included a demo program
which is released as PD.
Hopefully this will inspire more programmers out there to use OpenGL
in their applications."
...and look at what Carmack's saying about making the Mac using Mac OS X his main platform, on which there is no Direct X. Doom was developed on NeXTSTEP, and ported to other platforms after that, and Carmack's been saying since the first release of Rhapsody DR1 that if Mac OS X sized up to what it's grand-dad NeXTSTEP offered, he'd jump the NT ship to use it again.
OpenGL isn't dying. At least, it won't from id.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
Last I heard, Nvidia was going to be providing OpenGL for the X-Box. If they do, we will probably do some simultanious development for X-Box. If not, it would have to wait until after the game ships to be ported.
The X-Box specs put it as a larger leap over PSX2 than PSX2 is over Dreamcast, but anyone with sense can see that by the time it ships, the hardcore gaming PC will already be a generation ahead of it in raw power.
The X-Box should be able to keep up for a while, because you can usually expect to get about twice the performance out of a fixed platform as you would when shooting for the broad PC space, just because you can code much more specifically.
I don't have much of a personal stake in it, but I am pulling for the X-Box. If you need to pick a feudal lord in the console market, I would take microsoft over sony/sega/nintendo any day.
John Carmack
As I understand it, right now licensed developers can use Sega's built in OS for low-level stuff on the DC, or they can use WinCE + DirectX. I've read that there is OpenGL support for the PowerVR2 that powers the Dreamcast, but whether or not that's available to developers now, I have no idea.
Instead of WinCE and DirectX, we could finish the port of Linux and add OpenGL. Linux would handle all MM, networking, input devices, and the framebuffer (which is 8MB on the DC). Then we could also port SDL because I see it as the most full-featured and cross-platform (7 different platforms) open source multimedia library in existence. For example, this would allow a port of QuakeForge much simpler than a full native DC port.
Finally, OpenGL (which can be accessed through SDL) would be ported (still fuzzy on this) and you would have a full development system for the DC that was fully open source and useable by anyone with a DC (without a GD-ROM).
DC software developers would be able to choose which kernel features and libraries they want distributed with their final project. Even Sega would win with something like this, only problem is, finding concrete specs on the Dreamcast is next to impossible. Hopefully this could be started without waiting on the DC to be "opened" by Sega.
Right now I'm trying to determine how the CDX demo CD fooled the DC into thinking it was a valid DC app. This DC development site has info on how to build a serial cable to interface to the PC. If software can be burned that accesses the serial port, then we can do cheap development on the DC. I've also e-mailed the guy who put up the DDH page (for more info + schematics), but I haven't got a response yet. If anyone out there has any low-level info at all on the DC please let me know.
Marcus
OpenGL's history on the PC has been somewhat rocky and turbulent. As recently as four years ago many 3D accelerator manufacturers would not publicly admit they were supporting OpenGL because of fear of reprisal from Microsoft.
After GLQuake and other OpenGL game titles began shipping, 3D accelerator manufacturers saw the business sense in supporting OpenGL, and Microsoft was not in a position anymore to stop them -- although some manufacturers were still very edgy about putting too much support into OpenGL. At least they could post OGL drivers on their driver support Web pages without too much fear.
By mid-late 1998, there was a serious leadership vacuum in the OpenGL space. The 3D accelerator vendors didn't have strong leadership anymore because SGI was busy dealing with its own set of issues. This caused a very fractured OpenGL strategy to develop on the PC -- basically, OpenGL was considered a necessary API for support, but each vendor sort of went their own way when it came to extensions, stability, and optimization.
By early 1999, those 3D chip vendors that were not NVidia realized they were at a very significant disadvantage when it came to API support under Windows. 3Dfx had Glide, sure, but Glide was already singing its swan song as developers started moving to more standardized APIs. At this point, NVidia also began exposing strong OpenGL extensions so that developers could begin using their cool features before DX8 shipped. This has set a precedent of exposing pretty core features of a chip set in OpenGL before DirectX N+1 ships. Hopefully other vendors -- specifically ATI and 3Dfx -- will get their respective acts together and start shipping chips and drivers competitive with NVidia's.
The key now is to watch how multiple vendors resolve their disparate extensions without a single strong leader that everyone trusts. If they can't manage to come up with a set of universal extensions and a consistent, predictable path to rolling these capabilities into future OpenGL base specifications, then things could get very touch and go until a strong leader emerges in the OpenGL space.
Brian Hook
Do you work for the man? This is FUD. I've never written anything with Direct3d, so I can't get into specifics about the distinctive difference between the new Direct3d features vs. the current OpenGL features/extensions, but you seem to have a pretty myopic, narrow view of the graphics world. A few points:
1. The moral issue: Direct3d is a closed Microsoft technology. Unless you're sitting in front of a WinX box or using some of the nifty Wine emulation, you probably won't be able to use Direct3d. This means, effectively, that Direct3d at this point can't be used by anyone seriously developing software (like CAD/3d design apps or even games) that hopes to be cross-platform. Writing Direct3d apps means you're aiding and working for the man. Do you only want to develop for Microsoft products?
2. OpenGL can always add features/extensions from competing API's. Maybe the standards process isn't as fast as it should be (look at all those GL_NV extensions), but there is clearly an open, active industry wide process to add new functionality to the API. Just as Direct3d has cloned OpenGL over the past few years, OpenGL can always effectively clone Direct3d.
3. Some of the new Direct3d features that I've seen (like shaders and skinning) are pretty highlevel. Shouldn't these be done in a higher level API? Even if these new features are germaine to a fairly low-level 3d api, by the time these extensions are adapted well enough by 3d cards to actually be usable in a mainstream graphics engine, the OpenGL standards body will probably have added them.
"look at the Microsoft/Bungie combo"
4. Bungie is a really good company, and it's a smart move of Microsoft's to pick them up, and I'm anticipating Halo just as much as the next guy, but I really don't see what this has to do with a graphics API.
"look at what the X-Box provides compared to OpenGL"
5. The X-Box is a console. OpenGL is a graphics API. This is comparable to saying, "look at what Linux provides compared to C." Also, the X-Box, according to the specifications, will support OpenGL (as does the PS2 and Dreamcast) and probably plenty of other API's, so I don't really see what your point is here.
Simply because OpenGL finally has some real competition (unlike glide *cough* *cough*), I fail to see how it's going to die.
If you're interested in doing OpenGL programming, you really should buy the "OpenGL Programming Guide, Third Edition." It's written by the OpenGL Architecture Review Board, so they obviously know what they're talking about. It starts with the extreme basics and goes into detail about even the most advanced techniques, as well as talking about improving performance. It has very good references for GLX (the X OpenGL extensions), AGL (Mac OpenGL stuff), PGL (OS/2 Warp OpenGL stuff), and WGL (Win32 OpenGL stuff).
The ISBN number is 0-201-60458-2
--
There seems to be some confusion about just what OpenGL is, and what it can and cannot do. So, let's clarify.
-- 3dfx vs. OpenGL. This is like comparing apples to pigs. OpenGL is a crossplatform 3D API for a variety of cards and systems. 3dfx is a card manufacturer. Possibly what the individual who wrote this post was thinking about is Glide, which is 3dfx's own semi-proprietary (now open, actually, if memory serves) API for programming their video cards. The Linux XFree86 3.3.x OpenGL drivers nestle on top of Glide. So do the XFree86 4.0 ones, although to a far lesser degree.
-- OpenGL HAS been changing since 1995. It is an "open" format, ergo the name "OpenGL". Anybody who has an OpenGL implementation can write extensions to it. Examples of these include some of the proprietary extensions developed by NVidia for their cards, like GL_REGISTER_COMBINE_NV. While the base implementation of OpenGL hasn't changed much, the extensions have. A variety of the more "popular extensions", such as the compiled vertex arrays extension, have made it into most OpenGL compliant libraries.
A body exists known as the OpenGL Architectural Review Board who approves these extensions and gives them an ARB approval rating, thereby formalising them as extensions which people should support. An example of which is the GL_MULTITEXTURE_ARB extension.
The primary difference to a hardware vendor between OpenGL and Direct3D is that Direct3D is controlled solely by Microsoft. (What a surprise). Therefore, if a company like NVidia, Matrox, 3Dfx, or ATI wants to develop some nifty new function on their cards, like... hardware mesh deformation, for instance... they would want to support both OpenGL and Direct3D. Now, with Direct3D, they need to pester Microsoft to add it to the official implementation, and that could take forever, and cost them lots of money. For OpenGL, since they write the OpenGL compliant libraries themselves (although often based on code by and licensed by SGI), they can do it immediately.
That's why OpenGL is IMO better: it's an Open API that can expand a lot quicker, and which better reflects the "I want it, I'll add it" philosophy which lets good stuff grow quickly. A company can add whatever they want to their OpenGL compliant libraries without having to suck up to SGI, whereas they DO have to suck up a lot to Microsoft to get anything done.
Nicholas
disclaimer: opinions contained therein are not neccessarily those of my employer.
- NeHe productions has over 20 OpenGL tutorials online, starting at the absolute beginning.
- The OpenGL Challenge is a weekly OpenGL compo that requires entries to be opensource. Has some *really* cool stuff.
- Romka Graphics has loads of misc OpenGL stuff, worth checking out.
- The OpenGL FAQ and troubleshooting guide is another overload in OpenGL-related material.
And besides that, I also run my own daily news site located at www.demoscene.org and is all about multimedia development, so a couple of OpenGL-related links turn up every week. Hope this helps...
It is interesting watching the way the tides of public opinion flow around some technical issues.
Over the last year or two, it was amazing the amount of panic among hardware companies that Sony caused with the PlayStation 2. Engineers that really should have known better were walking around with a paniced look, thinking "my god, they are going to crush us, we need to rethink everything!". It was disturbing to see PR effect technical people that much.
PS2 is unquestionably the most powerfull console, but it is a straightforward evolutionary step in power, not the "unprecedented leap forward" that it was billed (and perceived) as. People generally realize that now.
Microsoft seems to have captured much of the same sense of technical inevitability with DX8.
DX8 is good. Microsoft has a long history of shipping an initially crappy product (DX3), then aggressively improving it until it is competative or superior to everything else. Many people underestimate the quality of microsoft's products by only forming opinions on early versions, and never revising them.
The crucial advances of DX8 are the vertex and pixel shaders. I think that the basic concepts are strong, and they will give real benefits.
I expect that that functionality will be exposed through OpenGL extensions by the time I need it.
For one thing, DX8 is modeled pretty closely on Nvidia's hardware, and Nvidia's hardware is already fully exposed through their register combiner extension, even somewhat moreso than under DX.
The issue will be finding consensus between the other hardware vendors.
The upside is that not all hardware designs are exactly in line with DX8, and some usefull and interesting features exist that DX8 doesn't expose. It is looking like several hardware vendors are making moves to expose ALL of their functionality through OpenGL extensions to be available when the product ships, rather than at the next DX cycle.
The other issue is still portability. I am 100% committed to delivering our next title on linux and MacOSX (NOT MaxOS-9), in an effectively simultanious timeframe. That would be more troublesome if I was gung-ho for DX8.
I'm happy that microsoft is doing a better job, but I don't feel that I will be in a disadvantaged position continuing to work with OpenGL.
John Carmack