Slashdot Mirror

I wish that people that pretend to be computer experts would do the teeniest bit of research.

How about this gem: First introduced in 1995, Microsoft's DirectX application programming interface (API) was designed to make life easier for developers by providing a standard platform for Windows-based PCs. Before the arrival of DirectX, developers had to program their software titles to take advantage of features found in individual hardware components. With the wealth of devices on the market, this could become a tedious, time-consuming process.

I'm glad he cleared that up for us. Because this little known company called SGI didn't develop OpenGL back in 1992. In fact, were it not for MS, we would still be in the computer graphics dark ages.

I'm not trying to troll here. I am just pissed that people pretend to be experts when they don't have a clues what they are talking about.

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 :)

Here are some potential "killer apps" for a 3D desktop:

Hydra is a three-dimensional extensible markup language (XML) instance viewer/editor that was developed to aid in standards development efforts. It uses OpenGL to display XML documents as a tree structure that can be manipulated in various ways by the user. Additional information is displayed in the tree using shapes, colors, and varying sizes and positions.

Croquet is a software architecture designed to enable collaboration between users across the Web in a shared 3D space. Croquet is not merely a 3D user interface for visualizing file systems or web sites, but a complete development and delivery platform for doing real collaborative work in a distributed 3D space.

kernel3d produces a 3D animation of Linux source code development. Shapes and different colored lines are used to represent files, function dependencies, variable dependencies, file size modifications, files being moved across directories, and new files (see screenshot).

Wow, you are very uninformed for someone who was rated +5 Insightful.

OpenGL exposes new 3D functionality much faster than DirectX, through the OpenGL extension mechanism. It may not be as convenient as having a "standardized" API (and OpenGL 2.0 will address as much of that issue as it can), but it is still better to be able to use new functionality immediately, rather than waiting for the next DirectX release (or worse yet beta) from Microsoft. NVIDIA's drivers even support all of this under Linux.

As to your "rare titles" comment, see my other post for top games using OpenGL. Also reflect on the fact that every id game plus all the games based on id engines (Heretic 1/2, RTCW/ET and many more) all use OpenGL exclusively.

And guess what, when id releases Doom3, I'm pretty sure it'll raise the bar again. Perhaps by then quite a few people will have shader-capable video cards. ;-)

For more correct information about OpenGL, feel free to check out the official OpenGL website.

As opposed to the state of Microsoft, where they have standards you *can't* license.

OpenGL is open for anyone to license and implement.
DirectX is not. It is proprietary and you *have* to agree with Microsoft's vision.

In fact I am incredibly surprised you would call DirectX a standard; it is a platform tied, closed, proprietary, and controlled API.

They are the 'standard' in the sense that Microsoft, having the largest market, in supporting it and pushing it also makes it the most common API. Of course I'm sure you mean to imply that by saying the 'standards' I list aren't standards at all, but despite the fact that they have patents and licensors, I think they are still standards! (I also listed open source groups too, if that's confusing you).

MP3, MPEG4, AAC, are all defined by the ISO-MPEG group.
Firewire was created by Apple, but has it's own trade association
OpenGL has it's Architecture Review Board.
PDF is an open format, and as such a subset has been adopted by the ISO as a document interchange format and standard.
Zeroconf, as well as WebDAV, is an IETF working group. Included in that list is LDAP, Kereberos, IPv6, and DHCP.
Java is questionable, I probably should not have included it there ^^
PCI, PCI-X, USB, and AGP are all standards as well, with working groups and standards bodies.

My point is that Microsoft will take 'standards' and then change them to suit their needs, and Apple does not. If Microsoft is to become like Apple, then that means endorsing and supporting open source groups (Apache, SMB, KHTML, SSH, etc), opening the source of their own programs (IE core, OS core, etc), and using industry standards instead of rolling their own to control the market (DirectX, ActiveX, XDocs, etc).

So what is a standard? I propose that a standard is any format, API, or interface that you can license, get access to, and not worry that it is being controlled by a single organization who's wishes may differ markedly from yours. By that definition, Java definitely doesn't qualify; but also none of Microsoft's "standards" as well, while MP3, MP4, Firewire, etc, all do.

Despite them not being free, libre, or open.

I just googled for some OpenGL-based options, and Amaya looks interesting.

Anyone used Amaya or have other recommendations for an open source, OpenGL based SVG rendering API?

X is not concerned with 3D stuffs except for the initialisation of the GL context.

As soon as the app has its own GL context, it directly talks to the hardware. X has nothing to do with this business except in the forwarding of events (mouse, keyboard). Only the driver, the app and the 3D card play a role in this case.

Now, Quake3 can be expected to have a rather advanced renderer that pushes as little stuff as possible to the graphics card, so it's not such a big surprise that it can do with one hundred megabits. The bandwidth of AGP 1x is 266 megabytes per second, which does put the network one magnitude lower, but then again if you can get 10fps over the network where you can get 100fps locally, the values are in the ballpark.

I've sort-of tried this with Half-life, but the client side ran Wine between HL itself and the network (which might cause a lot of overhead outside - or then not, I can't tell) and the server side had an old ISA network card, so I got at best something like one frame per second in the hazard course. 15 fps on much better hardware is, IMO, conceivable and credible.

