[Loading A Scene]

The thing is, you don't need to do anything in C++ to let the LUA scripts load their things. They are all called by the first UpdateWorld() call in C++, which you can do also before the main loop once to have some better preloading.

My intuition says we should use LUA for all ProcessScene handling, as it's also tied closely to the game development, according to the WYSIWYG principle.

 

If something is not possible in LUA, then gamelib's ProcessScene should kick in and do the rest, but I have to make an option in gamelib to remove it's claws from ProcessScene when LUA is used. Right now it just kills all LUA scripts, which kinda works since it takes care of what it killed

[To be or not to be inherited]

I voted for option 2, it sounds like less duplicate code, and easier maintenance.

Although I think that intelligence is too slow for modern needs, and that intuition replaces it completely (referring to your option 4 comment).

[2.3 DrawLine]

Yeah, it's just a simple direct mode OpenGL command after all, but when it's called often, like in speed tests, the fact that the DLL call has to go through many more instructions (BlitzMax GC, C headers) than a C++ inline function (which is stored directly into the loop, not even calling the function internally (thus avoiding the stack, which is slow)), sums up in the speed difference.

 

Sure it's not a bottleneck, as nobody would call thousands of DrawLines per frame

[Loading A Scene]

While gamelib's ProcessScene still works with 2.3, I think it's not really needed anymore, since LUA does all the ProcessScene with each Model's own script. With the entity scripts you get much more flexibility into the ProcessScene function (like adding parts from disk to models), although gamelib has lots of stuff already built-in.

I don't know yet what is the final solution, as I just need to use them more and write games to see where the benefits and limits of either method show themselves.

[2.3 DrawLine]

If you are using C++, you might consider using gamelib's Line function instead, as it's about 10 times faster than LE's DrawLine:

inline void Color(double r, double g, double b, double a)
{
glColor4f(r,g,b,a);
}

inline void Line(int x, int y, int w, int h)
{
glBegin(GL_LINES);
glVertex2i(x,y);
if(0==w)w=1;
glVertex2i(x+w,y+h);
glEnd();
}

[mass = 1 ... Real weight equivalent ?]

Actually Flexman is right, the gravitational pull makes heavier object fall faster. In addition there is no such thing as vacuum, as 90% of the universe is dark matter. Dark Matter has just the same kind of resistance as air, but of course much lower, so the shape and size of bodies matters also when they fall through dark matter.

[GetElasticity/SetElasticity]

I added the following lines to base.lua, and got body elasticity working via the properties dialog, but I would like the commands to be OOP style, and GetElasticity() is missing:

 

Each line was added after the corresponding line with "sweptcollision":

	group:AddProperty( "Elasticity", PROPERTY_FLOAT )

	elseif key=="elasticity" then
	return 1 --feature request: entity.model:GetElasticity()

	elseif key=="elasticity" then
	SetBodyElasticity(entity.model,value) --feature request: entity.model:SetElasticity(value)

[mass = 1 ... Real weight equivalent ?]

It means comparison for equality. A single = would be an assignment.

[mass = 1 ... Real weight equivalent ?]

From my experience how mass==1 objects behave in LE, it's very similar to 1kg objects in real life.

[LEO, Framewerk, LUA. Where does one start?]

Framewerk doesn't create the graphics window, so it's up to you if you use fullscreen or windowed mode.

Graphics(800,500); // windowed
Graphics(1920,1080,32); // fullHD fullscreen

[LEO, Framewerk, LUA. Where does one start?]

I wouldn't say it's only for FPS, since also flight simulators, train simulators, submarine simulators, golf simulators, horse simulators, MMO, RPG, RTS, and all kind of games which need a realistic looking environment can use it.

 

Maybe some commands for changing some shader settings could be added, but if the default values are correct and give a realistic looking scene, there is not much need for them either. I think many players don't want too much special effects either, if they give no benefit to the gameplay, but only lower FPS.

[CreateJointHinge not working correctly?]

It should still have its convex collision hull, but that works also when rotating it with TurnEntity(), it just won't get affected by other physics bodies, but the other physics bodies will.

[Textures path question]

You need to save the DDS texture as DXT5 + generate MipMaps. Without MipMaps the engine doesn't show the texture at all.

[I Just Found Out!!!]

If you want to run your programs without Administrator account, you can put them under c:\users\username, which should be queried using the %userprofile% environment variable.

As far I know, this is the only directory where the user can write files on Vista and Windows 7. It's similar in Linux, where the user has write access only to /home/username.

 

This is needed when you publish your game, since most people don't want to risk their computer by running as Administrator.

