I have tested FPC port only on Windows, and performance is nearly the same as original C++ code.
Maybe someone that has Linux could debug FPC port and find that slowdown.
Announcement: Beta code release
Everything seems to work fine in both fullscreen and windowed mode on Vista 32-bit running on a nVidia 8800GTX card.
Quote: Original post by Willbo_
Everything seems to work fine in both fullscreen and windowed mode on Vista 32-bit running on a nVidia 8800GTX card.
with some changes compiles and runs flawless on Vista 64 bits too.
Quote: Original post by ShadowromQuote: Original post by Willbo_
Everything seems to work fine in both fullscreen and windowed mode on Vista 32-bit running on a nVidia 8800GTX card.
with some changes compiles and runs flawless on Vista 64 bits too.
It would be great if you could submit those changes. [smile]
Quote: Original post by BBBQuote: Original post by ShadowromQuote: Original post by Willbo_
Everything seems to work fine in both fullscreen and windowed mode on Vista 32-bit running on a nVidia 8800GTX card.
with some changes compiles and runs flawless on Vista 64 bits too.
It would be great if you could submit those changes. [smile]
I posted some comments on page one of this thread ;-)
I'll send in my modifications as soon as get home from work. I'll just have to clean up the code a bit o_O
/Shadowrom
I've only read through the first tutorial, and none of the windowing code itself, but here's my feedback so far:
I suggest using references on the interface instead of pointers, where possible, when the consuming class/method doesn't plan to delete the object. It requires less error checking, has easier syntax to use, and is slightly easier for a newbie to understand. If the object isn't going to be reseated, references can be used as private members, too.
In main, the window object is allocated via new and deleted at the end. It should probably be placed on the stack, instead, since this is less error prone. It is also more exception safe.
Calling endl in all over the place will flush the buffer when it isn't necessary. It may be better, readability-wise, but in a larger application will kill IO performance.
If a method has to do any error checking, it should do full error checking for all arguments. OnResize, for example, only does error checking for a single argument. I also suggest moving as much error checking as possible to calling code. This lets implementors of these interfaces write clean code that is free from error checking, and allows them to focus on the meat of the tutorial.
I advise switching casts to use C++ style casts, like static_cast<>(), reinterpret_cast<>(), etc. Casts are type system hacks, so should be avoided. When you need them, though, C++ style casts prevent bugs by being less potent, stick out like a sore thumb in code reviews (easier to make sure they're doing the right thing), and are easier to search for.
I highly applaud the current effort. Teaching OO to newbies is definately the right thing to do, and I wish this sort of code was around when I was first teaching myself OpenGL =)
I suggest using references on the interface instead of pointers, where possible, when the consuming class/method doesn't plan to delete the object. It requires less error checking, has easier syntax to use, and is slightly easier for a newbie to understand. If the object isn't going to be reseated, references can be used as private members, too.
In main, the window object is allocated via new and deleted at the end. It should probably be placed on the stack, instead, since this is less error prone. It is also more exception safe.
Calling endl in all over the place will flush the buffer when it isn't necessary. It may be better, readability-wise, but in a larger application will kill IO performance.
If a method has to do any error checking, it should do full error checking for all arguments. OnResize, for example, only does error checking for a single argument. I also suggest moving as much error checking as possible to calling code. This lets implementors of these interfaces write clean code that is free from error checking, and allows them to focus on the meat of the tutorial.
I advise switching casts to use C++ style casts, like static_cast<>(), reinterpret_cast<>(), etc. Casts are type system hacks, so should be avoided. When you need them, though, C++ style casts prevent bugs by being less potent, stick out like a sore thumb in code reviews (easier to make sure they're doing the right thing), and are easier to search for.
I highly applaud the current effort. Teaching OO to newbies is definately the right thing to do, and I wish this sort of code was around when I was first teaching myself OpenGL =)
I'm not sure if this is the right place to put this...
I would like to see a suggestion box place for nehe.
Specifically, I would like to ask if other programming languages could be downloaded. I use pygame (derived from python) and I was only able to get python nehe instruction on tutorials 1-10. I understand all of that now, so now I'm ready to move on... but my C++ skills are nonexistent.
I would like to see a suggestion box place for nehe.
Specifically, I would like to ask if other programming languages could be downloaded. I use pygame (derived from python) and I was only able to get python nehe instruction on tutorials 1-10. I understand all of that now, so now I'm ready to move on... but my C++ skills are nonexistent.
[size="1"]And a Unix user said rm -rf *.* and all was null and void...|There's no place like 127.0.0.1|The Application "Programmer" has unexpectedly quit. An error of type A.M. has occurred.
[size="2"]
All non c++ ports are made from third party contributors so we have little control over that.
But most tutorials does explain enough to be pretty easy to code in any language, especially if you already have done the first 10.
(but you should lean to at least read and understand c++ code, everything becomes simpler then)
But most tutorials does explain enough to be pretty easy to code in any language, especially if you already have done the first 10.
(but you should lean to at least read and understand c++ code, everything becomes simpler then)
www.flashbang.se | www.thegeekstate.com | nehe.gamedev.net | glAux fix for lesson 6 | [twitter]thegeekstate[/twitter]
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement