OpenGL 1.5

Yogijalla writes "SGI and OpenGL ARB just announced the OpenGL 1.5 specification, introducing support for a new OGL Shading Language. Also, check out the new Java bindings to OpenGL. OGL 1.5 is a step towards the OGL 2.0, already suggested 2.0 by 3DLabs." Also worth pointing out that OpenML SDK has been released as well.

Comments

Gotta love

[Anonymous Coward]

those editing skills.

OGL 1.5 is a step towards the OGL 2.0, already suggested 2.0 by 3DLabs.

Re:Gotta love

[Anonymous Coward]

I think your interpretting this sentence incorrectly. Although, I havn't read the article yet so bear with me. I think it meant to read:

OGL 1.5, already suggested as being called 2.0 by 3DLabs, is a step towards a release of OGL 2.0.

Which in itself is awkward and cumbersome to read or write. Basically it just reminds us that written language cannot always express ideas the most efficiently.

unless of course you use a Borkulator.

Re:Gotta love

[Anonymous Coward]

Basically it just reminds us that written language cannot always express ideas the most efficiently.

No, it reminds us that /. editors can't write.

Somewhat old, it's been there since Monday...

[ericvids]

But I'm happy to see that they're finally putting a high-level alternative to the ARB_vertex_program and ARB_fragment_program extensions. I've been dabbling in these extensions and it's been a huge pain. Also just in time for the class I'm teaching next semester.

I wonder when these will become standard (not just as an ARB extension but as an ARB required feature). Hopefully in 2.0? It will save a lot of calls, at the very least--just check the version number of the GL implementation, no more searching extension strings... :)

Re:Somewhat old, it's been there since Monday...

[luther]

I wonder when these will become standard (not just as an ARB extension but as an ARB required feature). Hopefully in 2.0? It will save a lot of calls, at the very least--just check the version number of the GL implementation, no more searching extension strings... :)


You can see at :

http://www.opengl.org/developers/about/arb/notes /m eeting_note_2003-06-10.html

That the reason that it was called 1.5 and not 2.0 is that the shader language didn't make it to the core specs, and that they plan to promote it to core specs (and release 2.0) soon, possibly even in the next ARB meeting in september or the one thereafter.

Here is the quote :

The result was a simple majority of non-abstaining YES votes, but not a supermajority. Interpretation of this vote required some care since final spec approval requires a supermajority vote, while consideration of features for the final spec requires only a simple majority. Because the NO votes were strongly held, we expect that trying to approval a core revision including the shading language would carry extremely high risk of failing to approve the spec. We will therefore not include the shading language into the core at this time, but instead drive a new core version as soon as there's more experience with the extensions, perhaps as soon as this fall.

As previously agreed in the marketing working group, we will call the new core revision OpenGL 1.5, reserving OpenGL 2.0 for a future core revision including the shading language.

Re:Somewhat old, it's been there since Monday...

[SlashdotLemming]

Somewhat old, it's been there since Monday...

Then why didn't you submit the story on Monday?

Re:Somewhat old, it's been there since Monday...

[ericvids]

I would have, but I never submitted stories before, and who knows if I'll get accepted anyway? Besides, it's only now that I have no classes so I can participate in Slashdot discussions. :) (It just so happened that I teach CG, so...)

Re:Somewhat old, it's been there since Monday...

[21mhz]

As previously agreed in the marketing working group, we will call the new core revision OpenGL 1.5, reserving OpenGL 2.0 for a future core revision including the shading language.

I think it was a marketing error. They should have called it OpenGL 2.0 Full Speed and reserve OpenGL 2.0 Hi-Speed for the future core spec.

Sorry, couldn't resist a joke referring to a recent turmoil in USB packaging names, which have been clarified later.

Great

[Anonymous Coward]

Now I need to buy another video card.

Re:Great

[ericvids]

> Now I need to buy another video card.

Oh, not necessarily. The OGL shading language is just a high-level version of the shading extensions that have previously existed. I'm pretty sure drivers will adapt by simply compiling the code before passing it to the card. The other extensions mentioned (like the ARB_vertex_buffer_object and ARB_occlusion_query) have been extensions to 1.4 for a while now, and my GeForce FX 5600 supports them already. :)

Now if the cards can accept the high-level language itself... that would be interesting (and perhaps will make for a bigger, hotter video card...)

Re:Great

[Goodbyte]

> The other extensions mentioned (like the
> ARB_vertex_buffer_object and ARB_occlusion_query)
> have been extensions to 1.4 for a while now, and
> my GeForce FX 5600 supports them already. :)

ARB_vertex_buffer_object, maybe but ARB_occlusion_query is new (though I think it is a direct promotion from NV_occlusion_query)

Woohoo

[Duncan3]

"Non power-of-two Textures"

That's _thee_ key feature Apple needed to do the fully OpenGL desktop, along with a pile of more eligant error handling of course. Glad to see it's now standard.

It also makes the modeling and artist guys much happier. Do you have any idea how hard it is to make everything out of squares?

2.0 should put the last of what we need for the next 5 years into OpenGL, then maybe people can start writing more portable games again.

Re:Woohoo

[ericvids]

> That's _thee_ key feature Apple needed to do the fully OpenGL desktop,

But there have always been tools to circumvent the power-of-two limitation. You can always use only part of a texture on a primitive (triangle, quad, etc.). There are tools to tile non-power-of-two textures on a power-of-two texture to minimize memory usage.

At least in game dev, it didn't really prove to be useful. (Except for those artist whiners who insist that they can use any size image that comes out of Photoshop. *laugh* just kidding guys... I hear ye)

I'm just thinking that Apple wouldn't be making the late introduction of non-power-of-two textures into OpenGL as a plausible excuse for not making the desktop fully-OpenGL already. Besides, they can always introduce Apple-specific extensions--why didn't they do that already? Methinks they're just lazy. :)

Re:Woohoo

[Anonymous Coward]

Apple did implement GL_EXT_texture_rectangle (DRI implements it as well). It has some uses, especially with GL_APPLE_ycbcr_422 or GL_MESA_ycbcr_422, but in games, it is non issue, for reasons you mentioned. Do not forget, that NPOT textures still aren't first-class citizens compared to POT textures, you lose tiling for example.

Re:Woohoo

[zenyu]

"Non power-of-two Textures"

That's _thee_ key feature Apple needed to do the fully OpenGL desktop, along with a pile of more eligant error handling of course. Glad to see it's now standard.