I don't know how commercial games do it, that they can write under "C:\Program Files (x86)\", at least in the installation phase they might ask for the Administrator password, but how they can write after that, must be some trick with native Windows API calls (where they grant the user write access to the directory). Actually there is also a DOS command to do that, if I remember right, so your installer might use that if you don't want to hardcode Windows API functions in your program.

[CreateJointHinge not working correctly?]

Thanks, that works much better, but if I do all attachments to the airplane this way, I lose all property dialogs in Editor.

For example the smoke emitter is really nice to have in Editor, and not in code.

 

I think I will just use TurnEntity() on the propeller, since Newton has a problem with high speed rotations also.

The wheels can be done by code, as they don't need any adjustments in Editor.

The engine exhaust smoke should be done in Editor, as it's too much coding to make particles by code.

[CreateJointHinge not working correctly?]

I tried to make a standalone LUA demo, and it works fine there, when I used Vec3(0,0,0) as position and Vec3(0,0,1) as pin. I can't figure out what's different in Editor.

dofile("scripts/base.lua")
RegisterAbstractPath("")
Graphics(800,600)
fw=CreateFramewerk()
DebugPhysics(1)

model=CreateBodyBox(1,1,4)
pos=model:GetPosition()

target=CreateBodyCone(1,1)
target:Move(Vec3(0,0,-2.7))
target:Turn(Vec3(90,180,0))

fw.main.camera:SetPosition(pos)
fw.main.camera:Turn(Vec3(0,-90,0))
fw.main.camera:Move(Vec3(0,0,-10))

model:SetMass(1)
target:SetMass(1)
SetBodyGravityMode(model,0)
SetBodyGravityMode(target,0)

CreateJointHinge(model,target,Vec3(0,0,0),Vec3(0,0,1))

while(KeyHit(KEY_ESCAPE)==0) do
target:AddTorque(Vec3(0,1,0))
model:AddTorque(Vec3(0,2,0))
fw:Update()
fw:Render()
Flip(0)
end

[global lua variable]

You can use GetTarget(0) to get a target entity from another, and set a EntityKey in the target entity.

I guess you could also use SendEntityMessage to send a message to the target, but that needs probably a bit more coding.

[CreateJointHinge not working correctly?]

I tried all combinations, but it still rotates model, when I rotate target around its Z axis:

CreateJointHinge(model,target,Vec3(0,0,-1.67),Vec3(0,0,1))
CreateJointHinge(model,target,Vec3(0,0,-1.67),Vec3(0,0,-1)) -- maybe pin needs be outside of both bodies?
CreateJointHinge(target,model,Vec3(0,0,-1.67),Vec3(0,0,1)) -- maybe target should be jointed to the model, and not vice versa?
CreateJointHinge(target,model,Vec3(0,0,-1.67),Vec3(0,0,-1))
CreateJointHinge(model,target,Vec3(0,0,-30),Vec3(0,0,1)) -- maybe both position and pin needs to be outside both bodies?

[Lua and key input?]

It should work, you should use AppLog("KEY SPACE DOWN") to see if it has any effect.

Keypressed work only if you click on the Editor scene first, I click on the terrain so I don't select any objects.

[object sinks threw terrain?]

And if you just deleted model, you can't use it anymore. I thought you wanted to parent the body1 to the mesh, somehow like:

EntityParent(entity,body1)

Although I don't know right now how to get the mesh from the entity

[print to engine.log]

I found out why it didn't work for me: I used print("HELLO"), and not Print("HELLO"). print is the standard the LUA command, and it doesn't do anything with Editor, not even on the DOS console when Editor is started from the DOS command prompt.

[CreateJointHinge not working correctly?]

I don't know if the Pin is relative or absolute to the Position vector. Like I said, I'm just trying and guessing, since there is no documentation how joints should be used (not even on the Newton forum, and they don't have a wiki of the commands either).

[object sinks threw terrain?]

Something like FreeEntity(model), and then body1=CreateBodyBox() and EntityParent(mesh,body1).

[Pascal / Delphi Headers]

Delphi is more than Pascal, but it should understand everything what Pascal does. Pascal is like C, while Delphi is like C++. There is also Object Pascal and Turbo Pascal, which were earlier versions of Delphi, although I think Object Pascal goes it's own line.

 

But for sure Delphi does also everything what Object Pascal does. It's like Pascal/Object Pascal in GNU standard, and Turbo Pascal and Delphi is Microsoft VC++ (just made by Borland instead).

 

What's maybe more important to know is that Pascal supports also #ifdefs, so the same header files can be used for Delphi and Pascal.

[object sinks threw terrain?]

You probably can, but I think you need then to remove the Editor created static physics body first with LUA code (not from disk, but from the mesh).