It is very nice, but adapting real-world metaphors to such a degree makes very little sense. What most forget is that real-world metaphors are not optimal. For example, a pile of paper is not optimal because it is hard to search something in it. Using computers, I can access a text file nearly instantly, so why should I want a delay because of the metaphors? IMO the last really useful UI invention was the desktop search, because it satisfies most user's needs: a) fast access, b) easy search, c) instantly accessible.
Of course, this is a research project, and some of its results may find their way into mainstream UIs. For example, I could think of a variation of the lasso menu. Draw a lasso using the mouse over a couple of files, then pull up, and a directory is created with all marked files in it.
Well, one thread per sound is insane, NO ONE will do that. It is common to have ONE thread for the ENTIRE soundsystem, and this thread handles optional sw mixing, 3D positional updates etc. You do not WANT and NEED one thread per sound for this. Networking: depends on the game. For a server, one thread per player is reasonable, for a client it is not. As for scene management etc., it is not only very hard, it is often absolutely pointless. The data structures are too dependent of each other. The amount of mutexes guarantee a net benefit of 0%. As for high-level: well, low-level would be one thread walking the scenegraph for renderable nodes, while another thread serializes the thing to a disk, a networking thread adds nodes etc. It is absolutely crazy to think that this would actually HELP performance. Since nowadays everyone seems to be keen on using multithreading everywhere, I wouldn't be surprised to see such atrocities in some games soon.
I am NOT talking about the GPU. I am aware of parallelization there. I am talking about parallelization in scene management, which is pointless there (no net gain). As for physics, networking and sound.... i ALREADY mentioned them. Did you even *read* my posting?
Well, I did not mean the GPU parallelization. We are talking about Multi-Core CPUs, right? How am I supposed to write a 3D game taking advantage of multithreading? I already mentioned some separations, but they all help with latency, not speed (well, in multicores speed is increased too, but this is just a side-effect in that case).
Well, then show me how to insert a parallel architecture in your typical 3D game. Multithreading can work only in very high levels, by separating stuff into a sound thread, networking thread, rendering thread, physics thread, and a main one (usually containing the gameplay). But you cannot insert multithreading into the graphics subsystem; its pointless, except for expensive precalculations (like relief map voxelizations or some PRT stuff). There is just no point in using multithreading for scenegraphs, the synchronization overhead kills any speed gain. And, the aforementioned separation certainly helps in reducing latency (critically important for networking), and that is the REAL benefit in most cases.
This is a myth. The OGL-D3D wrapper shipped together with Vista is *optional* and intended for IHVs not willing or capable of writing OpenGL ICDs (its harder to write them than a D3D HAL). Vendors can always write a Vista-compliant ICD which does _not_ disable Aeroglass. See GDC slides for more.
In the latest DirectX 9 SDK there is a DirectX 10 preview, with samples, API references, programming guides.... very detailed indeed. This is intended for developers to adjust their engines in order to be able to use the new features, and to learn to use them.
The problem is: DirectX 10 is tremendously well designed, and offers functionality way beyond what OpenGL offers. Superbuffers, geometry shaders, a trimmed down API, texture indices (great for instancing!), improved batching (again good for instancing) etc. I fear the ARB will be as slow as a slug again and include some of these features in maybe 5 years, which will be definitely too late. Just look at how long it took them to get a decent render-to-texture extension finished (considering that rtt is one of the most important features today, this gets even worse). The ARB has to speed up, or OpenGL will cease to be of value for any games.
You know, IDEs do not mandate usage of RAD, usage of bazillion wizards etc. Aside from RAD, the real advantages of an IDE shine when your project spans multiple large source files. The IDE has knowledge about the files the projects consists of (at least, there is a list of all files for quick access, something I REALLY miss in vim for example). Going further, since IDEs know this list of files, they can apply refactoring properly, which is incredibly useful. (Refactoring is something I miss in Visual C++.) Autogeneration of the build system files is another benefit of using an IDE (although I recommend to stay away from IDE-autogenerated autotools stuff; then again, I generally stay away from them).
I prefer an editor for small stuff, like a helper application which consists of only one or two files. An IDE is overkill there. And yes, for learning how compiling & linking works, using an editor and a makefile is wise. (At least it helps later when linker errors appear, which is quite hand when the people don't know what a linker does.) But for bigger things, I prefer an IDE.
Heh. Obviously, you don't know how to use Visual C++ properly. Aside from the.vcproj and.sln files (which are necessary since they contain information about all files in the project), VC does not have to generate ANYTHING. In fact, VC is easier to use than most Linux C++ IDEs.
With full 3D support? What about shaders? (I'm generally not a fan of featuritis, especially not in the graphics department, but shaders are one hell of a nice feature.)
The IP concerns are valid. Often, they are exaggerated, thats true. I would welcome a law where hardware disclosure is mandatory, but with protection from ligitations. This would be a small step however, since a lot of know-how is in the drivers, not in the hardware.
What would really be nirvana would be for an entire community of willing volunteers to write their driver for free, which could happen if the vendor would just release some damn specs! Then the support cost wouldn't just be lower, it would be zero because the community would be supporting itself!
Oh yes. I see. Volunteers striving to recreate nVidia drivers. With shaders, Z-pyramids, FSAA, bazillion tricks & tweaks to max out performance. Riight. Maybe ready in 2043? Because, the specs won't help you much since a TON of functionality resides in the drivers.
Also, instead of being dependent upon a company to release drivers, now we are dependent on volunteers to be constantly motivated to maintain the drivers. The day they lose motivation, drivers get broken because of kernel changes, and is kicked out of the kernel. Goodbye driver.
Besides, "trade secrets" are not necessary for a hardware company to succeed anyway.
Ah, yes. But not in this universe. Well, I guess the small companies may survive for a while without them. But especially between ATI and nVidia there is a cold war, and each one would LOVE to get their hands on some of the others' secrets. Patent violations are only one of the weapons.
Look at all the hardware that does have Free drivers: CPUs, mass storage devices, sound cards, network cards, etc.
Oh yeah, and you can mix these with a GPU, since they are all so similar. Sheesh, get a clue. GPUs are even more complex than CPUs, and hundreds of thousands of times more complex than your typical NIC.
Those don't have any "trade secrets" that prevent drivers from being written, and there is absolutely no reason for video cards (and wireless chips) to be any different!
Wireless chips have FCC problems (source code available = you can tune the chip to send at any frequency). In other countries, this does not apply. But then again you cannot use chips manufactured there in the US, which is just one of the biggest markets in the world.
Video cards: I told you already. In fact, there is absolutely no reason why nVidia and ATI should EVER GPL the drivers, release the HW specs (which are patent-encumbered too) etc. If one does it, the other uses it to crush the opponent. And then we have just ONE GPU manufacturer.
Most recent 3D games for Linux were developed using these binary drivers.
The open-source ones are CRAP for 3D! Most don't even have hardware-accelerated 3D support. Try playing Doom3 with OS drivers.
Also, they weren't built for those drivers, wtf are you talking about? They use OpenGL for 3D. OPENGL. Not a direct driver interface. The whole POINT of drivers are to be a middleman between the standardized OS interfaces and the hardware.
The fact that developers are writing software that relies on these proprietary blobs for acceptable performance is a step backward for free software.
Again the same error. If you want to write software using 3D stuff from post-1995 you NEED nVidia/ATI binary drivers, because the other ones are useless. And yes, there are MORE uses for them than just games. (HW-accelerated raytracing for example.)
I would rather have the X we have today than an improved X that only works when I install non-free drivers.
And I don't. The chance that the binary drivers will EVER become opensource is about nil. I want good 3D, I NEED good 3D for my work. So no choice here. Also, I don't like an X server with artificially crippled functionality.
1) Hacking into NASA for three years with a 56k only? 2) What about using the "Print" button which makes a screenshot? (Well, in Windows it does.) 3) They are suppressing free energy? Why? Free energy would launch an incredible boom for economy, help greatly in pollution reduction, provide an excellent way of getting rid of oil dependency, provide instant cheap space exploration (and thus access to the vast resources on the moon and in the asteroid belt, for example), erase any poverty and/or hunger etc. So WHY should anyone suppress that? Can anyone tell me why?
Yeah. CS: Source should have been focused on gameplay enhancements. CS was never about graphics, its about gameplay. Thus, its a pity CS: Source failed, because the added physics could introduce nice new elements into the game (like, using objects as weapons, pushing crates over so they fall on enemies etc.)
Properly used, the new tech can actually enhance gameplay. Realtime shadows are *very* useful in a stealth game - imagine Thief with realtime shadows, indicating when someone is coming around the corner. (Also, your shadow needs to stay out of sight.) Physics can tremendously enhance gameplay, as long as it is used evenly across the game world. For example, if a map contains little interaction, but at some places, there are weird puzzles that work with the physics engine, you know something went wrong. This is really an indicator that the designers wanted to show off with the physics. But, if you can knock down enemies by dislodging rocks for example (Indiana Jones-style), or play with buyoyancy (and thus create bridges over water with some wood), then you can even enhance multiplayer sessions with it.
Not because its not feasible (it is, although not in the near future), but it just doesn't pay off. Pay attention to the bump mapping effects. Normal mapping was introduced - BIG impact (lighting really looks quite different, and the bumpmaps add a lot to the scene). But parallax mapping and the like? Their advantages are not as obvious, sometimes you actually have to look for it (watch the Unreal3 video, they really had to emphasize the use of virtual displacement mapping, which is just another parallax/relief mapping derivative). The point is, the cost/benefit ratio becomes unacceptable after a certain limit. Choose the techniques that have a big impact, like: the aforementioned bump mapping, cheap non-physics-based refraction (like HL2 uses), some good skies, GOOD character animation. You would be surprised just how far you can get with this. In fact, sometimes you do want cheaper visual quality, for example when you want to draw lots of entities, because better visual quality means more expensive pixel shaders, which in turn hit the fillrate limit quickly. So, if you want a space shooter with 5000 ships, you should stick to simple bumpmapping (which really makes a difference in space sims, since the hard light in space outlines surface structures quite well) and leave out the fancy parallax mapping stuff out. These kinds of stuff will become easier once batching & instancing becomes easier.
For physics, the same applies. Previously, the game world wasn't all that interactive, now I can throw around stuff. Great! Has a huge impact, changes a lot. But now, as physics advance, the advances become less relevant. At some point, it just doesn't matter if I can collide 15000 boxes in realtime.
Depends. A gas engine is more efficient for long distances, but for the usual 50km drives through a city, with lots of traffic jams and red traffic lights, you are better of with the electric one.
Ehrm.... hydrogen is a way to TRANSPORT energy, its not a source. Fusion would be a source. A hydrogen economy would need more power plants since someone has to stuff all that current into the water to get hydrogen. Or, if the water-splitting algae/bacteria finally arrive (there are lots of nearly ready versions), someone has to send those volts to light up the tanks where they live. The ideal hydrogen car is in fact an electric car, but with fuel cells & hydrogen tanks instead of batteries.
Slashdot Mirror
c) is kinda redundant... :)
It is very nice, but adapting real-world metaphors to such a degree makes very little sense. What most forget is that real-world metaphors are not optimal. For example, a pile of paper is not optimal because it is hard to search something in it. Using computers, I can access a text file nearly instantly, so why should I want a delay because of the metaphors? IMO the last really useful UI invention was the desktop search, because it satisfies most user's needs: a) fast access, b) easy search, c) instantly accessible.
Of course, this is a research project, and some of its results may find their way into mainstream UIs. For example, I could think of a variation of the lasso menu. Draw a lasso using the mouse over a couple of files, then pull up, and a directory is created with all marked files in it.
As another poster already said, file I/O is a bottleneck regardless of ANY language. So, try something different. Real-time h264 decoding for example.
Well, one thread per sound is insane, NO ONE will do that. It is common to have ONE thread for the ENTIRE soundsystem, and this thread handles optional sw mixing, 3D positional updates etc. You do not WANT and NEED one thread per sound for this.
Networking: depends on the game. For a server, one thread per player is reasonable, for a client it is not.
As for scene management etc., it is not only very hard, it is often absolutely pointless. The data structures are too dependent of each other. The amount of mutexes guarantee a net benefit of 0%.
As for high-level: well, low-level would be one thread walking the scenegraph for renderable nodes, while another thread serializes the thing to a disk, a networking thread adds nodes etc. It is absolutely crazy to think that this would actually HELP performance. Since nowadays everyone seems to be keen on using multithreading everywhere, I wouldn't be surprised to see such atrocities in some games soon.
I am NOT talking about the GPU. I am aware of parallelization there. I am talking about parallelization in scene management, which is pointless there (no net gain).
As for physics, networking and sound.... i ALREADY mentioned them. Did you even *read* my posting?
Well, I did not mean the GPU parallelization. We are talking about Multi-Core CPUs, right? How am I supposed to write a 3D game taking advantage of multithreading? I already mentioned some separations, but they all help with latency, not speed (well, in multicores speed is increased too, but this is just a side-effect in that case).
Well, then show me how to insert a parallel architecture in your typical 3D game. Multithreading can work only in very high levels, by separating stuff into a sound thread, networking thread, rendering thread, physics thread, and a main one (usually containing the gameplay). But you cannot insert multithreading into the graphics subsystem; its pointless, except for expensive precalculations (like relief map voxelizations or some PRT stuff). There is just no point in using multithreading for scenegraphs, the synchronization overhead kills any speed gain. And, the aforementioned separation certainly helps in reducing latency (critically important for networking), and that is the REAL benefit in most cases.
Without LAMP, I will get much less daily wtfs at http://thedailywtf.com/ !!111one
This is a myth. The OGL-D3D wrapper shipped together with Vista is *optional* and intended for IHVs not willing or capable of writing OpenGL ICDs (its harder to write them than a D3D HAL). Vendors can always write a Vista-compliant ICD which does _not_ disable Aeroglass. See GDC slides for more.
In the latest DirectX 9 SDK there is a DirectX 10 preview, with samples, API references, programming guides.... very detailed indeed. This is intended for developers to adjust their engines in order to be able to use the new features, and to learn to use them.
The problem is: DirectX 10 is tremendously well designed, and offers functionality way beyond what OpenGL offers. Superbuffers, geometry shaders, a trimmed down API, texture indices (great for instancing!), improved batching (again good for instancing) etc. I fear the ARB will be as slow as a slug again and include some of these features in maybe 5 years, which will be definitely too late. Just look at how long it took them to get a decent render-to-texture extension finished (considering that rtt is one of the most important features today, this gets even worse). The ARB has to speed up, or OpenGL will cease to be of value for any games.
You know, IDEs do not mandate usage of RAD, usage of bazillion wizards etc. Aside from RAD, the real advantages of an IDE shine when your project spans multiple large source files. The IDE has knowledge about the files the projects consists of (at least, there is a list of all files for quick access, something I REALLY miss in vim for example). Going further, since IDEs know this list of files, they can apply refactoring properly, which is incredibly useful. (Refactoring is something I miss in Visual C++.) Autogeneration of the build system files is another benefit of using an IDE (although I recommend to stay away from IDE-autogenerated autotools stuff; then again, I generally stay away from them).
I prefer an editor for small stuff, like a helper application which consists of only one or two files. An IDE is overkill there. And yes, for learning how compiling & linking works, using an editor and a makefile is wise. (At least it helps later when linker errors appear, which is quite hand when the people don't know what a linker does.) But for bigger things, I prefer an IDE.
Heh. Obviously, you don't know how to use Visual C++ properly. Aside from the .vcproj and .sln files (which are necessary since they contain information about all files in the project), VC does not have to generate ANYTHING. In fact, VC is easier to use than most Linux C++ IDEs.
Only Xfce is a DE. Fluxbox, Icewm... are window managers. You need to build stuff around them to create a DE (config GUIs, apps, file managers etc.)
With full 3D support? What about shaders? (I'm generally not a fan of featuritis, especially not in the graphics department, but shaders are one hell of a nice feature.)
The IP concerns are valid. Often, they are exaggerated, thats true. I would welcome a law where hardware disclosure is mandatory, but with protection from ligitations. This would be a small step however, since a lot of know-how is in the drivers, not in the hardware.
You, Sir, don't have a clue.
What would really be nirvana would be for an entire community of willing volunteers to write their driver for free, which could happen if the vendor would just release some damn specs! Then the support cost wouldn't just be lower, it would be zero because the community would be supporting itself!
Oh yes. I see. Volunteers striving to recreate nVidia drivers. With shaders, Z-pyramids, FSAA, bazillion tricks & tweaks to max out performance. Riight. Maybe ready in 2043? Because, the specs won't help you much since a TON of functionality resides in the drivers.
Also, instead of being dependent upon a company to release drivers, now we are dependent on volunteers to be constantly motivated to maintain the drivers. The day they lose motivation, drivers get broken because of kernel changes, and is kicked out of the kernel. Goodbye driver.
Besides, "trade secrets" are not necessary for a hardware company to succeed anyway.
Ah, yes. But not in this universe. Well, I guess the small companies may survive for a while without them. But especially between ATI and nVidia there is a cold war, and each one would LOVE to get their hands on some of the others' secrets. Patent violations are only one of the weapons.
Look at all the hardware that does have Free drivers: CPUs, mass storage devices, sound cards, network cards, etc.
Oh yeah, and you can mix these with a GPU, since they are all so similar. Sheesh, get a clue. GPUs are even more complex than CPUs, and hundreds of thousands of times more complex than your typical NIC.
Those don't have any "trade secrets" that prevent drivers from being written, and there is absolutely no reason for video cards (and wireless chips) to be any different!
Wireless chips have FCC problems (source code available = you can tune the chip to send at any frequency). In other countries, this does not apply. But then again you cannot use chips manufactured there in the US, which is just one of the biggest markets in the world.
Video cards: I told you already. In fact, there is absolutely no reason why nVidia and ATI should EVER GPL the drivers, release the HW specs (which are patent-encumbered too) etc. If one does it, the other uses it to crush the opponent. And then we have just ONE GPU manufacturer.
Most recent 3D games for Linux were developed using these binary drivers.
The open-source ones are CRAP for 3D! Most don't even have hardware-accelerated 3D support. Try playing Doom3 with OS drivers.
Also, they weren't built for those drivers, wtf are you talking about? They use OpenGL for 3D. OPENGL. Not a direct driver interface. The whole POINT of drivers are to be a middleman between the standardized OS interfaces and the hardware.
The fact that developers are writing software that relies on these proprietary blobs for acceptable performance is a step backward for free software.
Again the same error. If you want to write software using 3D stuff from post-1995 you NEED nVidia/ATI binary drivers, because the other ones are useless. And yes, there are MORE uses for them than just games. (HW-accelerated raytracing for example.)
I would rather have the X we have today than an improved X that only works when I install non-free drivers.
And I don't. The chance that the binary drivers will EVER become opensource is about nil. I want good 3D, I NEED good 3D for my work. So no choice here. Also, I don't like an X server with artificially crippled functionality.
1) Hacking into NASA for three years with a 56k only?
2) What about using the "Print" button which makes a screenshot? (Well, in Windows it does.)
3) They are suppressing free energy? Why? Free energy would launch an incredible boom for economy, help greatly in pollution reduction, provide an excellent way of getting rid of oil dependency, provide instant cheap space exploration (and thus access to the vast resources on the moon and in the asteroid belt, for example), erase any poverty and/or hunger etc. So WHY should anyone suppress that? Can anyone tell me why?
Yeah. CS: Source should have been focused on gameplay enhancements. CS was never about graphics, its about gameplay. Thus, its a pity CS: Source failed, because the added physics could introduce nice new elements into the game (like, using objects as weapons, pushing crates over so they fall on enemies etc.)
Properly used, the new tech can actually enhance gameplay. Realtime shadows are *very* useful in a stealth game - imagine Thief with realtime shadows, indicating when someone is coming around the corner. (Also, your shadow needs to stay out of sight.) Physics can tremendously enhance gameplay, as long as it is used evenly across the game world. For example, if a map contains little interaction, but at some places, there are weird puzzles that work with the physics engine, you know something went wrong. This is really an indicator that the designers wanted to show off with the physics. But, if you can knock down enemies by dislodging rocks for example (Indiana Jones-style), or play with buyoyancy (and thus create bridges over water with some wood), then you can even enhance multiplayer sessions with it.
The problem is, multithreading is no shiny new hammer. Many problems in game logic just aren't suitable for multithreading.
Never, really.
Not because its not feasible (it is, although not in the near future), but it just doesn't pay off. Pay attention to the bump mapping effects. Normal mapping was introduced - BIG impact (lighting really looks quite different, and the bumpmaps add a lot to the scene). But parallax mapping and the like? Their advantages are not as obvious, sometimes you actually have to look for it (watch the Unreal3 video, they really had to emphasize the use of virtual displacement mapping, which is just another parallax/relief mapping derivative). The point is, the cost/benefit ratio becomes unacceptable after a certain limit. Choose the techniques that have a big impact, like: the aforementioned bump mapping, cheap non-physics-based refraction (like HL2 uses), some good skies, GOOD character animation. You would be surprised just how far you can get with this. In fact, sometimes you do want cheaper visual quality, for example when you want to draw lots of entities, because better visual quality means more expensive pixel shaders, which in turn hit the fillrate limit quickly. So, if you want a space shooter with 5000 ships, you should stick to simple bumpmapping (which really makes a difference in space sims, since the hard light in space outlines surface structures quite well) and leave out the fancy parallax mapping stuff out. These kinds of stuff will become easier once batching & instancing becomes easier.
For physics, the same applies. Previously, the game world wasn't all that interactive, now I can throw around stuff. Great! Has a huge impact, changes a lot. But now, as physics advance, the advances become less relevant. At some point, it just doesn't matter if I can collide 15000 boxes in realtime.
Depends. A gas engine is more efficient for long distances, but for the usual 50km drives through a city, with lots of traffic jams and red traffic lights, you are better of with the electric one.
Ehrm.... hydrogen is a way to TRANSPORT energy, its not a source. Fusion would be a source.
A hydrogen economy would need more power plants since someone has to stuff all that current into the water to get hydrogen. Or, if the water-splitting algae/bacteria finally arrive (there are lots of nearly ready versions), someone has to send those volts to light up the tanks where they live. The ideal hydrogen car is in fact an electric car, but with fuel cells & hydrogen tanks instead of batteries.