I suspect the trick to this is maintaining consistency: always doing some time on it every day, and always logging it down. Apparently I had finished Tutorial #4: Buffers, Shaders, and GLSL, but had not yet gone on to Tutorial 5: Texturing.
That makes a certain amount of sense, as, around the time I was doing this last, Rastertek took its tutorials down, and while the Internet Archive had the text, it lacked the textures to be applied.
You know how they say that the journey of a thousand miles begins with a single step? Apparently it also requires a second step, a third, and all the rest too.
Restarting after a long hiatus is rather interesting. In the interim, RasterTek took down their tutorials, then re-uploaded them, and I’ve managed to forget where I was in the tutorials. I’m pretty sure I’m somewhere either in the middle of, or at the end of #4: Shaders, because the program compiles, and runs, but I’m not quite sure where I am, because instead of the coloured triangle, it gives me a square. Not sure if that means I’m into the next tutorial, or if I was just fiddling around with parameters to see what happened.
It does mean, however, that I need to go through the full tutorial, and compare my code with the original author’s. Code review time!
You all take care,
Harry Voyager
Got everything copied in and compiled on Tutorial #4, Rendering Your First Triangle, and lo and behold, the triangle doesn’t appear to render. It’s not throwing any errors, it just doesn’t render.
I’m thinking I’m going to have to use the debugger to step through the code to see what the program is actually doing. I suppose I should look at this as a learning experience, rather than as incredibly tedious.
I’m also thinking I need to figure out ways to store things that need to be routinely modified in somewhere other than the compiled code…
Turns out all that was needed was to set Studio to import the mission icons from the MS server. That and fixing a number of typos my transcription introduced, and Tutorial 2: The Framework, runs.
Now we’re into the bones of actually running OpenGL. Apparently it requires about two pages of define and typedef statements. This puts me on the horns of a dilemma: to Transcribe, or to copy? On on hand, simply copying the example code into a working build is quick, and shouldn’t introduce any new errors. On the other hand, transcribing everything requires looking at every line of the code, and have some idea what it actually does, but it is very time consuming.
Do I take the quick path to running code, or do I take the slower path, with the better potential for upfront understanding? Or is the slow path just an illusion of greater understanding?
Technically, this is the fifth day I’ve been working on this, though I’ve only just decided to start blogging it. So far I have started, then abandoned, for now, Android development due to an issue with the emulator wanting to loop infinitely trying to load sound drivers that don’t exist (even with the -noaudio flag active), and I have reverted back to plain PC development.
I’ve found an interesting set of 3D graphics tutorials on RasterTek I’ve gotten the Tutorial 2 Framework transcribed into Visual Studio 2012, and my typos all fixed, and I’ve discovered that between the time when RasterTek wrote his code, and when I’m trying to run it, there have been some changes in the character encodings used. Now I get to dive into the wonderful world of C++ Strings to figure out how to get it to compile on my machine. Fun. (No, I don’t know if that was sarcastic or not, either.)
Digging around has turned up this interesting article: Code Project: The Complete Guide to C++ Strings We’ll see if it solves the issue, or just leads to more questions (or both).
Have fun on your Thursday!
Harry Voyager
