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
I'm working on an OpenGL driver with the company I'm with now so here's some of my thought after being in it for a while:
The OpenGL ARB is a lot slower in aporoving proposed extensions. The reason for this is that OpenGL was not designed with games in mind, and they have a lot to consider before adding an extension, so not to contaminate the OpenGL standard by mistake.
Direct3D is another story - MS accepts a lot of extensions propsed by cardmakers really quickly, primarily because it is designed for games, and for game developments, more features == better eye candies.
The result is, D3D now incorporates a lot of features that OpenGL doesn't. Hardware shadow, Texture compression, Bump mapping, Anisotropic filtering, Video texture are the most important ones.
On a driver level, the two are similar. However feature-wise, there are some capabilities of a video card that can be made use by D3D but not OGL, unless you add your propriety extensions, which I don't recall a lot of games use.
Maybe more companies like id can change the minds of the OGL ARB...
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
True by the time xbox ships, the PC CPU will be at god knows what speeds. I would think the video cards will be somewhat close. But the big bonus for xbox development is the target machine spec you develop for. No needing to worry about supporting that ancient PIII500/TNT2U setup :)
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 isnt that great, why is every soo unbelievably excited about it ??
Because it is a CLEAN and ORTHOGONAL API design. You probably don't remember Execute Buffers back in Direct3D 3.0 It only took MS _4_ versions to get a graphics API straightened out.
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
I'd love to see som leveraging of the Open Source movement to get some real inovation going. I'd like to see some developments into 3D window interfaces, and OpenGL would be a great tool. All the projects I've seen on this have been pretty lame. Linux might have a great opportuniy to leap-frog the cometition here.
"Let your heart soar as high as it will. Refuse to be average." - A. W. Tozer
OpenGL is an API, 3dfx cards are hardware. Maybe you're thinking of glide? Glide is 3dfx's proprietary API, which at this point is missing a lot of features that GL, for the most part, has. People like GL because it's portable. 3D games, for instance, programmed in GL will work on any platform that supports it. For example, if you port your program that uses GL from mac to pc or even a game console, as long as that platform has support for rendering GL markup it will work. Glide is fast, but it requires 3DFX hardware. Glide is also, to the best of my knowledge, a closed standard. DirectX/Direct3d requires the windows platform. So OpenGL is the only standard that is both open and portable. Oh, and GL can look beautiful given you have it setup right.
Trolls, it must be cool to be that bored.
http://www.sgi.com/fahrenheit/index.html
gives SGIs take on why they no longer support Fahrenheit.
Gingko
i don't do sigs. oops.
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
--
Things I love about OpenGL: ;)
- Great performance.
- Rock solid stability (On NT anyway
- It support BeOS (oh yea, and Linux too.)
Things I hate about OpenGL:
- Dumb extansibility model. C'mon, do we need NV_COMBINE_REGISTERS, ARB_COMBINE_REGISTERS, and ATI_COMBINE_REGISTERS? There should be more central control. (What the hell is the ARB doing).
- Slow pace of feature add-ons. With a game market moving at this pace, and nVidia incorporating dozens of cool (usefull!) features every 6 months, OpenGL just can't seem to keep up with DirectX. I think Direct3D 8 already outguns OpenGL for standard features.
- It still only really usable in Windows, Suns, and SGIs.
Argg, what to do! Of course, there is no way in hell I'm going to learn Direct3D, because frankly, the designers were on crack. They have a beautiful extendible model (a set of COM objects) and then they fuck the API to look like this! (Of course you'll have to pry my dead body of DirectDraw, hard to program or not!)
A deep unwavering belief is a sure sign you're missing something...
Microsoft controls the most popular operating system on planet earth, along with its associated APIs. If Microsoft decides that it wants to help one manufacturer more than another, the ramifications can obviously be immense.
If you're developing new graphics technology and Microsoft opts not to support your new features in their next API, the effect would be chilling on your product's competitiveness. This is something that's always in the back of the mind of a hardware developer as they decide how vocal they wish to be about Direct3D and its shortcomings.
Brian Hook
In the first article there is a link to a sample Makefile for cube.c. I'm using RedHat 6.2 and the only tweak I had to make was to replace the initial spaces on line 12 of the Makefile with a tab.
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.
Best bet is to get the "Red Book" - the OpenGL programming guide. This is a great book, especially if you're new to graphics concepts. (Although, if you want a good graphics book, Computer Graphics Principles and Practice by Floey, Van Dam et al. is still the best text IMHO).
.
The Red Book is available online here
Some good tutorials are here
For general information, plus a lot of good links, www.opengl.org is the place to look.
Gingko
i don't do sigs. oops.
- 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...
Prove to me that xig solution is not superior to alternative before flaming away !
Ok, how's this? XFree86 is the only X server for Linux which supports DGA - hence, no other X server will run the majority of fullscreen Linux games.
--
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
In response to the question about Farenheit:
Farenheit was supposed to be a joint initiative between Microsoft and SGI in an attempt to unify the diverse graphics APIs. It was thought by many that this was an attempt by Microsoft to appease the developers, coming at around the time when major developers were petitioning Microsoft to continue with OpenGL support in Windows9x - most particularly to do with Microsoft's removal of the MCD model, forcing IHVs to write complete implementations of OpenGL - a non trivial task.
Bits of Farenheit were supposed to appear in DirectX 7. I didn't see them. I read a white paper on the scene graph technology they were talking about - looked interesting. I believe the Farenheit project was eventually 'put on the back burner' a little while ago now.
There was a scare around Christmas when it was reported that OpenGL wasn't making its way into Windows2000 releases. This turned out to be a rumour and nothing more.
On the subject of stagnation of the API: Don't forget that vendors can expose extensions to OpenGL through a well documented and standardised extensions mechanism. This is what happened with multitexture - in GL 1.1 multitexture was exposed via an extension, many vendors implemented it and thus in 1.2 the feature was standardised. It's a very different model to DirectX's 'lets throw everything we can think of in this year and give em another interface to play with' development. The point is that OpenGL was designed properly in the first place.
Gingko
i don't do sigs. oops.