Now all the guy needs is a spring loaded crank, with self regulating unwinding. I seem to recall a mechanical crank for an emergency radio/light that takes a few turns, but unwinds with regulation depending on the power requirements of the device.
This would be particularly neat if the guy could make a USB dock with one of these mechanically regulated spring loaded cranks.
AFAIK humans are really bad at regulating their power output, electrochemical (super-capacitors/batteries) storage is very inefficient, but electromechanical (spring loaded) storage is exceedingly efficient. Chock one up for the clock-work makers of old!
I think the OpenGL API is exceptionally clean, and generally stable. Yes, there are core code paths in OpenGL that are not accelerated by everyone, nor every driver. However, I find the general implementation far better for developing real 3D applications. 99% of the time I am not developing for other hardware, I'm working to get a concept rolling at 15fps on whatever I'm developing on. Same concept that John Carmack uses to develop his next generation game engines. Just push the boundary till it crawls, because in the timeframe it takes to refine the product to a shippable solution will unfailingly show a shift in feature support. This means, you make it WORK at 15fps or even slower then, over the next year, design code paths that optimize for existing hardware.
Both Direct3D and OpenGL require 'special' code paths to handle the tons of strange hardware out there; there is no escaping that fact. Therefore the various application code paths must be designed to switch over to alternative paths, primarily for optimization purposes.
Otis, you know from DemoGL how hard it is to handle all the tons of alternative hardware out there through OpenGL, but have you done the same with Direct3D? I find the CAPS structures in Direct3D far more difficult to write support code because I end up dealing with the problem of supporting various BITS of Direct3D which may kill my code dead, instead of reliably knowing OpenGL's core code path always works albeit slowly. Another interesting consideration, once your application has demand to work correctly by over even a hundred users because it looks cool, expect the next driver iteration to support the code path better. ATI has been highly responsive to my requests in the past, and so has nVidia.
Extensions are there mainly to optimize code paths for specific purposes. With the ability to transfer frame buffer data back into texture data, allows for nearly everything to be accomplished in multiple passes, even extremely slowly. Only some very specialized pixel operation absolutely require cube mapping, generalized shader, or bump support. However, they are generally cosmetic, and should be treated as dress-up accelerated features. i.e., Grab a Toy Story DVD and watch the 'behind the scenes' stuff, it's amazing to see how the visual process works. Animate simple blocky characters, apply lighting and moderate texture detail, drop in finer meshes, dress-up the scene, and polish. That's how programming game engines work too.
Slashdot Mirror
Our university (UVic) has the two programs; Computer Science for all the theory and Software Engineering for all the practical pragmatic stuff.
Have a look at this video:
http://bseng.uvic.ca/pages/home/video_mpg.html
(yes, I made it... )
Now all the guy needs is a spring loaded crank, with self regulating unwinding. I seem to recall a mechanical crank for an emergency radio/light that takes a few turns, but unwinds with regulation depending on the power requirements of the device.
This would be particularly neat if the guy could make a USB dock with one of these mechanically regulated spring loaded cranks.
AFAIK humans are really bad at regulating their power output, electrochemical (super-capacitors/batteries) storage is very inefficient, but electromechanical (spring loaded) storage is exceedingly efficient. Chock one up for the clock-work makers of old!
Sorry, I disagree about the mess with OpenGL.
I think the OpenGL API is exceptionally clean, and generally stable. Yes, there are core code paths in OpenGL that are not accelerated by everyone, nor every driver. However, I find the general implementation far better for developing real 3D applications. 99% of the time I am not developing for other hardware, I'm working to get a concept rolling at 15fps on whatever I'm developing on. Same concept that John Carmack uses to develop his next generation game engines. Just push the boundary till it crawls, because in the timeframe it takes to refine the product to a shippable solution will unfailingly show a shift in feature support. This means, you make it WORK at 15fps or even slower then, over the next year, design code paths that optimize for existing hardware.
Both Direct3D and OpenGL require 'special' code paths to handle the tons of strange hardware out there; there is no escaping that fact. Therefore the various application code paths must be designed to switch over to alternative paths, primarily for optimization purposes.
Otis, you know from DemoGL how hard it is to handle all the tons of alternative hardware out there through OpenGL, but have you done the same with Direct3D? I find the CAPS structures in Direct3D far more difficult to write support code because I end up dealing with the problem of supporting various BITS of Direct3D which may kill my code dead, instead of reliably knowing OpenGL's core code path always works albeit slowly. Another interesting consideration, once your application has demand to work correctly by over even a hundred users because it looks cool, expect the next driver iteration to support the code path better. ATI has been highly responsive to my requests in the past, and so has nVidia.
Extensions are there mainly to optimize code paths for specific purposes. With the ability to transfer frame buffer data back into texture data, allows for nearly everything to be accomplished in multiple passes, even extremely slowly. Only some very specialized pixel operation absolutely require cube mapping, generalized shader, or bump support. However, they are generally cosmetic, and should be treated as dress-up accelerated features. i.e., Grab a Toy Story DVD and watch the 'behind the scenes' stuff, it's amazing to see how the visual process works. Animate simple blocky characters, apply lighting and moderate texture detail, drop in finer meshes, dress-up the scene, and polish. That's how programming game engines work too.