Quote: Original post by bigsofty
Im VERY disappointed... by insisting on C++ instead of plain old C, you have increased the difficulty level by insisting that the user must know C AND OO C++ techniques. This is NOT what the original Nehe was all about... start at the simplest and work your way up...

Converting tutorials from plain old C was also very easy... from C++, a language with specific OO syntax structure, will I fear prove complicated and unreadable when refrenced against the original code.

C is easier to digest than C++ to the average noobie, I think anyone would agree.

There are lots of C++ openGL tutorial sites, the original Nehe was largely successful because of the level it expected from it audience...simple C, allowing people to focus on the OPENGL code... this is something you seem determined to ignore with your own view of what YOU think people should know before learning OpenGL...

...what a mess.

I disagree. When I first found nehe's (Jeff's) site, I didn't know anything about windows programming, and every time I looked at the window creation code, it gave me a headache (not because of how it was written, but because I had no idea what was going on). The only part that I was concerned with was what went in the main rendering loop.

There is simply no need for someone who is just starting out to understand the window creation aspect of the base code. That's why it is separated from the rest of the tutorials. You do realize that c++ compilers can compile c code right? So if you want to write your rendering code in c, it will work.

And as a bonus, the new code provides a pretty good example of an object oriented language in action for anyone who would like to learn a language that facilitates game developement (the main reason why people come here). I say... what a relief.

Quote: Original post by bigsofty
Im VERY disappointed... by insisting on C++ instead of plain old C, you have increased the difficulty level by insisting that the user must know C AND OO C++ techniques. This is NOT what the original Nehe was all about... start at the simplest and work your way up...

I see your point, though personally I thought NeHe was all about learning OpenGL, and C++ can be an excellent way to hide the confusing platform dependent stuff. OpenGL itself is still a C-style API and always will be.

From what I can see though the basecode is mostly a naive implementation of the Glut framework. ;-) Though not a wasted effort on behalf of the authors if they ever find time to release the code and document what's actually going on.

Even C++ can be simple ;-)

I've had a few issues with the code, but I'm not shure if it's the kind of feedback you guys want right now. First, in Lesson 4, the cube will get translated to a variable value that increases over time - the efect is that, eventually, the cube will disapear from the screen. I'm not shure what was the idea when that was made. The problem is on function CNeHeLessonFour::OnRender(), and the only way I could get it working was by replacing glTranslatef(0.0f,m_Trans,-9.5f); with glTranslatef(0.0f,0.0f,-9.5f); - but that's porbably not what you guys want.

Also, in Lesson5, I don't know why but the cube doesen't spin (EDIT: I assigned an initial value to m_rot, and it started spining - but I'm not shure if this should be done in the constructor or in Initialize();). Plus, if you compile by simply pressing F5 (or ctrl+F5, I'm not shure) in Visual C++ Express 2005, you will get a error of texture not found - the texture should be in the same directory as the project - well, that's how I got it working at least. EDIT: in this lesson, the TGA texture is loaded each time I resize the screen - I tried to figure out what was causing this, but I couldn't figure it.

Again, I believe you guys are more worried about the bigger picture right now, but I'm just pointing some minor problems I had. Overall, this thing looks incredible! Maybe this is because I'm mainly interested in leraning C++ right now then OpenGL, but the bonus "OOP in action" thing was just awesome - it looks like I can learn a lot from it. The open and compile thing was also something really helpful.

Now, if you don't mind, I'll try to port my glut-based project into Lesson5 - let's see if it works.

Congratulations on this!

[Edited by - algumacoisaqualquer on July 4, 2007 8:09:33 AM]

lesson 4: yes normally m_trans does increase with the velocity over time.
But 3 rows down we manipulate the velocity in both magnitude and direction and this is what causes the bouncing effect, perhaps any problems you have are related to the problem below.

lesson 5: it should rotate from the beginning, maybe it has to do with the compiler, (hmm... strange it does so on my comp too, have to check the new code).
And F5 doesn't really compile, it debugs, and the executable is not run in the right folder for it to find the textures, hit F7 instead.

Well we will certainly look into this.

I know that the F5 was in the debug mode (well, I discovered the difference very recently actually =D ), what I meant is that I - as a avarage lazy guy that wanted everything to work with a click of the mouse - noticed that. Solving it was very easy, and I don't really think you guys should bother with it - I'm just pointing that other people will eventually run into the same problem that I did. But explaining the difference between debug-mode and actually compiling will work, I believe. Of course, I believe you guys are more interested in things more critical right now - I'll see if I find anything...

EDIT: I was playing a little with the Lesson5 code, and then I realised that the method void CNeheLessonFive::OnResize(int w, int h) was calling OnInitialize(); in the last line - I think this is why the texture was loaded multiple times. That function was not nescessary over there, because OnInitialize(); was already called somewhere else.

EDIT2: Actually, this didn't solved it, because the function is also called when the screen is set to fullscreen (or reset to windowed mode). Pressing spacebar calls the function CNeheWIN32Window::CreateGLWindow(...), that in turn will call CNeheWIN32Window::Initialize(), and then Initialize() will call CNeheLessonFive::OnInitialize() - every time we hit the spacebar. Just don't ask me how to solve this!

[Edited by - algumacoisaqualquer on July 6, 2007 9:00:52 AM]

I wish there was more RAII and less explicit uses of delete in the implementation. RAII is simple enough to introduce to a beginner. After all, if you are going to require C++ might as well get them on the right C++ track.

I don't really like the method you've chosen for switching backends. Commenting and uncommenting lines is kinda... I don't know... primitive. I would have one wrapper function (CreateNeHeWindow()) which calls the correct platform-specific function based on a #define or a constant or something. I suppose your way is easier for beginners, but I find this to be helpful, especially when compiling for different targets (just add the proper #define to the build target). Just my 2 cents.

Quote: Original post by algumacoisaqualquer
EDIT: I was playing a little with the Lesson5 code, and then I realised that the method void CNeheLessonFive::OnResize(int w, int h) was calling OnInitialize(); in the last line - I think this is why the texture was loaded multiple times. That function was not nescessary over there, because OnInitialize(); was already called somewhere else.

EDIT2: Actually, this didn't solved it, because the function is also called when the screen is set to fullscreen (or reset to windowed mode). Pressing spacebar calls the function CNeheWIN32Window::CreateGLWindow(...), that in turn will call CNeheWIN32Window::Initialize(), and then Initialize() will call CNeheLessonFive::OnInitialize() - every time we hit the spacebar. Just don't ask me how to solve this!

OnInitialize in the OnResize was a bug, it should never have been there. Just delete it.

Just so everyone knows, I think the lessons are on hold for now while we wait for OpenGL "Longs Peak", it would be silly to write lessons now only to have a new API coming out soon.