Gamedev.net has a TON of resources relating to game development, including a giant reference section which points to a lot of information about anything game-related.

Related to your question, a good compromise between low-level OpenGL and a full game engine (or even a commercial one here) would be GLUT. Instead of giving a piss-poor explanation of what the GLUT library is all about, I'll just point you to their FAQ. For sound there is OpenAL or the ubiquitous FMOD.

Depending on what you're looking for, a library probably is out there just waiting for you to find it. Instead of asking very general questions like this, I highly recommend you check out a little search engine called Google to find libraries or engines that suit your specific needs. Cheers!

Apple's OSX does all rendering through Quartz, (as PDFs) which is accelerated by OpenGL, and called QuartzExtreme.

That's not accurate. Quartz is really made of two parts: Quartz 2D and the Quartz Compositor.

The Quartz Compositor is reponsible for compositing all the layers (desktop, windows, layers inside windows) on-screen. It offers Porter-Duff compositing, which was developped at Pixar more than 15 years ago. See this post from Mike Paquette for details. Mr Paquette is one of the main developpers of Quartz. Quartz Extreme is "simply" an OpenGL implementation of Porter-Duff compositing and modern graphic cards offer the primitives needed to do that very efficiently.

The Quartz 2D layer is what offers drawing primitives following the Postscript drawing model. The same drawing model is used with PDF (no surprise), Java2D and SVG (and Microsoft's GDI+ ?). This part is not HW accelerated. I am sure Apple is working on it, but it wouldn't surprise me if new HW will be required to make this possible. There is a strong incentive for card manufacturers to offer acceleration, since Longhorn is supposed to use GDI+ extensively. I doubt that such acceleration will fit in the traditionnal OpenGL/Direct3D rendering pipeline.

The Apple JVM team implemented HW accelerated Java2D drawing in their 1.3.1 JVM. Their 1.4 JVM doesn't offer it (1.4.1 was a massive rewrite for them, 1.3.1 was more of a quick port to OS-X using some of their "old" carbon code). There were quite a few problems when HW acceleration was used. I hope they can and will wait for a system-wide Quartz-2D HW acceleration, it seems ludicrous to have the JVM team spend resources on an effort that will be wasted once Quartz2D is accelerated.

See Apple Marketing page, another post from Mike Paquette, and the presentation from Apple at SIGgraph about Quartz Extreme and OpenGL.

If that post doesn't end-up rated +5 informative, I don't know what will ! :-)

The Irony of Indy Games

Outside of the handheld ( PalmOS, PocketPC ) markets, or cell phones... many indy games are either crap... or sales pitches to publishers! Im not saying all... there are probrably dozens of exceptions, but on the whole this remains true. Its funny though, when you look at "past" indy games...

HomeWorld
Doom
FlashPoint

Really... by definition, an indy game is self financed, without a publisher in site. Its funny that that moment you have success in the indy market, you tend to get picked up by a publisher... then your no longer indy! ;) Than again, there are a few companies that are going from commerical projects to more of an indy style. Once you see the amount that publishers take... you start to see the value in online distro's!

For anyone really interested in learning more, check out:
Garage Games Misc resources, plus a licensable engine
FlipCode Great gaming related site
Gamedev.net Like flipcode, but less mature ( you'll see! )
Gamasutra The site for game developers! Must see
CrystalSpace LGPL 3d Engine. Very impressive
WildTangent Cheap game engine (web based), plus online publishing
Auran Jet Affordable 3d engine, flexible licensing
OpenGl The site for OpenGL info. Lots of useful links

From the above list, you should easily be able to find anything else your looking for! ;) Enjoy the world of game development for zero cash!

This is good news, but I should point out the OpenGL 1.5 spec is not at this moment available yet, it's only been announced. Hopefully it will be available with some headers and implementations Real Soon Now (tm). I know the past few ATI Catalyst drivers have had experimental glslang extensions in them... Of course, it'd be nice if Microsoft would update their implementation such that OpenGL on Windows could make use of this without going through extensions, but I'm not holding my breath, nor is it really a huge issue.

