The State of OpenGL

CowboyRobot writes "No longer vapor, but a true 3D-embedded engine, OpenGL is on the move. Pixar and others would love to be able to render their movies in realtime, and that desire has prompted the intended release of OpenGL 2.0, due in a few months. Khronos is now in charge of further extending OpenGL to cellphones and handheld gaming devices."

Comments

Small Cell Screen

[Anonymous Coward]

Yay, I get to play around with 2x2 pixel rendered characters on the cell now.

Re:Small Cell Screen

[Salsaman]

No, you just need to buy two phones, one for the left eye, and one for the right eye, and a special new 'hands free' kit that holds the phones in front of your face.

Re:Pixlet

[PurdueGraphicsMan]

Pixlet is for playback (a codec), not for rendering films. Unless I'm missing something in your post.

Re:Pixlet

[LousyPhreak]

Pixlet
Pixlet is the first studio-grade codec for filmmakers, and it's available exclusively in Mac OS X v10.3 Panther. Tuned for use with high-definition source, it allows digital film frames to play back in real time on any 1Ghz G4.

and what exactly has that to do with rendering?

customer: show me your best cabriolet
salesman: well we have this used bike here...

Re:OpenGL is Dead

[b0r0din]

I thought we told you not to come back here after that Monkey Boy Dance incident, Steve.

Damn them

[Anonymous Coward]

When will they figure it out OpenGL is not necessarily desirable in a cellular phone?

I want business class reliability, not a the ability to rent subpar games on my cell phone for $5/month.

When I'm on the phone all day because of my work I want it to be there for important calls, not fizzle out after an hour because it's got a 640x480 pixel screen with 24-bit color.

Re:Damn them

[happyfrogcow]

no sh*t. imagine the battery drain from using a processor that can use openGL. who needs that crap. I'm all for openGL as a 3d standard, but cellphones don't need 3d. cellphones don't need games. Am i going to be ranting about cellphone batteries not lasting an hour, like i am with laptop batteries, in a year?

again, vote with your wallet.

Re:Damn them

[LousyPhreak]

so you must be the only one to not wanting 24/7 support by.... clippy! (with opengl es even in 3d!)

Re:Damn them

[Anonymous Coward]

Maybe they'll make phone without games available for people like you (and me). Meanwhile if they get it going in cellular phones, the people who want games for whatever reason will have those phones available to them. I don't see any reason to oppose what they're doing unless you have some reason to believe it's going to be a universal standard.

Re:Damn them

[Anonymous Coward]

Renting those games cost $5 per month each or $10 for a single download. Ring tones cost $1 each is a billion dollar industry already.

They will give everyone a color phone with polyphonic ring tones to increase the potential market for rentable games and downloadable ring tones.

Isn't that what YOU'D do if you were a major dealer like Verizon?

Re:Damn them

[Esoteric Moniker]

You can always go back to a 486 100Mhz and get outstanding battery life. Graphics are no different, you pay for your performance in battery life. Do you honestly think every cell manufacturer is going to slap these chips in all their phones if the battery life is terrible? No there will be consumer (for fun) phones i.e. N-Gage and professional (not for fun) phones that have no spiffy anything but "Just Work".

Re:Damn them

[HeghmoH]

So buy a phone with a black-and-white screen and long battery life. Nothing's stopping you.

Re:Damn them

[dmomo]

Something doesn't have to be "needed". Isn't "Wanted" good enough. I don't use a cell phone at all. But some people do. A lot of people don't use them for important things, or business things. They just like them. 3D games on a cell phone? Some people might like that. That's enough of a reason to make it available.

Re:Damn them

[Azghoul]

Hmm, funny, I don't remember you being declared the only person to own a cell phone.

How about realizing that there are other users out there? How about realizing that teenagers ( a gigantic market, by any measure ) might WANT their phones to play games?

Be a little more myopic next time, AC...

Re:Damn them

[sbaker]

If there *is* going to be 3D on cellphones and PDA's then I'd much prefer that they ran a standard API than a non-standard one. Given that there really are only two 3D standards, I'd much rather it was OpenGL than Direct3D.

So - *IF* we want 3D then we want OpenGL.

But do we want 3D in cellphones?

The supposed 'killer app' for 3D on cellphones is the idea of using the positioning detecting capability of the phone - along with network access - to provide an annotated 3D map of your present location. Think of the navigation systems in cars - but in 3D - so you can find the elevator you need to get to a particular office in a big unfamiliar building - or find where you left your car in an multistory parking lot.

Games will obviously use the technology too.

I don't know whether this is important to people or not - but if 3D is happening, it should CERTAINLY be in OpenGL - initially a small subset - gradually improving to a full-blown implementation in every phone as the technology catches up.

Personally, I'd be much happier with a last-generation basic phone that had 10x battery life and didn't lose service quite so easily.

Re:Damn them

[Bandman]

Maybe OpenGL isn't desirable in a phone that you want to buy, but someone else might want it.

Re:Damn them

[jackbird]

Ah, yes... That worked as a strategy for laptop purchases for about a year and a half starting in 1994. Then they stopped selling them. Same thing is happening in cellpohnes now.

Re:Damn them

[stienman]

1) You are not their target audience.

2) Eventually cell phones, pdas, computers, entertainment devices (tivo,etc) will converge into one or two devices, one of which will be portable. This is one item on the continuum leading towards the ubiquitous always on computing device.

3) OpenGL on the cell phone is simply a way of saying, "OpenGL on any platform requiring 3d graphics." It's marketting. It may not be used heavily on cell phones, but perhaps new a new HDTV format will allow for an opengl data stream to place products in pretaped shows for different areas (ie, midwest viewers see a CVS pharmacy, while southeast see an Eckard). Having a pared down implementation meant for little processors and low resolution screens is an asset. Don't abuse the implementation if the idea can be generalized.

-Adam

Re:Damn them

[srwalter]

Yes, and cell phone makers are required to build the phone that you want, and only you want. It's your right as an individual to make everyone else bend to your will. Other people want color phones? Damn them, indeed!

Oh wait, I forget that we have a free-market... guess you did, too.

Re:Damn them

[HeghmoH]

Two points:

First, they still sell black and white portable computers today, they've just shrunk; before they were 5-pound portables, now they're quarter-pound Palms.

Second, battery life, both for portable phones and portable computers, has been on the increase, not the decrease. My portable computer from the mid-90s (black and white, even) was lucky to get two hours. My giant, power-sucking G4 with a full-color 3D-accelerated screen is unlucky to get three hours; I can get five hours on light use. My girlfriend's full-color-screen, MIDI-playing, Java-gamed cell phone lasts for four days between charges. I see no reason for this trend to reverse; indeed, people tend to value battery life extremely highly, and so manufacturers value it accordingly highly.

Re:Damn them

[Mantorp]

I'll gladly trade my 5 yr old nearly featureless phone for a brand spanking new quattro band gigaflop lcd Wi Fi processor sms zinc battery technological marvel.

Re:Damn them

[kabocox]

Stupid parents for letting teenagers have game enabled cellphones. When I was in HS, my bothers wanted pagers/beepers. They got them. Mom treated them as recall buttons. She'd let them roam, but when she wanted them back, she'd page each of them. IF they didn't call her right then, no more pager.

I could understand GPS enabled pagers for teenagers, but what parent would want to let a teenager have a glorified gameboy phone?

Re:Damn them

[Puff Daddy]

Parents who want their kids to have a useful device instead of a glorified leash might want to get them a "glorified gameboy phone."

Next time my car breaks down and I have to call for help I'll remember how stupid my parents were for getting me a phone instead of a pager.

Re:Damn them

[alienw]

The supposed 'killer app' for 3D on cellphones is the idea of using the positioning detecting capability of the phone - along with network access - to provide an annotated 3D map of your present location.

That has got to be the stupidest idea I've ever heard. It's hard enough to get a map that shows STREETS accurately on a GPS, much less elevators inside of buildings in a 3D environment on a cellphone. Besides, how the hell do you navigate? It's hard enough with a mouse and a keyboard, much less with a cellphone with a numeric pad and a postage-stamp-size screen.

Re:Damn them

[canajin56]

No you can't. My 486 100Mhz laptop doesn't last more than 2 hours.

Re:Damn them

[canajin56]

You missed the part where the kids WANTED a pager.

Re:Damn them

[iantri]

However, the Palms you compare get a battery life of ~25-30 hours on a black and white model.

You're lucky to get 10 hours on a colour model.

This is a more accurate comparison to colour cell phones, as they are devices of a similar class.

Re:Damn them

[Zeplin]

Count me in for Nokia Quake.

Re:Damn them

[spectre_240sx]

Agreed. While I see the poster's point, there will still be cellular phones with no frills and superior reliability and good battery life. Just because one segment of the market decides they don't want games and such on a cellular, does that mean that the entire market should suffer with dull boring phones? He / She is being somewhat hypocritical here (no offense intended, just pointing something out).

Re:Damn them

[TaliesinWI]

Easier said then done. When was the last time you saw a decent B&W phone for sale that wasn't the $200 Motorola v60? Maybe one or two here and there depending on what carrier you go with but there's really no ubiquitous B&W phone across carriers anymore.

Re:Damn them

[kindofblue]

You don't have to use the keypad. A cellphone can be equipped with an accelerometer which can be used to sense movement and changes in orientation of the cell phone. That could let you twist and tilt the phone to get a different view of a scene. The cell phone could therefore be equipped to know where it is with GPS and how it is oriented and moved, using motion detectors, a compass, and accelerometer.

I imagine that a store or restaurant could supply a 3-D view of their storefront with their online yellow pages entry. Your GPS-enabled cell phone would find the store you want, provide a 2-D of it's location and display a 3-D model of the street scene and store front; so your cell phone or mobile computer could show you exactly what your destination looks like.

This may be overkill for finding the nearest Taco Bell, but the Postal Service, EMS and ambulances, FedEx, social workers, car rental agencies, the tourism industry, etc., and of course, police and military, could definately benefit from having these gadgets for customers/patrons.

Re:Damn them

[John Miles]

Great. Now my cell phone has inertial navigation as well as Reality Engine-class rendering.

How am I supposed to power this thing without a license from the Nuclear Regulatory Commission?

All I wanted was a phone, dammit.

</luddite>

Re:Damn them

[alienw]

Sure. You could also put a Pentium 4-class processor into the phone, as well as a large display and a powerful video card. Except then it would be a desktop PC, not a phone.

Re:Damn them

[Decaff]

Given that there really are only two 3D standards, I'd much rather it was OpenGL than Direct3D.

If you are developing software for future mobile phones you are almost certainly going to be using Java (J2ME), as there is no way you want your compiled code to be limited to a specific CPU or operating system on those devices. In that case you will be coding using the Java 3D API which hides the specific 3D libraries on the device. So why do you care if its OpenGL? Why should you care?

Re:Damn them

[Grishnakh]

2) Eventually cell phones, pdas, computers, entertainment devices (tivo,etc) will converge into one or two devices, one of which will be portable. This is one item on the continuum leading towards the ubiquitous always on computing device.

I've been hearing this for years, and I still think it's crap.

TV and computers are two different things. There are times when it's useful to be able to do the functions of one on the other, but there's no way that families of the future are going to just have a single TV that does everything.

For one thing, any family with more than one person will want multiple devices, so they don't have to share. If these devices are too expensive because they do too much, people won't buy one for every bedroom.

But more importantly, if I'm doing programming, writing documents, working on my web site, etc., there's simply no way I'm going to want to do that sitting on a couch looking at a TV across the room. This type of work is easier done on a smaller, high-resolution screen (or three) within arm's length.

Similarly, I don't want a little 21" screen to watch movies on; I want a very large screen in front of some couches.

Of course, it'd be nice to be able to also watch those movies on the desktop PC, store a lot of them on a central server, edit them on the PC and then watch them on the big TV, etc., and that's what home networking is for.

The way things should be (and a lot of people already have set up such systems in their homes) is that there's a central server for the home which stores all the gigabytes of media data that people might want to use in various locations around the house: movies, music, photos, etc. Then there's multiple devices throughout the house that can access this server and use the data on it: stereos, TVs, home theaters, etc. Ideally, most devices in the house will just be thin clients, with all the computing being done on the server. A small client to read MP3s/Oggs from the server and play them on the stereo (www.slimdevices.com has something like this); "media adaptors" to play MPEG4 videos on the various TVs throughout the house. As for TiVO, this should be a function of the server, not a separate device that can only be connected to one TV.

Re:Damn them

[MattyCobb]

How about realizing that there are other users out there? How about realizing that teenagers ( a gigantic market, by any measure ) might WANT their phones to play games?
being one of them myself (until just a few months ago when I hit 20) i can confidently say that they will buy a Gameboy Advance SP :) and laugh at the people playing 3d games on their phones. I mean really.
Pong or tetris on your phone - cool. Unreal 2 on your phone - retarted. If young people want higher end games they will look to a PDA or gaming system 9 times out of 10; at least all the ones i know. It has to do with control and feel of the system more than anything.

I am perfectly happy with my indestructable, always has service, ungodly long battery life StarTAC that my parents got me for my 15th birthday. It does text messaging and calls people. Thats all I want in a phone. And better still, it damn near always gets service and its going 5 years strong. If I want to game on the go, Ill use a Gameboy.

I think their is a market for games on cellphones. And their is a smaller market for high end 3d games on cellphones. But its nothing like this gigantic market you think exists. ...except maybe in japan. ... they love things like that.

Re:Damn them

[frycarson]

Because not everyone blows their load at the thought of coding in java.

Re:Damn them

[boelthorn]

My quite new SonyErricson T610 lasts about 5 days (medium use). My old Philips Xenium did 2 weeks and I buyed it 2nd hand...
These are my experiences with the trend of battery life...

Re:Damn them

[Decaff]

Ah! Usual /. anti-Java dogma.

As virtually all new phones come with Java built-in, its kind of moronic not to use it.

Of course, if you prefer wasting your time hard-coding OpenGL calls and re-compiling for each make of phone, that is up to you, but as a business model its suicide.

Re:Damn them

[Azghoul]

First off, shame on the public school system for your spelling and grammar mad skillz. :)

That out of the way, I never said there was a ny gigantic market for it.

When phones first came out, did you know you wanted text messaging on them? I sure didn't (still don't, but that's beside the point).

I don't expect things like UT2 on a freakin phone (not when you need GHz to get it to run at all), but I can easily see better, more colorful, more interesting pong and tetris, can't you?

Again, just because you don't want feature X in your phone doesn't mean there isn't a market for it. And if the market doesn't support it long term, than the companies wasted their money. So what?

OpenGL ES with hardware support?

[Stiletto]

Although right now OpenGL is all that's out there for low-cost portable embedded 3D software, no one is going to develop with it until hardware support emerges. Who wants a handheld 3D mapping device that takes 10 seconds to redraw a frame using an ARM9 software renderer?

Re:OpenGL ES with hardware support?

[LousyPhreak]

exactly thats the point of opengl es.

as it is only a subset of the opengl standard trimmed for low power/low speed devices it is (or will be) also fast in software. afaik there are also hardware renderers for opengl es in the works.

and remember:
we hat 3d games long before the gigahertz pcs with 3d accelerators were out and they were a tiny bit faster than 1 frame/second.

Re:OpenGL ES with hardware support?

[arbitrary nickname]

It's *not* really designed for software implementations. This is a common misconception. Relies on depth buffers for sorting - which can be wasteful on memory bandwidth for software implementations (there are better alternatives in many cases (BSP trees, portals, bucket sorting)

After having a look at the spec, OpenGL ES seems -1, Redundant. Why not just aim for full OpenGL, starting with a 'MiniGL/QuakeGL' style implementation, of the sort which really got the ball rolling on the PC.

However, I believe it does include fixed-point maths support - very useful for all the ARM-based devices out there with no FPU.

Re:OpenGL ES with hardware support?

[Mithrandir]

The simplistic reason for this is that the full OGL spec, or even the "miniGL" drivers are still waaay to complex for what is needed on these devices. Things like multitexturing, and anything that requires readback from the state is especially costly. The point was that on these devices they dont want full OGL support. If they did, they wouldn't have even bothered starting this spec. It is to provide a spec that has a greatly reduced footprint (memory, API coverage, etc) that allowed first class 3D graphics on smaller devices. If you want full OGL support, you do full OGL, not a partial implementation. There is no point "working upwards to full OGL" because they are never going to get there with this spec. Once a device wants to head towards desktop OGL support, then they bite the bullet and implement the complete API.

It was also determined that most of that sort of functionality was not needed. Other things like 1D and 3D textures, attribute stacks, display list etc are just non existant. On the other end, there are things that never existed in OpenGL, such as the fixed point maths support, along with defined accuracy measures etc.

In the beginning, OGL-ES had two primary targets - small footprint mobile devices, and safety critical markets (ie avionics displays etc). In the former, they needed basic functionality, but enough to do things like overlays and texturing. In the latter, they needed a very small API footprint that can be verified IAW with various authorising bodies (eg FAA for avionics, NIH for medical devices etc). In both cases, a miniGL driver was just not good enough because miniGL still assumes the full OpenGL spec and only for one particular application. Both groups required a formalised spec that they can point to and claim "this is what we support", complete with some logo branding. miniGL still assumed a desktop based system, neither of the target groups for OGL-ES could make a lot of those assumptions (for example floating point abilities at all)

FWIW, I was a member of the ES spec development group until about 3 months ago and still am on the spec mailing lists.

Re:OpenGL is Dead

[Xeo 024]

DirectX has won the war, with better features, performance, and availability.

I don't know about availability, OpenGL is cross-platform (works on OS X, Linux, Windows, etc.) while DirectX is Windows only. OpenGL is also included with many if not all graphic cards. So it's just as widely available, if not more, than DirectX.

Re:Pixlet

[PurdueGraphicsMan]

customer: show me your best cabriolet
salesman: well we have this used bike here...

Exactly.

Sun

[Brando_Calrisean]

What about the ability to stick to-do notes on the BACK of your cellphone? Wouldn't that make mobile 3D worthwhile?!

Re:Sun

[thumperward]

I for one welcome our underrated Sun-trolling comedy overlords.

- Chris

I hope so

[re-Verse]

For so long, DirectX had to struggle and claw to keep up with OpenGL - they did just that, while OpenGL sat mainly idle (well, John Carmack was a big help to it)... Now it seems the shoe is on the other foot, and OpenGL is going to have to move deftly to surpass DX9, and soon enough 10...

I sincerely hope it happens. I wish developers felt more inclinded to make their 3D engined GL based rather than DX based, so the day where I can play any game in linux may actually arrive. Of course, we have to give massive amounts of respect to those who do make OpenGL platforms for their games (ID, Epic), but what about those who feel DX is easier and more practical for what they do(Valve).

Maybe if we're lucky, the Carmack will drop in to this discussion and tell us exactly what he thinks needs to happen to really make GL a reality for most gamaes again.

Re:I hope so

[westlake]

Carmack can still build an engine. But his game designs are frozen in the 'nineties. Which is likely to prove the stronger seller and have more impact on developers, Half-Life 2 or Doom 3?

Re:I hope so

[KozmoStevnNaut]

For the more mature gamers who remember the good old days with Doom, Quake and Duke Nukem 3D, Doom 3 will be the best.

For the kids (for whom Half-Life was their first real FPS), Half-Life 2 will probably be the best.

I'm rooting for Doom 3.

Re:I hope so

[Dinny]

Fuck that. I remember Wolfenstein 3d and Catacombs Abyss in addition to all of those that you listed. Half-life is a better game. Unless Value changed drastically Half-Life 2 will be a better game then Doom 3. The will both still be AAA products, but I fully expect Half-life 2 to be a better game and more fun to play. I expect Doom 3 to be more awe inspiring and technically amazing.

Re:I hope so

[sydb]

Nothing from this decade or the last comes close in 3D gameplay to Knot in 3D. Now there's a classic, and it ran fast in 48k at 1MHz.

Re:I hope so

[sydb]

Here's a better link.

Re:I hope so

[ScrewMaster]

They've all missed the point. Duke 3D was impressive because you could BREAK THINGS. The environment wasn't just there for show, you could interact with it in pleasantly destructive ways. Quake I disliked because, while it was beautiful to look at, you really couldn't do much but open doors and use elevators. I LIKED the way I could be in the middle of a network gunfight in Duke, run up to the second floor of a building, KICK out the window with my foot (with glass shards falling around me) and blaze away. After an intense battle on a dance floor, we would have shot out the mirror behind the bar, blasted all the liquor bottles into particles, and shattered vases, flowerpots and ashtrays all over the place with appropriate sound effects. That was very cool, and really enhanced the overall immersivity of the game. When it was over we would just look around at all the destruction and cheer.