I suspect it's for bind to texture, not anything that can already be done by just using part of the texture. Supposedly nVidia has been waiting for 1.5 before doing bind to texture in UNIX environments (currently only a WGL extension.) For me, on the FX, copy has actually turned out faster than bind, but that is hopefully just a driver limitation. Rectangular textures also have nice coordinates for using them in multi-layer programmable pipeline settings. (I haven't read the specs yet, just extrapolating from the nVidia extension.)

Re:Woohoo

[Duncan3]

Yes there are hacks, but those hacks eat memory, and you only have so much texture memory on a card.

And Apple has a loooong list of OpenGL extensions. They implemented this all some time ago now. You should see some of the realtime video editing that they can do.

Nothing gets into OpenGL that wasn't an extension first - that way it's all developed and debugged before we have to deal with it.

Re:Woohoo

[ericvids]

Oops, sorry for the apparent misinformation. I'm aware of those extensions--what I meant in my previous post is that Apple can always introduce their Apple-specific extensions into their desktop, but they haven't done so already. :)

Re:Woohoo

[arekusu]

However, NPOT textures are the only way to get fully accelerated DMA AGP updates. POT textures are not currently accelerated in 10.2.6, see Apple's TextureRange sample code.

As you point out, this is primarily useful with video textures, but any game that does animated textures can take advantage of it.

Re:Woohoo

[ericvids]

Oops, check my response to Anonymous Coward on the other subthread. :) Sorry for the misinformation. Apple did have non-power-of-two textures through the multivendor GL_EXT_texture_rectangle extension; I was just pointing out that they didn't bother using this for their desktop. :)

You're right about the hack-nature of what I proposed though. In practice, however, you only lose very little texture memory, if you have a good tiler. Besides, I believe that non-power-of-two textures will suffer some memory loss as well in two ways:

(1) If the card vendor gets lazy and implements non-power-of-two textures as power-of-two textures. I've seen this happen with DirectX 7 on a GeForce 2 before--damn texture loader forced a power-of-two memory space for my proportional-width font characters, which is why I had to make my own tiler in the first place! :)

(2) If the bitmap word spans on the card force a power-of-two texture width, which will accumulate if you have a large amount of small textures.

Re:Woohoo

[mpaque]

>> That's _thee_ key feature Apple needed to do the fully
>> OpenGL desktop,
>
> But there have always been tools to circumvent the
> power-of-two limitation. You can always use only part
> of a texture on a primitive (triangle, quad, etc.).

The gotcha here is that Apple needs to take a window backing store, a buffer, and apply that as a texture to the quad. Doing this by the old slice-n-dice into assorted power-of-two tiles is a pain, and an intermediate copy that just slows things down.

It particularly gets in the way if the non-square content happens to be a video DMA stream.

Non-power-of-two textures, buffer as texture, and a few other details are all needed for Apple's Quartz Extreme trick. The Longhorn guys will figure this out eventually...

Re:Woohoo

[spitzak]

An implementation is free to use the hacks to get the non-power-of-2 textures. The point is that the hack is now inside OpenGL and thus the interface *allows* a non-hack implementation. This is entirely a good thing. Way too much of OpenGL and X (and Windows GDI and some parts of DirectX) is crap like this where just a trivial amount of extra code would make a better interface, but the implementors don't add it because "it can be done by the user".

Apparently it is very difficult for developers to see where they could improve their interfaces because this sort of design happens so often. Try: if you have a call and it takes arguments, make ALL possible argument combinations do what the caller would expect, even if it is "obvious" how the call should be modified to work. Conversely, don't *add* arguments or calls. It is difficult...

Doom 3

[DeathPenguin]

The shipping date is coming up in a few months for Doom 3. Any ideas on whether it will be using OpenGL 1.5, or is Carmack still intent on pushing the industry forward by implementing draft standards?

Re:Doom 3

[Yuioup]

I wouldn't be surprised if OpenGL 1.5 is largely based on the work that Carmack has done on DOOM III.

Re:Doom 3

[bogie]

Not to bring your down, but all signs are point to Doom3 being a lot longer than a few months away.

Re:Doom 3

[Forkenhoppen]

It's sad but true; Carmack's probably the one person out there with the biggest influence on new revisions of the OpenGL spec.

As to whether or not it's largely based on his work, however, that's another story. Honestly, there are tons of people working on the same thing that Carmack is. He's just the most well known, with the biggest profile. The technology behind Doom III, while interesting, really is just a natural, next logical extension of the current state of 3D graphics.

Re:Doom 3

[FreonTrip]

Doom 3 will ship with at least five OpenGL rendering paths to address the fragmentation of capabilities in the video card market: a failsafe path for the original Geforce and Geforce2s, an older Radeon-specific path, a Geforce3/4 specific path, a newer Radeon-specific path, and an OpenGL 2.0 path. The latter's probably the one in which you're most interested. :-) His tinkering with a prerelease 3Dlabs P10 board and the preliminary OpenGL 2.0 spec impressed him enough to convince him that this was The Right Thing.

Re:Doom 3

[Daniel Phillips]

all signs are point to Doom3 being a lot longer than a few months away

According to my fuzzy recollection, JC was saying that Microsoft is paying them large amounts of money to hold off releasing until the XBox version is ready. That must be some large pile of money.

I think he also said that id would use the time profitably, to make Doom 3 even better. It's apparently been release-ready for quite some time.

Re:Doom 3

[V.P.]

So Microsoft is paying off the son of God now?

For shame!

Would like to try the OpenML SDK

[Biomechanoid]

An OpenML SDK is now available

http://www.khronos.org/openml/sdk/linux_requirem ents.html

Id really like to try this OpenML SDK, but it seems you are requered to enter your phone number - now why is that??

Re:Would like to try the OpenML SDK

[Dr. Photo]

Id really like to try this OpenML SDK, but it seems you are requered to enter your phone number - now why is that??

*shrug*

SDL also offers crossplatform media functionality (and it beats the pants off of GLUT when working with OpenGL), and definitely doesn't have any such silly requirements. ;-)

Or you could just tell the OpenML people your phone number is 867-5309. :-)

Re:Would like to try the OpenML SDK

[i_am_nitrogen]

OpenML and SDL are hardly the same thing... Check out the Jahshaka home page for an idea of the kind of application OpenML will benefit. OpenML is really an awesome thing. It finally brings together 2D and 3D raster graphics (OpenGL) with video processing and synchronization capabilites, providing a standard platform for applications to perform accelerated compositing, editing, effects, and other operations on various media. Hopefully we'll see an Open Source implementation of the SDK in the future.

SDL is simply a low-level hardware abstraction layer. It doesn't even have geometric drawing code.

Re:Would like to try the OpenML SDK

[Biomechanoid]