The OpenML SDK is an alpha release and the final spec for it won't be out until about this time next year.

However, the Khronos Group also released the OpenGL ES spec and there's actually a couple implementations already available. OpenGL ES is for embedded systems and mobile devices, it's essentially just a subset of OpenGL. Seems like it might be pretty nifty...

While the name OpenGL is owned by SGI (since OpenGL was invented at SGI), OpenGL itself is managed by the OpenGL ARB (Architecture Resource Board).

From OpenGL.org:
The OpenGL Architecture Review Board (ARB), an independent consortium formed in 1992, governs the OpenGL specification. Composed of members from many of the industry's leading graphics vendors, the ARB defines conformance tests and approves OpenGL enhancements. Currently the board includes representatives from 3DLabs, ATI, Compaq, Evans & Sutherland, Hewlett-Packard, IBM, Intel, NVidia, Microsoft, and SGI.

I remember reading somewhere that Microsoft has recently pulled out of the OpenGL ARB.

Also, adding to the reply of the parent post, OpenGL has the huge advantage of being portable. I have talked to one or two games developers who have told me that porting the OpenGL portion of their game to another platform is fairly straighforward. The remaining 5% of the work is usually politics and platform specific configurations and this is what is the hardest. BTW if my two games programmers' opinion is not representitive of the rest of the games developers, please let me know.

and use OpenGL

First, i dont understand why some people think its a bad idea nvidia are doing Cg. One of the goals of Cg is easier crossplatform development.. thats a noble cause if any =D

Secondly, my bet is OpenGLs shading language and Cg will eventually merge.

check: this

and notice this part:

Compatibility with DX is very important, but they're willing to weigh advantages of changes vs. cost. Cg and the proposed "OpenGL 2.0" language are similar but not identical; both look like C, and both target multiple underlying execution units. Interfaces, communication between nodes, and accessing state across nodes are different. It's very late, but not too late to contemplate merging the two languages.

OpenGL already does this for you automagically.

Check this and this.

OpenGL already does this for you automagically.

Check this and this.

Platform independent code.

There are projects out there that aim to provide a platform-independent method to produce commercial-quality games. There is no real reason that a company has to struggle with long, difficult ports of system-oriented code if they use the platform independent OpenGL (and other libraries) instead.

Now, how do you convince developers (or, more importantly, their managers) of the value of this approach? I don't know, because to a manager market flexibility is just Yet Another Buzzword (TM).

Anyway, as I've stated elsewhere, you're ignoring the fact that Linux does have games. You needn't rely on software ports to attract gamers to Linux (although I will admit that it does make things easier).

people into retro gaming, or required to use other old software. I'm so glad we are slowly approaching this point. UT2K3 has Linux support out of the box. The demise of Loki is something that I initially thought was going to set back the Linux gaming community for years, but then I've seen games like UT2K3, Castle Wolfenstein, and if you want to count their late to the punch arrival Never Winter Nights come out native. If we could only get Blizzard on the bandwagon, and Maxis more firmly seated the other developers would have little choice but to jump onboard. gatesh8r is right. If Wine gets to good to fast not only will it slow some developers to adopt Linux natively, it may loose a couple that we already have. I'm counting Apple as our new Ace in the Hole. The Mac actually has the attention of the developers, and porting from BSD to Linux should be much easier than porting from Windows to Linux. Of course if everyone adopts and improves on SDL and OpenGL they will have little to worry about when porting anyways. Especially if OpenGL2 ever makes it way to daylight with all the Active X type replacements it's supposed to have available.

Look. I wouldn't post these things if I hadn't done anything more than read a marketing blurb off Apple's website. Check out the PDF Apple submitted to Siggraph. Look at the data-flow diagrams on page 10. Look at the line that says "Quartz2D." Note the color: orange. Now, look at the legend in the top right hand corner. Lookup the meaning of the color orange: "software," as in "software-rendered." Quartz Extreme is a misnomer. It should actually be Quartz _Compositor_ Extreme. OpenGL is only used to accelerate window compositing, not to actually draw stuff inside the window. In EVAS, the little line for Quartz2D would be red, as in "Hardware accelerated."

They don't (or at least it depends what you mean with hardware rendered, as anything is hardware rendered).

Hardware 3D stuff is already there including network transparency through GLX
and 2D alpha-transparency is provided by the XRender extension.

