Advertisement

Whats with lesson 1?

Started by January 19, 2005 04:19 AM
7 comments, last by Mezmirous 19 years, 10 months ago
Man, whats with lesson 1 in nehe? so much code just to launch a blank screen. were in fact it requires a lot less then that. and what with it using windows.h? this defeats the purpose of using OGL, limit access from cross platforming it. My blank screen code, works perfectly fine. /////////////////////////////////////////////////////////////// #include <stdlib.h> #include <GL/glut.h> void init(); void display(); int main(int argc, char*argv[]) { glutInit(&argc,argv); glutInitDisplayMode(GLUT_SINGLE|GLUT_RGB); glutInitWindowSize(250,250); glutInitWindowPosition(100,100); glutCreateWindow("Circle"); init(); glutDisplayFunc(display); glutMainLoop(); return 0; } void init() { glClearColor(0.0,0.0,0.0,0.0); //init view value glMatrixMode(GL_PROJECTION); glLoadIdentity(); glOrtho(0.0,1.0,0.0,1.0,-1.0,1.0); } void display() { glClear(GL_COLOR_BUFFER_BIT); glFlush(); } /////////////////////////////////////////////////////////////// I understand that his code does a little more, like full screen and so on, but for the first lesson, he could at least start off with something at least more basic. like i understood exactly what he was saying, just the tutorial added a bunch of other things that wasnt really needed for a blank screen.
Thanhda TieDigital Shock, Technical Director & Business Relations15-75 Bayly Street West, Suite #173Ajax, Ontario, L1S 7K7Tel: 416.875.1634http://www.digitalshock.net
Well, for starters, his code looks big because it's commented and spaced out for easy reading. Much more importantly, he's creating his window using plain old Windows API, whereas you cheated by using GLUT. If you're OK with losing the flexibility to do whatever you want with your window, and with including another DLL with your app whenever someone downloads it, then that's not a problem. Otherwise, or even if you just want to know what's going on 'under the hood', GLUT is not an option.
Advertisement
yeah, because of this i did not start from nehe's first lesson. :) , i could not.
there may be a zero tutorial for really beginners, that explains the theme of opengl, win32 and somethnig from cross-platform and somthing else..
+-+-+-+-+-STR
Ahhh bollox, I'm totally wasted(drunk/pissed up)
But NeHe shows ya in tut 1 how to create a winodw, in err, Windows... and "hook" up OGL... SDL = like 1 line of code?
However, as the dude before me said, "depth, detail = knowledge" or summin, I dunno, damn rum/beer/spliffs ... NeHe rulez, so does his mum ;)

hehe,