OpenML is really an awesome thing.

But do developers have to give a phone number just to try it??

Re:Would like to try the OpenML SDK

[Ridge]

The source is available from the Khronos Group, though like I mentioned in another post the SDK is alpha and you have to sign an NDA to get it. It apparently uses 3 licenses, SGI Flavor of GNU Lesser GPL, SGI Free Software License B, and SGI Flavor of GNU General Public License GPL. Whew. I haven't looked over it very closely yet, so I can't judge the quality or functionality at this time.

Re:Would like to try the OpenML SDK

[Anonymous Coward]

Bah, it doesn't even have Mac support. It's of little use.

Re:Would like to try the OpenML SDK

[AllUsernamesAreGone]

If they demand phone numbers, they should expect people to enter fake numbers. What're they going to do, phone you up about it?

Re:Would like to try the OpenML SDK

[Goth Biker Babe]

OpenML is an API. Initially it didn't have any concrete code support. If you want an Apple version, implement it.

Re:Would like to try the OpenML SDK

[Anonymous Coward]

SDL is simply a low-level hardware abstraction layer. It doesn't even have geometric drawing code.

Just as SDL_image provides additional image loading, SDL_sound provides additional sound loading, SDL_mixer provides a nicer interface to SDL's audio layer, and SDL_ttf and SDL_bmf add font loading interfaces, there are add-ons for primitives (SDL_draw, SDL_gfx, SDL_prim, sge) and GUIs (paraGUI, SDL_gui, wGui, GUIlib, aedGUI).

As you note, SDL is really a simple audio and framebuffer abstraction, and that's all it's ever been intended to be. A quick glance at the SDL library page, however, gives a quick idea of how extensions are kept modular, and how many there are for almost all reasonable applications of SDL.

Or, to put it another way, the tools are there -- but do you really want them in the core if all you're after is a simple framebuffer?

Re:Would like to try the OpenML SDK

[i_am_nitrogen]

I wasn't complaining about SDL in any way. It does a great job at what it's meant to do. I was just pointing out that it has very little to do with OpenML.

So:

[Anonymous Coward]

- What still remains before we can say OpenGL is back toward its original goal (you write for one standard instead of having to write for every single little card driver, something kind of ruined by the fact that many things these days, every card uses a different opengl "extention" to do the exact same goal.)

- What still remains that DirectX excels at that OpenGL is lagging behind at

- What of the things in the above two lists will be fixed by OpenGL 2.0, when/if it is adopted.

Re:So:

[ericvids]

These are valid concerns. I'm surprised the guy got marked as a troll.

> - What still remains before we can say OpenGL is back toward its original goal [...] every card uses a different opengl "extention" to do the exact same goal.)

Well, I must say that OpenGL never really swayed from its original goal. OpenGL follows a pseudo-Bazaar philosophy--let vendors push for features they want, and if they get a massive following then it's good enough to put into the standard. I say pseudo-Bazaar because, unlike open source, this process happens somewhat too slowly for it to be competitive with DirectX.

> - What still remains that DirectX excels at that OpenGL is lagging behind at

The only thing that DirectX seems to excel at right now is standardized support for a lot of graphics programming constructs, i.e. its D3DX library (especially those mesh/skinning functions, quaternion arithmetic and the myriad transformation matrix builders it has by default--can anyone say D3DXMatrixShadow? :))

However, we can also say that DirectX contains too many features that won't be used by many (and in fact some of them do get dropped in subsequent API releases) OpenGL, on the other hand, tries to promote a *clean* standard, not a super-bleeding-edge standard that contains a lot of cruft. That is also the reason why OpenGL lacks the utility functions I mentioned in the above paragraph; many developers have a (portable) base of utilities that works well for them, and all they want is a (portable) API to display their graphics, not something like DirectX which coerces you to use the Microsoft-only stuff for mostly everything (including the math, which should be something the programmer himself should handle).

> - What of the things in the above two lists will be fixed by OpenGL 2.0, when/if it is adopted.

OpenGL 2 is a draft (and therefore moving) standard, and it will be largely up to the ARB to define what is being used by most applications to be declared fit for the standard. It doesn't necessarily mean it will beat DirectX in terms of functionality, but it will surely be a cleaner, more general standard that vendors will be happy to adhere to.

Re:So:

[Anonymous Coward]

I have not looked at the new OpenGL specs, but so far one key missing feature is fast copy to video memory. DirectX supports locking AGP textures, which propably is a lot faster then what OpenGL has to offer. This is important when displaying video on a texture for example. Also OpenGL doesn't support typical video color formats.

Re:So:

[FuriousBroccoli]

- What still remains before we can say OpenGL is back toward its original goal (you write for one standard instead of having to write for every single little card driver, something kind of ruined by the fact that many things these days, every card uses a different opengl "extention" to do the exact same goal.)

Agreed.

- What still remains that DirectX excels at that OpenGL is lagging behind at

Totally disagree. D3D9 is currently 'ahead' of OpenGL, with it's unified shader system, effect file framework, and the HLSL (which can be processed in software). OpenGL is too vendor specific (read: Cg) and is currently playing catch up.

Note: my comments are from a game development POV. I can't speak for other industries.

Re:So:

[Dr. Sp0ng]

...and the HLSL (which can be processed in software). OpenGL is too vendor specific (read: Cg)...

You realize, of course, that HLSL and Cg are the exact same language, right? Microsoft helped nVidia develop Cg, and then renamed it to HLSL for the DX9 implementation.

Re:So:

[FuriousBroccoli]

You realize, of course, that HLSL and Cg are the exact same language, right? Microsoft helped nVidia develop Cg, and then renamed it to HLSL for the DX9 implementation. The key phrase is "DX9 implementation" which is what sets DX apart from OpenGL. I can use HLSL with any DX9 compliant card. Can't necessariy do that with Cg, due to it's implementation.

Jenny jenny

[Anonymous Coward]

who can I turn to? 867-5309

OpenGL + Perl

[Anonymous Coward]

Apropos to the recent Perl 6 announcement I'll just go ahead and mention the perl interface as well. Wouldn't want anybody to forget.

Shader language

[gtada]

Anybody checked out the OpenGL Shader Language? Is it like HLSL (same syntax as Cg)? I've been learning Cg, and I have to say that I like it... I'm kinda hoping developers will standardize on Cg.

Re:Open GL?

[noselasd]

"OpenGL is the premier environment for developing portable, interactive 2D and 3D graphics applications. Since its introduction in 1992, OpenGL has become the industry's most widely used and supported 2D and 3D graphics application programming interface (API), bringing thousands of applications to a wide variety of computer platforms. OpenGL fosters innovation and speeds application development by incorporating a broad set of rendering, texture mapping, special effects, and other powerful visualization functions. Developers can leverage the power of OpenGL across all popular desktop and workstation platforms, ensuring wide application deployment.
" - www.opengl.org

And as an additional note, you need an OpenGL driver specifically for your gfx card to take advantage of the hardware acceleration it can do. An OpenGL implementation in software is provided by e.g. Mesa - http://www.mesa3d.org/

Indeed

[Ridge]

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

Step toward OpenGL 2.0

[Frohboy]

Granted, OpenGL 1.5, with improved programmable shader support is indeed a step toward OpenGL 2.0, it is really a fairly minor evolutionary step.

When OpenGL 1.0 was initially proposed, it provided a standard implementation for fixed pipeline segments (with the idea that individual implementations could selectively choose which pieces of the pipe would be implemented in software, and which would be implemented in hardware). This was a very significant development, as it meant that everyone could operate with the same set of rules, and could do the same things, but those without hardware support may suffer some performance penalties (of course, with modern CPUs, some of the stages in the pipeline can have very high-perf implementations in software).

Since then, the rules have changed significantly. Hardware developers have started to suggest that the behaviour of the individual components of the pipeline could be programmable. NVidia and ATI have already responded to this, providing a wide variety of programmable shader technologies (e.g. programmable vertex and pixel shaders). I understand that OpenGL 1.5 essentially brings this level of programmability up to current levels (I think that DirectX 9.0 does the same thing, but I would love for someone to correct me on this. I haven't touched DirectX in a while, so I'm a little rusty. In fact, at the pace that hardware is evolving, I'm actually very rusty, and likely collapsing due to decay.) OpenGL 2.0 extends this idea of programmability to every stage of the pipeline. For most current video cards, this means that a lot of that programmability has to be implemented in software (which is essentially what people are doing anyway. If you want to implement programmable textures, you write software that interfaces with your video card's static texture routines.) 3DLabs is hoping to turn the computer graphics world on its ear by providing almost completely programmable graphics cards. Nearly every stage of the pipeline should be programmable in hardware. Of course, we will have to wait to see what they deliver, but I imagine that even if their cards suck ass in terms of performance (or they'll be targetted to the super high-end, so most of us will never see them), they should offer some features that will force some new developments from ATI and NVidia, which will eventually make their way down to regular consumers.

It's good that OpenGL 1.5 is out, to help keep OpenGL on the map of standards (especially since DirectX is a really inconvenient standard for those of us who don't run Windows), but I'm still pretty psyched for the release of OpenGL 2.0, w00t!

Re:Step toward OpenGL 2.0

[Stary]

I think that DirectX 9.0 does the same thing, but I would love for someone to correct me on this.

Okay, so here's for you, not a correction but more like a clarification: DirectX has had this functionallity since at least DirectX 8. For game developers, these things aren't "new and exciting" anymore, they're things you need to make a new game. So - this issue of not having a standard interface to programmable shaders in opengl has been a big factors in making people move to DirectX for a while now, so this is really a welcome update.

OGL 1.5 - Legal Issues

[BigFootApe]

IFAICR, nobody has been able to do work on programmable hardware shader support for DRI (because of IP issues on some GL_ARB_Vertex* extensions). Is the new shader language similarily problematic?

Re:OGL 1.5 - Legal Issues

[dmiller]

I suspect that it is due to a lack of documentation from the hardware vendors rather than IP issues.After all - DRI wouldn't *implement* the vertex/shader programs, just expose the functionality that the hardware already has.

Unfortunately, no-one on the DRI mailing list responded the last few times I asked there...

Re:OGL 1.5 - Legal Issues

[BigFootApe]

OpenGL Extension Registry:

Look here for the document on GL_ARB_vertex_program and here for the document on GL_ARB_fragment_program. Specifically, look under IP Status.

Hardware shaders definitely have legal entanglements.

Re:OGL 1.5 - Legal Issues

[dmiller]

Yes, but it is not the DRI that _implements_ these - the patents would have to be licensed by the hardware vendor.

What about the postscript desktop?

[Aqua OS X]

No doubt, my knowledge of 3D APIs and hardware is pathetic; however, what exactly do you mean by "fully OpenGL desktop"?

I thought Apple's intentions were to give users a postscript desktop. OpenGL is simply a window to unused 3D hardware that could be used in place of an expensive proprietary postscript coprocessor (ie; like those old NExT cubes).

Isn't quartz extreme no more than an openGL wrapper?

Re:What about the postscript desktop?

[Dominic_Mazzoni]

No doubt, my knowledge of 3D APIs and hardware is pathetic; however, what exactly do you mean by "fully OpenGL desktop"?

Quartz Extreme, Apple's name for the Mac OS 10.2 version of the Quartz Compositor, uses OpenGL to render what you see on the screen. Note that just because it uses OpenGL doesn't mean that it uses any 3D - all it takes advantage of is 2D bitmaps, special effects like shadows, and alpha transparency.

But that's a really big deal! It means that all of the bitmaps representing your windows and other screen objects are in your graphic card's RAM, and moving a window in OS X doesn't require computing of any pixels at all on the CPU. (Unfortunately, resizing is slower, because every redraw requires sending a new bitmap, of a different size, to the graphics card.) This also allows them to do the Genie effect, window scale effects, and Expose superfast without wasting any CPU cycles. Compare that to Windows or X - when you move a window, all of the windows underneath it get repaint events, which can take a while to trigger depending on the application.

Note that the Quartz Compositor is a totally different thing than Quartz, the new 2D graphics library in OS X that is designed to replace QuickDraw.

The Quartz Compositor is what makes it possible for QuickTime movies to keep playing when you minimize them to the dock, transparent overlays to smoothly fade in and out when you hit a volume control key on the keyboard, and 10.3's fast user switching to literally "rotate" the screen in 3D to show the other user's desktop.

Quartz Extreme - i.e. using OpenGL to implement Quartz Compositor - is what makes it fast.

The great thing about Quartz Extreme is that Apple has only begun to explore the possibilities. The fast user switching effect probably only took them a day to code up, because all of the underlying technology was there.

Re:What about the postscript desktop?

[darkov]