Network transparency just means, that you have to have the possibility of doing remote calls (in one way or another) without being actually aware of it. It doesn't mean, that all calls have to be done over the network. The network is transparent (in other words invisible) to the application. That is what abstraction is for.

The app makes a call "Draw text with 50% transparency at X,Y". The underlying system makes a local function call, which, depending on the current situation, might or might not translate in to marshalling of the call, transporting it over the net, unmarshalling at the client, who might or might not use the graphics hardware in drawing the text.
Should the situation permit it, it could translate into a driver call, which draws the text directly by using the given hardware.

OpenGL is not only a 3D rendering engine. In fact, the <TITLE> tag on www.opengl.org reads "OpenGL - High Performance 2D/3D graphics."

OpenGL is a full-featured graphics API and is equally capable of doing 2D and 3D operations. There have indeed been some unique video applications built with OpenGL.

Whether that qualifies it as a "multimedia platform" is a judgement left to the reader.

The only way to get game developers to come to Linux is to develop a Direct-X like API that makes it easy to develop Linux-native games.

What's wrong with SDL / OpenGL? It is stable, featureful, and cross-platform. The API is full featured, and the implementation is rock-solid. Throw in OpenAL, and you have got everything that DirectX does (except stupid patented crap like force-feedback input) in a standards-based package.
That is about as "linux-native" as it gets. I can't think of a single desktop-targetted distro that doesn't include the SDL libraries. If more windows developers used SDL for their games, then the Linux and MacOSX ports would be almost effortless.

Sigh. We were talking about workstations here. Apple makes very nice laptops. I don't use one because I need workstation power, but I'm space constrained. But Apple's "workstations" are really not worth how much they cost, especially since I really don't like OS X (Linux person myself). Anyway, you're dead wrong. Windows are not the UI. Scrollbars, toolbars, icons, text, widgets, etc, are the UI. Just read Apple's own PDFs. They clearly show that OpenGL is used only for compositing (certain apps like FInal Cut also use OpenGL for transparency effects). However, actual drawing (Quartz 2D) is most definately not accelerated. You'd think it would be, because Quartz 2D is vector based, and the imaging model is pretty easy to support via OpenGL, but it isn't.

To bad Apple's own tech documents don't bear that out. Just read the PDF. All 2D is rendered by the CPU to a texture using Quartz2D, and all the window textures are composited via OpenGL. QE is a misnomer. It's not acceleration for Quartz2D, but a replacement for QuartzCompositer. The performance improvements you're seeing come from the fact that the CPU isn't having to composit all those windows anymore, so it has more power free to redraw faster. It's kind of a dubious improvement, because Quartz Extreme simply speeds up the compositing step, which is a step other graphics systems don't even need. Compositing of all windows is necessary to achieve window shadows and real transparency, but don't be fooled into thinking that you're not paying a *huge* performance price for those two bits of eye candy.

In Longhorn and EVAS, OpenGL is used for actually drawing window contents. This could be a big improvement. For example, somebody did an SVG viewer that used OpenGL. There was a huge performance improvement. Current GUI's are all still largely bitmap based (OS X more so than most others, ironically). Icons are bitmaps, widgets are mostly bitmaps, text is bitmaps, etc. This is due to the fact that newer "shinier" GUIs require gradients and other effects that current 2D engines simply don't accelerate. However, with accelerated vector drawing, we could theoretically make all icons and widgets SVG images, allowing them to be more dynamic and scalable.

I'm sorry that I didn't get a chance to look at this topic sooner!

Here at the University of Illinois, I'm a project leader for our game programming club Gamebuilders, so I'm pretty well versed in the rudiments of game design.

Yes, the best thing that I can recommend for anyone starting with game programming is to go the OpenGL route. For better or worse, graphics programming is a major component of game design, and OpenGL is general enough so your skills might apply to any number of systems if you choose to pursue a career in game developlent.

That said, the best way to get started with OpenGL is to use GLUT, the OpenGL Utility Toolkit. It's a great way to learn OpenGL without having to get bogged down in the specifics of the OS you're dealing with.

Also, there are numerous tutorials available on the subject of OpenGL and game programming in general on NeHe's site. If I had to point beginning to intermediate game programmers to one site and one site only, it would be there.

If you have any specific questions about OpenGL or GLUT, feel free to send me an email, as well!

Not that I have written any major 3D software, or even work in the 3D industry. But at uni we learn't openGL as part of our computer graphics course.

Once you have mastered the coordinate system it is so mind booglingly easy to get graphics on screen it's insane :) Writing good fast graphics is another issue but it makes the creative process so much more fun seeing your work on screen quickly.

