Slashdot Mirror
The State of OpenGL
CowboyRobot writes "No longer vapor, but a true 3D-embedded engine, OpenGL is on the move. Pixar and others would love to be able to render their movies in realtime, and that desire has prompted the intended release of OpenGL 2.0, due in a few months. Khronos is now in charge of further extending OpenGL to cellphones and handheld gaming devices."
Pixar and others would love to be able to render their movies in realtime,
Ummmm......Pixlet.
Visit Jonesblog and say hello.
I don't know about availability, OpenGL is cross-platform (works on OS X, Linux, Windows, etc.) while DirectX is Windows only. OpenGL is also included with many if not all graphic cards. So it's just as widely available, if not more, than DirectX.
exactly thats the point of opengl es.
as it is only a subset of the opengl standard trimmed for low power/low speed devices it is (or will be) also fast in software. afaik there are also hardware renderers for opengl es in the works.
and remember:
we hat 3d games long before the gigahertz pcs with 3d accelerators were out and they were a tiny bit faster than 1 frame/second.
-- Karma: beyond good and evil - mostly affected by posting political
I'm going to learn opengl in a few months during the holidays before I start my PhD. I work with simulations of the Sun and use IDL to visualise the results. but I think it would be cool to have more "realistic" pictures, plus having the hardware acceleration has benefits when dealing with a lot of data (IDL gets real slow for 2D simulations at resolutions above a few hundred squared)
these simulations are done on beowulf clusters (imagine that!) so I think opengl is the best (the only other API I know of being directx)
OpenGL 2.0 is not as exciting as the new major version number might indicate. Probably the most important new feature of OpenGL 2.0 was going to be the GLSL high level shader language. However, in order to speed up its support by hardware companies, this was instead put into OpenGL 1.5 spec when it was announced last year; GLSL already has implementations by 3DLabs, ATi and nVidia. OpenGL 2.0 will still add some useful new features, but it won't be the world-shattering event that 3DLabs promised in their original proposals.
My friend is working on a multipurpose game engine, with the ability to "plug in" different graphics managers - so you can have the beauty of DirectX 9 on your Windows version, and seamlessly switch to OpenGL when you port it to Mac OS.
:-(
Or should I say, when I port it to Mac OS, since that's my job. I wish I had the slightest idea how his engine worked... He has all sorts of complicated code that compiles fine on his x86, but is gcc-unfriendly.
I've got more mod points and GMail invi
Jan 16th 2002: SGI transfers 3D graphics patents to MS
Jul 09th 2002: Microsoft Claims IP Rights on Portions of OpenGL
Jul 11th 2002: 3D graphics world shaken by patent claims
Jul 13th 2002: Microsoft patent claims may affect OpenGL
Mar 3rd 2003: Microsoft quits OpenGL board
I am a licensed indie Torque owner and I have to say it is a very impressive game engine when it comes to cross platform game development. Not only does it run pretty smooth just like games such as Wolfenstein: ET and Tribes 2 (T2 was actually not really good on Linux compared to it on Windows) its source code is actually gcc friendly.
:). It uses BSP structures for what is called Interiors which are basically buildings and the GG community has been making great advances in the game engine for several years so it isn't something that will sit there and idle for months, it's always being worked on by several groups of people. So the whole game engine development is mainly driven by community resource submissions.
About Tribes 2, its Linux port wasn't very good and it choked from time to time for no real reason and Torque engine doesn't have this problem. The real history of Torque is that it came about right after Tribes 2 was released and GarageGames company was formed which are several former Dynamix Employees (even the founder is the founder of the company) working at GG. Torque Game Engine I have to say is far better than the old Tribes 2 engine (if you worked with Tribes 2 and then Torque you would know exactly what I mean by it).
Anyway the engine is pretty good in my opinion and as a note to those Quake lovers Torque doesn't do BSP structures for the whole map. It has a true terrain system that goes on forever and no it doesn't loop all the way around (but I've seen mods pull this off
I guess I've talked my head off long enough and put several readers to sleep, sorry. Check out the site for yourself and maybe consider getting a license (please read the license agreement before forking over cash for it since I've seen many people ask questions about the license AFTER they bought it!)
This space is not for rent.
Most frames in Pixar movies are rendered using some form of ray-tracing. While it is possible to use vertex and fragment shaders in uncoventional ways to do ray tracing, this is *not* what the OpenGL pipeline is designed for. Great for games, but ray-tracing will still be done using render farms (and not in real time).
Two points:
First, they still sell black and white portable computers today, they've just shrunk; before they were 5-pound portables, now they're quarter-pound Palms.
Second, battery life, both for portable phones and portable computers, has been on the increase, not the decrease. My portable computer from the mid-90s (black and white, even) was lucky to get two hours. My giant, power-sucking G4 with a full-color 3D-accelerated screen is unlucky to get three hours; I can get five hours on light use. My girlfriend's full-color-screen, MIDI-playing, Java-gamed cell phone lasts for four days between charges. I see no reason for this trend to reverse; indeed, people tend to value battery life extremely highly, and so manufacturers value it accordingly highly.
Mod down posts with a "Free Mac Mini/iPod" sig, they're spam!
The original article post seems to confuse different forms of OpenGL. OpenGL|ES is the embeded stripped down OpenGL for mobile & embeded systems. OpenGL 2.0 is just a proposal from 3DLabs and may never get off the drawing board. Most of the significant changes that OpenGL 2.0 introduced have been implemented and released either as extensions or as part of OpenGL 1.5, so it's just not clear if or when OpenGL 2.0 will actually arrive, there's a lot of resistance because 2.0 intended to throw some stuff out and many developing, selling & using OpenGL implementations think that it's a REALLY bad idea to do that. With OpenGL|ES there is already a version 1.0 and you can actually get this in several forms from implementations that run on phones to wrappers around OpenGL that you can use on the desktop to emulate OpenGL|ES. OpenGL|ES is in the process of developing version 1.1 right now.
From coding experience the integration is pretty much non-existent or not very strong. APIs such as Direct3D and DirectSound have consistent API styles, but they don't share much API. It is possible to write an OpenGL application that uses DirectSound and DirectInput, like GLQuake.
The simplistic reason for this is that the full OGL spec, or even the "miniGL" drivers are still waaay to complex for what is needed on these devices. Things like multitexturing, and anything that requires readback from the state is especially costly. The point was that on these devices they dont want full OGL support. If they did, they wouldn't have even bothered starting this spec. It is to provide a spec that has a greatly reduced footprint (memory, API coverage, etc) that allowed first class 3D graphics on smaller devices. If you want full OGL support, you do full OGL, not a partial implementation. There is no point "working upwards to full OGL" because they are never going to get there with this spec. Once a device wants to head towards desktop OGL support, then they bite the bullet and implement the complete API.
It was also determined that most of that sort of functionality was not needed. Other things like 1D and 3D textures, attribute stacks, display list etc are just non existant. On the other end, there are things that never existed in OpenGL, such as the fixed point maths support, along with defined accuracy measures etc.
In the beginning, OGL-ES had two primary targets - small footprint mobile devices, and safety critical markets (ie avionics displays etc). In the former, they needed basic functionality, but enough to do things like overlays and texturing. In the latter, they needed a very small API footprint that can be verified IAW with various authorising bodies (eg FAA for avionics, NIH for medical devices etc). In both cases, a miniGL driver was just not good enough because miniGL still assumes the full OpenGL spec and only for one particular application. Both groups required a formalised spec that they can point to and claim "this is what we support", complete with some logo branding. miniGL still assumed a desktop based system, neither of the target groups for OGL-ES could make a lot of those assumptions (for example floating point abilities at all)
FWIW, I was a member of the ES spec development group until about 3 months ago and still am on the spec mailing lists.
Life is complete only for brief intervals in between toys or projects -- John Dalton
You may want to have a look at JSR-231 then, which is the official bindings of OGL in Java. If you need something more immediate, the JOGL project, which is the baseline for the JSR, should be checked out. It can be found on the java.net site.
Life is complete only for brief intervals in between toys or projects -- John Dalton
Well it's designed to run any sort of game, and a number of different "plugins" (a C++ class inheriting from an abstract plugin class) allow specialization as the given genre demands. So far using this engine a lot of 2D games have been developed - a working DDR clone (albeit only with keyboard support and crummy graphics), a decent version of Asteroids (vector graphics, scrolling, camera zoom, camera rotation, minimap/radar, running at 60fps or better - Asteroids is the testbed for most of the engine's new toys), a Commander Keen-like platformer (bitmap-based graphics with camera rotation and hundreds of enemies on screen with virtually no slowdown), an ASCII shoot-em-up and a few others I can't think of off the top of my head. There's also a primitive vector-3D game (6-player Pong with 5 computers :)....) using the engine.
The core engine itself mainly contains only a few pieces that are common to most genres: graphics management (which is then passed off to a renderer of your choice), UI element handling, collision detection, and the like.
The engine also has built-in scripting and a console mode (where the game pauses and you can enter commands as if part of a script, which is very cool, and very useful for debugging - stuff like SET_X PLAYER 120... and yes the console can be disabled)
I've got more mod points and GMail invi
> SDL is a reasonable answer to portability while still accomplishing the integration that MS has achieved, but SDL isn't really as mainstream as OpenGL is.
SDL and OpenGL are not mutually exclusive. I have very successfully used SDL to handle joystick input, window creation, and sound output, with OpenGL for 3D. SDL in fact is designed to work this way, since SDL will create OpenGL rendering contexts for you when you create windows, and it handles the fullscreen video modes far easier than any other method of creating OpenGL contexts that I have used.
And just for comparison: I ported a DirectX/3D game from windows to SDL/OpenGL on Linux, and cut out about 1000 lines of code in the process because the DirectX API is so ugly. (I realize that might imply DirectX is more powerful, and I also realize my abhorrence of the MS DX API may be simply personal preference, and to boot, this was a DX5 program, so the API may be simpler now. I'm just relating the facts as I found them.)
Oh, and wasn't SDL used by Loki quite often for porting games to Linux?
Drivers are closed source now. Drivers will continue to be closed source in the future in spite of where the compiler lies. Having the compiler in the driver is the right decision.
Don't like it. 3DLabs released the front end to their compiler. There is work being done in Mesa to support GLSL.
From now on, all bitching about open versus closed drivers will be modded as offtopic. Everyone knows the pros/cons and reasons for either decision. No need to drive it into the ground.
if i recall correctly, SDL was originally developed by a guy who worked at Loki.
Actually, Loki hired the guy who developed SDL.
When all you have is a hammer, every problem starts to look like a thumb.