GLut = type "init" = make an openGL window on almost any OS.... NeHe = "mega code" for Windows... (MS windows = 90% of comp sofware eh?)
MS done a good job, I am billy lover (Trying linux, but struggling with ATI drivers and X.org.conf file, argh!

Glut = initWindow(whatever); // done
NeHE = doStuff(); // Woah! that's how Windows works!

More code, = more knowledge
boo ya!
DC
haha, yes i agree, NEHE RULES!! i love the site, i'm on like turtorial 8, but the fact of the matter, the first lesson scares a lot of ppl away, i understand exactly the flexibility of what he is doing. i personally like SDL, rather then GLUT, but GLUT is very good for explainning stuff to Newbies. like the guy said above, that he got scared off. i know so many others that said the same thing. Thats why i was thinking of launching a very NOOB, OGL site. using glut, and explainning from the limited basic API's, then slowly moving on to more flexible API's later on the lessons.
Thanhda TieDigital Shock, Technical Director & Business Relations15-75 Bayly Street West, Suite #173Ajax, Ontario, L1S 7K7Tel: 416.875.1634http://www.digitalshock.net
Well, I think we've all had our little experiences with code fright eh?

I think the problem is just that, code fright. The code might look all confusing and completely undecipherable, but if you think about it so was file IO when you first learned it. There was something about ifstream classes ofstream classes..then you were thinkin: "OMG WTF ARE CLASSES?!?!", you panicked and ran away never to return to the code until the next time you were interested and ready for it.

The thing is, you're usually interested in it and are willing to look at the 100+ lines of code thoroughly once you've learned more about C++ and maybe read a few documents about OpenGL, or when you've coded bigger well-structured programs(exceeding 80 lines). It's all about reducing code fright, and focusing on what the task at hand really is. If you don't get rid of the idea that 100+ lines of unrecognisable code is fearful then you aren't ready for what it is you're coding just yet.

That's why NeHe is good; because you never really know how good you are until you can look at code and say "I know what this does, it's beautiful". When you look at that code in lesson one and understand it, or aren't baffled by the length and complexity, or fear of it as it might be, then you can move on and code that piece of information to the fullest extent.

If you're having trouble understanding the code in that lesson, I would suggest copying the code into your compiler, and read it. Don't look up functions, don't look up acronyms, anything like that. Read the code, and see what it tells you. Anylize what the function names and acronyms might refer to, what the program is doing to the variables and what it's asking of the variables. Then look at the functions and acronyms, put them together in your mind and see what it offers you. Game programming isn't just: startGame(); If you start learning it that way then you're going to hate yourself for it, trust me.

NeHe does a good job of assessing peoples coding levels in my opinion. The fact that he doesn't resort to the "easy way" and use SDL or GLUT is why I thoroughly enjoy his tutorials, and his projects. His code is thorough and structured to the best of his ability for the time frame he's given. I'll admit when I first saw his code my jaw dropped and I went to another website, putting OpenGL behind me and started working on something else. What I was working on was SDL.

You know what I didn't like about SDL? I didn't know how the code worked, I never knew how a window was created, how the class was registered, or how exactly someone would deal with WM_CLOSE or WM_PAINT. You might say that I didn't need to know about it, but in all actuality knowing how things work is programming. On one side there was the easy SDL that didn't "show me" what it is that I was doing, on the other was the cryptic Win32 code.

Later on I wasn't as afraid of unrecognizable functions and long lines of code, and I made a window using pure WinAPI. The SDL program I made before took about .2-.3 seconds more than the WinAPI program to do its thing. I thought "Why does it take so long, if it's such a simple program?". Point is, code reuse is an utter neusence if you want to make things faster. Sure you can make a class for creating and modifying a window, maybe you call it CWindow and require the programmer to set every member in the window class. But the question still remains, how much will you get out of your program if you only set the values that you need? .2-.3 seconds is alot of time when you're dealing with a game, that's 20-30 frames right there.

Game programming is just that, utilizing those 20-30 frames, getting the most out of what little ram and processing power you have. A poorly coded game WILL run slowly, it will have extremely poor frame rate and collision response, and I'de wager clipping errors as well. A hello world program is only doomed to not compile, you can't go wrong with a hello world program. Whereas a game you will have thousands to hundreds of thousands of runtime errors possible in every game loop iteration. What if you didn't have to fix them at all? What if, you never programmed the errors the first place?

They don't call it game programming for nothing you know ;) Complex information needs to be written in a complex way.
Advertisement
i totally agree with you. the problem i have is that lesson 1 could have been broken down into smaller sub lessons. i find it the best way to learn something is by showing you the easy way to do it, and the more flexible way to do it. when i first saw nehe. i was like wow, thats a lot of code just to init a screen. where in SDL it was really only 1 line of code. I personally love the way Nehe teaches the OGL, but not until i did more studies in what i was getting into. i would have to say only 2/10 people that check out the Nehe site actually go on with the lessons, the rest just get scared and run away. I think thats because they dont understand half the stuff he is saying. Thats why i was thinking of making a prep nehe site. a site that prepares you for a OGL. using Glut, and SDL.
Thanhda TieDigital Shock, Technical Director & Business Relations15-75 Bayly Street West, Suite #173Ajax, Ontario, L1S 7K7Tel: 416.875.1634http://www.digitalshock.net
Hello, I just have to say this, the amount of coden in tutorial 1 is really hard to get down(im really new to coding). But i hope it is worth the effort it will take to learn it, therefor i still hang around here instead of other openGL sites where the tutorials are 15 lines long instead of 5-8 pages.

Btw, do i need to be abel to code like a hero in c++ before i start on openGL?





**dumb registration mail, wont send give me my password**
You must attain level 50 in C++ Haxor Skillz before you code OpenGL my friend o.o You might die otherwise! lol

I'de say you can learn anything you want to from just looking at C++ code. The syntax is straightforward, it only bites you when it's 1am and you've ran out of coffee >_>

So yeah, you can do OpenGL even if you know a moderate amount of C++. Functions, classes, structs, pointers, references, macros, includes, headers, vectors, file io, device io. If you know those well then you're gonna do great in OpenGL :)

This topic is closed to new replies.

Advertisement