The Quartz engine (the 'postscript desktop") is used largely to create the contents of the windows. OpenGL, at this stage, is used to paint the windows onto the screen, after they've been rendered by Quartz (or Quickdraw in some cases). OpenGL gets more hardware support than Quartz rendering. A fully OpenGL desktop might leverage more of the hardware so that it becomes more of a "wrapper" for GL, but I don't think it's that simple. Maintaining the rendering quality of Quartz may mean OpenGL isn't up to scratch in many places.

Re:What about the postscript desktop?

[darkov]

But that's a really big deal! It means that all of the bitmaps representing your windows and other screen objects are in your graphic card's RAM, and moving a window in OS X doesn't require computing of any pixels at all on the CPU.

Actually, that's due to the fact that the bits are in your computer's RAM. Quartz double buffers all drawing so that it doesn't flash and looks smooth. Because of this no redrawing has to be done when part of a window is revealed. On the other hand, resizing means that the buffer has to be reallocated and redrawn.

Re:What about the postscript desktop?

[IamTheRealMike]

Yes, all that is absolutely correct. I'd just like to point out that you don't really need to use OpenGL to do those things though, at the end of the day the 2D/3D primitives all boil down to a sequence of instructions to the card. For instance X pixmaps (on XFree) are already stored in video RAM.

The main problem with XFrees responsiveness is not whether it uses OpenGL or not (which ultimately makes little difference) but how it interacts with applications and how it pokes the video card. For instance very few drivers fully accelerate RENDER (which is 2D hardware acceleration for alpha channel blending and some other things). That means you end up doing very slow framebuffer reads, compositing in software then upload. I guess part of the reason for using OpenGL was to work around the reluctance of driver manufacturers to write specialist fully optimized drivers for their hardware.

Not to mention that most apps are very slow at processing Expose events. There has been talk of doing what MacOS does here and having apps directly render client-side into a compressed backing store.

Re:What about the postscript desktop?

[Aqua OS X]

Interesting... so how exactly does postscript/pdf play into this?

Re:What about the postscript desktop?

[CableModemSniper]

Its a different layer of abstraction. DisplayPDF is used to 'describe' the widgets, the window contents, etc. The OpenGL part is getting this information (in a rawer form, ie. pixels and textures, what have you) to the card. Its kinda like how the grpahics card cares very little about the internal representation of a JPEG file, it just draws the pixels sent to it. If Apple based their desktop on Jpegs (a really bad idea) they could still use OpenGL to render it.

Re:What about the postscript desktop?

[eggnet]

No, it's because the bits are in your Video RAM. If they were in main memory, they would have to be transported to the video card via the cpu, or at a minimum consume memory bandwidth.

What I always wondered

[Anonymous Coward]

I've heard the comments before that Direct3D/Quickdraw3D are "high-level" standards, and OpenGL is a "low level" standard-- i.e., OpenGL is largely primitive things, meaning developers must implement a bit more engine on their own; Direct3D tries to bring in the programmer at the higher level but limits them if their needs don't exactly fit that of Direct3D. Is that an accurate portrayal?

What I always wondered is why the OpenGL people don't promote a two-level standard; the low-level is OpenGL as it exists now, the second level of the standard would be optional. and consist of the kinds of things that Direct3D/Quickdraw3D would have offered, higher level things. The second-level standard would be implemented on *top* of the first level standard, meaning it would be as portable as the base is and not provide a roadblock to changes in creating new opengl versions. Something like Mesa.

Is this an attractive idea, or do the present existence of third-party libraries that sit on top of opengl make such an idea irrelivant? Even if so, it seems a "standard" higher-level library for opengl could take out one of the big complaints of Direct3D programmers ("OpenGL is too much work!")

Let me know if anything i've said here is wrong; I've followed the Direct3D/OpenGL argument but have personally done nothing more complex than some simple GLUT applications. (And I didn't even get enough into GLUT to see to what extent it functions as a higher-level 'cover' API for OpenGL..)

Re:What I always wondered

[ericvids]

> I've heard the comments before that Direct3D/Quickdraw3D are "high-level" standards, and OpenGL is a "low level" standard

Yep, Direct3D does try to bring in the programmer at the higher level, and it does limit the programmer if they're programming anything other than games. That's because Direct3D (and DirectX in general) is meant for games in the first place; other media-intensive apps are somewhat secondary, although they can be done in DirectX, and for that particular application you have DirectShow (which used to be separate from DirectX, FYI, but is now part of it. I don't know why, but Microsoft said so.)

I think Direct3D is more of that two-level standard you're trying to elaborate on. In fact, for a while Direct3D really is defined like that--it used to have a "retained mode" for high-level apps and an "immediate mode" for low-level ones. (They've since unified it into one immediate mode and did away with retained mode altogether.)

The primary users of OpenGL, on the other hand, have been on the field for ages already, which means that they probably have all of the higher level stuff as part of their intellectual property. Using another vendor's API for what they already have is generally a dumb thing to do (lost productivity due to the fact that most of their apps are written in their old, working libraries already, and rewriting them in Direct3DX is tedious and error-prone). Besides, OpenGL clearly defined itself as a standard for displaying high-performance graphics, and helping the programmer on his other tasks (representing models, parameterizing the effects he can do in his engine, etc.) isn't really part of that goal.

Re:What I always wondered

[Avakado]

What I always wondered is why the OpenGL people don't promote a two-level standard; the low-level is OpenGL as it exists now, the second level of the standard would be optional.

That is what GLU is for, and GLUT does some job too.

Re:What I always wondered

[Anonymous Coward]

Well, there's OpenInventor, very, very popular in the "serious" 3D science/engineering/architecture world. It's also excellent for games, I found. But the problem was most implementations cost $$$ - it's only relatively recently that free ones have appeared.

Re:What I always wondered

[idlethought]

This suggests there is a hole waiting to be filled by OpenGL.GAME - extensions that provide those features the games writers want specifically.

Open Source being Open Source I imagine there are five or ten contenders already floating around- anyone know which are best of breed for BSDish Licencing and GPL Licencing respectively?

Re:What I always wondered

[gbjbaanb]

I don't know about 'extensions' but there are plenty of game libraries.

SDL could be considered one, it handles OpenGL windows.

PLIB (.sf.net) is a game library, it contains some feaures that assist games developers (a GUI, fonts, scene graph, utility fns).

OpenSceneGraph is rather good.

and a host more - use google to find them, or search through SourceForge, or even the OpenGL page has a set of links.

As for the licence - most of these are LGPL, which I think is the most appropriate licence for a library.

Re:What I always wondered

[JohnFluxx]

OpenSceneGraph can use sdl btw - a rather powerful combination too

Re:What I always wondered

[p3d0]

What I always wondered is why the OpenGL people don't promote a two-level standard; the low-level is OpenGL as it exists now, the second level of the standard would be optional. and consist of the kinds of things that Direct3D/Quickdraw3D would have offered, higher level things.

Forgive my ignorance, but isn't that what GLU is for?

Re:What I always wondered

[Anonymous Coward]

I wouldn't say the OpenGL is lower level the DirectX. In fact DirectX lets you get practically full access to the video hardware, while the features in OpenGL, even with custom extensions, usually get you nowhere near the full capabilites of the hardware.

I don't know how DirectX could only be useful for games. It was true a few years ago, but certainly not know. I think that DirectX is now the standard and OpenGL is something that tries to keep up with the pace. DirectX 9 is perfectly suitable for practically anything while OpenGL seems to be standing still.

The problem with OpenGL is that it doesn't let your hand on the hardware. No locking of texture memories for example. A very important feature that seems to be never coming.

Re:What I always wondered

[johnnyb]

"What I always wondered is why the OpenGL people don't promote a two-level standard"

That would be silly. Why not give people a choice of what to use on the second level? Especially if it's implemented in terms of the first level, it really doesn't matter what you use.

Re:What I always wondered

[Anonymous Coward]

Forgive my ignorance, but isn't that what GLU is for?

Correct: GLU provides high level facilities, including tesselators, mipmaps, quadrics, ( spheres, disks etc. ) NURBS ( a higher level interface to the evaluators in OpenGL ) as well as many other features.

if you want higher than that there is Open Inventor.

Re:What I always wondered

[p3d0]

Thanks for the link!

How will this affect Doom 3?

[Muhammed Absol]

ID is already doing amazing shit with OpenGL, will this be something that helps a game like D3 do more or do the same thing faster?

OGL 2.0...

[zenyu]

- What still remains before we can say OpenGL is back toward its original goal (you write for one standard instead of having to write for every single little card driver, something kind of ruined by the fact that many things these days, every card uses a different opengl "extention" to do the exact same goal.)

- What still remains that DirectX excels at that OpenGL is lagging behind at


I don't think pt.1 has really been lost, unless you are doing really cutting edge stuff you can use OpenGL pretty happily as is. Many scientific applications are actually coded to Performer which works just fine on OpenGL 1.0. I've written lots of stuff, some just a couple years ago, that used plain immediate mode OGL 1.0, with a switch added later on for vertex arrays.

What remains is the vertex and pixel shaders, these will be in 2.0. They are already pretty much supported with the nv FX and I guess the 3D Labs card. I haven't been programming the ATI card, though many have for it's speed advantage, but from what I understand it doesn't quite live up to the requirements of 2.0. Also I think 3D Labs is pressing for infinite length programs, this can be implemented in the driver by simply compiling to multiple passes implicitly, though who knows about the performance. But the nv would handily beat the ATI if you do this because it can natively handle pretty long instruction streams. Unless this is already a driver trick, I dunno.

2.0 will almost certainly wait until ATI is ready on the hardware level at least. If you program to extensions...OpenGL is ahead of Direct X, but this means you are stuck with the vendor if you use their specific stuff, say using fp30 Cg on the FX. I think everyone pretty much does program to extensions and not the standard if they are doing cutting edge stuff, usually with a compile or run-time code switch based on the extensions present.

Official Java bindings, finally

[lokedhs]

It's great to see that the Java bindings will become "official". Anyone who messed around with Java3D knows why this is a good thing.

Re:Official Java bindings, finally

[SanLouBlues]

Yes! The only question is whether they'll make it a part of the standard JRE which would help make java a healthy competitor to shockwave in the world of premium minigames. That and whether we'll be able to put OpenGL contexts in a MFing lightweight component instead of using awt.

Re:Official Java bindings, finally

[MojoMonkey]

Don't forget, there are two very popular bindings currently out and very usable: lwjgl which does away with AWT/Swing and JOGL which keeps AWT/Swing support. I currently use LWJGL for some hobby stuff I'm doing. Bindings are begining to become VERY good, especially using the new nio package.

Re:Official Java bindings, finally

[sbrown123]

There are more than just lwjgl and JOGL:

GL4Java
SDL4Java (has an OpenGL binding)

development speed is critical

[rexguo]

I'd much prefer to see Sun/SGI base their work on GL4Java (www.jausoft.com/gl4java) than starting from scratch all over again. The industry needs this now and needs it fast. Microsoft has already got DX9 bindings for .NET months ago, but Sun/SGI has only announced it -now-? GL4Java, which is open-source, has been around for a long time and is pretty mature. It has survived the competition from commercial offerings like Magician (which is now dead). In fact, last year, SGI (or was it Sun?) used a customized version of GL4Java to show off the new NIO features of Java, rendering a 300MB+ terrain dataset in real-time. The speed at which Sun/JCP develops Java, and the speed at which SGI/ARB develops OpenGL, is a shame, let's hope they change this tradition this time!

Re:development speed is critical

[rreyelts]

Actually, Sun is already sporting a new OpenGL binding for Java, JOGL, which has been available for several weeks now.

One of its key features is that the Java bindings are automatically generated from the C OpenGL bindings, so it's pretty trivial to keep it up to date with the very latest changes Compare this to gl4Java which has really started falling out of date.

Unless you already bought one

[Namarrgon]

...drivers will adapt by simply compiling the code before passing it to the card

Sure, if you already HAVE a fancy-schmancy GeForceFX/Radeon 9500+ level card. For previous-generation hardware, you might get very simple shaders to work, but for more complex shaders that require looping, data-dependant branching, overbright float pixels etc, you're still gonna need new hardware :-) Even earlier hardware, well, tough - you might get vertex shaders if you're lucky.

Now if the cards can accept the high-level language itself...

No chance :-) It's difficult enough to decode the time-encrusted x86 instruction set for efficient hardware execution by a flexible CPU. It'd be a helluva lot harder to decode modern, high level, arbitrary-syntax code for execution on a much less flexible, highly parallely & extremely specialised GPU...

Re:Unless you already bought one

[ericvids]

> Sure, if you already HAVE a fancy-schmancy GeForceFX/Radeon 9500+ level card.

I think this concerns those guys who got the top-of-the-line cards just now, anyway. *Of course* they'll be concerned if the card they just bought becomes useless this soon. I'm pointing out that it's (probably) not the case with OpenGL 1.5 -- it seems that most of it can be implemented on existing 1.4 hardware. I'm not so sure though; haven't read the specs yet.

> No chance :-) It's difficult enough to decode the time-encrusted x86 instruction set for efficient hardware execution by a flexible CPU.