Duke's overall game percentaging was very well-thought-out. The impact of various munitions was adjusted such that you didn't die too quickly, but still the relative damage levels incurred appeared realistic. And again, when a pipe bomb or a laser trip bomb went off, it would destroy any nearby breakable objects or windows, as you would expect it to do. In games like Half Life or Quake, everything around you is pretty much explosion and/or bulletproof, and that isn't particularly realistic.

Playability is the key to a game with staying power, and playability is, unfortunately, not something that has achieved much focus in recent games. It also is not intrinsically bound up with the graphic quality of the visual environment. The majority of development effort has been expended in creating gorgeous 3-D environments, not good games. A game is supposed to be entertaining, and once the "oooh!" and "ahhhh!" wears off, if the product isn't truly playable you'll find yourself not playing it no matter how pretty the pictures are. At that point you've just wasted your money.

Re:I hope so

[ScrewMaster]

And as an aside, there were several successor games to Duke Nukem 3D, all based upon variants of Ken Silverman's original Build engine. Shadow Warrior, Blood and Redneck Rampage are three that I played regularly, and all were excellent, highly-entertaining games. In many respects I believe the game industry has take a step backwards in recent years.

Re:I hope so

[KozmoStevnNaut]

Yes, the Build-based games were some of the best and most fun FPS games ever.

I still think the Quake games (especially Quakeworld and Quake 3) were and still are the best deathmatch games, simply because of the almost perfect physics. Jumps just feel right, and not awkward as in Half-Life.

But as you said, the breakable scenery in Duke3D made for some pretty cool matches. I think Doom 3 and Half-Life 2 are going to be the beginning of a wave of games with plentiful breakable object, just like in Duke3D. Max Payne had good physics, and a great movie feel to it. Too bad it wasn't a multiplayer game.

That said, UT2004 makes somewhat good use of physics. It's the only game where I've been able to shoot down a plane with a car launched by a grenade :)

Re:I hope so

[KozmoStevnNaut]

Half-Life was a good game, with an OK storyline. But it's still nowhere as brilliant as Duke3D or Quake.

I agree that both HL2 and Doom3 are going to be AAA titles, but I'll probably only play Doom3, mostly because HL2 is going to use STEAM (which I hate) and DirectX9 (which I really, really don't like). I'm also waiting patiently to see how well Raven is going to handle the Doom3 engine for Quake4.

Re:I hope so

[kubrick]

When will Half-Life 2 be out, though? If they were originally targetting September last year, and had a feature set to match, it may look a little dated by the time this September rolls around, depending on what else is out there. Unless they take more time to add more features/better visuals... which can end up causing its own delays.

It's a little harder to gauge that with Doom 3, as IIRC id don't like to announce release dates far in advance.

Re:I hope so

[westlake]

Mindless destruction can be fun in small doses, but survival in Half-Life depended on careful management of your resources. For me, the most satisfying moments came in finding an economical solution to a problem, not in blasting everything that moved. I am not sure that Carmack understands what the "stealth" shooter has added to the genre.

Half-Life in the single player game stands out because of it's pace and story, the shrewd take it took on the first-person perspective pioneered in Wolfenstein and Doom, and the creation of an environment that had the look and feel of a real place rather than a tournament maze.

Re:I hope so

[Brewdles]

Often the best games running on an id engine were not made by id. It doesn't matter if Doom 3 isn't a good game itself, someone will license it because the fact is that id have experience in building and licensing engines. Isn't this really Valve's first engine, being that Half-Life was built on a modified Quake engine?

Re:I hope so

[shione]

*sniff* thanks for the nostagia. I loved playing the billiards after shooting down some hogs. :)

Re:I hope so

[KozmoStevnNaut]

I'll play it on a friends computer, then, since my 20GB Win2K partition is probably 'disappearing' soon.

The simple fact that Doom3 will run on Linux makes it much more likely that I will buy it instead of HL2.

Re:I hope so

[John Courtland]

You hit the nail on the head. I don't think it matters if id makes a great "game" anymore, just a great engine. They'll make so much licensing it out that it probably doesn't even matter if they sell a single copy of the original.

Famous misquote from the old Batman show

[Pike]

"Touch one hair on her head and I'll render you limb from limb!"

Re:Carmack (of ID software)

[Anonymous Coward]

And how exactly is rewriting your code to use new OpenGL extensions all that different from rewriting your code to use the newer version of DirectX? Its not, aside from the fact the extension docs are usually utterly horrible, and the DirectX docs are very good. I guess in your magical world you don't have to upgraded your video card to get new hardware features in OpenGL too. bah

OGL alone is not enough for gaming

[BigBuckHunter]

Hopefully, this will prompt more developers to join efforts to create a feature rich gaming framework for *nix. SDL is a great start, but lags behind DirectX in a number of ways. I look forward to seeing this 2.0 release breathe new life/blood into this area of development.

Thank you for your time,

BBH

Re:OGL alone is not enough for gaming

[System.out.println()]

My friend is working on a multipurpose game engine, with the ability to "plug in" different graphics managers - so you can have the beauty of DirectX 9 on your Windows version, and seamlessly switch to OpenGL when you port it to Mac OS.

Or should I say, when I port it to Mac OS, since that's my job. I wish I had the slightest idea how his engine worked... He has all sorts of complicated code that compiles fine on his x86, but is gcc-unfriendly. :-(

Re:OGL alone is not enough for gaming

[fforw]

Your friend's project sure sounds exciting. Now there will be nine hundred and ONE incomplete, poorly-written, multipurpose game engines on Freshmeat! Praise the Lord!

.. still bitter about yours ?

Re:OGL alone is not enough for gaming

[System.out.println()]

1) It's not on Freshmeat - it will be in-house.
2) He has $23,000 set away for starting a game company - the plan is to start a game company and have our first game on the market about the time we graduate college. Unrealistic dream? Maybe.
Also, you don't know my friend. He's not only a genius, but actually sticks to what he's creating until it's done... with the exception of when he learns a new trick that makes his program 10% more efficient... but yeah...

Re:OGL alone is not enough for gaming

[Shinobi]

Hey, that's no worse than many open source project that are GCC friendly.... But it's a fucking bitch to try and use any other compiler, because the dumb fucks have used GCC-specific code, and ignored the C and C++ standards. Linux is one such example.

Re:OGL alone is not enough for gaming

[westlake]

I am curious about what you mean by a "multipurpose game engine." Games are generally defined by genre, first-person shooter, role-playing, flight simuation, etc., and players tend to object to a one-size-fits-all solution.

Re:OGL alone is not enough for gaming

[Lord Omlette]

The reason DirectX dominates so thoroughly is because it's the complete package, but at the very least we (you, they, whatever) can start catching up in the sound arena w/ OpenAL.

Re:OGL alone is not enough for gaming

[System.out.println()]

Well it's designed to run any sort of game, and a number of different "plugins" (a C++ class inheriting from an abstract plugin class) allow specialization as the given genre demands. So far using this engine a lot of 2D games have been developed - a working DDR clone (albeit only with keyboard support and crummy graphics), a decent version of Asteroids (vector graphics, scrolling, camera zoom, camera rotation, minimap/radar, running at 60fps or better - Asteroids is the testbed for most of the engine's new toys), a Commander Keen-like platformer (bitmap-based graphics with camera rotation and hundreds of enemies on screen with virtually no slowdown), an ASCII shoot-em-up and a few others I can't think of off the top of my head. There's also a primitive vector-3D game (6-player Pong with 5 computers :)....) using the engine.

The core engine itself mainly contains only a few pieces that are common to most genres: graphics management (which is then passed off to a renderer of your choice), UI element handling, collision detection, and the like.

The engine also has built-in scripting and a console mode (where the game pauses and you can enter commands as if part of a script, which is very cool, and very useful for debugging - stuff like SET_X PLAYER 120... and yes the console can be disabled)

Re:OGL alone is not enough for gaming

[Shinobi]

Since those extensions aren't part of the ANSI C standards, and people use those, congrats, a standard was broken. If you had bothered to read correctly, I wasn't complaining about GCC and the crew behind it specifically, I was complaining about the idiots that use those specific non-standard extensions. Some of those idiots are the same people who complain about lack of adherence to standards...

Re:OGL alone is not enough for gaming

[BigBuckHunter]

I believe that SDL already provides low level access to an OS's sound system (whether it be Also, OSS, etc...)

Thank you for your time, BBH

Re:OGL alone is not enough for gaming

[macshit]

because the dumb fucks have used GCC-specific code, and ignored the C and C++ standards. Linux is one such example

Actually the linux source is pretty good about using gcc extensions only when necessary -- i.e., because the standard is lacking, not because they're "dumbfucks".

For instance, gcc's extended "asm" syntax (parameter passing, constraints) is extremely important for the sort of low-level code a kernel needs sometimes [and, no, moving all assembly code into separate files is not an adequate replacement -- it would result in both much worse performance (because the compiler couldn't optimize around it), and increased maintenance burden].

In cases where the standard has caught up with gcc, linux has moved to using the standard syntax (e.g., recent big changes like replacing gcc-specific structure field initialization syntax with the equivalent C99 syntax).

Re:OGL alone is not enough for gaming

[westlake]

I'd like to see an engine that combined the best elements of 2 and 3D from RPGs like Fallout and Lucas's Grim Fandango. Interiors in "true" 3D games can be wonderfully convincing, but out of doors the illusion of space and complexity is too easily lost. One tree is not a forest.

Re:OGL alone is not enough for gaming

[Shinobi]

Hmmm, compiler being unable to optimize around it if the code is in separate files is just a matter of how the compiler is written, especially since invoking an external assembler can be done without drawbacks too.

As for using it only when necessary for performance... That's quite hilarious, since there are lots of games, drivers etc that require lots of performance, are written in standard C, and compiled with ICC, Metrowerks, Visual C/C++ or Borland, and do not require such extensions.

Re:OGL alone is not enough for gaming

[macshit]

The point of using extended asm is not to write large chunks of stuff in assembly, it's to write very small chunks (often 1-2 instructions) that can't be represented using standard C -- e.g., special machine instructions that most compilers don't even know about -- and keep the interface between these little asm chunks and the surrounding C code as lightweight as possible. By having the ability to tell the compiler more about how a chunk of assembly code works (which is what extended asm does), it doesn't have to make pessimistic assumptions about it; unlike C code, most compilers can't analyze assembly code to see what properties it has.

