Those of you who've been following the progress of the NeHe site will be aware that some time ago a team of skilled volunteers was formed with the intention of producing fresh, up-to-date content for the site. Until recently we've unfortunately not had much in the way of progress visible to the public and we would like to take this opportunity to thank people for thier continued patience with the work the team has been and continues doing. Producing a good quality set of lessons that's worthy of carrying on the NeHe legacy is a large task, especially for a team of people doing this in what spare time they have available, but rather than compromise on quality the team has been hard at work to produce the best possible results. You may have noticed some recent updates to the NeHe site. You're now able to submit OpenGL related-news which if approved will be posted to the NeHe front page. The code for the site itself has also been cleaned up somewhat to improve stability and response time, and work on this front continues to go on behind the scenes. We're also happy to announce that the code for the first five of the new lessons has reached a stage where we're releasing it for public beta. At this point we must stress that this is a beta version of the code and as such may still contain bugs; if you encounter any problems or have feedback or questions about the code, please respond to this topic in the NeHe discussion forum, making sure to give plenty of detail of any bugs you may be reporting. Download the sample code here How the files are structured: Known issues with the current sample code include: #1: The #ifdefs are a temporary solution. This will be adressed before the final version. Please wait with submitting your project-files. #2: Some keys in the GLX-backend aren't translated (I couldn't make all of them work. These are clearly marked and help would be appreciated). #3: Improperly placed VisualStudio project-files. If you take a look under each lesson-directory you will see a /project-directory, and these contain sub-directories for specific window-backends and IDEs. So for example if you have made a project file for SDL and VisualStudio 8 then it should go in /lessonX/projects/windows/sdl/vc8. However, as mentioned earlier, we might do some final adjustments to the structure so please wait with making project-files for each lesson. We hope to have the accompanying lesson text available for public review shortly and will keep you updated on progress. In the meantime, we look forward to feedback on the beta code.

Good work!

One gripe though: you should not use hard tabs to indent code.

Quote: Original post by BBB

Quote: Original post by Anonymous Poster
One gripe though: you should not use hard tabs to indent code.

Yhea, I agree with you (not sure about the rest of the team but I think they would too).

Um BBB, perhaps you forgot we had a vote on this and most of us voted for tabs, not spaces [wink]. But if that's the only criticism on the code, I'm very glad though..

Nice job guys [smile] Code looks solid.

Quote: Original post by Anonymous Poster
One gripe though: you should not use hard tabs to indent code.

well it was discussed in one of our earliest design meetings.
The main argument against hard tabs are that they indent to much (up to 8 characters), and this is especially a problem in heavily nested code (and code shouldn't really be that nested), however, this is only a problem in some editors as the majority of (c++) editors takes this in consideration and only use like 4 characters.
On the other hand in heavily nested code you also would need a LOT of spaces, like 9-12 compared to 3-4 tabs, there could literally be more spaces than code, there is also the problem of extra spaces when copying code.
Hard tabs are also auto formating in editors like VC++ meaning comments line up nicely even while editing the code(slightly), this might be possible with soft tabs, but it would make the whole thing a bit more complicated.
Ultimately we decided on hard tabs, though it is really a matter of taste(like Pepsi vs Cola or VI vs Emacs) and will not actually impact the code at all except for the formatting issues.

Edit: Besides my typewriter teacher always said "use tabs instead of spaces", but then again she also claimed that ordIII on the ABC 806 computer in a terminal server config was the ultimate word processor.

Seriously, that source code is lightyears ahead of the old NeHe code.

I wonder, if the tutorial sources are that good, then what will the actual tutorials look like?

Good to see so far we have a positive response. Even though it’s only been out for a short time frame. The idea of using tabs was decided early on in the design process when we were devising a coding standard. It will most likely stay that way in order to have consistency.

Well on the subject of tabs, I think most people will be fine with whatever, as long as you are consistent... which you have not been so far it seems. Most of the files have a mix of both tabs and spaces, and some comments are lined up, and some are not (which looks a bit messy to me). Many people like a tab size different to 4, and at the moment that messes some of the code up a bit.

Also it would be nice if you were consistent with the end of line characters. I would suggest you stick with the windows ones (like you have in main.cpp) and remove all the unix eol characters.

Anyway, those kind of problems aren't too important.

More importantly I think you should be focusing on the comments etc... which I think are a bit lacking, unless you plan to add a bit more? The comments throughout the methods are ok, but I think you really need some overview type comments, explaining the flow, what the purpose of each method is etc. This is particularly important for the early lessons, so people don't get lost, and also for the more complex lessons so people can have a quick glance through and find the parts they are interested in.

It's a good start though.

Quote: Original post by Thorgrim
More importantly I think you should be focusing on the comments etc... which I think are a bit lacking, unless you plan to add a bit more? The comments throughout the methods are ok, but I think you really need some overview type comments, explaining the flow, what the purpose of each method is etc.

I believe the intent is that this will be explained by the accompanying lesson text, rather than cluttering up the sample code with too many comments that wouldn't actually be there in production code, but if there are specific areas that could be better commented I'm sure the team will be open to suggestions.

Code looks good to me guys, great work!