That's because x86 uses a general instruction set. The reason why graphics cards have attained a faster rate of speedup than Moore's Law is because graphics uses very specialized instructions, with a lot of room for optimization.

We'll probably never get the syntactical form of the high-level language understood on the card anytime soon, but for the bytecode form of the high-level language (ala Java), it's a very good possibility... and it's less ambitious (more feasible) than that of the Java-chips....

OpenGL rulezzz !

[Anonymous Coward]

GL4Java is great, but i never understand why those people never did a JCP! By the way Java3D is ready and working for years ;-) Ok, it is not suitable for gaming but it is just a wonder to prevent 3D headaches.

Looking at how few people get interrest in the multimillions buck And the MS.net FUD, no one realy fear the MS "wonderland platform" as a replacement of Java or C/C++, anymore.

Just a big costy joke from MS again .... that f**ked up the VB users and all the MS legacy skills :o)

Glad to see SGI back in the place on OpenGL anyway !

SLK

What happened to Fahrenheit?

[gakguk]

All I remember about it is that cool poster of flames on the water or something.

Re:What happened to Fahrenheit?

[lokedhs]

Farenehit was a great success, actually. Not many project succees in doing exactly what they set out to do.

Microsoft said that Farenheit would be the new standard 3D API and replacement for DirectX, and they managed to get SGI on board on it, which of course was the only purpose.

