In xgl you should disable it, the extension is present anyway (no matter whats written in the xorg.conf). Also, if you have a nvidia hardware, you should disable it in xorg.conf.
Then again, guess I'll have to go get that high end video card just to run the next distro.:)
No, actually not. The rendering presented in the video does not need a 7800. This is basic 3D rendering most on-board graphics chipsets can handle. This functionality has been around for a decade in consumer cards.
I agree. Furthermore, the current state actually does not make much sense. Considering that, for example, nvidia-chips do not have a dedicated 2D core anymore, the driver has to emulate 2D for the legacy 2D APIs that have been used until now. Essentially, dedicated 2D development is dead; its nonsense to have a 2D core since the 3D one can do everything 2D-related much faster and with extras like blending or shaders.
So right now we have an artificial distinction between 2D and 3D. The vendors have to deal with composite stuff AND with opengl acceleration, sometimes simultaneously. Using OpenGL as the base for everything is much better, since opengl already has a client/server-architecture, driver development gets easier, X as a whole becomes leaner, responsiveness and look-n-feel of X improve, and the CPU does not have to deal with fake transparency stuff.
So its all about moving the 2D/3D-distinction away from the driver into the X server.
I doubt we will see any changes in the AAA sector. Development is so expensive that stuff HAS to sell, thus new ideas don't get a chance. There are a few exceptions, the only ones I can remind of right now are Escape From Butcher Bay and Unreal Tournament 2004, both games surprised me - not necessarily because of the tech (although EFBB is very impressive technically), but because its a hell of a lot of fun to play them. I regularly catch myself playing old 2D point-and-click adventures and amiga games like Deuteros (the virtually unknown Millennium sequel, and one of the few sequels that are really superior to the first one), and I start thinking why no one does this marvelous gameplay with today's technology. (Then reality kicks in again and I remember the costs issue.)
Yeah, the next big hit will be the casual games and the indie games IMO. Slowly, tech is becoming "good enough" (unless you are a graphics whore). Its still a lot of work to get a decent-looking game done, but free gaming engines are becoming better and better (although most still lack decent toolchains), and if you look at projects like the FS2 source project (Freespace2 with vastly improved gameplay and graphics) or the Babylon 5 game, it becomes clear that indie games aren't necessarily doomed to have crappy looks anymore. It is impressive how far you can get with a Radeon9600-class hardware (again, see EFBB), the industry just doesn't make full use of it because of the tight time schedule - it is easier to force the customers to buy new hardware....
I hope Nintendo's move takes off and indie gamers make a successful return. The garage developer is back, ladies!:)
Escape From Butcher Bay Dreamweb Master Of Orion Deus Ex System Shock 1 & 2 Ascendancy X-Com 1 through 3 (#4 is a little disappointing) Fallout 1 & 2..... and many others.
Of course, if you manage to stay within the bounds of SDL, it is easier. But you seem to think that stuff like Unreal3 compiles trivially on both Windows and Linux, with almost zero additional efforts, and that it was soo easy to plan it that way from the start. Get real.
Also, you still didn't bring valid counter-arguments to my "irrelevant nonsense". Chances are, you have neither the skill nor the experience for this.
"Again, who cares? Why do you think this is about open source vs closed source engines? Yes, it took a while to make NeL. It took a while to make doom3 and unreal engines too. It even took a while to make the halflife 2 engine, didn't it? It takes years wether you do it portable or not. Ignoring this simple fact will not make it go away."
Its not open vs. closed, its typical-opensource-hobbyist-engine vs. commercial ones. Commercial does not mean closed source automatically. NeL is a good example for this. Yes, writing a cutting-edge engine takes years. It takes even longer if you don't write it for one platform only - THAT is what you refuse to accept.
"Because its CHEAPER. They don't want to add support costs for a very small userbase. This is what I said in my first post to this thread. Try reading it."
Try thinking for once. It is cheaper, right, because it is easier to develop, it takes less time, has less potential bugs, and results in less support necessary, less testing etc. If it would be really totally trivial to port it, with zero additional costs and time, then more companies would be doing it.
"Yes, simple engines like the doom3 and unreal engines."
These are the minority. They aren't "lots of people". These are TWO commercial engines. And the other tons of engines? Look for them in the net. There are TONS of simple engines with the setup I described (OGL, SDL..) And this is supposed to be representative? And, again: why isnt Source portable? Why is not the CryEngine portable? Unreal and Doom3 were developed by the two most famous and influential devs in their league. They have the luxury of writing ports to Linux. Most other game development studios don't, they need the game to be out as soon as possible, and this excludes platform-independence. It is easier and faster to use the WinAPI and DirectX directly in Windows, which still is the PC gaming platform Nr.1. Aside from Sweeney and Carmack and a few other commercial AAA developers (Unigine looks promising) only the hobbyist engines can afford the extra time to develop cross-platform.
"No, you have stated your opinion. I choose to believe the opinions of more experienced people than you. Not to be a dick, but who's opinion do you think I would give more weight, you or carmack? Nobody is saying that making a portable engine vs a non-portable one is exactly the same, just that when you consider the years of work involved, portability is a tiny piece that doesn't really have much impact on the total timeline."
For carmack it doesnt have much impact. For people porting the first time to Linux (i.e. the majority of all PC game devs) it has. To port existing codebases is so expensive no one does it just for fun. Developing a game engine from the ground up to be portable requires knowledge of cross-platform development, of issues with all platforms to be supported, and a great deal of software design skill to wrap this up nicely. Usually, your first engine is quite tied to the platform you developed it in, even when using OpenGL (try porting your engine when there are WinAPI/X11/WGL/GLX calls all over the place). Carmacks engines always relied on OpenGL, which makes things much easier (porting Direct3D stuff is near impossible, since it requires complete rewrites of huge portions of the code). It gets a lot harder if one starts supporting more than one API. But even with OpenGL only, it is far from trivial. Carmack has a lot of cross-platform development experience, also he is one hell of a coder, so I'm not surprised platform independence is not time-consuming for him. He also has the luxury to be able to start new engines from scratch.
If platform-independent engines are so easy to write, why are developers so keen on using XNA? Microsoft promises near-transparent portability between DirectX 10 stuff on PC and on the XBox - how can they advertise with it? No matter if XNA really works or not, why is this promise attractive? BECAUSE IT MAKES PORTABILITY EASIER, and therefore cheaper. Also, Mr.Carmack really likes XNA, and considers moving towards Direct3D 10.
"In a perfect world we wouldn't have this discussion."
Correct.
"There's more to 3D graphics APIs than cutting-edge gaming features."
Yes, but today, 3D gaming is one HUGE part of it. It is the driving force behind the progress in the consumer-level cards market. It is the number one reason why stuff like Doom3 or FEAR can exist today. If the ARB is reasonable, they recognize this. 3D-Gaming has become one main pillar of 3D graphics, there is no way around that.
"OpenGL was originally designed for professional 3D graphic modelling, not gaming."
See above.
"That it does so well in games is an example of how efficient and well thought out it was originally designed."
Well.... it does well, but it could do better. That's why OpenGL ES was designed. Also, it won't do well for games if the ARB decides to sleep again.
"Getting these new "features" into OpenGL is a no-brainer. Seriously. Children can do it."
Geometry shaders a no-brainer? Superbuffers? Practical, flexible instancing? Constant buffers? Well, they fit in nicely into the API, thats true, but the point is whether they will be available soon enough or not. Considering the ENORMOUS time it took them to finish the FBO spec (and its not even an ARB_ one yet, just EXT_ !), OpenGL's future may be grim.
"You have a point about drivers, since most drivers are closed-source, meaning we have to rely on nVidia and ATI to provide drivers that work with OpenGL. But if they didn't it would only hurt their products. There's always competition, nobody can use their market dominance to force something this significant."
Reconsider the market you are talking about. For CAD stuff you don't need fragment programs. You do need them for games. Of course nVidia and ATI will continue supporting OpenGL for CAD, but for GAMING? Remember that shader support is far from trivial. Developing driver code for it is time consuming and expensive. If there is no market for OpenGL games then well.... goodbye state-of-the-art. And goodbye gaming-in-Linux; AAA-titles for the PC will not be able run on another OS than Windows, since it will be the ONLY one with a cutting-edge 3D API.
Its not relevant if it is your favourite or mine. If it doesnt have cutting-edge features, it will fall behind. If it falls behind, less and less commercial games will use it, and less reason will be there for the big IHVs to write drivers supporting the API. And poof! its gone. THIS is the main problem.
Of course this doesnt matter if you develop stuff that works on your computer and never leaves it. But once you want it to run elsewhere you have to consider these things.
In a perfect world, there would be no Direct3D, since the ARB would be a fast, competent organization, and the API wouldn't be as cluttered. A SDK would exist, in its volume, contents, and documentation on par to the Direct3D SDK.
"And? What does this have to do with anything? Its a portable engine that anyone can view the code to see that you are wrong. I don't care how it was made, that has nothing to do with anything. The fact is lots of people make portable engines, and its not hard (compared to writing a comparable non-portable engine)."
First: Development of NeL took YEARS by experienced, full-time paid developers. THIS is the difference. Your typical run-of-the-mill opensource engine didn't experience that amount of development. Also, since you STILL do not understand, ask yourself why Crytek, Valve, Raven, Bungie, EA, and countless others do not write portable games. Guess what? BECAUSE IT IS EASIER. You can get away with the 3D API that is superior in Windows (Direct3D) - not technically, but in terms of extras & support (docs etc.) You don't have to abstract your system, and can safely access platform functionality directly, resulting in a faster development cycle. Also, linux user support, quality assurance, these things do cost, you know? The other facts (platform quirks, different compiler....) were already mentioned by me.
Lots of people make portable engines? Lots of people make SIMPLE portable engines. Most portable engines are a combination of OpenGL, SDL, and FreeImage/DevIL/Corona/. Most engines are little more than wrappers for these libs.
"The effort required to create that engine as it is, vs the effort required to make it non-portable is very similar. But of course your opinion is correct, and mine is wrong right? Because I have only written tetris clones and you wrote doom3 obviously."
I already brought the real-world facts that prove that you are wrong and writing portable engines isnt easy. Your choice to simply ignore them says a lot.
Right now, OpenGL is on-par with Direct3D 9, now that the framebuffer object extension is out. Direct3D 10 is a wholly different issue, however. It has support for geometry shaders, constant buffers, superbuffers... OpenGL needs to catch up with new extensions or else it will fall behind, again. And this time, it may not survive.
Correct. The mind is much more sensitive to correct motion. I guess good motion blur and very good animation together can help a lot. Lighting is very advanced these days, in static settings PRT can make it look very real if used together with HDR. So this one isn't lacking, but animation is. Lighting has been pushed a lot in the past, but animation was left behind. A serious mistake. Half-Life 2 did it right (or at least less wrong than most) by improving animation.
"Ah yes, that's why people are releasing commercial games written with them right? Would you care to backup your bullshit by telling me what is wrong with the engine behind saga of ryzom (NEL)?"
NeL is not your typical opensource engine. Its a commercial product with an opensource option, just like Radon Labs Nebula Device.
"What kind of crazy non-sequiter is this? I didn't say anything about toolchains, or even that anyone should use an open source engine. I simply said they are there so anyone who wants to see you are wrong can. Just look at the code, portable, full featured 3d engines used in commercial games. Its not a big deal. And even some closed source engines are portable."
Wrong. Its quite simple: "full featured" has to include a good toolchain, or else its not full featured. The Unreal 3 Engine is full featured. Ogre is not. Irrlicht is not. Crystal Space is not. Nebula/Mangalore is not (unless you buy the toolchain from Radonlabs). If you mean "full-featured for graphics", then you aren't talking about a GAME engine (there's more to games than just graphics you know). But for developing portable games easily you need a good, portable GAME engine. Clear?
"Uh, you are telling me the doom3 engine isn't good? Or did you forget that its portable too?"
And of course you believe that it was incredibly easy to make it portable, right?
Have you EVER actually written something portable that's more complex than a Tetris clone? I sincerely doubt that. So here's a tip for free: stop talking about stuff you don't understand.
"but I would like to see an example of "import parts of a 3D engine" that are still hand coded in assembly."
SSE1/2/3-optimized math stuff maybe? Those 4x4-matrices fit nicely in SSE.
"You do realize there are full featured, portable, open source 3d engines out there right?"
Yes, and NO ONE of them is an AAA-production option. The _best_ engines are commercial ones. There is no Opensource engine able to keep up with Unreal3. Maybe in 3 years, but Epic will have realtime raytracing engines by then. Most opensource 3dengines lack decent toolchains. A toolchain means more than just some exporters. By toolchains I mean stuff like UnrealEd or the shader builder shown in some Unreal3 screenshots. A full-featured, state-of-the-art opensource GAME engine (i.e. not just graphics) just does not exist. Period. Many try to write one, no one succeeded yet.
"So anyone can go ahead and see that making a portable 3D engine isn't any harder than making a non-portable 3D engine."
Hahahaha. How funny. Once you get to the point of writing a GOOD engine you will see that you are wrong. I don't mean OpenGL initialization, you can get away with SDL for this one. (But, there are pbuffers, which are platform-dependent; they still need to be supported since FBOs are quite new and not supported everywhere yet.) Next: sound? OpenAL has some serious performance issues with Ogg playback (the UT2004 linux devs didn't like this), so you may be forced so switch to something else, again the best libraries are commercial ones (FMOD, BASS...). SDL input is very basic, you may be in need of more (libraries like OpenInput and OIS aren't very well documented). Also, platform issues like shared object handling, compiler handling, compiler quirks on each platform etc. won't make life easier. In Windows Visual C will be used almost certainly (sorry MinGW devs), so you cannot get away with a win32 gcc. Also, in Mac you still have the endianness problem (until they finish switching to Intel).
And, you forget that Direct3D has a VERY good documentation, tons of samples, both covering even state of the art stuff like PRT and HDR. Microsofts XNA program result in a D3D game be very easy to port to the XBox - another BIG plus. Sony is going for OpenGL ES + Cg, but this OpenGL is quite different from the one you use.
As the GP said, an OpenGL pendant to the Direct3D SDK is missing (yes, I know the D3D SDK is no standalone package). Also, Direct3DX is a wonderful Direct3D utility library, I miss something comparable in OpenGL. Last but not least, if OpenGL does not get superbuffers and geometry shaders/programs soon, Direct3D 10 will again lead.
AJAX for 3d modeling? AJAX for word processors? AJAX for image manipulation?
Yeah right.
Re:Distribution on Windows
on
Why Use GTK+?
·
· Score: 0, Offtopic
I develop in Windows and Linux, and would NEVER use Gtk in Windows. I tried. If you want to do cross-platform GUI development, I recommend to use wxWidgets, ftlk or fox instead (or Qt if you got the money).
CEO: Open Source is bad, we can't sell product X, we must give it away freely! OpenSource Advocate: Why not? Dual-license it, GPL for free stuff, $$$ for commercial usage..... elsewhere...
A: Why not use X? B: Its bad, because it is dual-licensed!
You see a problem here? Telling people that you can sell your stuff AND releasing it as OS and at the same time yelling against it because its only GPL for non-commercial stuff?
Tempting....
on
Why Use GTK+?
·
· Score: 2, Interesting
to start a Gtk+ vs. Qt Flamewar here. Gtk+ is easier to install & handle (moc can be a real PITA sometimes), but until Gtk+ gets a really GOOD documentation and API, I'll stick with Qt. No, neither google nor devhelp are adequate. I want a reference as well done as the Qt one. Does such a thing exist?
I know this part. The real deal is how to encode the results. Usually, MTF & ntropy coding is used. AFAIK Compressia uses distance coding instead of MTF.
I always wanted to know how Compressia ( http://www.compressia.com/ ) works. It uses some form of distance coding, but information about it is quite rare.
You know, there are lots of people out there eager to have a XP alternative. AN ALTERNATIVE. You want to force people to either become geeks or stay with XP, which is just plain stupid. (K)Ubuntu, Mandriva, Fedora, SuSe etc. all struggle to be Joe Average-friendly and use the l4m3 DEs instead of your l33t WMs.
One big plus of VS is its debugger. I prefer it hands-down over gdb. gdb is quite powerful, but cryptic. Sometimes it doesnt show the backtrace, sometimes it simply ignores breakpoints, and it is VERY helpful if I can click on the line with the access violation and the editor jumps to the source file & line, while having several watch windows with the variables I entered showing their values etc. I know this can be done with gdb too but not as fast and comfortable. Then again, I can imagine that a gdb integration for emacs exists.
Generally no. Less memory, faster, dependent on fewer packages, these are all reasons for a GEEK. Joe Average doesnt care about that. The big DEs have file managers (I really like konqueror), do not need to be configured by manually editing some configfiles (BIG BIG reason against small DEs for end users - they dread complicated-looking stuff like this), have built-in help, support for tons of tasks (like browsing, watching some videos - and no, mplayer is not userfriendly, neither is its GUI; kaffeine is the enduser player), graphical frontends for tasks like fonts installation, printer installation etc.
Small DEs are good for specific workstations where the users are unlikely to do anything else than the pre-planned type work (like cgi departments with 3d artists using maya, or medical workstations with only one app running constantly, like some MRI-scan analysers).
Yeah, thats true. manpages are NOT for endusers. Definitely. I do like Microsofts CHM format a lot, but I don't know if it can be used freely. Then there is DocBook, which could be used for a standard documentation. For Linux, maybe a modular documentation system would do fine. Basic documentation common to all distros, and on top of that KDE documentation, K3B docs, KDevelop, Konqueror etc. as modules. AFAIK only devhelp features this, but devhelp is very gnome-centric.
To me, the study is already flawed. You've dropped a load of information onto her lap, while a complete "newbie" doesn't have that same luxury. How can a usability study be unbiased in this manner? Who's to say you didn't provide her with REALLY good links to KDE information, while giving half-assed links to Gnome?
No, thats actually a good start. User X gathered some information from various links and tries to work with this little knowledge. Its the same in Windows. There are tons of Windows help sites, tips&tricks etc. and help sites. Usually, geek Y gives Windows user X these links when X wants to do something with Windows (Y being the geek-next-door). Also, Y is often not a true geek, but one of the wannabe power users who read about the newest coolest memory optimizer shareware in the newest shiny CD on that PC magazine.
Slashdot Mirror
In xgl you should disable it, the extension is present anyway (no matter whats written in the xorg.conf).
Also, if you have a nvidia hardware, you should disable it in xorg.conf.
Then again, guess I'll have to go get that high end video card just to run the next distro. :)
No, actually not. The rendering presented in the video does not need a 7800. This is basic 3D rendering most on-board graphics chipsets can handle. This functionality has been around for a decade in consumer cards.
I agree. Furthermore, the current state actually does not make much sense. Considering that, for example, nvidia-chips do not have a dedicated 2D core anymore, the driver has to emulate 2D for the legacy 2D APIs that have been used until now. Essentially, dedicated 2D development is dead; its nonsense to have a 2D core since the 3D one can do everything 2D-related much faster and with extras like blending or shaders.
So right now we have an artificial distinction between 2D and 3D. The vendors have to deal with composite stuff AND with opengl acceleration, sometimes simultaneously. Using OpenGL as the base for everything is much better, since opengl already has a client/server-architecture, driver development gets easier, X as a whole becomes leaner, responsiveness and look-n-feel of X improve, and the CPU does not have to deal with fake transparency stuff.
So its all about moving the 2D/3D-distinction away from the driver into the X server.
I doubt we will see any changes in the AAA sector. Development is so expensive that stuff HAS to sell, thus new ideas don't get a chance. There are a few exceptions, the only ones I can remind of right now are Escape From Butcher Bay and Unreal Tournament 2004, both games surprised me - not necessarily because of the tech (although EFBB is very impressive technically), but because its a hell of a lot of fun to play them. I regularly catch myself playing old 2D point-and-click adventures and amiga games like Deuteros (the virtually unknown Millennium sequel, and one of the few sequels that are really superior to the first one), and I start thinking why no one does this marvelous gameplay with today's technology. (Then reality kicks in again and I remember the costs issue.)
:)
Yeah, the next big hit will be the casual games and the indie games IMO. Slowly, tech is becoming "good enough" (unless you are a graphics whore). Its still a lot of work to get a decent-looking game done, but free gaming engines are becoming better and better (although most still lack decent toolchains), and if you look at projects like the FS2 source project (Freespace2 with vastly improved gameplay and graphics) or the Babylon 5 game, it becomes clear that indie games aren't necessarily doomed to have crappy looks anymore. It is impressive how far you can get with a Radeon9600-class hardware (again, see EFBB), the industry just doesn't make full use of it because of the tight time schedule - it is easier to force the customers to buy new hardware....
I hope Nintendo's move takes off and indie gamers make a successful return. The garage developer is back, ladies!
Escape From Butcher Bay .....
Dreamweb
Master Of Orion
Deus Ex
System Shock 1 & 2
Ascendancy
X-Com 1 through 3 (#4 is a little disappointing)
Fallout 1 & 2
and many others.
Of course, if you manage to stay within the bounds of SDL, it is easier. But you seem to think that stuff like Unreal3 compiles trivially on both Windows and Linux, with almost zero additional efforts, and that it was soo easy to plan it that way from the start. Get real.
Also, you still didn't bring valid counter-arguments to my "irrelevant nonsense". Chances are, you have neither the skill nor the experience for this.
"Again, who cares? Why do you think this is about open source vs closed source engines? Yes, it took a while to make NeL. It took a while to make doom3 and unreal engines too. It even took a while to make the halflife 2 engine, didn't it? It takes years wether you do it portable or not. Ignoring this simple fact will not make it go away."
Its not open vs. closed, its typical-opensource-hobbyist-engine vs. commercial ones. Commercial does not mean closed source automatically. NeL is a good example for this. Yes, writing a cutting-edge engine takes years. It takes even longer if you don't write it for one platform only - THAT is what you refuse to accept.
"Because its CHEAPER. They don't want to add support costs for a very small userbase. This is what I said in my first post to this thread. Try reading it."
Try thinking for once. It is cheaper, right, because it is easier to develop, it takes less time, has less potential bugs, and results in less support necessary, less testing etc. If it would be really totally trivial to port it, with zero additional costs and time, then more companies would be doing it.
"Yes, simple engines like the doom3 and unreal engines."
These are the minority. They aren't "lots of people". These are TWO commercial engines. And the other tons of engines? Look for them in the net. There are TONS of simple engines with the setup I described (OGL, SDL..) And this is supposed to be representative? And, again: why isnt Source portable? Why is not the CryEngine portable? Unreal and Doom3 were developed by the two most famous and influential devs in their league. They have the luxury of writing ports to Linux. Most other game development studios don't, they need the game to be out as soon as possible, and this excludes platform-independence. It is easier and faster to use the WinAPI and DirectX directly in Windows, which still is the PC gaming platform Nr.1. Aside from Sweeney and Carmack and a few other commercial AAA developers (Unigine looks promising) only the hobbyist engines can afford the extra time to develop cross-platform.
"No, you have stated your opinion. I choose to believe the opinions of more experienced people than you. Not to be a dick, but who's opinion do you think I would give more weight, you or carmack? Nobody is saying that making a portable engine vs a non-portable one is exactly the same, just that when you consider the years of work involved, portability is a tiny piece that doesn't really have much impact on the total timeline."
For carmack it doesnt have much impact. For people porting the first time to Linux (i.e. the majority of all PC game devs) it has. To port existing codebases is so expensive no one does it just for fun. Developing a game engine from the ground up to be portable requires knowledge of cross-platform development, of issues with all platforms to be supported, and a great deal of software design skill to wrap this up nicely. Usually, your first engine is quite tied to the platform you developed it in, even when using OpenGL (try porting your engine when there are WinAPI/X11/WGL/GLX calls all over the place). Carmacks engines always relied on OpenGL, which makes things much easier (porting Direct3D stuff is near impossible, since it requires complete rewrites of huge portions of the code). It gets a lot harder if one starts supporting more than one API. But even with OpenGL only, it is far from trivial. Carmack has a lot of cross-platform development experience, also he is one hell of a coder, so I'm not surprised platform independence is not time-consuming for him. He also has the luxury to be able to start new engines from scratch.
If platform-independent engines are so easy to write, why are developers so keen on using XNA? Microsoft promises near-transparent portability between DirectX 10 stuff on PC and on the XBox - how can they advertise with it? No matter if XNA really works or not, why is this promise attractive? BECAUSE IT MAKES PORTABILITY EASIER, and therefore cheaper. Also, Mr.Carmack really likes XNA, and considers moving towards Direct3D 10.
"In a perfect world we wouldn't have this discussion."
Correct.
"There's more to 3D graphics APIs than cutting-edge gaming features."
Yes, but today, 3D gaming is one HUGE part of it. It is the driving force behind the progress in the consumer-level cards market. It is the number one reason why stuff like Doom3 or FEAR can exist today. If the ARB is reasonable, they recognize this. 3D-Gaming has become one main pillar of 3D graphics, there is no way around that.
"OpenGL was originally designed for professional 3D graphic modelling, not gaming."
See above.
"That it does so well in games is an example of how efficient and well thought out it was originally designed."
Well.... it does well, but it could do better. That's why OpenGL ES was designed. Also, it won't do well for games if the ARB decides to sleep again.
"Getting these new "features" into OpenGL is a no-brainer. Seriously. Children can do it."
Geometry shaders a no-brainer? Superbuffers? Practical, flexible instancing? Constant buffers? Well, they fit in nicely into the API, thats true, but the point is whether they will be available soon enough or not. Considering the ENORMOUS time it took them to finish the FBO spec (and its not even an ARB_ one yet, just EXT_ !), OpenGL's future may be grim.
"You have a point about drivers, since most drivers are closed-source, meaning we have to rely on nVidia and ATI to provide drivers that work with OpenGL. But if they didn't it would only hurt their products. There's always competition, nobody can use their market dominance to force something this significant."
Reconsider the market you are talking about. For CAD stuff you don't need fragment programs. You do need them for games. Of course nVidia and ATI will continue supporting OpenGL for CAD, but for GAMING? Remember that shader support is far from trivial. Developing driver code for it is time consuming and expensive. If there is no market for OpenGL games then well.... goodbye state-of-the-art. And goodbye gaming-in-Linux; AAA-titles for the PC will not be able run on another OS than Windows, since it will be the ONLY one with a cutting-edge 3D API.
Its not relevant if it is your favourite or mine. If it doesnt have cutting-edge features, it will fall behind. If it falls behind, less and less commercial games will use it, and less reason will be there for the big IHVs to write drivers supporting the API. And poof! its gone. THIS is the main problem.
Of course this doesnt matter if you develop stuff that works on your computer and never leaves it. But once you want it to run elsewhere you have to consider these things.
In a perfect world, there would be no Direct3D, since the ARB would be a fast, competent organization, and the API wouldn't be as cluttered. A SDK would exist, in its volume, contents, and documentation on par to the Direct3D SDK.
"And? What does this have to do with anything? Its a portable engine that anyone can view the code to see that you are wrong. I don't care how it was made, that has nothing to do with anything. The fact is lots of people make portable engines, and its not hard (compared to writing a comparable non-portable engine)."
....) were already mentioned by me.
First: Development of NeL took YEARS by experienced, full-time paid developers. THIS is the difference. Your typical run-of-the-mill opensource engine didn't experience that amount of development. Also, since you STILL do not understand, ask yourself why Crytek, Valve, Raven, Bungie, EA, and countless others do not write portable games. Guess what? BECAUSE IT IS EASIER. You can get away with the 3D API that is superior in Windows (Direct3D) - not technically, but in terms of extras & support (docs etc.) You don't have to abstract your system, and can safely access platform functionality directly, resulting in a faster development cycle. Also, linux user support, quality assurance, these things do cost, you know?
The other facts (platform quirks, different compiler
Lots of people make portable engines? Lots of people make SIMPLE portable engines. Most portable engines are a combination of OpenGL, SDL, and FreeImage/DevIL/Corona/. Most engines are little more than wrappers for these libs.
"The effort required to create that engine as it is, vs the effort required to make it non-portable is very similar. But of course your opinion is correct, and mine is wrong right? Because I have only written tetris clones and you wrote doom3 obviously."
I already brought the real-world facts that prove that you are wrong and writing portable engines isnt easy. Your choice to simply ignore them says a lot.
Right now, OpenGL is on-par with Direct3D 9, now that the framebuffer object extension is out. Direct3D 10 is a wholly different issue, however. It has support for geometry shaders, constant buffers, superbuffers... OpenGL needs to catch up with new extensions or else it will fall behind, again. And this time, it may not survive.
Correct. The mind is much more sensitive to correct motion. I guess good motion blur and very good animation together can help a lot. Lighting is very advanced these days, in static settings PRT can make it look very real if used together with HDR. So this one isn't lacking, but animation is. Lighting has been pushed a lot in the past, but animation was left behind. A serious mistake. Half-Life 2 did it right (or at least less wrong than most) by improving animation.
"Ah yes, that's why people are releasing commercial games written with them right? Would you care to backup your bullshit by telling me what is wrong with the engine behind saga of ryzom (NEL)?"
NeL is not your typical opensource engine. Its a commercial product with an opensource option, just like Radon Labs Nebula Device.
"What kind of crazy non-sequiter is this? I didn't say anything about toolchains, or even that anyone should use an open source engine. I simply said they are there so anyone who wants to see you are wrong can. Just look at the code, portable, full featured 3d engines used in commercial games. Its not a big deal. And even some closed source engines are portable."
Wrong. Its quite simple: "full featured" has to include a good toolchain, or else its not full featured. The Unreal 3 Engine is full featured. Ogre is not. Irrlicht is not. Crystal Space is not. Nebula/Mangalore is not (unless you buy the toolchain from Radonlabs). If you mean "full-featured for graphics", then you aren't talking about a GAME engine (there's more to games than just graphics you know). But for developing portable games easily you need a good, portable GAME engine. Clear?
"Uh, you are telling me the doom3 engine isn't good? Or did you forget that its portable too?"
And of course you believe that it was incredibly easy to make it portable, right?
Have you EVER actually written something portable that's more complex than a Tetris clone? I sincerely doubt that. So here's a tip for free: stop talking about stuff you don't understand.
"but I would like to see an example of "import parts of a 3D engine" that are still hand coded in assembly."
SSE1/2/3-optimized math stuff maybe? Those 4x4-matrices fit nicely in SSE.
"You do realize there are full featured, portable, open source 3d engines out there right?"
Yes, and NO ONE of them is an AAA-production option. The _best_ engines are commercial ones. There is no Opensource engine able to keep up with Unreal3. Maybe in 3 years, but Epic will have realtime raytracing engines by then. Most opensource 3dengines lack decent toolchains. A toolchain means more than just some exporters. By toolchains I mean stuff like UnrealEd or the shader builder shown in some Unreal3 screenshots. A full-featured, state-of-the-art opensource GAME engine (i.e. not just graphics) just does not exist. Period. Many try to write one, no one succeeded yet.
"So anyone can go ahead and see that making a portable 3D engine isn't any harder than making a non-portable 3D engine."
Hahahaha. How funny. Once you get to the point of writing a GOOD engine you will see that you are wrong. I don't mean OpenGL initialization, you can get away with SDL for this one. (But, there are pbuffers, which are platform-dependent; they still need to be supported since FBOs are quite new and not supported everywhere yet.) Next: sound? OpenAL has some serious performance issues with Ogg playback (the UT2004 linux devs didn't like this), so you may be forced so switch to something else, again the best libraries are commercial ones (FMOD, BASS...). SDL input is very basic, you may be in need of more (libraries like OpenInput and OIS aren't very well documented). Also, platform issues like shared object handling, compiler handling, compiler quirks on each platform etc. won't make life easier. In Windows Visual C will be used almost certainly (sorry MinGW devs), so you cannot get away with a win32 gcc. Also, in Mac you still have the endianness problem (until they finish switching to Intel).
And, you forget that Direct3D has a VERY good documentation, tons of samples, both covering even state of the art stuff like PRT and HDR. Microsofts XNA program result in a D3D game be very easy to port to the XBox - another BIG plus. Sony is going for OpenGL ES + Cg, but this OpenGL is quite different from the one you use.
As the GP said, an OpenGL pendant to the Direct3D SDK is missing (yes, I know the D3D SDK is no standalone package). Also, Direct3DX is a wonderful Direct3D utility library, I miss something comparable in OpenGL. Last but not least, if OpenGL does not get superbuffers and geometry shaders/programs soon, Direct3D 10 will again lead.
AJAX for 3d modeling? AJAX for word processors? AJAX for image manipulation?
Yeah right.
I develop in Windows and Linux, and would NEVER use Gtk in Windows. I tried. If you want to do cross-platform GUI development, I recommend to use wxWidgets, ftlk or fox instead (or Qt if you got the money).
This is so typical.
.... elsewhere...
CEO: Open Source is bad, we can't sell product X, we must give it away freely!
OpenSource Advocate: Why not? Dual-license it, GPL for free stuff, $$$ for commercial usage.
A: Why not use X?
B: Its bad, because it is dual-licensed!
You see a problem here? Telling people that you can sell your stuff AND releasing it as OS and at the same time yelling against it because its only GPL for non-commercial stuff?
to start a Gtk+ vs. Qt Flamewar here. Gtk+ is easier to install & handle (moc can be a real PITA sometimes), but until Gtk+ gets a really GOOD documentation and API, I'll stick with Qt. No, neither google nor devhelp are adequate. I want a reference as well done as the Qt one. Does such a thing exist?
I know this part. The real deal is how to encode the results. Usually, MTF & ntropy coding is used. AFAIK Compressia uses distance coding instead of MTF.
I always wanted to know how Compressia ( http://www.compressia.com/ ) works. It uses some form of distance coding, but information about it is quite rare.
You know, there are lots of people out there eager to have a XP alternative. AN ALTERNATIVE. You want to force people to either become geeks or stay with XP, which is just plain stupid. (K)Ubuntu, Mandriva, Fedora, SuSe etc. all struggle to be Joe Average-friendly and use the l4m3 DEs instead of your l33t WMs.
Linux zealots. Sigh.
One big plus of VS is its debugger. I prefer it hands-down over gdb. gdb is quite powerful, but cryptic. Sometimes it doesnt show the backtrace, sometimes it simply ignores breakpoints, and it is VERY helpful if I can click on the line with the access violation and the editor jumps to the source file & line, while having several watch windows with the variables I entered showing their values etc. I know this can be done with gdb too but not as fast and comfortable. Then again, I can imagine that a gdb integration for emacs exists.
Generally no. Less memory, faster, dependent on fewer packages, these are all reasons for a GEEK. Joe Average doesnt care about that. The big DEs have file managers (I really like konqueror), do not need to be configured by manually editing some configfiles (BIG BIG reason against small DEs for end users - they dread complicated-looking stuff like this), have built-in help, support for tons of tasks (like browsing, watching some videos - and no, mplayer is not userfriendly, neither is its GUI; kaffeine is the enduser player), graphical frontends for tasks like fonts installation, printer installation etc.
Small DEs are good for specific workstations where the users are unlikely to do anything else than the pre-planned type work (like cgi departments with 3d artists using maya, or medical workstations with only one app running constantly, like some MRI-scan analysers).
Yeah, thats true. manpages are NOT for endusers. Definitely. I do like Microsofts CHM format a lot, but I don't know if it can be used freely. Then there is DocBook, which could be used for a standard documentation. For Linux, maybe a modular documentation system would do fine. Basic documentation common to all distros, and on top of that KDE documentation, K3B docs, KDevelop, Konqueror etc. as modules. AFAIK only devhelp features this, but devhelp is very gnome-centric.
To me, the study is already flawed. You've dropped a load of information onto her lap, while a complete "newbie" doesn't have that same luxury. How can a usability study be unbiased in this manner? Who's to say you didn't provide her with REALLY good links to KDE information, while giving half-assed links to Gnome?
No, thats actually a good start. User X gathered some information from various links and tries to work with this little knowledge. Its the same in Windows. There are tons of Windows help sites, tips&tricks etc. and help sites. Usually, geek Y gives Windows user X these links when X wants to do something with Windows (Y being the geek-next-door). Also, Y is often not a true geek, but one of the wannabe power users who read about the newest coolest memory optimizer shareware in the newest shiny CD on that PC magazine.