As per Matrix's (Matrices?) instructions I have started a "What should we do with the site?" thread. Does anyone have any ideas or comments on making NeHe the best OpenGL site on the planet, bar none? Things that we could contribute to or ask for could range from: - Site/theme redesign - More tutorials (of course) - Merging the GameDev.net OpenGL with NeHe to add more content and a "one stop shop" for OpenGL help - More contests - Redesign the downloads area into categories for easy searching (engines, source, language, etc) - Add a texture and model area - White papers on advanced theories. ... the list is virtually endless. Please feel free to add any comments or suggestions to this thread. Hopefully Andrew (our wonderful new moderator) will take them on board and consider them. These things take time but suggesting them early on will put them in the minds of the people who can do this and, hopefully, they will see the merit and help in whatever way they can.

The following is my personal opinion. It does not reflect the opinions of GameDev.Net LLC.

Fix the tutorials. This was talking about NeHe, after all.

Other than that, merging NeHe with GDNet's OpenGL resources completely makes sense. You can even subsume OpenGL under NeHe, such that all things OpenGL on GameDev.Net are found at NeHe.

Again, my personal opinion.

//EDIT: Your link was busted. I think it's pointing an the entry you wanted now - Kaz.

[Edited by - Kazgoroth on March 20, 2006 4:49:01 AM]

As per our discussion on the grand announcement both lc_overlord and I are willing to write a series of tutorials. lc_overlord will probably be covering OpenGL related problems while I will try to fill in the gap in places people tend not to tred. Here are a few topics I'm considering:

- scripting languages
- build systems
- developer tools
- source versioning
- code design
- BigOh
- optimization and tracking memory leaks using valgrind
- debugging using gdb

The point being that I want you guys to be both compitent in GL and have the capacity to apply that knowledge in most if not all contexts that arise. Again, if you have any qualms or complaints about how the tutorials are given currenlty, make them known so that future tutorials will improve.

I've also come up with an interesting contest Idea that sould attract more attention to the site. I propose we hold a "Basecode contest". If you're familiar with the Winamp contest I held eralier, this one takes a slightly different spin on things. Instead of being supplied with a basecode, you are expected to write a basecode for a piece of software. Ideas like:

Integrating GL with:
- firefox (its already been done but the easiest basecode to use will win in that case)
- OpenOffice
- Any other app with a plugin type interface

The idea is to give plugin developers on the net a reason to want to come to nehe (since we will have a lot of GL interfaces to other software once we're done).

Cheers,
- llvllatrix

A nicer theme/design on the tutorial pages would be nice. Mabye highlighting on the code too? It gets confusing sometimes how the code/comments are laid out and coloured. Hurts the eyes after a while too.

I must say that my NeHe SDK did fix a lot of the problems from the tutorials along the way (although sometimes in unorthodox ways), so I'm sure some of that can still be salvaged.

Quote:Original post by Oluseyi
Fix the tutorials.

Agreed. I realize that a lot of people think fondly of NeHe as How They Learned Graphics Programming, but the fact is, it's a recipe approach that doesn't help people internalize the concepts being presented, and may even discourage experimentation. Type in these mystical lines of source code and shadows will miraculously appear, it says, and when they don't you'll have no friggin' clue why because you didn't know why they would show up in the first place. (Next stop: the Graphics Programming and Theory forum, to post the message "shadows arent working what do i do to make them work".) Many people who learned from NeHe have gone on to great things in spite of that, but why should we settle? These days, there are some really great books out there to help you learn graphics programming which will also help you stand on your own two feet. The NeHe approach, I think, is one which is drastically in need of revision.

I suppose that begs the question what and how should we revise? Here are some suggestions:

- A consistent, cross platform, clear build system: I think the choice lies between scons and Makefiles. I would personally recommend scons (perhpas this is the first tutorial I should write). We may also consider using SDL exclusinvely to make the basecode even more cross platform.
- Diagrams: Where are they necessary?
- Links to extended reading: a lot of work to be done here to get NeHe integrated in with the rest of Gamedev.
- Clear documentation: What specifically is confusing? Again, a lot of work here to scour postings to see what exactly people are having trouble with.

Perhaps it may also be appropriate to ask NeHe what he would change if he were to rewrite all of his tutorials?

Please add to this list,
- llvllatrix

I would disagree strongly about the suggestion to use SDL. It's fine for cross platform code (especially OS X), but one of NeHe's strong points was that it showed the tutee how to do things from a system point of view, without providing them with the crutch that the SDL ultimately is. If necessary, write an SDL version of the tutorials, but don't make it the default, especially not for Win32/Win64 systems.

btw - doesn't scons require python? Wouldn't that confuse newbies a bit? (Talking from experience as an ex-lecturer here - Me: "Here's a language you're not going to use, but you need to put it on your PC to make other bits work." Them: "Eh?")

Sorry if I came off rather negative, but I'm just giving my experiences on teaching this kind of thing [ignore]

Quote:Original post by gregs
I would disagree strongly about the suggestion to use SDL. It's fine for cross platform code (especially OS X), but one of NeHe's strong points was that it showed the tutee how to do things from a system point of view, without providing them with the crutch that the SDL ultimately is.

What aspects of SDL which make it a "crutch" don't also apply to Win32?