Remember that at this time DirectX was hopefully behind OpenGL, and Microsoft needed to make sure that OpeNGL development came to a standstill for a year or so while they were improving DirectX. After they had suceeded with that, it was time to kill Farenheit and that's what they did.

When will companies learn? There is no way you can enter a partnership with Microsoft and come out on top.

OpenAL

[Wuukie]

Now we have OpenGL and OpenML. It seems nobody picked up OpenAL when Loki left the building.

Do Linux game developers (or anyone at all) use OpenAL nowadays for environmental sound effects? Is it any good in its present state? It seems the website www.openal.org hasn't been updated since 2002. Well, most of the stuff seems to be from 2001...

Re:OpenAL

[AllUsernamesAreGone]

"It seems nobody picked up OpenAL" Creative are the main supporters now. OpenAL is used in UT2003 and quite a few Linux games. The website is badly out of date - you pretty much need to be on the developer list to get the latest information.

Re:OpenAL

[Anonymous Coward]

UT2003 uses OpenAL.

Re:OpenAL

[jvalenzu]

Yeah, the web site needs to be updated. It will be soon, as part of a larger overhaul spearheaded by Creative. Hopefully this will serve to quell many of the people who think that no development is going on because we never rarely update the website.

OpenAL on Win32 I'd say is much more actively and aggressively maintained than its linux counterpart. Currently it's suffering from the lack of a full-time maintainer and not enough community contribution. I don't know if that's a metric of lack of general interest in sound programming, a lack of interest in 3d audio, or lack of interest in OpenAL.

I strongly suggest anyone interested to subscribe to the mailing list. Check the website for more info.

Re:OpenAL

[Wuukie]

Thanks for the update. Good to see the efforts didn't go in vain.

The website definitely needs to be updated. I haven't been developing with OpenAL, but I was interested in it. But I lost my interest even back then when Loki was still there. The website showed no life at all and I didn't bother to check out the mailing lists because all I wanted was news and information about the proceedings.

What's your position regarding OpenAL? Do you see OpenAL has gained developer interest in recent times? Do you see it becoming recognised standard a la OpenGL?

Re:OpenAL

[jvalenzu]

I guess I'm the defacto Linux OpenAL maintainer. I wrote the linux implementation when I worked at Loki. But my current maintenance is anything but full-time, and the existing code is looking very long in the tooth.

OpenAL is gaining interest on the Win32 platform, which is really where it counts. Creative in general and Garin Heibert in particular have been phenomenal, really good citizens of the free software community. There are developments under way that may help that. Ryan Gordon has used it for some of huge mountain of porting work he does, and as a matter of protocol, any fix or feature that Ryan wants, he gets.

On the Linux platform, who knows what the future holds. I'm really not trying to be a troll but my view of the feasability of the Linux desktop and Linux gaming has gotten much more pessimistic since my time at Loki. OpenAL may be recognized as a "standard" complement to OpenGL just as OpenGL loses all remaining relevancy.

But ignoring all those things - the things out of Linux user's immediate control - I have it on good authority that the web site will more accurately reflect the things going on with OpenAL development very, very soon. If you have an interest, join the mailing list. To quote a reliable source, "it really is your library."

Re:Open GL?

[afroborg]

STFW
Google is a wonderful thing

Remote OpenGL apps

[Brian Blessed]

Related to this topic, I would like to know if I can run OpenGL programs on one of my thin clients over X, i.e. what hardware and software is required?

I know that people have done this with SGI kit, but most commodity X drivers don't seem to support remote OpenGL and there is precious little information around.
Has anyone tried this?

- Brian

Re:Remote OpenGL apps

[Goth Biker Babe]

If it's a decently implemented X server on the client then it should support it provided the application isn't using any calls or extensions that aren't supported. For example my Linux PC (with GForce4 graphics card) will work as an X server for my Indy for some applications but not for others.

Re:Remote OpenGL apps

[Oggust]

That's probably because many old SGI apps need DGL, which nobody but them supports. Remote OpenGL works really well though, I use it all the time.

/August.

Official Open[GL,AL] bindings for Java

[MarkSwanson]

Sun announced full Open[GL,AL] support here:

http://games-core.dev.java.net/

Here's a great example of using OpenGL/OpenAL under Win32/Linux written in Java.
(It uses the LWJGL - which is an OpenGL/OpenAL Java wrapper that uses nio).

http://www.puppygames.net/

Tremendously slow progress

[Junks Jerzey]

Microsoft rushed ahead with Direct3D in the mid 1990s, made lots of well-publicized mistakes early on because of a general lack of 3D knowledge, then nailed it starting with the graphics side of DirectX 8. The next version, DirectX 9 is a dead-on match for what's generally considered the state of the art in PC video cards. Microsoft isn't even planning DirectX 10, because DX9 is still way beyond what most people need or use (well, that, and the overall decline of the the PC video market). And, believe it or not, DX9 is a breeze to use and has a well-designed API (once you get over the usual COM nonsense that comes with DX in general). Meanwhile, OpenGL, which I'll admit was much better designed from day 1, is going to reach the DX9 level in about five years, if things keep going as they are.

The article confuses me.

[Randolpho]

In it, it makes no mention of Java3d, which is a scene graph API with bindings to OpenGL or Direct3d. Is this announcement going to be a thin binding, or a new version of Java3d? Or will it replace Java3d?

Inquiring minds want to know! :)

Re:The article confuses me.

[deanj]