BTW, ICC can compile linux these days, as they've added the necessary gcc extensions...

Re:OGL alone is not enough for gaming

[Shinobi]

That depends on the compiler itself, if the developers have chosen to implement the actual instructions.

You still need to tweak the kernel with some patches for it to work well enough. And yes, I tried it with ICC 8.0. However, it's an ugly klutch when you need to break standards-compliance to do so.

Re:OGL alone is not enough for gaming

[System.out.println()]

Well you could build such an engine off of my friend's engine. The problem, I think, is simply power: there's not enough power to create an outdoor environment with enough detail to create the "illusion of space" you describe. I think the best example I have seen of a game that did that was Smuggler's Run, and early PS2 game. The graphics were pretty amazing, and you could see for miles - it really did look like the great outdoors, and it ran at 60fps. If you've never seen it and are interested in a good-looking, wide-open outdoor environment, I'd recommend renting it or the sequel. (though not having played the sequel, I can't say if it was as good)

Re:OGL alone is not enough for gaming

[Too Much Noise]

As for using it only when necessary for performance... That's quite hilarious, since there are lots of games, drivers etc that require lots of performance, are written in standard C, and compiled with ICC, Metrowerks, Visual C/C++ or Borland, and do not require such extensions.

that's a broad statement - and you can't support it. Take drivers for instance - you need to do some low-level device access that can't be done in standard C (try to write something to a port in C; heck, even vector math in video drivers can't be done by standard C). And about the kernel, asm it's not always about performance - it's also about the cpu-dependent stuff. Standard C is by definition blind to this as it has to be cpu-agnostic.

Then again, maybe you meant 'hilarious' as a compliment ;-)

OpenGL 1.5

[PlatinumInitiate]

OpenGL is used in the Torque engine alongside Direct3D (D3D on Windows, OpenGL on Mac and Linux). It would be great if OpenGL could eclipse Direct3D, and become the premiere 3D platform once again. Perhaps we will see this with the release of OpenGL 2.0, but for a few years Direct3D has been slowly but surely catching up and then surpassing the aging OpenGL standard.

A lot of our customers demand Linux in their solutions (networked gaming terminals) to avoid the cost of licensing Windows XP Embedded for each machine, and the option so far has been to go the Mesa/OpenGL/SDL route (WineX is still too slow for what we do), which, while it has worked, is technically slightly inferior to our Windows equivalents. Hopefully OpenGL 2.0 will change this.

Re: OpenGL 1.5

[Black Parrot]

> OpenGL is used in the Torque engine alongside Direct3D (D3D on Windows, OpenGL on Mac and Linux).

How well do Torque-based games run on Linux?

Re: OpenGL 1.5

[PlatinumInitiate]