For windows development you can even start with openGL for free :) (yes even on windows). I would recommend getting the MinGW compiler which is free, and openGL - again a free download. Information can be found here a quick google search turned up this page and it is a good summary.

use google to find some simple openGL sample programs to work from- and away you go :) Have fun!

> The problem with OpenGL is it doesn't keep up with the features of new cards the way DirectX does.

You know that there are extensions to OpenGL? That OpenGL is so old is merely a sign of its extensability.
The problem is the most current are vendor extensions, and as the part vendor indicates, it is very specific to a vendor.

Concerning this problem, DirectX is a little bit better, but not purely devoid. DirectX 8.0 is very NVidia-specific. DirectX 8.1 is developed with ATI in mind. (Or was it the other way around).

OpenGL 2.0 will hopefully overcome the current deficiencies.

Have a view at an earlier post on Slashdot on that matter.

http://www.opengl.org lists 1.4 as the latest version. Guess I was wrong about that. I'll still stand by my original point though: the turn-around time from feature request to releasing a new API has been shorter with DirectX. OpenGL 1.0 was relesed in July of 1992. There have been four revisions since (1.1, .2, .3 and .4). DirectX has had twice the major releases in half the time.

Why does linux make everything so damn hard. I use linux, but only because I believe in free software and right now its the only real provider capable of doing what I want to do. But it is so outdated it just bugs me. Somebody needs to take these suggestions, and actually think for a second about how much better linux would be if they were just implemented (also I have running about 4 linux desktops and 2 linux servers, so I'm not a super mega linux geek, correct me if I have an off point here):

1) Why does everything have to be compiled into the kernel. What? Can the kernel not map shared objects into its memory space? And if it can't, why not?

2) Why don't they establish only standard APIs that device drivers have to implement (seperate of the kernel and not built into some stupid x-windowing system or something irrelevant to what it does example: sound drivers for KDE), i.e.:
OpenGL - graphics library
OpenAL - audio library
insert appropriate nic standard
insert appropriate printer standard, etc. and make the stupid x-windowing system just another interface that runs on top of OpenGL, jeez.

3) The everything is a file mechanism is really getting outdated. Why are there not object oriented shells yet? Come on, just pop a javascript shell in there, make ObjectInstantiators/ObjectSerializers that detect file types and convert to the appropriate object instance, so javascript can instantiate it, use it, serialize it back to disk, and then move on.

4) Why do we still use program based architectures? Programs are way too linear. We need objects and an object handling mechanism (like javascript or something similar to it, like a Delphi UI or something) not programs. Once you make a program things get hard coded in that make it too specialized to be used in anything other than what it is designed for, if everything was just an interactive object, you could chain them together and do all sorts of neat tricks, that you could never dream of with standard file based shells/programs. And then you could serialize these object webs you create to disk for use as kind of a template(I'd say program but you could easily modify these to fit your needs). Sounds way better than standard file based scripts to me. Although javascript scripts sound nice too.

5) If we are going to be using a program/file based OS, lets make the program names intelligible. Lets see: vi, emacs, joe (joe??? what the hell man), yast, lilo, initrd, sh, etc., etc.. Come on guys name your programs something intelligible, and leave the credits in the fscking readme file. At least if dos had something it had convenient keywords (copy, rename, delete, deltree, EDIT). I realize I could make symlinks to my hearts delight, but that is only assuming you know what the program your looking for is called.

6) Why did anybody think it would be a good idea to integrate the inetd with the x-windowing system (xinetd). Yippee, all the speed of NT servers on a linux system. Of course thats assuming you use inetd to begin with.

7) This one is for the distros: quit using the damn graphical installers. Graphical installers don't make installing any faster (quite to the contrary in a lot of cases), and in installing on older hardware a lot of times it makes it nearly impossible. I'm all for straightforward installers, but you don't have to be in a graphics mode to do it (fine standard VGA modes will work)

8) Hey I got a fun idea, lets put all those binaries in one directory, with no real index as to what each of these programs with obfuscated names do, and then lets give no easy way to find out what it does short of running it. Woo! And don't say, "One word, man" or "info" those systems are pretty fucked up as it is.

9) Standardize the damn locations, follow the LSB biatches.

10) This may sound contradictory to the above, but... abolish the Unix file system layout. I can't stress enough how a simple object persistence/serialization mechanism would be way better than a file system any day. Anyways, those are just my rants/suggestions as to what needs to be changed or layered on top of the linux filesystem if they wanted it to actually be a BETTER OS than windows or MacOS.

