Just wanted to give a quick update on how things are going. First of all be assured that Nehe is still in development, progress has just been a little slow lately as we do this on our free time and have school and/or work besides Nehe. [smile] I would also like to give some info on the current plan. As you all know we have decided to re-write the tutorials and, most importantly, their code. For this we decided to make two codebases. One simple basecode used in the first 15 (or so) lessons and an advanced SDK for all lessons after that. The introcode has been kept as simple as possible to help inexperienced users learn OpenGL while the SDK has much more bells and whistles (a big kudos to our team-member Gregs for all his work on the SDK). One key aspect in both the introcode and the SDK that I want to highlight is that we have separated all the generic OGL code from the OS-specific, window-system related code. Here is how we have coded the introcode (note that if you are a beginner you will probably don't understand the following. But don't worry, everything will be explained in the actual lessons): First we have the class for each lesson, for example class CNeheLesson02. This class houses the generic OpenGL code and is completely operating-system-independent. We then have a class for each window-system (GLX, WGL, SDL et.c.) that takes care of window-creation and all the OS-specific aspects. These classes all inherit from CNeheBaseWindow which acts as an interface. The only thing the lesson-class needs is a CNeheBaseWindow pointer. The lesson-class doesn't know or care about which window-system-class is hidden behind this pointer. You simply write a backend-class for SDL/GLX/WGL/GLUT/whatever, tell the CNeheLesson<X>-class to use it and thats all there is to it. Thanks to this design ALL of the lessons can right from the start be used on any operating system with any windowing-sytems. This also means that we have a shared codebase for the windowing-code. If someone discovers a bug in the GLX-code we simply update the CNeheGLXWindow-class. All you need to do is download the new CNeheGLXWindow-source, tell CNeheLesson<X> to use it instead and voila: you benefit from the new, improved code. [smile] In the old nehe-tutorials you would need to manually update _EVERY_ lesson by hand which needless to say wasn't very fun. One drawback though is that this increases the complexity a bit and you also get a few issues with the different keycodes of the various window-APIs, but we think that the advantages greatly outweigh the slight increase of complexity. Also, one of our goals with the new Nehe-lessons is to teach newcomers how to write proper code and this is a very good technique. If you are studying design-patterns then you know that this is called the "Adapter Pattern". This new design is by the way one of the reasons why we are so delayed. When I wrote the forum-announcement on beta testing I thought that we would be able to quickly implement this new design but that has clearly been not the case. However I think we can all agree that it should rather be done properly and released late rather then improperly and early. [smile] I and the rest of the team will continue working and in the meantime make sure you all have a good winter-holiday and a happy new year. [smile] Cheers // BBB and the NeHe-team

Sounds good, but it seems you have paid far too much attention on making this an OO exercise and not an OpenGL learning resource, will the old versions of the lessons still be available and also ports to other languages?

Very good news. Glad to see you guys are doing this. I've actually attempted many times to create a robust design like you guys have mentioned and each attempt has only had limited success. I look forward to seeing how you overcame some of the roadblocks I encountered and your implimentation of the design.

Any ETA on when we might see some of the updated tutorials?

"CNeheLesson02", "CNeheGLXWindow" ... I see you have adopted hungarian notation... pity. Of course it's good that NeHe finally gets updated, but... you can't win every time.

"FirstThereIsThePlainHungarianNotation" and "aNDfINALLYtHEREiStHEiNVERSEhUNGARIANnOTATION" are NOT hungarian notation. They are a good example of CamelCase typing.

Hungarian notation means that ugly and obnoxious variable/function/class name prefixes, like CSomeClass, CSomeOtherClass or prefixing class/structure members with m_ or p_ and it does not end there. What do you think the WPARAM and LPARAM in Windows API mean? I have seen stuff that look like szpczaSomething and similar other ugly variable names. Very ugly and unneeded stuff.

I know, I know... I'm just ranting. I do appreciate what you're doing with NeHe.

Hungarian notation is in my opinion a waste of time. I used to be a huge hungarian notation fan for years, until i actually thought about it for a moment. Without hungarian notation, what types do you think these variables are ?



Does hungarian notation give you anything? rsi maybe, but it won't tell you anything you don't already know from simply looking at the variable names. It also makes intellisense & code autocomplete less useful, since you end up scrolling through 20 to 30 m_'s before getting to what it is you want.

Imo, if you need your hand holding to tell you that m_szName is actually a text string, there is something wrong. How often do you see variables called m_dwName ?

Don't get me wrong, Coding standards are very useful, but really hungarian takes it to the extreme with no actual benefits. As an example, the coding style i use now is



I don't really see the point of using the underscore m_ and g_, it just adds to rsi; hence i just m and g.