Quote:Original post by chollida1 [...]I'd tend to disagree with some of that, I do agree that say C++ will still be C++ in 10 years but I'd say its the techniques that stay the same.
The bubble sort has been taught for 30 years, same with linked lists and tree strucutres.[...]
Of course linked lists have been linked lists for a while now. How many different techniques can you use to implement it, though? At least 3 (procedural, OOP, functionally and of course each of those 3 can have 50 different implementations) and I'd bet much much more. Once we start getting into paralell processing more it'll be a whole new ball game from what most people know, and if we ever get a serious quantum computer built that will be another completely different way.
As far as keeping up, you don't have to unless your work requires you to. Technology might sell games, but it doesn't make them good games. I'd much rather you(meaning any indie game developer) spend a few minutes whipping up a basic OGL/DX7 framework and then the rest of the time on figuring out gameplay and mechanics etc to make a good game than to spend years writing shaders to release "an engine called a game"
"Walk not the trodden path, for it has borne it's burden." -John, Flying Monk
Quote:Original post by Fidelio66 Most of the tutorials and I guess amateur games just use softwareprocessing and don't even test for hardwareprocessing, just like the geforce card and its hardware T&L was never invented.
No, no. It's the amateur games that use hardware and T&L and shaders and DirectX 9.1 and what not when they don't need to. Professional downloadable games try to have the game work on as many computers as possible and as such go through a lot of pain and technical tricks to use software rendering.
By the way, it's hard enough for me to keep up with old stuff - I want to learn Lisp and bash scripting and Emacs and gdb. I just tend to stay away from all these "new" "technologies" that may or may not be around a few years from now.
My game, when it was first created, looked awful. So we added all kinds of nice effects - bumpmapping, specular highlights, reflective water, particle systems, you name it. It still looked like crap. What finally made it look good? Plants. Lots of them.
The point is this: the same things that make a real-world scene look good are what make a computer scene look good. My apartment is an attractive environment because it has subdued lighting, plenty of houseplants, well-coordinated colors, and because it looks comfortable.
Technology is only useful insofar as it helps duplicate some real-world effect you want to achieve. Your engine pushes lots of polygons? Why? Oh, because houseplants have lots of polygons - well okay then. Your engine has multiple light sources? Why? Oh, because you want to implement subdued lighting - well okay then. Your engine has specular reflections? Why? Unless some interior designer said "you need more shiny stuff in your living room," then there's no point implementing speculars. Of course, if you're trying to do a rainforest scene in which everything looks wet, then that's a whole other story.