I port video games to Linux for a living, so I am probably qualified to comment on this.

Do NOT optimize for Wine. You probably can't anyhow, since both Win32 (at least, DirectX) and Winelib are moving targets to varying degrees, what works and works well in one version of Wine will not necessarily do so in another.

I think Wine is an excellent piece of work, but I'd imagine even the Wine developers would rather have native Linux applications than emulated win32 apps (and if they don't, they should).

This is doubly true for game development, where you need every CPU cycle you can reasonably get.

Wine, Winelib, and WineX are really meant to be bridges to make Linux more feasible in the short term by letting Win32 programs run in some form, even if they just limp along. They are afterthought solutions to running software that we have no real ability to use, but think we can't do without.

The ideal solution is to write portable code in the first place. Be mindful of what you write, and follow some basic principles:

1) Don't tie yourself to a compiler. If you build on Visual C, take time to build on a different compiler (specifically, GCC) every now and then. Getting code to compile on various platforms is half the battle.

2) Don't tie yourself to a platform's API. Use cross-platform libraries and toolkits where you can, use abstraction layers in your own code where you can't. If you do this right, a good chunk of the porting work is just filling in stubs for a new platform. For game development, you should be looking at Simple Directmedia Layer for most of your needs. Other libraries like my own PhysicsFS can abstract file handling for you. OpenAL can give you 3D positional audio if SDL's stereo output is insufficient, and OpenGL gives you 3D accelerated graphics if SDL's 2D linear framebuffer is insufficient.

3) If PowerPC (MacOS, specifically) is of interest to you, be conscious of byte ordering. Always be conscious of structure packing regardless of platform. If 64-bit platforms (Alpha, Itanium, Hammer) are of interest to you in the future, don't do silly things like cast pointers to ints and such.

4) Don't use assembly code. Ever. If you _must_ use it, you better have a C fallback. Be smart and use NASM on win32 and Linux, so you don't have to deal with the massive differences in inline syntax between Visual Studio and GCC.

If you are more than one developer, the easiest way to do this is to have a devcrew made up of at least one person for each targeted platform. This makes it easy to make sure that things aren't silently breaking on MacOS while you write code for Win32, since that developer will catch it in his next code sync (you _are_ using source revision tools, right?).

Good luck to you.

--ryan.

Prove it. I'm getting my info right from Apple's released info. Read this document. Note, especially, page 10, where it shows the data flow diagram. Note how Quartz "Extreme" simply takes the place of Quartz Compositor, and the Quartz2D drawing to window buffers is still done in software (read the legend). Now, beg for forgiveness.

Right on (from another scientist using a Lintel system with a good video card and gigabit ethernet.)

The significant corollary is our preference for quality OpenGL cards in our machines.

Doesn't mean it will happen, but it looks like maybe the ARB are considering all options at the moment.

It does not become "port from Windows to Unix" instead. Porting to X11 and porting to the MacOS X gui are not the same.

Ahhh. But we were speaking of 3D Rendering software (Assumed to include modeling and animation). In that case, the choice is simplified because Mac OS X uses OpenGL, as does SGI, Solaris, Linux, etc. "Porting to OpenGL" can be very close to "Porting to Mesa"

Perhaps I should have said more of "Port from Direct3D to OpenGL". Hmmm... but in that case... OpenGL is an option on Windows also, so it could go with "Develop for Windows only, or develop for Windows, Mac OS X, Linux..."

Where the OSes differ with regard to porting (having to change source code, rather than simply recompiling) is mainly in the user interface.

Yes. However, when an application is ported (or developed initially for cross-platform) cleanly, the functionality and UI are abstracted in a better way. Platform specifics are minimized, and shared common code is maximized. Then going to another platform is simplified.

However, there's another issue. The vast majority of games out there don't rely heavily on the native UI widgets. Most gamers like their own UI. If you're doing a game on OpenGL anyway...

NVIDIA has signed an ARB Contributor License for the NV_vertex_program extension; copies were distributed to interested parties. For questions, contact Stephen Pettigrew, spettigrew 'at' nvidia.com Microsoft wanted to alleviate concerns about their statement last week regarding possible claims on vertex program IP. Dave Aronson apologized for the perception that they aren't acting in good faith. They are trying to follow ARB regulations about stating IP as much as possible. When a vote was imminent, they reviewed and felt that they had patents or patents pending covering vertex programming. They do plan on coming up with licensing terms, and have set a hard deadline for themselves of 2 weeks before the June ARB meeting.

You can read a little about the ARB here.