There are demos on the GarageGames website, some of them run on Linux, download a few for yourself and see. If your system meets all of the requirements (P2-500 or higher, 256M of RAM, NVidia TNT2 or higher, OpenGL/Mesa and SDL, the games that specify that they run on Linux will (as far as I've experienced) run without problems.

If you are talking about writing games yourself, it depends how you write the game. With the Torque engine, you get the source code for the engine itself and you basically do your own thing. If you add a lot of Windows-specific C++, you are just asking to have issues when you try and port it. If you write a game specifically for Linux, though, obviously, it will not be a problem. The best thing to do is download the Torque engine demo from the GarageGames site and give it a try, and if you like what you see, get the Indie developer license for the Torque engine source code ($100). The features that come with the engine make it a lucrative proposition - commercial quality games are possible (Tribes 2 uses the Torque engine, for example).

Re: OpenGL 1.5

[FuzzyBad-Mofo]

Tribes 2 for Linux runs quite well. Torque is a very powerful engine, allowing up to 88(?) players simultaneously, excellent network code, and dynamic terrian generation (there is no 'edge' of the map).

Re: OpenGL 1.5

[TypoNAM]

I am a licensed indie Torque owner and I have to say it is a very impressive game engine when it comes to cross platform game development. Not only does it run pretty smooth just like games such as Wolfenstein: ET and Tribes 2 (T2 was actually not really good on Linux compared to it on Windows) its source code is actually gcc friendly.

About Tribes 2, its Linux port wasn't very good and it choked from time to time for no real reason and Torque engine doesn't have this problem. The real history of Torque is that it came about right after Tribes 2 was released and GarageGames company was formed which are several former Dynamix Employees (even the founder is the founder of the company) working at GG. Torque Game Engine I have to say is far better than the old Tribes 2 engine (if you worked with Tribes 2 and then Torque you would know exactly what I mean by it).

Anyway the engine is pretty good in my opinion and as a note to those Quake lovers Torque doesn't do BSP structures for the whole map. It has a true terrain system that goes on forever and no it doesn't loop all the way around (but I've seen mods pull this off :). It uses BSP structures for what is called Interiors which are basically buildings and the GG community has been making great advances in the game engine for several years so it isn't something that will sit there and idle for months, it's always being worked on by several groups of people. So the whole game engine development is mainly driven by community resource submissions.

I guess I've talked my head off long enough and put several readers to sleep, sorry. Check out the site for yourself and maybe consider getting a license (please read the license agreement before forking over cash for it since I've seen many people ask questions about the license AFTER they bought it!)

Re: OpenGL 1.5

[13Echo]

Very well, actually.

If you check out http://www.garagegames.com you will see that almost all of the Torque-based software products have native Linux and Mac versions.

Try ThinkTanks. It's a pretty cool example.

Re:OpenGL 1.5

[Mithrandir]

OpenGL has not lagged behind D3D, they have targetted different markets. OpenGL sees itself as visualisation oriented and raw performance. D3D sees itself as a gaming API. Even at the lowest level, this means several significant differences in approaches taken to a given subject. For example OGL has had 3D texturing and accumulation buffers since almost the beginning of time, but D3D barely supports the equivalent functionality. Given OpenGL's focus, I can hardly see it ever being the preferred API for game development. Try to do a serious simulation application in D3D and you'll see the same situation, just in reverse.

Re:Carmack (of ID software)

[Dracolytch]

Mod parent down (Further)

There is no relationship between the release of graphics libararies and the requirement to purchase video cards.

~D

my interest fwiw

[rokzy]

I'm going to learn opengl in a few months during the holidays before I start my PhD. I work with simulations of the Sun and use IDL to visualise the results. but I think it would be cool to have more "realistic" pictures, plus having the hardware acceleration has benefits when dealing with a lot of data (IDL gets real slow for 2D simulations at resolutions above a few hundred squared)

these simulations are done on beowulf clusters (imagine that!) so I think opengl is the best (the only other API I know of being directx)

Re:my interest fwiw

[L7_]

you should check out celestia: an open source solar system visualization tool. it is avaliable at http://www.shatters.net/celestia

there is a windows installer if you are running that and don't want to be hassled with compilations, or you can download the source from cvs to compile either on your linux or windows machine

Re:my interest fwiw

[Laser Lou]

The APIs are fairly basic, but there is a lot of theory behind 3d rendering, and that definitely takes time to learn and master. Look at any book on 3d grapics in a bookstore, and you'll see. Without a firm knowledge of the theory, its difficult to use that APIs to make something substantial. I suggest you start learning that asap.

Re:my interest fwiw

[wass]

I've used IDL before, and I'd avoid doing any very intensive calculation on it (unless it was 'linkimage'd to an external C routine). Some of the specific IDL calculation routines are optimized (FFT for one), and i've FFT'd 64k arrays of floats, but that's about the limit.

Anyway, since you use IDL on a Beowulf I'm assuming they finally added multithreading. That's good, when I used it before my PhD (I'm doing condensed matter physics now, but used IDL at my research job prior to this) there was no multithreading in IDL, which was kind of annoying at the time.

IDL is good at visualization, and the interactive mode is really nice, but I would avoid using it directly for actual intensive calculations. But if you have alot of code written already, check out the external development guide, it's not that hard to link to external C programs. I did that to call low-level hardware IO routines, and run the high-level data-acquisition code from IDL w/ GUI and the niceness of IDL's display routines.

Re:my interest fwiw

[rokzy]

>Anyway, since you use IDL on a Beowulf I'm assuming they finally added multithreading.

maybe they have but the way I used it the sims were run on a beowulf, but then IDL only ran on a workstation to analyse the data afterwards.

Re:my interest fwiw

[Anonymous Coward]

Using OpenGL to visualise scientific results is, in some ways, "wrong". For visualising scientific results and such, I would recommend VTK (Visualisation Toolkit). OpenGL is just a graphics library, and visualising any results with it would usually mean transforming everything into geometric primitives before rendering - a lot of work, in other words. VTK uses OpenGL for rendering, but also contains many functions for extracting, transforming and doing calculations on the data.

The functionality of VTK is closer to IDL, and uses OpenGL as the rendering subsystem. Very interesting, and widely used...

Re:my interest fwiw

[rokzy]

thanks for the info.

I probably wasn't clear, but I don't intend to use OpenGL for actual analysis, just for the pretty pictures and movies afterwards ;-)

I'll check out VTK

Re:article text

[Funk_dat69]

Many developers, however, believe Java 3D is at too low a level.

Say what?
You don't get much higher-level than a scenegraph API like Java3D.

I think the author may have been confused, although he did get the overall point right. OpenGL ES on J2ME will probably be the way this goes.

OpenGL 2

[woodhouse]

OpenGL 2.0 is not as exciting as the new major version number might indicate. Probably the most important new feature of OpenGL 2.0 was going to be the GLSL high level shader language. However, in order to speed up its support by hardware companies, this was instead put into OpenGL 1.5 spec when it was announced last year; GLSL already has implementations by 3DLabs, ATi and nVidia. OpenGL 2.0 will still add some useful new features, but it won't be the world-shattering event that 3DLabs promised in their original proposals.

Re:OpenGL 2

[woodhouse]

You're splitting hairs. The entire of OpenGL 1.5 is ARB extensions. There are no new "core" features in OpenGL 1.5, however cards can only be said to support OpenGL 1.5 if they support the ARB extensions.

BTW, have you actually programmed for ATi's GLSL implementation lately? It's improved a lot over the last few months, and it's very usable at this point. I can't give details due to an NDA, but expect ATi's implementation to be at 1.0 very soon.

Re:OpenGL 2

[Saville]

For 1.5 VBOs were promoted to core from extensions, but you don't need to support GLSL in order to support OpenGL 1.5 because it was left as an extension.

Re:OpenGL 2

[jra101]

The OpenGL Shading Language extensions (ARB_shader_objects, ARB_vertex_shader, ARB_fragment_shader, ARB_shading_language_100) are NOT part of OpenGL 1.5. An implementation can advertise OpenGL 1.5 support without any of these extensions.

They will be added to OpenGL 2.0.

Re:OpenGL 2

[jafuser]

I hope they take into consideration some of the plans that are being put into place for DirectX 10 (aka Directx Next). According to this article, it looks like there are going to be a lot of fundamental changes to the underlying architecture in DirectX 10.

I'm not knowledgeable enough to be an advocate of either DirectX or OpenGL, but it would seem like some really *neat* stuff should be possible with the changes mentioned in that article.

Re:OpenGL 2

[_|()|\|]

Probably the most important new feature of OpenGL 2.0 was going to be the GLSL high level shader language.

GLSL is clearly OpenGL 2.0's killer feature. Check out the GLSL section of 3Dlab's site for some resources. The slide show from Randi Rost's book tour are on-line as a 9 MB PDF. Before too long, you should be able to download RenderMonkey, a cool tool for playing with GLSL and D3D shaders.

Unfortunately, NVIDIA's GLSL implementation has a ways to go. You won't even get the necessary ARB extensions unless you set a debug registry flag (google "ShaderObjects"). After that, good luck.

I'm anxious to see how the industry receives GLSL. Will we get some decent drivers before Doom 4?

Re:Pixlet

[PurdueGraphicsMan]

When the article talks about rendering in real-time it isn't talking about the compressed/flattened video playing a full frame rate, it's talking about OpenGL being able to calculate/shade/render a model in realtime verses waiting X mins/hours for a frame to render. It's talking about the process of converting vector data to raster data.

Re:OpenGL is Dead

[the_demiurge]

Yes, DirectX runs on those 90% running Windows.
So does OpenGL, and OpenGL can and does run on other platforms too. 95% is a larger percentage than 90%.

Re:Pixlet

[Anonymous Coward]

omfg.

so if something uses the word "rendering" in it, it's on topic.

3d rendering is one thing.

video rendering is something completely different.

they are as different as me "rendering" something in charcoal on a napkin.

but hey..if yelling at moderators gets you points...don't let me stand in your way.

Re:OpenGL is Dead

[Damek]

...Microsoft rules. They really are the most innovative and resilient software companies in the world.

So you acknowledge that they should be broken up into multiple companies? Groovy!

Re:Pixlet

[Anonymous Coward]

-1 Factually incorrect.
You may want to look up the definition of "rendering" ("The process of creating an image (on the screen or some other medium) of a model".
Pixlet has nothing to do with rendering except as a working format for the already rendered images. The article is talking about OpenGL, a 3D API, which is suitable for rendering, not about what happens with the rendered pictures (which could be compression with pixlet).

Re:article text

[Mongoose]

I'm glad this guy is an EE, since he doesn't seem to know wtf he's talking about in _software_ engineering terms. You can't compare DirectX and OpenGL. He's trying to say D3D is a better solution just because it's bundled with DirectX which is tied to Microsoft's IDE. If you want to only do WIN32 development, then sure DX is fine. However consider there is only one game console that uses D3D, and we all know how big a market share it has. Sure not all Playstation 2 titles use an OpenGL based engine, but many do. Where as all gamecube titles use nGL on ATI GPUs. Also if you want to bother to port your application to Linux or Mac OS you must use OpenGL. ( 64bit platforms are nice for addressing more memory for those models. Would you rather run Maya for example with more or less memory? )

I'm so sick of DX vs GL for PCs over the years too. They don't do the same thing. This is why Sam started SDL, and several vendors are making similar frameworks. I admit OGL doesn't support all the wiz, bang features in core. However if you really want performance, then using the vendor EXT ( extentions ) are the only way to go anyhow.

On a related note..

[rkaa]

Jan 16th 2002: SGI transfers 3D graphics patents to MS
Jul 09th 2002: Microsoft Claims IP Rights on Portions of OpenGL
Jul 11th 2002: 3D graphics world shaken by patent claims
Jul 13th 2002: Microsoft patent claims may affect OpenGL
Mar 3rd 2003: Microsoft quits OpenGL board

Re:On a related note..

[pragma_x]

It never ceases to amaze me at how systematic Microsoft is at dismantling, buying, litigating or outright squashing its competition. The question is: will the actions the parent posted have any effect on this rendition of OGL?

Re:OpenGL is Dead

[ImpTech]

Whether you care about that last 5% or not, it still exists, and combined with the Windows 90% (to which OpenGL is most definitely available) you get 95% availability for OpenGL versus 90% availability for Direct3D. See, even with your faulty made-up numbers, OpenGL still comes out on top.

Wait for the OpenGL hardware

[metalmario]

The current handheld devices are not suitable for 2D/3D graphics, because their memory bandwidth is so poor that texturemapping will make the software crawl. I'd get excited when the mobile devices get real 3D hardware acceleration. Even a 400MHz XScale doesn't cut the mustard if it spends its time waiting for the memory. Have been using OpenGL ES for over six months now...

Re:Carmack (of ID software)

[woodhouse]

Actually that's not true. Currently new video cards have to support the features the latest version of DirectX (or more specifically Direct3D) if they want to be called DirectX 9.0 video cards. Because of the way Microsoft specifies the requirements and hardware vendors have to meet them, new releases of DirectX very much dictate the type of video card you need if you want to play the latest games.

New releases of OpenGL also require new video cards. If you want to play a game that requires OpenGL 1.4 or 1.5 then you'd better have an ATi 9500 or better. ARB_fragment_program, ARB_vertex_program and the new GLSL extensions aren't supported on anything older.

Java on top of OpenGL is happening...

[tommck]

My cousin's husband works for Sun and he said that the next version (1.5?) of Java will have Swing ported to OpenGL underpinnings... that way, even 2D apps will be MUCH faster.

He said they're realizing 4X speed increases on plain old 2D apps.

They're also working on making 3D game demos (some with 3rd parties) to demo that Java can actually now compete in the desktop game market...

Re:Java on top of OpenGL is happening...

[dasmegabyte]

Java and OGL would be an incredible combo. Basically, it's be .NET, only crossplatform and without the kludge of Mono's reliance on Wine for P/Invoke. And without C# (shame there, C# is the bomb, but who knows...maybe it can be compiled for the JVM!).

Re:Java on top of OpenGL is happening...

[dasmegabyte]

Well, C# has many things I like a lot: delegates, properties, the ability to ignore exceptions (hey, i'm lazy, and i often want exceptions thrown all the way back to the original caller without having to declare each intermediate method's throw signature) and an assembly based approach to file layouts (as opposed to one class per file, which is nice for bookkeeping but sometimes an inefficient way to code when you need a three line helper class or something). Some of those -- okay, just delegates -- are a limitation of the JVM.

Delegates, BTW, are awesome. They're about as close to functional programming as we desktop programmers are going to get!

Re:Java on top of OpenGL is happening...

[Mithrandir]

You may want to have a look at JSR-231 then, which is the official bindings of OGL in Java. If you need something more immediate, the JOGL project, which is the baseline for the JSR, should be checked out. It can be found on the java.net site.

Re:Java on top of OpenGL is happening...

[Lord Omlette]

Java3D was a fucking nightmare to use, I'm glad they're finally getting w/ the program and beefing it up ^^v

Re:Java on top of OpenGL is happening...

[noselasd]

Hold it..
Faster ? Yes, if one have installed the OpenGL drivers for the specific cards you
have. Many cards (on Linux) doesn't have hw accelerated drivers, and we are stuck with Mesa.
Which means software rendering.
Which means slow as hell.

Re:Java on top of OpenGL is happening...

[UserGoogol]

And of course, there's MLDonkey too.

Re:Java on top of OpenGL is happening...

[joib]

It's not like you can't have unchecked exceptions in Java too. All exception classes that extend RuntimeException are unchecked. I use them a lot, and I agree it's very nice to avoid cluttering the code with throw/try/catch stuff.

Re:Java on top of OpenGL is happening...

[tommck]

Yeah, but that's not Java's problem, it's yours :) Just like when I was a big advocate of OS/2 in the early days, you're going to have to buy the hardware for the OS for a while...

Re:Java on top of OpenGL is happening...

[willdenniss]

hey, i'm lazy, and i often want exceptions thrown all the way back to the original caller without having to declare each intermediate method's throw signature

easy - just wrap them in a RuntimeException (or if you are throwing your own - throw RuntimeExceptions or extensions of that class). Will.

Re:Carmack (of ID software)

[sbaker]

There is no relationship between the release of graphics libararies and the requirement to purchase video cards.

That's technically true, but useless information. There IS a strong relationship between the release of graphics libraries THAT YOU'D ACTUALLY LIKE TO USE - and the requirement to purchase video cards that are capable of running them.

You aren't going to be able to run GLSL (a crucial part of OpenGL 2.0) at anything like realtime rates without a graphics card that's less than a year old.

It is no longer the case that the graphics cards are chasing the graphics standards. The reality is that one or other of the two remaining 'mainstream' graphics card vendors comes out with a feature - and that feature is immediately added to the two remaining 'mainstream' graphics API's.

Re:OpenGL is Dead

[Anonymous Coward]

you must be new around here.

It's not "OpenGL is Dead"

Teh corretc way:

"Netcraft confirms: OpenGL is Dying"

then you put something like "suXXors!!!111" on the end of it.

sheesh.

gl pipeline not for raytracing

[nuttyprofessor]

Most frames in Pixar movies are rendered using some form of ray-tracing. While it is possible to use vertex and fragment shaders in uncoventional ways to do ray tracing, this is *not* what the OpenGL pipeline is designed for. Great for games, but ray-tracing will still be done using render farms (and not in real time).

Re:gl pipeline not for raytracing

[One Louder]

Uh, no. Pixar movies typically use the REYES micropolygon algorithm, with some assists from raytracing for certain effects as necessary, implemented within their Photorealistic Renderman (PRMan) product.

The notion that Pixar would use OpenGL for final rendering if only it were fast enough comes up every time a new video card or GL enhancement comes along just indicates how little people understand how Pixar actually makes their films. Oddly, Pixar really doesn't make this information much of a secret, and they'll even sell you the same software they use.

Re:gl pipeline not for raytracing

[Saville]

I thought most renderman stuff was rendered, not raytraced?

I'm sure you've seen the raytracing OpenGL examples such as nVidia's

The OpenGL 1.0 pipeline is great for games, CAD, etc. The future of OpenGL is basically "here is a really powerful parallel processor (AKA pixel shader) and some memory (AKA textures), go use/abuse this in anyway you like."

There are a lot of people working on General Purpose ways to program the GPU/VPU such as BrookGPU. Moving forward graphics chips look less like old style OpenGL where the chip is hardwired to support up to 8 lights, gouraud shading, and a texture, and more like a giant processing farm that will be good at certain tasks (render farm) and worse at others (compile farm). I belive raytracing will be one of the tasks future GPU/VPUs are good at.

Re:gl pipeline not for raytracing

[Moonbird]

Not quite. REYES is like a distant relative, but not quite a scanline algorithm.

Re:gl pipeline not for raytracing

[kmo]

Most frames in Pixar movies are rendered using some form of ray-tracing.

Technically, no. Renderman (the Pixar renderer) does not perform ray tracing. It uses a scanline renderer that is much faster than any ray tracer I've ever seen. They've been at this for literally decades, and are very good at it. Still, the most complex images in their movies can take many hours -- sometimes more than a day -- to render. The time-to-render doesn't seem to improve much from picture to picture because as computers get faster, they just add complexity to the scene.

Re:gl pipeline not for raytracing

[Anonymous Coward]

Tradtitionally, Pixar moves has absolutely no raytracing in them. Most of the movies have no need for them, as raytracing is mainly useful for non diffuse surfaces, which there are very few of in Pixar movies. They have however been struggling with adding some raytracing features into their renderer, and I believe there was some in Finding Nemo. Mostly likely there was some raytracing in the lighting calculation, in combination with the traditional REYES renderer.

Re:gl pipeline not for raytracing

[danlyke]

Just to be completely pedantic, I know that A Bug's Life had some raytraced shots. Larry Gritz kludged together something that let BMRT handle the pixels in the glass bits in, I think that giant jar that had all of the grain in it in Hopper's hideout.

It's been a while and I don't remember all of the details, and I'm not sure what else has been done ray-tracing wise since I left there.

But yeah, in general smart use of reflection maps is more reasonable than ray tracing for that sort of application.

Re:gl pipeline not for raytracing

[Viking Coder]

Peercy and Olano (Click on "PDF" in the upper right)

Presentation

ASHLI

GPGPU

More than Moore's Law

Moore's law : still for wimps

Using programmable graphics hardware (possibly through OpenGL) for final rendering is not that far off. (Definitely not in real-time, but as a more cost-effective way to do it, anyway.) Especially with the massive parallelism of rendering, and the fact that GPUs are far outpacing CPUs in terms of their speed and transistor counts.

OpenGL is much more similar to micropolygon rendering (REYES) than it is to raytracing in the first place. The shaders are where you spend all of your time, anyway.

Heck, do you think nVIDIA bought ExLuna (Larry Gritz, author of BMRT, and former Pixar employee) just for the fun of it?

Software for translating from RenderMan Shading Language to Cg?

And what about RenderMonkey supporting RenderMan?

Do you even remember PixelFlow from Pixar? Do you see the name Marc Olano on that paper? The same Marc Olano who talks about rendering on consumer-level graphics hardware? These things have far more in common than you seem to realize.

Re:gl pipeline not for raytracing

[cr0sh]

Interesting - is this REYES micropolygon algorithm in any way related to the old (late 80's?) computer graphic entitled "Road to Point Reyes" (I think that is right)?

I remember seeing an image of that in an old computer graphics "coffee table"-type book back in high school - and you mentioning that popped it in my head...

Re:gl pipeline not for raytracing

[One Louder]

Yes - that image was used as an example in the original paper describing the REYES algorithm.

Re:gl pipeline not for raytracing

[malducin]

Rendering is just a generic term. It just means transforming some scene description into an image. There are countless rendering methods: raytracing, radiosity, scanline, REYES, Metropolis, hybrids and stuff like photon mapping, etc.

RenderMan, strictly speaking is just a standard (for scene description). Pixar's implementation, Photorealistic RenderMan or PRMan for the most part has used the REYES architecture, hich doesn't use raytracing.

Re:gl pipeline not for raytracing

[greeneggs2000]

They'll sell it to you maybe several years later. E.g. Monsters Inc deep shadows.

Re:gl pipeline not for raytracing

[Pseudonym]

Not true. PRMan added raytracing support to PRMan 11, and it was used in Finding Nemo, mostly for the underwater volume caustics.

Most of the effects that "look" raytraced (the fish tank, the bags, reflections etc) were, of course, done with scanline rendering with various mapping tricks. Ray tracing is definitely in there, though.

Re:gl pipeline not for raytracing

[cr0sh]

Cool! Now, where would one find a full scale rendering (wasn't it 4096 x 4096? - don't know the bit depth)...

Re:Pixlet

[dasmegabyte]

Unless I'm missing something in your post.

Nope. He's just another tech wiseass who prizes seeming smart over being accurate.

ABOUT DAMN TIME!

[DurendalMac]

OpenGL has been languishing for years. It's about freaking time they gave the spec a nice big update. I'm a mac guy, but I have to admit that DirectX has a much better level of optimization than OpenGL does. Hopefully this new spec will make it's way into Mac OS 10.4 and give Macs a much needed boost in the graphics arena.

Re:ABOUT DAMN TIME!

[Saville]

Give me examples of what you're missing in OpenGL 1.5 that you get in D3D or how D3D is optimized more than OpenGL.

Don't say something like programmable graphics? OpenGL introduced fragment programs to take advantage of PS2.0 hardware (Radeon 9500+, GeForceFX+) before MS released DirectX 9.

Just because OpenGL started with a great base and has evolved up to version 1.5 doesn't mean it is worse than another API which is at version 9...

Troll?

Re:ABOUT DAMN TIME!

[be-fan]

1) Its Apple's implementation of GL that's less than perfectly optimized. On Windows and Linux, OpenGL is as fast as D3D.

2) OpenGL has numerous releases in the last few years. 1.3, 1.4, and 1.5 were all released in quick succession. What rock have you been hiding under?

Ahem...

[dustman]

No longer vapor, but a true 3D-embedded engine...

Since when has OpenGL been vapor?

Re:Ahem...

[ScottGant]

Really, I was wondering this myself. I mean, I've been playing OpenGL games for years now.

In the article they kind of say what they mean, but the headline in the Slashdot article makes it seem like OpenGL is FINALLY being released and is no longer vapor.

Me got cornfused....

Re:Ahem...

[be-fan]

They mean OpenGL ES.

Can we get X-ray vision too?

[cookie_cutter]

Seriously, your suggestion just gave me an idea: if your 3d image enabled cell phone has centimeter resolution positioning information (not easy, I know), then you could use the screen as a "magic window" to see things that aren't physically there.

Which could be your target as a glowing orb, or a character in of a video game super-imposed on the actual landscape, or the trail your friend took through the same city two years ago, or just some construct representing an interesting thing about your environment, or ...

I think that would be a real killer app.

Re:Can we get X-ray vision too?

[blackpaw]

You could actually be on to something there - sounds damn fun, first actually useful idea for games on a cellphone I've heard

To extend it - I'd rather have it as virtual environment googles or helmet with surround sound that you could use to overlay virtual object (trolls ? the aforementioned orb) on the real world - sort of a VR HUD, that would be cool.

Imagine the fun you could RPG'ing in an empty carpark building with that.

Time for someone to mention porn now ...

To my understanding...

[mark-t]

Direct3d has a few advantages over OpenGL that can't really be addressed by OpenGL.

For one, direct3d is integrated into the direct api which handles a multitude of things, multimedia and game input devices among others, that game developers are almost naturally drawn to by the appeal that so much work has already been done for them

OpenGL can't and really shouldn't have to address all these requirements, but it's just part of why there's been this ongoing struggle. SDL is a reasonable answer to portability while still accomplishing the integration that MS has achieved, but SDL isn't really as mainstream as OpenGL is.

I've seen soap opera plots that were less convoluted than this mess.

Re:To my understanding...

[omicronish]

From coding experience the integration is pretty much non-existent or not very strong. APIs such as Direct3D and DirectSound have consistent API styles, but they don't share much API. It is possible to write an OpenGL application that uses DirectSound and DirectInput, like GLQuake.

Re:To my understanding...

[flacco]

I've seen soap opera plots that were less convoluted than this mess.

given that soap opera plots are targeted at lobotomized cows barely aware enough to sign their name on a credit card application, that's not saying much...

Re:To my understanding...

[WilyCoder]

Who says you can't write the graphics engine in OpenGL, and all the other modules(music,netcode,etc) with DirectX ???

Re:To my understanding...

[mark-t]

Nobody... but directx isn't portable... and if you're not going to bother with being portable, why worry about using OpenGL?

Re:To my understanding...

[hawkstone]

> SDL is a reasonable answer to portability while still accomplishing the integration that MS has achieved, but SDL isn't really as mainstream as OpenGL is.

SDL and OpenGL are not mutually exclusive. I have very successfully used SDL to handle joystick input, window creation, and sound output, with OpenGL for 3D. SDL in fact is designed to work this way, since SDL will create OpenGL rendering contexts for you when you create windows, and it handles the fullscreen video modes far easier than any other method of creating OpenGL contexts that I have used.

And just for comparison: I ported a DirectX/3D game from windows to SDL/OpenGL on Linux, and cut out about 1000 lines of code in the process because the DirectX API is so ugly. (I realize that might imply DirectX is more powerful, and I also realize my abhorrence of the MS DX API may be simply personal preference, and to boot, this was a DX5 program, so the API may be simpler now. I'm just relating the facts as I found them.)

Oh, and wasn't SDL used by Loki quite often for porting games to Linux?

Re:To my understanding...

[Darth]

Oh, and wasn't SDL used by Loki quite often for porting games to Linux?

if i recall correctly, SDL was originally developed by a guy who worked at Loki.

Re:To my understanding...

[WilyCoder]

As far as desktop 3d programs, I find that OpenGL simply produces a better visual quality than DirectX. Guess I am just picky like that :/

Re:To my understanding...

[noselasd]

Uhm,, because the D3D API plainly sucks ?
Really. There are many reasons, personal preference,
more OpenGL experience. Favor C over C++ etc.

The real alternative is SDL for portability, handling input, windowing and other small things, OpenGL(ofcourse) for the grahics, and OpenAL for sound.

Re:To my understanding...

[abdulla]

We have OpenAL to address audio, we just need a good cross platform input library (SDL has a lot of problems in that way), but I guess that ties in heavily with window binding and creation that should also be abstracted in to a library. I guess GLUT fills this description but not many people seem to take it seriously. Everything else is basically standard interfaces that you can easily create a wrapper for.

Re:To my understanding...

[Tough Love]

if i recall correctly, SDL was originally developed by a guy who worked at Loki.

Actually, Loki hired the guy who developed SDL.

Thank you so much!

[MachineShedFred]

I really love it when shills post things like this. Can we please see some documented facts to back any of this up?

Innovative? They didn't do jack with 3D until OpenGL came along and showed them how. They had to buy it from SGI. This has been documented.

Resilient? Dictionary.com defines this as "Marked by the ability to recover readily, as from misfortune." This is actually true, as they were behind, and had to play catch-up. 10 years later, they have caught up with (and arguably surpassed) a technology that has changed very little. Until now.

If this is what defines one who "rules," I'd rather that MSFT "rules" while other companies and organizations just make better stuff.

Re:Thank you so much!

[Geoffreyerffoeg]

Microsoft indeed rules...with an iron fist. The rest of the industry cowers in terror under the tyranny.

OpenGL | ES is not OpenGL

[Performer Guy]

The original article post seems to confuse different forms of OpenGL. OpenGL|ES is the embeded stripped down OpenGL for mobile & embeded systems. OpenGL 2.0 is just a proposal from 3DLabs and may never get off the drawing board. Most of the significant changes that OpenGL 2.0 introduced have been implemented and released either as extensions or as part of OpenGL 1.5, so it's just not clear if or when OpenGL 2.0 will actually arrive, there's a lot of resistance because 2.0 intended to throw some stuff out and many developing, selling & using OpenGL implementations think that it's a REALLY bad idea to do that. With OpenGL|ES there is already a version 1.0 and you can actually get this in several forms from implementations that run on phones to wrappers around OpenGL that you can use on the desktop to emulate OpenGL|ES. OpenGL|ES is in the process of developing version 1.1 right now.

Re:OpenGL | ES is not OpenGL

[Saville]

There is a thread talking about OpenGL 2.0 going on right now. Basically the 3Dlabs proposal of a 2.0 which could be backwards compatible or pure was ditched and they're just going forward one step at a time. I guess OpenGL|ES can be thought of as the pure OpenGL 2.0 in some ways :)

Re:OpenGL | ES is not OpenGL

[Performer Guy]

No! Your last remark is wrong.

OpenGL|ES is ****NOT**** OpenGL.

OpenGL|ES is a * very stripped down* OpenGL for mobile and embeded applications, with a few additions for fixed point support. It in no way shape or form represents OpenGL 2.0 or any itteration of mainstream OpenGL which is still going strong.

It's long been understood that most of the 2.0 functionality was in 1.5 or earlier and the need for 2.0 has gone away except to deprecate older stuff, and many people don't want that to happen.

So yes OpenGL 2.0 is pretty much gone, but not because it's features are dead, just the concept of a 2.0 release is gone. OpenGL 1.5 is here and the next version will be 1.6, the next version of OpenGL|ES will be 1.1, they are different specifications.

Cell Phones?

[muonzoo]

" Khronos is now in charge of further extending OpenGL to cellphones and ..."

Why oh why, for the love of a higher reasoning! Doesn't any one make a Simple, Small, Functional mobile phone?!

I don't WANT fancy crap in my phone. I want it to WORK. Good RF, Bluetooth, Multi-band radio (global GSM), EDGE, long battery life and iSync support.
Where is _my_ phone?

Re:Cell Phones?

[Anonymous Coward]

Your phone is where the money isn't.

Re:Cell Phones?

[dodobh]

Thats fancy to me. My phone needs to do voice, and Short Messaging Services (texting for those in the US). I have one which does exactly that.
I need one with a better battery life though. Triband would be nice, but is not a must.
Simple and functional.

Re:Cell Phones?

[obirt]

Better yet, where is an updated StarTac?

Re:OpenGL is Dead

[zhenlin]

Innovative? I'd say no. (Except in terms of business.)

Resilient? Maybe. Then again, the world of PC practically revolves around Microsoft, so they don't really have much change to deal with.

Direct-compile model looks dangerous

[DLPierson]

The article says that the programmable features will be based the direct-compile model in which the compiler will be included as part of the driver.

Given the current less than good state of open source drivers for graphics chips this may well mean that most of the useful (i.e. works with your hardware) compilers may only be available in the Linux world as part of tainted binary drivers. It seems pretty likely that vendors who believe that their current drivers contain deep secrets than open source would reveal to their competition will be even more convinced of deep secrets of their compiler technology.

Not good news :-(

Re:Direct-compile model looks dangerous

[Screaming Lunatic]

FUD. Offtopic. Flamebait. Why does every discussion remotely related to graphics have to deteriorate into closed versus open source drivers zeolotry.

Drivers are closed source now. Drivers will continue to be closed source in the future in spite of where the compiler lies. Having the compiler in the driver is the right decision.

Don't like it. 3DLabs released the front end to their compiler. There is work being done in Mesa to support GLSL.

From now on, all bitching about open versus closed drivers will be modded as offtopic. Everyone knows the pros/cons and reasons for either decision. No need to drive it into the ground.

Re:Direct-compile model looks dangerous

[fm6]

You're simply stereotyping somebody who disagrees with you as an OS zealot. Yeah, there are lots of those, but you can have an intelligent opinion about the effect of closing source without getting religious about it. And this guy didn't.

Definition of optimism

[UpnAtom]

In markets where Microsoft is truly inferior, they dominate. What chance has OpenGL in the games market where DirectX is actually superior?

Re:Definition of optimism

[Brewdles]

Superior in what way, precisely? I know DX includes sound, input, network, etc. but the comparison here is between OpenGL and Direct3D.
Direct3D forces video cards into a certain mould. Direct3D 9 may be a nice spec, but it means that a video card maker can't add functionality beyond that and have it used through D3D.
OpenGL's extension system allows card makers to add new features and it means that developers can use these features as soon as drivers are available, not whenever MS feels like releasing a new revision of D3D. Granted this system means developers may have to do vendor-specific paths until the extension becomes core, but it's there if they want it.
Also, I don't believe that D3D has a driver conformance test; you don't really know what you're going to get on different system setups until you try them. OpenGL's conformance test may not be perfect, but it at least helps to even out the differences between systems.

How exactly is Java3D "low level"?

[Anonymous Coward]

The complaint made about Java3D, and why Java-OpenGL bindings like JOGL or GL4Java even *exist*, is that Java3D is too *high* level. It's a scenegraph API, not a low-level graphics API. Is OpenGL ES a similar thing? I had presumed that if it's aimed for the embedded market, ES would be pretty low level. Thus how in the world can ES be considered "higher level" than Java3D?

Re:How exactly is Java3D "low level"?

[Animats]

Actually, Java 3D (which never really worked) was too low-level in some respects. Not enough for a game engine, too much for a graphics API.

The collision detection primitives, to give an example I know something about, were badly chosen. There are ways to do collision detection very efficiently, but not using Java 3D's collision primitives.

Mobile phones with more power than a Dreamcast

[Saville]

2004 will see the first handheld devices using the same 3D technology that powered the Dreamcast gaming console.

Of course nVidia and ATI and others are also going to release 3d for mobile phones.

In the last video game generation people were shocked at the unbeliveable power the consoles had. The n64 featured an advanced 64bit 100MHz MIPS RS4?00 chip with SGI level 3d graphics designed by SGI for $200. Only a few years before that a slower 32bit 33Mhz MIPS 3000 chip with worse graphics would've cost many thousands of dollars. Just wait a couple years and we'll have $20 watches with gigs of memory to replace our iPods and more power than the xbox ;)

Real time films? Not any time soon.

[Anubis333]

As TD who works in the computer graphics field, let me state that the technology required to render a Pixar film in 'Real Time' is far off and ridiculous. Just because OpenGL looks better does not mean that it can support the shader functions that Renderman utilizes, not to mention the Fur and cloth APIs. Also, the majority of shots in movies aren't even single comp shots they involve many rendered elements, which you still have to comp together. I'd be all for the guy talking about how OpenGL 2.0 will benefit the artists by allowing them to get more feedback about the quality of the shot they're working on without preview renders, but thinking that OGL could replace final renders any time soon is wrong. Perhaps we are geting to a place where we could render the original Toy Story realtime and a general viewing audience might not know the difference. Perhaps. But I remember some really great PRman shaders from the film that wouldn't be posible in the real time version.

Re:Real time films? Not any time soon.

[Jackie_Chan_Fan]

This is exactly what i was thinking while reading all of this.

I'm a 3d Character Animator, and TD myself and found it interesting that no one really had brought any insight to this. I'm glad you did. Its all PR bullshit. The truth is... Pixar, or any other film quality 3d rendered artwork requires a lot more processing than any current gen realtime shading language can supply.

Not only things like fur, which you had mentioned... General image quality issues, complex shaders, raytracing, etc.

Whats MORE true.. and quite a posibility is that realtime cards may aid in rendering things like ambient occlusion passes and so forth. Nvidia seems to be demo'ing a bit of this right now. Hell if i could generate an ambient occlusion render pass off a quadro based card, or even better an FX card... excellent.

But its simply not reasonable to expect film quality renders anytime soon. Renderers like Mental Ray can use your Open GL supported accelerator to generate shadow maps and such... but really the complex shaders, and extremely accurate quality that is required just cant be done realtime. But we may get to the point soon where somethings can be handed off to the accelerator card.

But it wont be real time. That you can bet your donkey on. The polycount and texture map data require far more ram than any hardware accelerator has.

The sheer size of scenes (ram required), shader complexity/diversity, image quality issues, and of course your general advancements in techniques and new ideas... simply make depending on a 3d accelerator not realistic.

But like i said.. It may be possible to render a nice Ambient occlusion pass on these 3d cards... and that in itself is very welcomed.

Re:OpenGL is Dead

[alan_dershowitz]

It's not about platform availability, its about game availability. Most 3D games on PC are directx only, or prefer it. So out of the 90 percent PC market, say 100% use directx, and 60-80% use OpenGL.

By the time you figure in that most games come out on the PC and most games use only directx, DirectX does come out on top. It's an unfortunate fact that the PC gaming induxstry can completely ignore non-wintel platforms entirely and still be successful.

Re:Real time films? Sooner than you realize!

[Saville]

Actually ATI has given us Ashli which will compile renderman shaders to something that can be used real time. I'm sure you remember Final Fantasy: The Spirits Within running on a GeForce3. We've come a long way since then and in a couple years we're going to be a long way from where we are today. Sure, if you compile an advanced enough renderman shader you'll choke a wimpy ATI Radeon 9800XT (hahaha, the fastest pixel shading card on the market today), or if you tried to do a toy story scene it really won't be real time, but it'll still be faster than your CPU which will take hours or days.

In a just a couple generations Pixar will use render farms of GPUs on the PCI Express bus and the CPU won't matter. In a couple years high end video games will look just as good to the eyes of many people as movies like Shrek.

And my roommate claimed...

[stealth.c]

OpenGL was dying.

I guess he based that on the fact that the transition from Half-Life to Unreal Tournament was a transition from OpenGL to D3D. Whatever. DirectX can bite me. OpenGL has fucking PIXAR working on it.

Re:Real time films? Sooner than you realize!

[Anubis333]

The key here is: 'something that can be used real time.', it's not a PRman implimentation, it is merely a front end to give the artist some visual feedback as to the prman shader on the object. It renders and changes a UV baked raster image of the shader.

As for the Final Fantasy thing. I saw that at siggraph running on SMP PS2's. It's 'alright', but it didn't look a whole lot like the film, it looked like an OGL render of the film.

What you aren't understanding are the fundamental differences between scan line renderers, ray trace renderers, and real-time technology. Real-time can only 'fake' ray tracing, and it's not very accurate or good. Like I said, we are a long way off.

And don't jump up and down, some people have real-time SSS, radiosity, and raytrace demos, but they are very crude, and a long way off.

And sure, you can tweak a movie scene down to get it to look good and run on a next gen card when presented on a vid online or TV, but we're talking about film.

There's more than graphics...

[Handpaper]

Am I the only person who thought that:
"Over the next year or two, I think you're going to see a whole range of applications that use your graphics board as a supercomputer," Trevett says enthusiastically.
was the most interesting part of the article?
SETI@home, Finite Element Analysis, video recoding are all areas which could benefit from vector processing , matrix calculation and/or huge register sizes provided by GPUs.

Re:OpenGL closed source?

[rkaa]

Umm.. "Open" as in "Sorry, no Beer: We're Closed" ?

Isn't "Mesa" the (or "the major") Open-Source interpretation of it?

Re:Carmack (of ID software)

[Dracolytch]

This is actually one of the wonders of the way 3d cards are structured. Different graphics cards have different capabilities... Say you buy a card that's DirectX 8 compatible, and bump-mapping comes out in DirectX 9...

You computer must have DirectX 9 library installed, so it knows what to do with the bump mapping instructions, and send the right signals to your card.

The card, on the other hand, is still DirectX 8. Your computer will never send the bump-mapping commands to the card, because it knows the capabilities of the card.

So long as your computer has the right library, it knows what commands it can, and cannot, send to the 3d card. So, while the game requires DirectX 9, you can run it on a DirectX 8 card... You just won't get all of the latest bells and whistles.

It is possible to write software to quit if certain features are not supported. Generally, though, that's pretty rare, because every time you do that, you reduce your potential market.

~D

Re:Carmack (of ID software)

[Dracolytch]

Sure, if you want to be a DirectX 9.0 video card, then you have to implement the 9.0 specification. However, it is possible to run applications that require the 9.0 library on an 8.0 card so long as DirectX 9.0 is installed on the machine. In almost all cases you just won't get all the new 9.0 features (Such as bump-mapping).

Just because Microsoft comes out with a new version of DirectX, doesn't mean you have to get the latest card. So long as you upgrade your PC to the 9.0 spec, you should be able to run almost all programs well, just without some of the bells and whistles.

~D

Microsoft versus OpenGL

[Anonymous Coward]

> I guess he based that on the fact that the transition from Half-Life to Unreal Tournament was a transition from OpenGL to D3D.

Yes, but did that transition occur because D3D was better, in terms of technology and economics?

Or was there, perhaps, an outside influence tipping the economic scale...

Microsoft eyeing Vivendi unit?

Has Microsoft bought Vivendi Games?

Microsoft / Vivendi rumours gather steam

I don't know if the purchase actually took place, but they were talking, and Vivendi was deeply in debt, and Microsoft had lots of monopoly-generated cash. I think it's safe to assume that some sort of payoff occurred.

It is also widely believed that when Microsoft joined the OpenGL committee, it was for the purpose of sabotaging, and slowing down the technology.

That last bit is easy to believe, because it's the normal way that Microsoft operates. For example, consider these tidbits from the DOJ case Findings of Fact:

Microsoft's Jim Allchin, in a note to Gates:

> "I am positive that we must do a direct attack on Sun (and probably Oracle).... Between ourselves and our partners, we can certainly hurt their (certainly Sun's) revenue base.... We need to get Intel to help us."

Microsoft's Eric Engstrom describes Microsoft's goal as:

> "Intel to stop helping Sun create Java Multimedia APIs, especially ones that run well (ie native implementations) on Windows."

And Engstrom's proposed agreement with Intel:

> Microsoft would incorporate into the Windows API set any multimedia interfaces that Intel agreed to NOT help Sun incorporate into the Java class libraries. [emphasis/caps added]

So there you have a clear example of Microsoft using threats to sabotage open multimedia support.

If we want the PC to remain open (let alone the Internet), then we have to support technologies that don't come from Microsoft. In this case, it means supporting OpenGL, which is not hard to do, because it's a great technology.

Re:OpenGL is Dead

[praedor]

Add to that there is NO scientific app that uses graphic visualization that uses anything but OpenGL. OpenGL cannot die. It may not be used heavily in games, unfortunately, at least yet, but OpenGL rules the scientific world hands-down.

If/when linux makes more significant inroads into the desktop market, then games will follow. These games will require OpenGL, or someone is going to have to come up with another gaming-specific rendering lib that, if properly designed, would be fully cross-platform, supported on the mac, linux, and doze boxes. I don't see this happening, however, until and unless M$ puts a knife in OpenGL with their IP claims on part of the very heart of OpenGL. We need a truly OSS rendering system with the capabilities of Direct3D and that is free of IP claims.

Re:OpenGL closed source?

[razeh]

SGI made their sample implementation of OpenGL available at http://oss.sgi.com/projects/ogl-sample/index.html

some time ago.

Mesa is the open source implementation most people use if they need a software implementation. However, the hardware implementations are frequently many, many times faster and much prefered.

Linux gaming does not require OpenGL

[AHumbleOpinion]

If/when linux makes more significant inroads into the desktop market, then games will follow. These games will require OpenGL ...

Linux gamers do not need native Linux games or OpenGL based games. The majority of Linux gamers play Win32 games via dual booting or emulation. It is far more likely that emulation via WineX will continue to improve and become a very robust and reliable way to run Win32 games. Native Linux games will not be needed from a developers perspective. Keep in mind that getting a Linux gamer to buy a Linux version rather than a Win32 version does nothing for the developer. The only money to be made is from Linux gamers who refuse to dual boot or emulate and that is not enough to financially justify a full native and supported Linux version.

Re:Linux gaming does not require OpenGL

[praedor]

I think you are somewhat wrongheaded in your slant. I do not think WineX, such as it is, will EVER be good enough to play most games. It will almost never be good enough to play brandnew games. If developers were to use winelibs to build their games for windoze, you could take advantage of the strictly windoze-using game market while at the same time gaining linux users without the need of windoze. The problem here is that you would lose the ability to use nifty additions to Direct3D. WineX/Wine can only ever play catchup in a weak way. SOME games work right away, but most do not work, period. Of these many will never work in wine/winex.

This leaves the unlikely event that game companies would totally ignore linux in the future (once it gains a more significant foothold on the desktop market) and ONLY write for windoze and expect that everyone will have windoze on their systems simply to play games. That is the way it usually is NOW simply because it is necessity but it doesn't HAVE to be that way by any stretch.

Re:Killer app?

[Jedi Alec]

"Computer"
"Yes sir"
"Dial my mother-in-law"
"She's not speaking to you. I suggest that you let me order her some roses."

Now there's a market for malware :-) Next thing you know your phone will be suggesting(if it even bothers to do so) that you send your mother-in-law viagra, penis enlargements and nigerian business deals...

Re:OpenGL ES with hardware support? (NVidia)

[sien]

Have a look at the current Nvidia home page. We're already there.

The good thing is that it is Nvidia, who do the best OpenGL implementations around.

Has it been that long...

[obirt]

that people forgot about 3Dfx Glide? :)

Virtual environment WHAT?

[leonbrooks]

I'd rather have it as virtual environment googles

Errrr... oh, I get it! You'd be searching for stuff? (-:

Cue...

[leonbrooks]

...the hey-you-forgot-the-batteries jokes.

I call bullshit. Try this gem instead!

[leonbrooks]

Of course, if you prefer wasting your time hard-coding OpenGL calls and re-compiling for each make of phone, that is up to you, but as a business model its suicide.

Java isn't the only way to abstract either your graphics interface or endianness. There are much more efficient ways of doing both. If I was using an abstract language for my cellphone, I'd prefer something like Ruby.

Amongst other benefits, including much faster coding/debugging and better reusability, Sun's newfound cameraderie with Microsoft would then pose no risk to the future of my mobile 'phone code. Sun want to both have their cake and eat it, which is not a sustainable model of reality. Microsoft's view is much simpler: they want your piece of the cake, now, or they'll bury you in lobbyists and lawyers. It suits them to leave Scott's delusions intact.

Ruby, I might add, integrates with Java and you can even compile Ruby to Java bytecode if you like. This gives you a choice of JRE or native target. Ooh, let me think, which language would I rather use?

Re:I call bullshit. Try this gem instead!

[Decaff]

The ruby-> java bytecode sounds interesting (although I would not use a pre-alpha stage project for business development) is but you would still not be using OpenGL - you would be using an even higher level of abstraction away from the OpenGL driver.

Or if it's a Microsoft model...

[leonbrooks]

...it'll just be ordering it for you. And because it uses DRM, there will be no plausible deniability for you.