Quote: Original post by lc_overlord
We use TGA files instead of BMP so we can use transparancy right from the beginning, in theory we could use libpng, but TGA files are simple to load and gives some hints on how to write file loaders.

simple clipping is actually taught in the original lessons, just take a closer look at lesson 26.

Thanks for pointing me to that lesson!
Haven't reached that one though.

But I prefer using PNG files because they are about 4 times smaller in size.
My project uses a lot of images, about 4 MB of PNG's.
So the whole size of the project is kept to a minimum that way.
If I would use TGA files it would become 15 MB or more.

Cheers,
Cat

I've been reading NeHe for years, ever since I started my Visualization Degree back in 2000. It's pretty disappointing to see how the site has slowly crumbled over the last 12-18 months.

As part of another project, some friends and I have put together VizWorld (http://www.vizworld.com), a site for collecting information on Visualization Hardware & Scientific Visualization. We do have a little bit of information on OpenGL, but we'ld really like to expand it. If anyone wants to contribute, it's mostly a Wiki so feel free to start adding stuff! We focus mostly on high-performance large-scale visualization, but even the big viz stuff has to start small so any information is good information.

I think the new team should realise that:
a.) By not releasing updates you basically have a choke-hold over the website.
b.) There's not much point rewriting the existing articles from scratch - they're fine for learning purposes.
c.) Whenever you release any code we'll always find bugs (And contribute fixes) regardless of how long you take writing it.

I'm sure everyone is relieved to know that you've organised the team but the problem is that it isn't working because there are no results. After the first update is pushed out by your schedule of 'Godknowswhen' will you be taking another unspecified 'while' to push out the next update?

Sarcastic, yes. But I think it communicates the important message of letting everyone know just 'when' is.

Besides, while the team were inevitably 'fartoobusy' over the festive holidays, should we take it that it was also 'fartoomucheffort' to organise a festive coding competition? You see that's called letting the community contribute.

Sarcasm aside, my point is that this is a community driven website, and your current development 'process' is excluding that community. Which I think is the root of the current problem.

So, my proposed solutions are:
1.) Give responsibility for updates and maintenance back to Jeff OR
2.) Recruit a new team with a new set of objectives (ie. No rewriting of old material)
3.) Focus more on the community. (Mailing lists, competitions, article submissions, website submissions, comments)
4.) DONT rewrite the website - you're just wasting time.

Quote: Original post by Anonymous Poster
I think the new team should realise that:
a.) By not releasing updates you basically have a choke-hold over the website.
b.) There's not much point rewriting the existing articles from scratch - they're fine for learning purposes.
c.) Whenever you release any code we'll always find bugs (And contribute fixes) regardless of how long you take writing it.

I'm sure everyone is relieved to know that you've organised the team but the problem is that it isn't working because there are no results. After the first update is pushed out by your schedule of 'Godknowswhen' will you be taking another unspecified 'while' to push out the next update?

Sarcastic, yes. But I think it communicates the important message of letting everyone know just 'when' is.

Besides, while the team were inevitably 'fartoobusy' over the festive holidays, should we take it that it was also 'fartoomucheffort' to organise a festive coding competition? You see that's called letting the community contribute.

Sarcasm aside, my point is that this is a community driven website, and your current development 'process' is excluding that community. Which I think is the root of the current problem.

So, my proposed solutions are:
1.) Give responsibility for updates and maintenance back to Jeff OR
2.) Recruit a new team with a new set of objectives (ie. No rewriting of old material)
3.) Focus more on the community. (Mailing lists, competitions, article submissions, website submissions, comments)
4.) DONT rewrite the website - you're just wasting time.

Have you offered to help?

As to your solutions:

1) We have no control over that.

2) The reason the material is being rewritten is because
(a) There were constant complaints about teaching by cut and paste as opposed to actual learning.
(b) A lot of the old stuff is hopelessly out of date.
This does not mean that it wasn't (and still is) an excellent resource

The fact that the team is made up of professional software developers means that we are putting our spare time into this, and the lack of appreciation of this fact is quite palpable.

3) We have no control over this. The new team is just writing the new lessons + a new SDK.

4) Comments like this mean that I really wonder why we bother.

A huge amount of work that has gone into the new site, and we hope you'll like it when it's done, but the old lessons will not be taken down anyway, so I don't see what the problem is.

Re-affirming what lc_overlord stated the beginning tutorials will be much better at teaching the beginners the correct way to do things. The content is quite out of date and therefore some of the stuff that NeHe taught (glaux or display lists for example) is hardly used anymore. Re-writing some/all of this content is essential if you want new users who are looking to persue game development to be performing correctly.