OK, so 3DLabs is on the ball. But what ball is that? A ball of an as-of-yet "unapproved" specification (see an approved spec here?). How many hardware vendors are going to support OpenGL 2.0 with 110% effort when the spec is still being reviewed? Does that mean hardware vendors aren't allowed to try to gain market/mind share in the meantime?

I did note that Carmack hasn't seemed to say anything about Cg yet. As I'm sure most of us are, I am very interested in what he has to say. I suspect that he will be highly unimpressed.

This is already possible if the developers use SDL/OpenGL or CrystalSpace. I don't think either will support PS2 (unless you use the linux kit) and handheld support is probably shaky. But they're open source and cross-platform!

OpenGL has always been about working. SGI has kicked butt in the past because of taking adavantage of OpenGL hardware. Gamers just wanted to take advantage of the high end hardware. Now high end hardware is "gaming".

The screenshots look impressive. It would be cool if I could play that on my platform. And however I realize, that I belong to the minority of gamers (which is good, like Mark Twain has already said, "Whenever you find yourself on the side of the majority, it's time to pause and reflect."), I still think that when they would wisely program this game for many different gaming platforms and few desktop ones, it'd be a piece of cake to release other version. But I'm affraid that they would prefer us to use other options, unfortunately...

Oh, well, I gues I'll just have to wait for Mason, or Warewolf, or Sands of Syllus, or Archipelago, or Catacombs, or Belchfire, or Acid Tempest, or Phoenix...

Check out GLUT, it does a pretty decent job of covering the cross patform graphics and input handling that directx does.

Also of interest is the meeting minutes where the opengl panel discuss the implications of this leap, and raise some interesting questions:

> Bimal: Devil's Advocacy question: why do we want OpenGL to survive? If IHVs can't articulate this and drive progress, it won't survive.

I'd be really sad to see OpenGL go. Its the only way I've been able to fart around with all that graphic lovelness since University, doing my bit with deformable objects.

I hope they get their finger out and pull it off. Apple should be helping to sponsor this sort of thing really IMHO...

OpenGL, OpenAL, Boost++, and sometimes PLib

Julien.

In my opinion, there is no future for linux gaming if wine is the only way to go..

The problem is: at the moment, the best gaming API
is Microsoft DirectX, like it or not, and
the likelyhood of DirectX becoming a cross-platform API is zilch.

So obviously, Wine is needed at the moment, partly as a windows-simulator,
but also as an implementation of DirectX on linux.

In the long run, however, It's unhealthy to be dependent on an API dictated by microsoft.
We need a new, open, alternative.

Perhaps SDL 2.0 or OpenGL 2.0 is the answer needed?
Linux needs a killer DirectX-killer-API, much in the same way DirectX was the
MSDOS-killer that moved games development to windows.

However, if wine is the future of linux gaming,
we are (indirectly) giving that future to Microsoft.

Which would be correct. Linux is a kernel; a kernel's job is to run programs.
>>>>>
But those words carry a far larger meaning than the sentence implies. DirectX does only do sound, graphics, and input, but those words understate its power.

Just a tad, and DirectX Graphics's superiority is in areas that require hardware that most consumers (early adopters excluded) do not yet own. Even so, I hope Microsoft is enjoying its fleeting precious moments [gocollect.com] of superiority because they will end very soon.
>>>>>>>>
Why? The link you provide doesn't have anything to do with DirectX or OpenGL, so I surmise that you have no proof that OpenGL will suddenly stage a comeback. Even if OGL 2.0 gets rolling right now (it won't) it will quite awhile before the glacial-paced ARB will produce something useful.

Or "GLUT is infinitely weaker than DirectInput." Could you elaborate?
>>>>
Read the GLUT API, then read the DirectInput API. Juding from the GLUT 3.7 API reference GLUT supports three button mice, keyboards, and spaceballs. DirectInput can be programmed to handle anything, from mice with dozens of buttons buttons to 6 axis force-feedback joysticks to full-body cybersex suits. Also, GLUT's callback-based mechanism doesn't exactly scream "performance" in a game setting.

The sound quality of the General MIDI support on most consumer-grade sound cards sucks, and General MIDI has never been good for many genres of electronic music.
>>>>>>>
That's why DirectX doesn't use standard MIDI support anymore. On cards that have poor MIDI support, MS uses its (pretty good) software synth.

