- Totem often has the GStreamer backend, which in turn often does not have the codecs 99% of all people use. OK, geeks can refit them, but this is not about this group. - VLC has ZERO controls. No play, pause, volume,.... - MPlayer crashes, too often. When I use the mplayer plugin, I always stop before visiting a site with a video. Its especially bad when one closes a tab which is currently playing a video. - gxine opens a new window (which is the worst solution possible), and crashes. - kaffeine is more stable than gxine, but too opens a new window.
The only good embedded player I know of is Media Player Classic in Windows. It beats all the players above as well as the WMP one.
No. First, as soon as states are involved, your nice functional languages break down. Second, these chips vectorize, which is not the same as functional-style parallelization. You could write the same in C++ by having atomic tasks, which can gather, but not scatter, and one thread per core, each one with a list of tasks. This setup has no real side effects, but is NOT the same as as functional language. This also shows why GPUs cannot scatter (it would thrash the vectorization benefits, since pixel shader A would have to wait for pixel shader B to write on the pixel X; by disallowing scattering, pixel X can *only* be written by pixel shader A).
Which is absolutely irrelevant, because the most calculations are in 1. graphics, 2. sound, 3. networking, 4. physics, and the first three are *already* parallelized (sound and network usually run in their own threads, to minimize latency, but obviously multicores help). Physics calculations benefit from multicores, yes, but as someone else pointed out already, 95% of the Gflops sit in the graphics department, so we are talking about not much really.
There is no POINT in a web-based Photoshop. What are your options?
1) Do the actual image processing in the server, the client-side only presents results and gathers user input 2) Perform the image processing AND UI handling on the client
With (1), you get a huge scalability problem, you really need one hell of a server. With (2), you almost got a complete application already. So the only real benefit would be availability - you can access AjaxPS everywhere. But try to MAINTAIN or WRITE PS with Ajax. I bet you would shoot yourself. We need some *actual* webapp support before trying to pull of such projects. Some specs specifically designed for webapps, without the heaps of cruft and gluecode Ajax has. Unfortunately, because of IE market dominance, this is not going to be widespread.
Photoshop with Ajax? Just imagine this nightmare, both for users and developers. Imagine Maya with Ajax, SolidWorks, AutoCAD, *any* PC game, Mathlab, Mathematica, R,... with Ajax.
Technically, flash is way ahead of Ajax, and even with it you cannot pull of the apps mentioned above.
Re:If you can only use WEP, then VPN or SSH tunnel
on
WEP Broken Even Worse
·
· Score: 1
In theory, VPN is a good idea. But setting up one is one of the most difficult things known to man.
It is absolutely impossible to tell the Dune story in 2 hours, and this is why Lynch originally wanted to make the movie much longer, or in several episodes (like LOTR). This request was denied by the studio.
The opposite of this is one of the reason for the success of the LOTR treatment: it doesnt have to tell this enormous story in 2 hours. Now, get Lynch back, lets do a remake, this time with at least SIX hours combined (3 movies would fit nicely), and lets have a look at the result.
While I do like the project, I am very skeptical about it. Yes, I believe they will succeed in building a basic video card, but nothing like a nvidia one. This is relevant because it means that OpenGraphics will be a niche product. Catching up with nvidia and ati from scratch is next to impossible, especially in a resonable timeframe.
I have a i965 with GMA. It *never* worked for me well regarding OpenGL. In fact, it didnt provide OpenGL rendering *at all*. I tried for days to get it to work, with zero success.
Then I got me a nvidia card, and it worked out of the box. I also have a laptop with a mobility 9600. fglrx is an awful driver, but at least it provides OpenGL with DRI.
Re:This seems like a trend
on
eSATA Connectors
·
· Score: 1, Informative
Hold on. Many upgrades are not really necessary, but among the ones you missed were:
* PCI-Express: A true PCI successor at last. Back when the 3D accelerators were taking off, the PCI bus turned out to be not efficient enough, but a successor was not in sight. So, AGP was invented, which is essentially a PCI slot with accelerated CPU->GPU transfer (i.e. a hack). * SATA: Longer, MUCH thinner cables, hotplugging functionality, lower power consumption, Native Command Queuing (the HD can rearrange requests for improved performance). * Intel socket 775: The first socket where I found the CPU cooler installation to be easy. Previous sockets were a nightmare (478, or AMD's insane 462 socket). Oh, and no more pins means the CPU is no longer in danger of being useless because one pin got broken off. * General trend towards mainboards with tons of integrated stuff: more space, less worries about compatibility. * Core 2 duo: Finally the CPU manufacturers discover that wasting bazillions of watts is not a smart thing to do. I am still amazed by this CPU.
"Linux is only for l33t h4xx0rs, you lamer! It HAS to be needlessly complex and difficult to use, install, understand! Because we are "better", we are "l33t", and all those mundanes are not worthy of using it! Use this "Windows" if you are a mere mortal. Oh, and don't bother us with "user-friendliness" and "UI design", these things are l4m3."
Idiots like you are the main reason why the Open Source community is being perceived as a bunch of elitist asswipes. But guess what: if Desktop Linux comes, backed by quite resourceful organizations, then you and your kind won't have anything to say about it.
First, I doubt they are using display lists. VBOs would be the better candidate.
Second, if you have one locked-down platform, then it is stupid not to exploit this situation and introduce tons of custom extensions specifically for the PS3.
Third, its not like the PC. The *architectures* are wildly different, and so will be the extensions and OpenGL usage. For example, the PS2 had a ridiculously large bus to the vector processor; you were supposed to pass data through it all the time, in contrast to the PC, where you specifically avoid this (regarding the AGP bus here). On the other hand, you only have 32 MB RAM on a PS2, so it is very likely you have to redesign large parts anyway, unless you aim for the lowest common denominator, which gives you a crappy game (at least from a technical POV).
Optional code paths, you can afford that if the paths do not really vary much in structure. In Doom 3, all code paths had a similar structure, their differences were mainly in pass count and state setting, not more. However, a code path for a Wii is very different from one for the PS3 and the PC.
If you actually read my post, you'll notice this is not about Direct3D (not DirectX) vs. OpenGL. This is about why it is a VERY BAD IDEA to rewrite existing codebases to use OpenGL 2.1, which is pretty decent. Learn to read.
This does not invalidate my statement. Writing a game for two platforms from the start is something different than porting it after the game has been released for one platform. Besides, writing for multiple platforms is still costly. The PS3 quirks are totally different from the Wii ones, for example. In case of CoD, it pays off, but often enough it doesnt. (The aforementioned SOTC for example, which uses every PS2 trick in the book.)
I agree with your posting, but want to go into detail about this point: OpenGL ultimately means an inferior product. It's been true for a long while.
If you meant it from a purely technical POV - no. OpenGL 2.1 is on par with D3D 9. D3D 10 is another matter entirely, although OpenGL 3 seems like being at least on an equal level.
But the fact that 70-80% of the necessary functionality is in the extensions makes OpenGL in sum inferior. It is more expensive to develop for OpenGL than for Direct3D. With D3D I have a VERY GOOD documentation, tons of examples, all in *one* SDK. OpenGL? Everything is fragmented. There is GLee, GLEW etc. for extension handling, GLFW, GLUT, SDL and the like as a low-level handler layer for platform-specific stuff, and the documentation is often hard to get (I am not talking about basics, I am talking about things like framebuffer objects). "Read the extensions specs then." is a frequent answer. The truth is, they are often hard to understand - the D3D docs are orders of magnitude clearer and easier to read. Also lets not forget about the problems with bugfixing GL code since OpenGL provides very little feedback (software like glDEBugger and glIntercept help only to a certain degree...)
In sum, you get longer development times, more betatesting, more worries, and lose more money.
...I would rather they spent time making the Source engine use openGL so that game developers would be able to use the Source engine on the Playstation 3, Nintendo Wii, etc.
Unreal 3 is openGL hence why more companies are using that compared to Valve's Source engine. Hopefully they will get the hint sooner rather then later.
You do realize that PS3 and the like use OpenGL ES, which is NOT the same as the GL on computers? Besides, they have tons of custom extensions necessary to use these machines efficiently...
Oh, and forget about a Source rewrite for OpenGL. There just is not point in this. Direct3D works on the platform 96% of all PC gamers use. A rewrite is EXTREMELY time-consuming, because of the differences in the API designs. We're talking about at least a 6-month-delay here (very likely more).
Both DirectX and openGL just tell the gfx card what to do. But not equally. GL binds sampler states to a texture, D3D binds them to sampler stages. D3D has +Z as "inward", OpenGL -Z. D3D has +Y as "down", OpenGL "up". There is no equivalent to an OpenGL rectangle texture in Direct3D. The GLSL API works quite differently than the HLSL one etc. Do you want to finance the rewrite, the bug-fixing, beta-testing?
The fact that they decided to use DirectX which only works on Microsoft platforms for a game engine they're trying to license to other companies is pretty stupid from a business point of view.
"Only" is quite funny. Windows is an enormous gaming platform. Also, you get Xbox support nearly for free. As for machines like the PS3 and the Wii, forget about having one universal engine for all of them. ALL AAA titles are written specifically for one title, and maybe ported to another, requiring substantial rewrites (this is why usually console titles arent ported to other consoles). Try porting Shadow Of The Colossus from PS2 to Wii for example.
Sorry, but your suggestions are absolutely suicidal for all but the wealthiest of all game development companies. Because of the ARB being much too slow, OpenGL stagnated in the important years 1996-2001. Heck, a decent render-to-texture mechanism got introduced 2005, while DirectX already had one 1998. OpenGL was in an excellent position back in the 90s: Direct3D 3 sucked, OpenGL was better, easier, finer. But if you have graphics card manufacturers and game developers on one side, demanding more features, and an obscenely slow ARB on the other side, there can be only one solution - create another API. Nowadays many codebases are D3D based precisely because OpenGL just sucked in the post-D3D7 era. And rewriting the entire codebase is suicide, as already said. Which is a shame, because OpenGL is pretty decent now, and if the OpenGL 3 rumors are right, it will rock.
Ok, now I don't want to troll, flame, or otherwise. I am just curious. You don't seem to be a patent troll, you seem to be actually working on that thing. So why do you write something as offensive as "If it falls, it has joints, it looks right, and it works right, it's probably covered by our patent." ? Doesn't that sound like a patent troll's line? Like a complete blocking of this area?
Slashdot Mirror
Hey, pipe down. Those brains evolved in millions of years, we have been pursuing actual research into these fields for less than 80 years.
Because the embedded players suck.
....
- Totem often has the GStreamer backend, which in turn often does not have the codecs 99% of all people use. OK, geeks can refit them, but this is not about this group.
- VLC has ZERO controls. No play, pause, volume,
- MPlayer crashes, too often. When I use the mplayer plugin, I always stop before visiting a site with a video. Its especially bad when one closes a tab which is currently playing a video.
- gxine opens a new window (which is the worst solution possible), and crashes.
- kaffeine is more stable than gxine, but too opens a new window.
The only good embedded player I know of is Media Player Classic in Windows. It beats all the players above as well as the WMP one.
Well, this is possible already. In fact, automated sentry turrets are used in the Korean border.
No. First, as soon as states are involved, your nice functional languages break down. Second, these chips vectorize, which is not the same as functional-style parallelization. You could write the same in C++ by having atomic tasks, which can gather, but not scatter, and one thread per core, each one with a list of tasks. This setup has no real side effects, but is NOT the same as as functional language. This also shows why GPUs cannot scatter (it would thrash the vectorization benefits, since pixel shader A would have to wait for pixel shader B to write on the pixel X; by disallowing scattering, pixel X can *only* be written by pixel shader A).
Which is absolutely irrelevant, because the most calculations are in 1. graphics, 2. sound, 3. networking, 4. physics, and the first three are *already* parallelized (sound and network usually run in their own threads, to minimize latency, but obviously multicores help). Physics calculations benefit from multicores, yes, but as someone else pointed out already, 95% of the Gflops sit in the graphics department, so we are talking about not much really.
OTOH, web app interface development seems to be a lot easier and shorter than QT, GTK, etc...
Yeah, as long as the interface is not too complex.
Try doing something like Maya as a webapp.
There is no POINT in a web-based Photoshop. What are your options?
1) Do the actual image processing in the server, the client-side only presents results and gathers user input
2) Perform the image processing AND UI handling on the client
With (1), you get a huge scalability problem, you really need one hell of a server. With (2), you almost got a complete application already. So the only real benefit would be availability - you can access AjaxPS everywhere. But try to MAINTAIN or WRITE PS with Ajax. I bet you would shoot yourself. We need some *actual* webapp support before trying to pull of such projects. Some specs specifically designed for webapps, without the heaps of cruft and gluecode Ajax has. Unfortunately, because of IE market dominance, this is not going to be widespread.
Photoshop with Ajax? Just imagine this nightmare, both for users and developers. Imagine Maya with Ajax, SolidWorks, AutoCAD, *any* PC game, Mathlab, Mathematica, R, ... with Ajax.
Technically, flash is way ahead of Ajax, and even with it you cannot pull of the apps mentioned above.
In theory, VPN is a good idea.
But setting up one is one of the most difficult things known to man.
What the hell are you talking about? Gnome IPC was (is?) based on CORBA, not COM.
It is absolutely impossible to tell the Dune story in 2 hours, and this is why Lynch originally wanted to make the movie much longer, or in several episodes (like LOTR). This request was denied by the studio.
The opposite of this is one of the reason for the success of the LOTR treatment: it doesnt have to tell this enormous story in 2 hours. Now, get Lynch back, lets do a remake, this time with at least SIX hours combined (3 movies would fit nicely), and lets have a look at the result.
Then they are competing with Intel. This one is even harder since it comes already included on mainboard with intel chipsets.
While I do like the project, I am very skeptical about it. Yes, I believe they will succeed in building a basic video card, but nothing like a nvidia one. This is relevant because it means that OpenGraphics will be a niche product. Catching up with nvidia and ati from scratch is next to impossible, especially in a resonable timeframe.
I have a i965 with GMA. It *never* worked for me well regarding OpenGL. In fact, it didnt provide OpenGL rendering *at all*. I tried for days to get it to work, with zero success.
Then I got me a nvidia card, and it worked out of the box. I also have a laptop with a mobility 9600. fglrx is an awful driver, but at least it provides OpenGL with DRI.
Hold on. Many upgrades are not really necessary, but among the ones you missed were:
* PCI-Express: A true PCI successor at last. Back when the 3D accelerators were taking off, the PCI bus turned out to be not efficient enough, but a successor was not in sight. So, AGP was invented, which is essentially a PCI slot with accelerated CPU->GPU transfer (i.e. a hack).
* SATA: Longer, MUCH thinner cables, hotplugging functionality, lower power consumption, Native Command Queuing (the HD can rearrange requests for improved performance).
* Intel socket 775: The first socket where I found the CPU cooler installation to be easy. Previous sockets were a nightmare (478, or AMD's insane 462 socket). Oh, and no more pins means the CPU is no longer in danger of being useless because one pin got broken off.
* General trend towards mainboards with tons of integrated stuff: more space, less worries about compatibility.
* Core 2 duo: Finally the CPU manufacturers discover that wasting bazillions of watts is not a smart thing to do. I am still amazed by this CPU.
So not *all* upgrades are bad.
Translation:
"Linux is only for l33t h4xx0rs, you lamer! It HAS to be needlessly complex and difficult to use, install, understand! Because we are "better", we are "l33t", and all those mundanes are not worthy of using it! Use this "Windows" if you are a mere mortal. Oh, and don't bother us with "user-friendliness" and "UI design", these things are l4m3."
Idiots like you are the main reason why the Open Source community is being perceived as a bunch of elitist asswipes.
But guess what: if Desktop Linux comes, backed by quite resourceful organizations, then you and your kind won't have anything to say about it.
Deal with it.
First, I doubt they are using display lists. VBOs would be the better candidate.
Second, if you have one locked-down platform, then it is stupid not to exploit this situation and introduce tons of custom extensions specifically for the PS3.
Third, its not like the PC. The *architectures* are wildly different, and so will be the extensions and OpenGL usage. For example, the PS2 had a ridiculously large bus to the vector processor; you were supposed to pass data through it all the time, in contrast to the PC, where you specifically avoid this (regarding the AGP bus here). On the other hand, you only have 32 MB RAM on a PS2, so it is very likely you have to redesign large parts anyway, unless you aim for the lowest common denominator, which gives you a crappy game (at least from a technical POV).
Optional code paths, you can afford that if the paths do not really vary much in structure. In Doom 3, all code paths had a similar structure, their differences were mainly in pass count and state setting, not more. However, a code path for a Wii is very different from one for the PS3 and the PC.
If you actually read my post, you'll notice this is not about Direct3D (not DirectX) vs. OpenGL. This is about why it is a VERY BAD IDEA to rewrite existing codebases to use OpenGL 2.1, which is pretty decent. Learn to read.
This does not invalidate my statement. Writing a game for two platforms from the start is something different than porting it after the game has been released for one platform. Besides, writing for multiple platforms is still costly. The PS3 quirks are totally different from the Wii ones, for example. In case of CoD, it pays off, but often enough it doesnt. (The aforementioned SOTC for example, which uses every PS2 trick in the book.)
I agree with your posting, but want to go into detail about this point:
OpenGL ultimately means an inferior product. It's been true for a long while.
If you meant it from a purely technical POV - no. OpenGL 2.1 is on par with D3D 9. D3D 10 is another matter entirely, although OpenGL 3 seems like being at least on an equal level.
But the fact that 70-80% of the necessary functionality is in the extensions makes OpenGL in sum inferior. It is more expensive to develop for OpenGL than for Direct3D. With D3D I have a VERY GOOD documentation, tons of examples, all in *one* SDK. OpenGL? Everything is fragmented. There is GLee, GLEW etc. for extension handling, GLFW, GLUT, SDL and the like as a low-level handler layer for platform-specific stuff, and the documentation is often hard to get (I am not talking about basics, I am talking about things like framebuffer objects). "Read the extensions specs then." is a frequent answer. The truth is, they are often hard to understand - the D3D docs are orders of magnitude clearer and easier to read. Also lets not forget about the problems with bugfixing GL code since OpenGL provides very little feedback (software like glDEBugger and glIntercept help only to a certain degree...)
In sum, you get longer development times, more betatesting, more worries, and lose more money.
...I would rather they spent time making the Source engine use openGL so that game developers would be able to use the Source engine on the Playstation 3, Nintendo Wii, etc.
Unreal 3 is openGL hence why more companies are using that compared to Valve's Source engine. Hopefully they will get the hint sooner rather then later.
You do realize that PS3 and the like use OpenGL ES, which is NOT the same as the GL on computers?
Besides, they have tons of custom extensions necessary to use these machines efficiently...
Oh, and forget about a Source rewrite for OpenGL. There just is not point in this. Direct3D works on the platform 96% of all PC gamers use. A rewrite is EXTREMELY time-consuming, because of the differences in the API designs. We're talking about at least a 6-month-delay here (very likely more).
Both DirectX and openGL just tell the gfx card what to do.
But not equally. GL binds sampler states to a texture, D3D binds them to sampler stages. D3D has +Z as "inward", OpenGL -Z. D3D has +Y as "down", OpenGL "up". There is no equivalent to an OpenGL rectangle texture in Direct3D. The GLSL API works quite differently than the HLSL one etc. Do you want to finance the rewrite, the bug-fixing, beta-testing?
The fact that they decided to use DirectX which only works on Microsoft platforms for a game engine they're trying to license to other companies is pretty stupid from a business point of view.
"Only" is quite funny. Windows is an enormous gaming platform. Also, you get Xbox support nearly for free. As for machines like the PS3 and the Wii, forget about having one universal engine for all of them. ALL AAA titles are written specifically for one title, and maybe ported to another, requiring substantial rewrites (this is why usually console titles arent ported to other consoles). Try porting Shadow Of The Colossus from PS2 to Wii for example.
Sorry, but your suggestions are absolutely suicidal for all but the wealthiest of all game development companies. Because of the ARB being much too slow, OpenGL stagnated in the important years 1996-2001. Heck, a decent render-to-texture mechanism got introduced 2005, while DirectX already had one 1998. OpenGL was in an excellent position back in the 90s: Direct3D 3 sucked, OpenGL was better, easier, finer. But if you have graphics card manufacturers and game developers on one side, demanding more features, and an obscenely slow ARB on the other side, there can be only one solution - create another API. Nowadays many codebases are D3D based precisely because OpenGL just sucked in the post-D3D7 era. And rewriting the entire codebase is suicide, as already said. Which is a shame, because OpenGL is pretty decent now, and if the OpenGL 3 rumors are right, it will rock.
Ok, now I don't want to troll, flame, or otherwise. I am just curious. You don't seem to be a patent troll, you seem to be actually working on that thing. So why do you write something as offensive as "If it falls, it has joints, it looks right, and it works right, it's probably covered by our patent." ? Doesn't that sound like a patent troll's line? Like a complete blocking of this area?
I just hope this guy does not kill off NaturalMotion with his overly broad patents.
Ugh. CORBA. It can hardly get more convoluted and over-engineered than CORBA. It tries to be everything and achieves nothing well.
The question is: will they be present in the repositories?