andrew111

If you mean to combine the results of multiple shader programs into one, I think you will have to render the mesh to a texture with each shader program, and then blend the results together (probably using another shader program).

When I learn a new language I usually find a decent book to go through, where I go through each of the language features, e.g. syntax, modules, classes, functions, data types, inputting/outputting text etc, while trying out some small examples from each part (just so I don't immediately forget) and spending only enough time to get an idea of how each work (nothing in depth).

Then once I've got all that down I'll flip through the standard libraries and write some examples on any that interest me, while just making mental notes of the rest of the libraries so I know whats available if I ever need them.

Then after that like others have said, working on various projects that interest me, or for whatever reason I picked that language.

I'm not sure what LuaJIT is,

Well one thing you can do is use c code from within it.

I've just started looking at LuaJIT recently, and an idea I had apart from scripting world objects, was to use it to setup all the monotonous code, such geometry data (eg vertexarrayobjects, vertex buffers, attribute bindings, index buffers etc), shader programs, textures, texture samplers etc. Using luajit ffi to minimise the amount of cbindings necessary.

And then in your main program, load those 'resource files' into a table and just say:

load_resource("shader_program.lua");
lua_getfield(L,-1,"prog");
GLuint program = *((GLuint*)lua_touserdata(L,-1));
lua_pop(L,2);
..

glUseProgam(program);

A resource file might look like:

prog = CreateShaderProgram {
   {"vert",
	[[
	  attribute vec3 a_pos;
	  void main() {
	  ..
	  }
   ]]},

   {"frag",
	[[
	  void main() {
	  ..
	  }
	]]},
   {"attrib", "a_pos", 0}}

vao = CreateVertexArrayObject {
..
}

The More OpenGL Game Programming book's source code has an example under Chapter09/SkyDomesWin32. I'm not sure if the book explains it or not.

Don't you agree that C++ without OOP could just be C instead? Most of the improvements in C++ are related to abstraction. If you chose to ignore those, you might as well go with C?

Do note that I'm trying to teach a beginner the difference between C and C++. I dont have any other agenda here. But don't get me wrong, I never meant to claim that you can't write C++ procedurally. I agree that it will compile, but I'm also quite sure that the only reason it will still compile is because C++ never got a chance to get free of C. Stroustrup himself says that C is obsolete, and that he wants C++ to be free of it.

I'm not sure if you've programmed in c, I've used it a bit for writing libraries, and the main problems I have with it, are things that c++ has introduced shortcuts for, and of course its painfully lacking of the standard template library (So you have to implement your own lists, hashmaps etc). So not defining classes isn't really equivalent to c code.

And mixing procedural and OOP is the same application simply feels right-off stupid to me. I see no defense for it. (OR, more correcly: I see no defense for ME to do that.)

I know the feeling, I dislike mixing functional code with imperative code, but I think procedural and oop can fit together fine. I know the feeling of over obsessing with oop from when I first started programming. If you want to see programming from another perspective, to see why oop isn't so important, you should look at a functional language like scheme (racket is a good implementation) or haskell.

Also if you're interested in alternate oop systems, look at clos (common lisp object system), I think it's a vast improvement over the c++/java/c# oop system.

Knowing some of these things, I believe will help you put things in a better perspective.