I'm not in the same situation, but I graduated as a mechanical engineer and did (do) game programming as a hobby. If you are not sure about a career and that you'd enjoy coding >40 hours per week then maybe mechanical engineering is a better choice, since it's easier to get various (easy or more demanding, creative or non creative etc) jobs in that field. And definitely easier than getting a game programming job.
Working as a mechanical engineer can also be a good base for some own little game programmer studio, since it's pretty good paying.
This path works pretty good for me, though I only started programming after starting college.
Maybe it's a stupid suggestion, but computers, especially 1-2 year old models are not expensive (you don't even have to buy a new monitor if you already have one). It's even affordable with saved lunch-money.
So maybe you could update your machine.
First is extremely laziness. The number of questions I see that could be answered with six seconds of Googling is astounding, but generally even those are treated far more civilly than they probably deserve. There are also the "I got C++, how make game?" questions, which take lazy to a whole new level. Again I am still shocked at the treatment such a lazy question ellicits in these parts... I have seen pages of answer to a question someone took 2 seconds to write and often didn't bother with spelling or grammar checking in the least. On a near daily basis, I see two or three near identical threads on the same page! Yet, people still take the time and effort to respond to each of them.
That was my first thought. It is quite hard to be polite, when the exactly same question is asked, and there are 5-8 threads on the SAME FREAKIN PAGE on the For Beginners topic list. They seem not only lazy for some googling, but lazy to open their eyes. More, they are not lazy to put the total rampage-bait-for-me-words "YET ANOTHER" in front sometimes. The poster even knows that he is farking lazy.
And I don't know, maybe I was always a thinker, but seeing the sentence "I have no idea where to start" just gets me down. Maybe we are just too spoiled by the internet and this "information society".
I don't think games are more complex than other applications. It's just the emphasises are elsewhere.
If a game crashes, the user is pissed then she restarts. If a company's main management system crashes, catastrophe.
Applications can have quite complex user interfaces, much more complex than games of game (content) making tools.
Parametric 3D design software is one of the very few programming areas where I donn't have the slightest idea how the hell they work.
It's really the graphics and the audio that seems to be significantly more complex than other applications. And that applications (other than games) is a much broader field than game programming, so it's hard to realize the complexity of other applications.
It's so strange to me that people think there is fundamental difference between programming and game programming.
Why do people even with programming experience think that?
Graphics make them think that?
I have been always wondering.
Yup, V-sync solves that. I believe the choppiness is due to the interference between your forced ("hard coded") 60 fps and the display's refresh rate, which is only 60 fps nominally, but actually it's not precisely 60 fps. So the solution is to enable V-sync instead of the "hard-coded" refresh rate.
I tried to solve that with different refresh rates (up to 300 fps), but there are always hiccups with the display without V-sync.
I don't know about software "V-sync". I was trying to implement one for days, but I couldn't make it work. There isn't any functions that do "wait until refresh is ready" or that queries when the refresh is ready.
What's wrong with V-sync? The input lag it introduces? It's a bit different topic, try to look into that, but as I recall, you don't have much control over that. The video card drivers queue more frames for some reason, so the actually displayed stuff is always 2-3 frames behind.
EDIT: I didn't notice this one:
So why not rely on vsync? Because some computers can force a disable on gfx card config
That's the user's problem IMHO, not yours. It's her responsibility to change the setting of her driver, not yours. You can make a comment about this in the README/Help/Requirements file, I think that would be enough.
So just use v-sync (you can force enable/disable it in your software, if that's your problem. Maybe the ability to force it in the program depends on the driver or the video card, but I think it's doable)
A GUI rendering can be slow, because text rendering can be slow if there's a lot of text. So you can look into text rendering optimization.
I know you didn't ask for comments on the reinventing thing, but it's pretty strange that you are really reinventing the look of the standard win32 GUI.
If you want to release stuff with this GUI, it will kick your ass. And it will kick the users' ass. A GUI that just looks like the well known Windows GUI but doesn't work like it is a major user-anti-experience.
I don't think programming is the best candidate for this tutor thing. Having/getting gamer friends is very different than getting tutoring.
I say surf a lot on this site, especially the "for Beginners" forum.
All I can imagine about tutoring is that the tutor posts you some links about tutorials and books. You can do pretty much the same on the forum, but from a lot more sources.
A tutor may not be available all the time you have specific questions. We are! Tons of helpful users with various experience, a lot of them is the same situation as you. This forum is very active. You can have answers in even a few minutes.
I say you can do far-far better with a forum than a tutor (who is probably not a teacher, and probably not an expert either).
This kind of self shadowing (when the polygons are backfacing relatively to the light) shouldn't be handled with shadow mapping. This should be handled by the standard lighting, which you doesn't seem to have yet.
Simply put: even if there is no shadowing at all, this kind of self shadowing is handled by the simplest lighting models "by default".
Nevertheless, there will be this self shadowing artefact accidentally with shadow mapping. This can be handled usually in two ways: if your meshes are closed, then simply don't render backfacing triangles to the shadow map.
Adding a shadow bias value. Which you seem to do (R += 0.0005), maybe it's just not a good value. Maybe you need a negative value.
If you add this bias, you won't see the self shadowing. Because as I said earlier, you need to handle that with your lighting model.
EDIT: I say "you shouldn't" because you won't be able to solve this kind of self shadowing with shadow mapping (you'll always have this non smooth pattern) and you have to use lighting anyway.
No. I didn't mean that. Just think over what I said in my first post. "End of for loop" may be misworded. I meant "after the for loop".
The complier says not all control paths return a value. Can you figure out what path doesn't return in your code? With your modifications the code still produces this warning message so that means you didn1t insert the return -1 where I implied.
And think about it: what control path doesn't return value? The path that doesn't find the value. Just debug it on paper. That is the exact point where you have to insert the return -1.
Maybe my English sucks, but I think this should be clear.
Didn't the compiler give you a warning message something about BinSearch not returning a value? Because it's only returning a value, when it's found the element. Hmm.
What does it return when it finds the element? In what range? Hmm. It returns a zero or positive value.
Hmm. That means negative values aren't used. Hmm.
That means we could use negative values for other purposes, such as indication that the element is not used? Yay! Let's use -1 for indicating that no element is found (that's pretty standard). We could even use more negative numbers for other error codes, such as the input numElements was negative... That's another story.
But how can we decide if the element is not found? Wait. We already see that the BinSearch is only returning a value when it's found something. If it doesn't return, then what happens? Hmmm. We get to the end of the for loop!
So we know we have to return -1 when nothing is found, and we know that we arrive after the for loop when nothing is found.
Let's put a return -1 after the for loop then!
Yay! We have signalled that we haven't found the element, and we can act upon it by checking the return value of BinSearch in Main. Hmm, that also means we successfully decoupled the logic from the input/output.
In this particular program, we can print stuff differently depending on the return value. If it's -1, we print "nothing found". If it's >= 0, we print the value.
Yes, it's "context sensitive" as you use the term.
And you can safely assume it should work with any multitexturing capable openGL driver/videocard (obviously that is not broken, of from some random guy from the garage)
"Because its OpenGL.
When something works for you it doesn't mean that it will work for everybody."
This can be truth, but not with a well defined thing like this. I mean the multitexturing states' "context sensitiveness" (as you use the term) is a so simple and default behavior, vendors won't fuck it up.
(I hope I'm right, someone correct me if my statements aren't true)