Point me to a .mid file doing a good impression of a tb-303 to convince me otherwise. Why else did Unreal Tournament use S3M, XM, and IT tracked music instead of MIDI, and most newer games like q3a use streaming MP3 or ogg anyway?
>>>>>
The music requirements of Q3 or UT aren't exactly terribly stressing. MIDI is uniquely suited to all sorts of things, such as dynamic adaptation to the game environment, that are hard to do with pre-recorded music. With DirectMusic, you can program scores that follow a general patterns, but fluctuate depending on conditions or at random times. The power is there, it is only a matter of time (DirectMusic only became mature fairly recently) until some clever developer decides to use it.

The sockets API is also protocol independent and can support any protocol for which your sockets implementation (such as BSDsock or Winsock2) has a backend.
>>>>>
True, but DirectPlay is a *much* more integrated solution. It does lobbies, transport, all sorts of things.

Why can't you use the game engine (built on d3d+dsound or opengl+openal) to do cut scenes, as Metal Gear Solid and Zelda 64 do? Or do you have some other reason for wanting to play movies?
>>>>>>>>
DirectX isn't necessarily just for games. You can use DirectX to get hardware acceleration for DVD playing and other multimedia uses. Also, many games use video quite well. The Final Fantasy series, for example, uses full motion video to a great effect. Also, game engines still aren't up to the quality of good FMV yet.

All three libraries have DirectX backends, but they also have backends for operating systems not controlled by Single Point of Failure Corp. [google.com]
>>>>>
Yes, but their functionality is a fairly limited subset of DirectX's features. Also, it is not fair to criticize DirectX just because MS sucks. DirectX is a quality technology, Microsoft or not.

Organizational support for OpenGL continues, but it's not like the days when SGI was really pushing it. The Farenheit debacle turned off many people. Apple is still OpenGL oriented, but support is weak. From the minutes of the last meeting: "The next meeting date is set for Tue-Wed, December 11-12, 2001. Apple is tentatively willing to host again, if needed - the food budget was a bit of a problem for them this time."

What this proposal really calls for is a sort of "RenderMan Lite". The concept is very like RenderMan, with programmable shaders written in a C-like language.

This is an instance of the "programmable peripheral" problem. There's always a temptation to put programmability in peripheral devices. The usual problems of embedded systems programming apply - a special toolset is needed for the target system, debugging support is usually weak, and synchronization between host and target is complicated. That's why programmable peripherals are rare. (For example, we don't usually see the ability to put the file system in the disk controller, or the TCP/IP stack in the Ethernet controller, although hardware has been built and sold for both of those functions.)

What usually happens is that agreement emerges on what functionality a device should export, and device controllers implement that functionality, rather than exposing their innards.

...their idea )
OpenGL ARB meeting notes
Notice this:
Action: John Stauffer volunteered Apple to lead the short-term unification work. 3Dlabs volunteered to lead the long-term 2.0 work.

No, I don't. The culture at NVIDIA comes mainly from an SGI background, so OpenGL is something of a religion there. Further, unlike some companies, NVIDIA seems to understand the positive feedback effect of open APIs (just not Open Source, yet).

So, NVIDIA will have to be content with the current situation: "It runs at 30 FPS on the Radeon, but at 80 FPS on a Geforce 3!". ;-)

--- Example: ... "It's the hottest game of the year and they don't take ATI." (Sung to the toon of a Visa comercial. It's in Nvidias best intrest to make this happen. Tho maybe not in the markets best interest.

The current (OpenGL) situation is one where vendor-specific extensions are used to expose advanced functionality (shaders primarily). This means diffent paths through large portions of OpenGL based rendering engines. This is actually closer to 'NVIDIA specific' games, but NVIDIA knows that ISVs will just migrate to Direct3D where those features are properly abstracted. DirectX 8.0 has incorporated these features into the base API (and NVIDIA is just another player there, although it had a hand in defining the spec - just as it will with OpenGL 2.0).

OpenGL faces losing many ISVs unless there are standard ways to access these features. THAT is the motivation behind OpenGL 2.0. If you want strong, cross-platform 3D capabilities, do whatever you can to support OpenGL. OpenGL 2.0 looks like a great evolutionary improvement, and should continue to spank Direct3D in most respects. It certainly will in the area of Linux support. ;-)

If you're interested in OpenGL programming, there are many great resources on the web, including the The Official OpenGL Site and The OpenGL GameDev Mailing List.

299,792,458 m/s...not just a good idea, its the law!

Sure, but the latest OpenGL ARB (Architecture Review Board) minutes also have this comment from Bimal Poddar (Intel):

Devil's Advocacy question: why do we want OpenGL to survive? If IHVs can't articulate this and drive progress, it won't survive.

A "devil's advocacy" remark at an ARB meeting, but maybe not so far fetched in reality. - Mike (OpenGL dabbler)