Nehe OpenGL Tutorials Converted to SFML

[Konfig]

Hello all.  I am new to SFML and I am currently brushing up on OpenGL after having not used it for several years.  I decided to convert the tutorials over to SFML while I am going through them.  I currently have the first 10 tutorials converted and will add to the repository as I progress through them.  You can get the source at:  

git://github.com/cwbriscoe/NeHe-SFML.git

If you are new to OpenGL and have not heard of the Nehe tuorials, check them out here:

http://nehe.gamedev.net/

I have also included a Code:Blocks project file that is setup for the MinGW GCC compiler but it is probably pretty easy to switch to another compiler and/or IDE.  If you do use the Code:Blocks project file, then you will have to add the SDML /include and /lib locations in the appropriate places at the global project or global Code:Blocks level.

[Groogy]

Awesome, though do you think you'll have time to like set up a wiki on your github repo and also do a conversion of the actual tutorial? Would be pretty sweet to have.

[danman]

Why don't you use sf::Input instead of a std::map <key, bool> ?

[Nexus]

I think only the first few tutorials are worth to be converted to SFML code. A lot of stuff is OpenGL-specific (lights, fog, 3D) which SFML doesn't support.

Interesting are mainly how to set up an OpenGL window with SFML, but there is already an official tutorial and example about this topic.

[Konfig]

Awesome, though do you think you'll have time to like set up a wiki on your github repo and also do a conversion of the actual tutorial? Would be pretty sweet to have.

I don't really want to replace the tutorials.  I feel the originals are still good and I have copied most of the comments from the tutorial over to the converted source code.  When I get finished with the tutorials, perhaps I could create a Wiki with the descriptions of all the tutorials and link each one to the associated Nehe page and .cpp file in the repository.

Why don't you use sf::Input instead of a std::map <key, bool> ?

I completely missed that when going through SFML tutorials.  I agree that is a better way to do the movement keys.  I have made the changes.  Thanks.

Interesting are mainly how to set up an OpenGL window with SFML, but there is already an official tutorial and example about this topic.

I went through the OpenGL tutorial on this site.  The reason why I am converting them over to SFML as I go through them is to broaden my understanding of the SFML API as well.  I am making my changes available on Github in the hopes that my effort is also useful to somebody else learning OpenGL and/or SFML.  Some of the Nehe tutorials do not compile as is any longer because they use obsolete glaux libraries.

[panithadrum]

That's a pretty good idea. Now the Nehe tutorials look a lot more cleaner!

I noticed that you use Window::UseVerticalSync(vsync) on every frame, instead of using it after you change the vsync value.

[cristi121]

The link the OP posted doesn't work for me. I looked up his account and found a link which works for me, if anybody is interested:
https://github.com/cwbriscoe/NeHe-SFML

[xerpi]

I know this topic is old, but I think I shouldn't create a new topic for this:

I've ported NeHe-SFML samples to SFML2.0, here it is: https://github.com/xerpi/NeHe-SFML2.0

If you want to improve the Makefile...I'm not very used with Makefiles xd

[MaxBarraclough]

xerpi, I've done something similar at https://github.com/MaxBarraclough/NeHe-SFML2

I've ported the first 12 lessons. It's based on Chris Briscoe's SFML 1 port, at https://github.com/cwbriscoe/

I've also moved it to CMake.

Although it's working, I can't figure out how the keyboard event-handling works, in, say, Lesson 10.
The movement-key handling beginning at line 286 of
https://github.com/MaxBarraclough/NeHe-SFML2/blob/c2ef9849b478822f44588998c00f47e9251ceb48/nehe_lesson_10.cpp
seems to expect a sf::Event::KeyPressed to be there, despite that we've just run through our    "while (myWindow.pollEvent(event))" loop.

If I move the movement-key handling code up into the "while (myWindow.pollEvent(event))" loop, it stutters as one would expect.

[Hiura]

You can use the `sf::Keyboard::isKeyPressed` function instead of event in this case. See http://www.sfml-dev.org/documentation/2.0/classsf_1_1Keyboard.php#a80a04b2f53005886957f49eee3531599 .

[MaxBarraclough]

I've gathered that's the 'correct' way to do it - I saw it says so in Events explained :: "The KeyPressed and KeyReleased events".

My question was: why does the event-handling work fine in the cpp file I linked to?

It listens for movement keys inside the

while (myWindow.isOpen())

loop, but outside (and after) the

while (myWindow.pollEvent(event))

loop.

Non-movement keys, such as Escape to quit, are handled within

while (myWindow.pollEvent(event))

If I move the movement-key listening to there, it causes stutter.

The code doesn't work perfectly, mind - moving the mouse causes stutter. I'll probably look at moving it to the correct way using isKeyPressed.

I think I've figured it out now: it works when and only when the key-press event is 'left over' from

while (myWindow.pollEvent(event))

This means if I move my mouse around (firing events which are ignored) when holding down the left arrow button, I can cause it to stutter, or even stop, as the event 'left over' is no longer the expected keyboard event, but the mouse event, which is duly ignored.

[Hiura]

Okay. So currently the usage of event on lines 288-333 is undefined since myWindow.pollEvent(event) return false and you exited your event-processing loop.

If it works for you it is only bad luck (having an undefined behaviour is way worse than an actual crash). So basically if you want to get the status of a key outside this event loop you can use sf::Keyboard's API.

That's one thing. The second one now, about your stuttering, is probably related to the frame rate of rendering: your movements formulae doesn't take time into account. I guess you probably have some random stuttering because of that. Try formulae like x = v * t + x₀.