Java3D is currently on hold. This isn't a replacement for Java 3D, it's just something different. Kinda like Inventor is different than OpenGL, although it uses OpenGL.

Re:The article confuses me.

[Randolpho]

Hmm....

I didn't know Java3D was on hold -- I've been trying to write a program with it for the past few months too.

I wonder what this is going to be like. I'm not sure if I would prefer a thin wrapper or a totally new API.

Re:The article confuses me.

[deanj]

I'm using JOGL now, and haven't run into any problems. It's basically straight OpenGL, with only minor set-up things you have to do (initing the window, etc).

Re:The article confuses me.

[Mithrandir]

Not on hold - its officially dead. All of the resources working on the project have been moved off and are now working on either JSR-184 or the new OpenGL bindings JSR (once it gets started).

We're involved in various efforts to replicate and replace Java3D with another scene graph. If you need something immediate, take a look at the Xith3D project from Dave Yazel and the MagiCosm guys. Alternatively, if you can wait a couple of months, we're in the process of ripping our OpenGL scene graph out of the core of Xj3D to turn it into a separate project. The difference between the two is that Xith3D is focused on games (it has primitive objects for particle systems, for example) where our work is focused on CAVEs, powerwalls, linux clusters etc.

Re:The article confuses me.

[deanj]

It's not "officially dead" until Sun says it is. When I spoke to the developers at JavaOne, they said it was on hold. That's the official line right now.

Re:The article confuses me.

[Mithrandir]

Sun cannot ever proclaim anything dead. It is admission of failure to them and therefore not acceptable. If you are waiting for them to declare it as dead, you'll probably die before they will state that. JSDT is still officially "on hold" too - it has been for the last 4 years...

When evertything has been cancelled, and their developers are now not answering emails on the java3d list, and have been assigned to other parts of Sun, it is dead. Also, we already have been told that we'll have access to parts of Java3D - either completely open source, or access to the patents. Either way, they are not doing any more development on it, nor are there any intentions to return to develop it in the future.

Re:The article confuses me.

[deanj]

Yeah, I know...I know... technically (offical Sun party line), it's not dead, but for all practical purposes, you're right, it is dead. I was just relating what one of the developers said at JavaOne. I did a lot of work with it, so it's hard to see it go.

It'll be interesting what happens with the patents, particularly the .compile() part of the API, since I believe that's one of the things Henry Swizworal (I never could spell that) and the hardware guy (who's name escapes me at the moment...John Deering maybe?) got a patent on.
At one time I believe they were going to implement that in hardware, but the PC hardware vendors overtook the industry and basically made that irrelevent.

The real shame of Java3D's history is they never did put the proper number of resources on this project. I don't think there were more than three or four people working on it at any one time at Sun. I think they did one more release after Henry left for that networking company in Seattle, and that was basically it. They were working with Hanrahan's group on a shading extension, but I think that basically went away because of OpenGL's new stuff, and NVIDIA's stuff.

And actually, they do declare things dead. They put them into "end of life cycle" or something like that. HotJava is one of them. They have a page of the others, but I don't have that link handy. As you say, this rarely happens though.

You gonna start a JOGL FAQ site? :-)

2.0??? That's nothing!...

[siskbc]

...DirectX is already up to 9!

Too bad about Fahrenheit

[Serapth]

I notice the same thing happens everytime news is released about OpenGL or DirectX. Basically, it becomes a bash fest where one camp supports one API, and the other camp supports the other API. I've used both, and both have there merits ( well... Since Direct3D 7, they have... before that, D3D basically stunk). Now is a good time to bemoan what could have been.

Anyone remember Fahrenheit? The collabrative effort between SGI and Microsoft to redesign both API's, into a new, leaner more capable common api? Fahrenheit was to provide, a low level API, plus a scene graph api, plus a large model set api aswell. No more bitching... no more choose this, or choose that... no more being tied to one platform ( if you chose to use DX that is ).

Too bad... perhaps it would have all finally had a taste of world peace. RIP Fahrenheit, Ill miss what you could have been!

Ok... now back to the Direct3D vs OpenGL bashfest!

Re:Remote OpenGL apps (glx)

[TimeZone]

The glx X extension should allow remote execution of OpenGL apps. It basically works in a similar manner to X - instead of being executed remotely and drawing bitmaps on the local display, the OpenGL commands are passed to the local display, which renders everything. I tried it once a couple years ago, but it crashed my X server, so I've never actually seen it work.

TimeZone

Re:2.0??? That's nothing!...

[Anonymous Coward]

As a rule of thumb, when comparing Windows versions to non-proprietary alternatives, 9.0 2.0

The easy way

[KalvinB]

The easy way around that limitation is to have the artist draw the texture however he wants in any size and then have the coder stretch it into a best fit square. For instance if you have a 640x480 texture you can simply use Photoshop or whatever to set the image size to 512x512. For older cards you can have a second version shrunk to 256x256.

OpenGL and DirectX use 0.0-1.0 coordinates so it has no effect on the output (as far as the texture being mapped where it's supposed to be) as long as you don't crop the image.

Ben

comparison operator?

[siskbc]

As a rule of thumb, when comparing Windows versions to non-proprietary alternatives, 9.0 2.0

I'll assume slashdot ate your "less than" operator. Hey slashdot, can we please use angle brackets that aren't HTML tags?

Re:comparison operator?

[eatdave13]

You mean like this:

&lt; = <?

This might help...

[Yoda2]

Here is some more info on the Java bindings.

Definition

[Vegan Pagan]

OGL 1.5 is a step towards the OGL 2.0, already suggested 2.0 by 3DLabs.

A suggestion 2.0 is a suggestion you can't refuse.

If you can wait til quakecon....

[Sevn]

Not to bring "your" down, but they'll release a
playable beta version that we'll have for FREE
for a long damn time like they always do. Are you
old enough to remember when Quake3 Demo was the
most popular game on the net? If wasn't even a full
game. Nobody paid for it. They will do the exact
same thing with Doom3. Rumor has it they are
releasing the first multiplayer Doom3 demo next
month at quakecon. Considering they have already
announced they will be having Doom3 deathmatch
at quakecon, this rumor is probably close to the
truth.

Jedi Knight 2

[Anonymous Coward]

JK 2 used openal. I downloaded Creative's EAX optimized openal.dll and installed it in the JK2 directory in place of their standard dll. It was sweet.

run GL shaders now

[Anonymous Coward]

3Dlabs has an implementation of the OpenGL Shading Language available NOW that will run on all Wildcat VP cards.

On the 3Dlabs website are drivers, specs, an SDK and an open-source frontend for the Shading Language compiler.