Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Programming IT Technology

Programming OpenGL Articles 89

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."
This discussion has been archived. No new comments can be posted.

Programming OpenGL Articles

Comments Filter:
  • Do you forsee that the OpenGL extension-approval-integration mechanism will keep pace with Microsoft's iterative improvements to DirectX? Given that feature addition in both APIs appears to be driven by hardware improvements, do you think that this will ultimately be the deciding factor between the two APIs?

    Gingko

  • by RevAaron ( 125240 ) <revaaron AT hotmail DOT com> on Saturday June 24, 2000 @10:05AM (#978877) Homepage
    ...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.
  • by Wolfier ( 94144 ) on Saturday June 24, 2000 @12:00PM (#978878)
    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...
  • OpenGL existed long before consumer level hardware acceleration. I believe it will exist even if it isn't, since no high-level CAD vendors will consider DirectX. Remember, OpenGL exists for a lot more than just games.

    Gingko

  • Well, considering DirectX is only available on WinXX platforms... I somehow doubt that. And I'd suggest laying off the crack, it's probably bad for your health, not to mention your reasoning.
  • How about, OR NOT. I will not support XiG, for any reason.

    I don't like their advertising practices. I've tried their products before, and their claims about "better stability" are so much bullshit. If you want to buy their products, fine, be my guest; however, if I was going to go for a commercial Xserver (which I'm not, I like XFree just fine, thanks), I'd go for MetroX first - they support the free software community, instead of slamming it and (seemingly) trying to generate ill will.
  • by John Carmack ( 101025 ) on Saturday June 24, 2000 @11:31PM (#978882)
    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
  • no. only portability will be. ever tried directX on NT ?
  • This really irks me. If it was a typo, so be it.

    I thought the rules were:
    • AN if the first letter of the next word is a vowel.
    • A if the first letter of the next word is a consenant.
    Score: 2 (Informative) :P
  • 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 :)
  • it's supposed to look like some of the anti-russian propaganda from the cold war.
  • Just one question. How can Microsoft hurt your typical graphics card manufacturer ( say Matrox or 3dfx)?

    Take for example DX8. There are many new features close to nVidia's hardware (because nVidia currently has the best hardware features and nVidia is in close co-operation with MS). Now if MS doesn't like ATI and opts to not include API for vertex blending (supported by ATI hardware) then game developers won't use vertex blending and there is no advantage for ATI cards to include that feature. No matter how much faster/better looking games could be if it was supported by DX.
    _________________________

  • Dude!

    Have you ever written anything in DirectX? It's every bit as fucked up as MS's other API's. Besides that, it's tied to Wintel only, while OpenGL works on pretty much every platform worth a damn.

    Besides that, OpenGL has a much more active and rabid community around it. There are OpenGL tutorials all over the web, and books on it, and a hall of a lot more games with OpenGL support.

    It's entirely possible that DirectX will someday be able to do more than OpenGL can. But it will always be a pain in the ass to code in.

  • Then why is it, every time this comes up, there are plenty of disgruntled XiG customers who stand up and refute XiG's "faster/better/more stable" claims? It may be faster on _some cards_. But as unstable as I've found it to be, I can hardly classify it as "better".
  • John, isn't Microsoft talking about (memory, processor) upgrades for the X-Box? That would eliminate the fixed platform advantage. That, along with the off-the-shelf design of the X-Box are keeping me away from it.

    I think that Sony will keep the PS2 as a fixed platform, perhaps with the exception of some peripherals. This is what I want in a console! Something that I don't have to worry about upgrading to play x game on it.

    Refrag
  • DirctX - fucked up? A pain in the ass to code? Never were truer words spoken. It sucks big time. Why doesn't Mr Bill swallow his pride and fully embrace OpenGL drop that stupid D3D and incorperate OpenGL into DirectX.
  • Look OpenGL and D3D can stay in the crazy land of the PC. Please don't ask Nvidia or Microsoft to make our life harder by asking for generic APIs. Stop the insanity! Let Microsoft release a consol that may have a chance. I don't even want a stupid OS on it. Just a few helper function to read input, and the DVD, and stuff like that. I don't even want a stupid memory manager! Let us the developers figure that out. ( Like we have always do. ) Tomas
  • I wrote some FEA software whose graphics
    portion is completely built
    on Mesa/OpenGL and there are plenty of good
    reasons to use it.

    1)Completely open in terms of API

    2)Supported by GNU/Linux, Unix(through
    Mesa) and Microsoft(included in MSVC++).

    3)Books are pretty good.

    I was able to even build a crude button system
    with the GLUT library, and porting to Windows only
    took 1 day.

    There are some limitations, but overall, the
    design is pretty logical and relatively easy
    to learn.

    San Le
    slffea AT juno.com
    slffea.com
  • Yep. Xfree can't even get basic mouse support right let alone something fast enough to compete with DirectX ( which is btw not only graphics, excellent sound support is a big part of it.)
    The problem is that X is basically inferior to direct rendering subsytems (like GDI on Windows.)
    It is good enough for most desktop apps where flicker doesn't matter that much but for gameres every bit of additional power counts.
    Even for 2d games like AOK there is support in DirectX for page flipping which saves one huge screen blit. Where is that support in XFree (3 or 4.)?
  • by mrossbrown ( 70015 ) on Saturday June 24, 2000 @10:22AM (#978896) Homepage
    In lieu of the announcement on the DDH [slashdot.org] and the ability to burn Dreamcast software to CDRs (see the same article for info), here are some ideas surrounding OpenGL on the Dreamcast:

    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 [libsdl.org] 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 [mangakai.org]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

  • Just out of interest, how come it took you a day to port some GLUT code to Windows? I thought that GLUT code compiles out of the box on Windows and on Linux and on Mac and on...

    Gingko

  • GLUT code does compile and run perfectly on Win32. However, to make an executable using the *native* Win32 API (yes, the big one you've been warned about :-) ), you're going to need to get rid of the GLUT code and add a bunch of standard Win32 calls.

    _Adam Poulos;
  • Isnt that spelt Fahrenheit?

    -E
  • >Just out of interest, how come it took you
    >a day to port some GLUT code to Windows? I
    >thought that GLUT code compiles out of the
    >box on Windows and on Linux and on Mac and
    >on...

    You are mostly right. The reason it takes me
    so long is partly due to my ignorance of MSVC++
    ( Also, I need to change all file names to the
    8.3 name restriction under Windows 95) and
    a few quirks of MSVC++(you need #include
    windows.h), and some variable
    names aren't allowed, but otherwise, it is
    very straighforward.


  • What is Carmack saying about OGL vs. DirectX?

  • by UnknownSoldier ( 67820 ) on Saturday June 24, 2000 @10:31AM (#978902)
    > 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 standard is evolving extremely slow. Almost all vendors are implementing their new features as extensions. Extensions are flexible, but also hard to use, especially when there is no 'official support' in the driver. This is hard because when you want to have a certain effect in your application, and you need an extension for that, you HAVE TO code an alternative codepath for the people who have a different card with no support for that extension. (crashing crappy coded multitexturing programs on a G200 is a good example)

    D3D on the other hand always supplies you with a software emulation for a certain feature. Besides that, MS picks up new features very quickly and for example with the D3D 8, now in betatesting, D3D will have more features than OpenGL.

    I'm an OpenGL programmer, I love the api, but please, don't drag the old OpenGL vs D3D debate into this thread. There is no 'BETTER' or 'WORSE'. There is just: 'this api works on windows' and 'this api works on more than just windows'. Take your pick.
    --

  • 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.

    To which features are you refering? When I look at the specs for the vertex and pixel shaders for d3d 8, I can't imagine what kind of 'revolutionairy' feature won't be able to build with that. Sure, perhaps hardware voxels or NURBS tessalation in hw is an option that is not included, but are these features already announced by vendors? most cards are hardly able to render the shaders in hardware, do T&L etc. When the majority of consumers are using hardware that is able to do all that, we will be a year from now, and D3D 9 will be at the horizon.

    Still liked your shader implementation a lot though :) cheers.


    --

  • At the OpenGL SIG at SIGGRAPH last year (mostly SGI folks leading this), it did appear that Farenheit was effectively "over". SGI was concentrating their efforts on helping out in bringing OpenGL to Linux, which resulting in some open source releases of some SGI code, and not much else (AFAIK).

    As far as the scare about OpenGL in Win2K, it's true that it was blown somewhat out of proportion. OpenGL sits along side DX7 in Win2K, and both sides seem to be happy...for now. The one thing I did take away from the whole "statement" from MS was that (obviously) their efforts for the future would be concentrated on DX. Well, duh...
  • It's interesting you mention the PSX2 -- given the (somewhat overdone, IMHO) hype surrounding the X-Box these days, what's your take on working with OGL given that there will no doubt be a easier migration path to the X-Box from DX?

    Granted id is focused more on PC games, but at least from a mass-market viewport, consoles seem to be in the lead. When you say portability, the Linux and OSX markets seem pretty small compared with the 1-out-of-4 household PSX market.

    Quake III Arena rules, btw.
  • Where can I obtain these drivers?
  • John, I'm glad to hear that you're so interested in developing for other platforms besides Windows. After all, games do drive technology, right? =) I'd like to see other developers share this interest, and it seems to be happening, albeit slowly... Windows is not the greatest thing since sliced bread, that's for sure. I remember you saying in the October 1997 issue of PC Gamer that "if you program for DirectX, you're just plain locked in." It's true. I've tinkered a bit with OpenGL programming, and I find it to be relativly easy as compaired to DirectX. It's nice to see an effort to bring OpenGL to Linux, as I think it will greatly increase the interest in Linux, particularly with gaming (which goes back to me saying "games drive the market"). Keep making great games John, and I'll buy them. Keep supporting different platforms, and you've got a friend in me. I'll be first in line for Doom3 (or whatever it may be named =)

    Chris
    cfreas@multisoft.com
  • Does anyone know of a good site on non-photorealistic rendering? I would like to code my own shader, possibly a cell cartoon shader, and haven't been able to find anything.

    I would really appreciate anything, especially code examples...


    What do I do, when it seems I relate to Judas more than You?
  • by Brian Hook ( 204434 ) on Saturday June 24, 2000 @05:14PM (#978910) Homepage
    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

  • Eh, actually, from what I've heard (from numerous sources), the xig drivers are of MUCH lower quality than X4.0, and are much less stable. This may not be true for all graphics cards, but I've heard (again, from numerous places) that at least on 3dfx cards it doesn't hold anything on the X 4.0 servers.


    One Microsoft Way
  • // These are C style comments because // the new C standard was approved // last december. // How uniformed.
  • I hear many arguments about the death of opengl and the supremecy of DirectX and I keep thinking of the reasons I began programming in OpenGL and not in directX. Its all about the learning curve, or at least it was for me, a guy who at the time knew nothing outside of theory and C++ syntax. I had two choices DirectX (maybe v3 or 4 at the time) and OpenGL&GLUT. I tried DirectX first because back then OpenGL was still usually mentioned as a industrial graphics API not flashy game stuff. After a few large headaches I finally got a program to compile that filled a window with random pixels. Now you might think sure this is simple but it took me quite some time because I had to learn the cryptic DirectX syntax and a lot of windows specific crap as well. Enter OpenGL&GLUT: With its efforts to be completely portable OpenGL already had a sibling API that handled the windowing environments for you. So with maybe a scratch of my head and a file that was an impressively little amount of code I had a 3d shaded box spinning in space. Reality: Sure when I make something Im really expecting to take off I wont use GLUT because I'd like full control over what Im doing. Then again learning one set of funny API calls is a lot easier than 2. Yeah sure maybe DX will make leaps and bounds over OpenGL and you'll beable to make hardware accelerated voxel landscapes with synthesized textures and fractal trees popping up everywhere, but your going to have to lock yourself in a dark cubby hole and work at it for a long time. Meanwhile all the newbies to the field who are worried more about how to implement new technology and not how to walk on eggshells just to get a nice 3d image are going to learn on OpenGL... because its easier to start on. If it remains as training wheels to the big bad harley some of you think will be DirectX then so be it, it hasnt died. Personally with the potential for microsoft hitting the rocks and linux in all its Open Source glory taking a larger piece of the market Im going to want to develop with an API that will port without pagan rituals :). -bart Wow! that lasted longer than I'd hoped
  • hehe and I guess I should have formatted that better ;)

    -bart
  • Ancient PII500/TNT2U setup? Try no worry about supporting that ancient P233MMX/Voodoo1 setup.
  • sure beats the hell out of Direct3d!! I like the state-based machine style of OpenGL. Anybody know what ever happened to the SGI/Microsoft Farenheit project that was supposed to merge the 2?

    kicking some CAD is a good thing [cadfu.com]
  • Let's have more people programming opengl x servers instead..
  • 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.
  • by phwiffo ( 139975 ) on Saturday June 24, 2000 @09:18AM (#978919) Homepage
    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.
  • For anybody out there tired of open source "almost working" GL implementation, there is great solution for this problem available from xig. AcceleratedX people sell complete , hardware accelerated implementation of OpenGL for Linux.
    In same cases the price is only $29 !
    Worth checking out.
  • MS decided that OpenGL wasn't good for business and axed the project. In addition, they haven't updated any of the universal gl architecture they started in NT4 in win2k.
  • What do you mean by this "3dfx is a lot better"?
    do you mean the Glide or D3D with the 3dfx drivers. Colors being messed up is uesly a problem with the drivers gamma correction not the API. I have not tryed it but I have heared that the OpenGL implmation in the 3dfx driver is not that good?
  • I normally like OpenGL what with its crossplatform nature and use in GLQuake. Hell, I even used it in some of classes at the university to draw simple gourand lighting efetcs.

    Bur with the advent of DirectX 7.0 and the specs of the Xbox, I don't see OpenGL havng much of as life anymore. Look what Carmack's even saying about DirectX vs OpenGL, look at the Microsoft/Bungie combo, look at what the Xbox provides compared to OpenGL...and you my friend will be looking at the end of OpenGL within the year.
  • For anybody out there tired of open source "almost working" GL implementation, there is great solution for this problem available from xig. AcceleratedX people sell complete , hardware accelerated implementation of OpenGL for Linux. In same cases the price is only $29 !

    What's this? The back side of Linux Journal? If you haven't tried it lately, the Utah drivers are awesome and stable (modulo the NVidia ones). Then there's PI's DRI drivers, which are also spectacular (or at least the G400 ones, the card I have, and it looks the 3dfx ones are also quite good), but take longer to build ;-), and if you chose to buy an NVidia card, there's their drivers, too.

    For those of you that don't understand the LJ reference, go dig a LJ from January or something close. If you haven't got one, it's not really that important, you are only missing some fud...

    Moderators: please think twice before marking something as "interesting" without doing some research first.

  • > I expect he will drop Open GL soon.

    And how many portable games have YOU worked on?

    Carmack uses OpenGL because DirectX ISN'T available on *Nix, or Macs. So much for Direct X "being superior"

  • Hmmm... I bought XiG's accelerated server for ATI Rage128 cards. Constant lockups anytime I tried to run a GL app. Precision Insight's drivers, however, never gave me that problem.

    Adam
  • by Gingko ( 195226 ) on Saturday June 24, 2000 @10:35AM (#978927)
    http://www.sgi.com/fahrenheit/index.html [sgi.com]

    gives SGIs take on why they no longer support Fahrenheit.

    Gingko

  • > One of the probles with GL is that it is a standard.
    Standards are a _GOOD_ thing.

    > there havn't been any changes to it sense 1.2 back in 95ish.
    Better to have extensions that can be implemented any hardware vendor, and then re-evaluated to see if it should be moved into the core idea, instead of some half-baked idea. Do you remember execute buffers from D3D 3.0 ? How many versions has DX been through? Probably because MS can't get it RIGhT the FIRST time.
  • Do you know how far PI's work is coming with 3D support for the Rage 128 cards?
    I own one, and would love to see hardware acceleration in action.
  • Like the subject: says: I'm interested about tutorials in OpenGL. I know the extreme basics of it, but would be interested in a set of tutorials that would elevate my knowledge a bit.
  • by bran880 ( 84112 ) on Saturday June 24, 2000 @10:44AM (#978931)
    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 have an AGP card, support is pretty good. PCI cards are not supported as well (PI will be writing PCI Gart support for the linux kernel to improve performance for PCI cards). However, Rage128 cards are the least supported of the cards, having the newest drivers.

    Adam
  • dri.sourceforge.net it takes a long time to download (cvs), and about an hour and a half to build on my machine (dual PII 300 MHz).


    One Microsoft Way
  • 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!)
  • Windows supports OpenGL programming (although it manages it by converting the GL into D3D commands). This is what happens if, for example, you play Quake in software GL mode.

    Borland C++Builder is excellent for openGL programming, for example. Easy to whip up nice fancy shit.
  • Yeah, they seem to take particular pleasure in slamming XFree but at least 90 % of that is actually true. Their stuff is faster and better at least was for me ( on 4 different cards so far)
    XFree is actually good enough if you settle for that. The biggest problem I have with their stuff is crappy mouse support. It is very annoying having cursor freeze during any larger screen update.
  • I was not talking about 3D. Just plain old 2d games ( Age of Kings type ) where full screen blit actually counts. Having to blit does not necesarly mean your graphics won't be fast enough but it takes away tons of CPU cycles that could be used for other stuff ( AI etc...)

    "The only problem with Linux gaming is getting the games and apps themselves ported. "

    No , not really. There are tons of other issues like proper support for various controlers, unified and fully hardware based sound support.
    Linux is not great gaming machine by any means.
    Actually, what you said fits better BeOS than Linux since BeOS has really great standarized support for these features but lacks anybody who would be willing to use it.
  • by Anonymous Coward
    Some heavy hitters, including ATI, 3Dfx, IBM, SGI and Intel, have formed a special interest group to develop OpenML. As I understand it, this is an open media language offering to develop standards and extentions to not only graphics but other media types (sound and video come to mind). This will hopefully address the issues that you mention.
  • Just one question. How can Microsoft hurt your typical graphics card manufacturer ( say Matrox or 3dfx) ?

  • 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
  • That was sarcasm, btw :) And we are talking about another 18 months from now.
  • Nifty! Thanks!


    What do I do, when it seems I relate to Judas more than You?

  • What people don't seem to understand is that programming for a closed system (console etc) is very different then programming for the PC,MAC och a Unix/Linux dialect etc. The main thing is that for a console you can take advantage of every little hardware speciality that you can't with general PC/MAC hardware. So the fact that the hardware will be old in comparrison to the PC hardware of the time the X-box will still deliver a good punch, and while developers will get used to the hardware they will be able to use it better, just look at the PSX and the old games and then look at it's new games. It's a day and night difference.
  • One of the probles with GL is that it is a standard. there havn't been any changes to it sense 1.2 back in 95ish.

    DirectX may be a bitch to code in and it may be windows only but at least it is still being updated with new features.

    OpenGL otoh is simplicty in its self to code in.

    And ill take GL anyday over DirectX

    Sanchi
  • 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.
  • "Are you now, or have you ever been, a member of the napster comunity?"
    ___
  • Yeah, it is available if one is willing to spend couple hours chasing correct version of drivers for his card (assuming there is one.)
    All I am saying is that xig drivers are painless alternative which works very well and "out of the box"
    And no I have no links to xig beside using their products.
    Cleary, as of now, xig solution is much better than anything else for Linux.
    Prove to me that xig solution is not superior to alternative before flaming away !
    It costs money but so do almost all good things in life.
  • 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
  • by Gingko ( 195226 ) on Saturday June 24, 2000 @11:01AM (#978950)
    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 [srk.fer.hr]

    Some good tutorials are here [gamedev.net].

    For general information, plus a lot of good links, www.opengl.org [opengl.org] is the place to look.

    Gingko

  • These are some sites that were very useful to me when I was learning OpenGL:

    - NeHe productions [gamedev.net] has over 20 OpenGL tutorials online, starting at the absolute beginning.
    - The OpenGL Challenge [dhs.org] is a weekly OpenGL compo that requires entries to be opensource. Has some *really* cool stuff.
    - Romka Graphics [madli.ut.ee] has loads of misc OpenGL stuff, worth checking out.
    - The OpenGL FAQ and troubleshooting guide [frii.com] is another overload in OpenGL-related material.

    And besides that, I also run my own daily news site located at www.demoscene.org [demoscene.org] and is all about multimedia development, so a couple of OpenGL-related links turn up every week. Hope this helps...

  • Thanks. This sounds rather promising material, and I'll look for it next time I'll visit my favourite computing bookstore.
  • I think these, write once, and compile anywhere API's are the way to go... no meed to fuss with a virtual machine, and you get native speed. Now we need to see a standard for developing GUI's and the like. I know there are some out there now, but I am not sure which one to use.

    My experince with OpenGl was VERY posative, so I am excited about OpenAL and OpenGUI...

    Just a thought...
  • 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.
    --
  • by John Carmack ( 101025 ) on Saturday June 24, 2000 @11:21AM (#978955)
    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
  • by Admiral Burrito ( 11807 ) on Saturday June 24, 2000 @11:34AM (#978956)

    The problem is that X is basically inferior to direct rendering subsytems (like GDI on Windows.)

    Xfree86 4.0 has direct rendering, and Utah-GLX has been able to do direct rendering with XF86 3.3 for about a year now.

    Even for 2d games like AOK there is support in DirectX for page flipping which saves one huge screen blit. Where is that support in XFree (3 or 4.)?

    With OpenGL page flipping is handled by the driver if it is handled at all. Some drivers do it, but many don't because in practice it is a very small performance improvement. A large blit is nothing compared to drawing all of the polys required for a complex scene. As I recall from reading the utah-glx-dev list, the difference is somewhere around 2%. Hardly the killer feature you make it out to be.

    Really, 3D drivers in Linux are not that bad right now. Nv and 3dfx are clearly on-board, and they are probably the two biggest players in consumer 3d hardware. The situation is only going to improve, and at an increasing rate.

    The only problem with Linux gaming is getting the games and apps themselves ported. Hopefully that will improve now that the drivers are available.

    If you're a hardcore gamer you'll probably continue dual-booting for now, but if that's the only reason you use ms-windows then you've probably paid your last MS-tax.

  • Yow. whoa there.

    8.3 restriction under win95? er... that's DOS's restriction, not Win95's.
  • This is such disinformation...Software OpenGL under windows does not go through D3D. It is just not highly optimized. They are using the same Software OpenGL layer that they have always used and it existed before Direct3D was a glimmer in MS's eye...

    Yes, its a crappy implementation, but its not THAT crappy. If you must have software OpenGL, then use Silicon Graphic's [opengl.org] replacement or use Mesa. [mesa3d.org]
  • >Yow. whoa there.
    >8.3 restriction under win95? er...
    >that's DOS's restriction, not Win95's.

    A subtle point to be sure, but Win95 only
    hides the fact that it only allows for 8.3
    filenames, unlike Win98 which I think reformats
    your HD to 32 bit, so filenames can actually
    be larger.

    I consider whatever I see when I open up a shell
    as the operating system's filename limitation,
    and if Win95 is limited by DOS, then it is a limit
    of Win95 as well.

    Now if you are able to truly have larger filenames
    for your installation of Win95, then that's
    another story.

  • Yes, and all of the C compilers out there will
    certainly be upgraded to meet the standard.
  • the 8.3 thing you see in a DOS shell is there for backward compatibility only. I mount fat32 drives all the time, and that too gives me the long filenames, so I consider win95's fat32 filesystem to be 256 (255?) characters long.

    Of course, this whole thing is a hack (looking at the fat table with a disk editor isn't fun... fat32 filenames go like this:

    lmnopqrs.tuv
    abcdefgh.ijk

    and windows reads this as "abcdefghijklmnopqrstuv".

    Anyway, that convinces me that win95 has true long filenames (altho it IS really just a gigantic hack).
  • Actually I beleive 3dfx recently open sourced glide. But OGL is much more feature full, and glide is no suitable for none gamming aplications.
  • by Gingko ( 195226 ) on Saturday June 24, 2000 @10:01AM (#978963)
    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

  • by Anonymous Coward
    You're right all of the projects out there have been pretty lame.

    Here we have another example of Linux making huge leaps forward in technology that's already outdated. Let's all be happy for our retarded stepchild operating system, shall we?

    OpenGL is not as fast as the other graphics solutions out there. Sure, some of them may be proprietary but this just shows what the problems of an open source, free operating system *are*.

    It's not something that's going to get fixed in the short term. The simple fact is Linux will always be slower in 3d graphics. If you're a gamer, do not install Linux. I can not stress this enough.

    Do not let the "selection" of a few big name games trick you into wasting your time. Most of the games for Linux suck and they're slower than their windows counterparts.

    Unless you're a bigfan of the linux-only games like xlander. Some of you may remember lander as that game you used to play from some shareware pack on your windows 3.1 box. Well if you've been wanting to play that again, no worries! It comes with most Linux distributions.

    That's right, one of the games most linux distributors bundle with their software is a crappy, flickery version of a game that uses technology available from long before Windows 3.1.

    Let's be honest here: Do you really care that some kid hacking in his basement is learning opengl? When's the last time you spent a long time playing a game some kid made in his basement over the weekend? Real games take a lot of money, time, dedication and skill to develop. Your average high schooler does not have any of these.

    In closing, an example: I know so many linux fans that just love the game civilization: call to power. I bought it because several of my friends love playing games on Linux (because it's the only thing they run). I wish I could return the game. It's a boring, annoying piece of crap. It's much less fun than the earlier 16 color civilizations you're probably familiar with. But they'll play it day and night.

    There's a reason behind this madness. See, it's because they want so badly to like Linux, to be cool that they're willing to settle for something much less fun than what's available out there in our big world of games. It's really pretty sad.

    Thank you.

    -lb

Congratulations! You are the one-millionth user to log into our system. If there's anything special we can do for you, anything at all, don't hesitate to ask!

Working...