andrew111

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 {
..
}

but C++ does not run on a virtual machine like Java does.

That does not have anything to do with why c++ doesn't have an "Application" class for the main.

riverreal is correct in that c++ is a multi paradigm language, which means you use oop where it helps, and procedural or functional (limited) programming etc where they help.

And I don't think having an "Application" class helps at all, making a class to be instantiated once (except for cases of inheritance) seems like a wasted effort.

Well I'm using racket scheme to make small demos, though not a game. The advantages for are that it's functional, and has all the advantages that come with that (Of which I'm never going back to an imperative language for personal use).  You can mix imperative code with functional, which is necessary for doing inputs and outputs, e.g. drawing graphics, loading files, keyboard input etc.

Also it has macros which allow you do add extensions to the language, e.g. I used this to make a system for loading and setting shaders.

(define (some-effect)
  (effect
 	(attribute "a_pos" 0)
 	(attribute "a_nor" 1)

 	(uniform "a" 0.0 0.3 0.0)
 	(uniform "b" 0.9)

 	(vertex "
   	#version 150
   	attribute vec3 a_pos, a_nor;
   	uniform mat4 u_modelViewProjMat;
   	varying vec3 c;

   	void main() {
       	gl_Position = u_modelViewProjMat * vec4(a_pos,1.0);
		c = abs(normalize(a_nor));
   	}")

 	(fragment "
   	#version 150
   	varying vec3 c;
   	uniform float b[2];
   	uniform vec3 a;


   	void main() {
       	gl_FragColor = vec4(c+a+vec3(0.0,b[1],b[0]),1.0);
   	}")))

The disadvantages are that you have to write interfaces to c shared libraries to do anything useful, e.g. latest version of opengl, physics, sound, window etc. Though some of the other lisps might have bindings for those things already (I know common lisp does, but I prefer scheme).

I'm currently in the process of writing a library that auto generates bindings from c header files (nearly complete), it uses macros so that you just make a module and call a macro from my library which when compiled will auto generate the bindings for you.

I have a feeling writing a physics engine in it wouldn't be as fast as one written in c/c++, but for a game, if all the intensive code is imported from c bindings leaving the the rest in scheme, it should be fine.