OTTD Unlimited?

[belugas]

Looks, Behaviours, Properties, Decision processes, and more...

And a dll is not multi OS...

[Haukinger]

And a dll is not multi OS...

So what ?

[belugas]

OpenTTD is.

[DaleStan]

If I had to chose, I'd go for O(log N) and have a runtime-defined number of cargotypes instead of having to limit them at compiletime for constant lookup time.

NFO supports up to 254 cargo types. If that's not enough for you, then I think you have bigger problems than your lookup times.

Lua could be allowed to do everything from the beginning.

No, it can't. You simply cannot write a language that supports things that no one has yet thought of doing.
If you want to claim otherwise, make sure your proposed spec includes a way to set train property 2B.

Wanna bet I can ? Just define a hook that calls a script-function that looks like this:

Code: Select all

do_vehicle( vehicleid )

Then expose the world-state to the lua-vm and call the hook every game-tick for every pure-lua vehicle. The script can then arbitrarily affect the game.

Expand. Obviously, it is not sufficient to simply have direct access to all of Open's memory, since memory addresses are just as opaque as a sequence of numbers, and (especially if malloced) are not even guaranteed to be the same from one run to the next, much less one OS or processor family to the next. How are you planning to provide this access?

Don't reinvent the wheel just because you want to put a pretty hubcap on it.

What about reinventing a wheel that's not welded to the car and requires a manufactoring plant to exchange it but one that can be replaced by the driver of the car using simple tools?

That is exactly what we're doing. We're removing the hardcoded vehicle behaviours and replacing them with NFO-coded vehicle behaviours. And it's already quite easy to change the wheels. Making a new wheel is still hard, but even that no longer requires a forge.

If you ask it to specify the looks and behaviour of objects in ottd, then, yes it does the job.

You *SAY* that it does.
However, you haven't yet written anything that even begins to compete with NFO's abilities.

And a dll is not multi OS...

So what ?

To be slightly more verbose than Belugas, OpenTTD runs on Windows, Linux, *BSD, MorphOS, OSX (both PPC and x86), OS/2, and BeOS. Any solution you propose must also work on all of the above systems.

[Patchman]

Another thing for my better understanding - do you really have to update the sprites every gametick ? The positional information and cargos etc, ok, but the sprites ? Wouldn't it suffice to update them each time the game updates the screen ?

Considering the game redraws the screen area containing the vehicle whenever it moves, limiting it to screen updates is not going to do much.

However, you do have a point, namely that sprite lookups could be deferred until a vehicle is visible on the screen, i.e. until the sprite is actually used. That would help quite a bit, and while I've considered coding that in the patch, so far newgrf has relatively little impact on performance so it wasn't worth it.

[DaleStan]

I wouldn't have guessed "only when necessary" would do much, at least for OpenTTD, due to the presence of random action 2s. Random 2s are indeed most commonly used for sprite selection, which doesn't affect the game state, but they can also be used in callbacks, which do affect the game state, so they must be processed in lockstep, just like any other RNG call, to ensure that multi-player games stay synced.

To my knowledge, there is no way to tell what vehicles/stations/&c. are visible on the screens of the other players. If this is so, every chain that could contain a random 2 must be processed on every tick (which is, with only a few exceptions, is "every chain, period[0]"), unless you have some knowledge that the chain won't need to be re-randomized. The only thing I know that guarantees that the chain won't re-randomize is if the object's random triggers are all clear, and I don't imagine that's a very common state.

Feel free to apply enlightenment if I've made some stupid mistake here.

[0] This is definitely vehicles, stations, houses, and industry tiles. Possibly also industries and bridges (CB33).

[Patchman]

Random action 2 is a read-only operation, the random values are changed only in specific conditions independent of the action 2 call, so it's not a problem.

[Haukinger]

To make things less abstract, I've done some testing.
The following code does 10000 calls to a lua-function and 10000 calls to a c++-function (both do the same thing):

Code: Select all

extern "C" {
  #include "lua/lua.h"
  #include "lua/lauxlib.h"
}
#include "luabind/luabind.hpp"
//  c++ function
int mf( int a, int b )
{
	if ((a-(a/b)*b)==0)
		return 0;
	return 1;
}

int main() {
  lua_State *pMyLuaState = lua_open();
  luabind::open(pMyLuaState);
  luaL_dostring(
    pMyLuaState,
// lua-function
	"function mf( a, b )\n"
	"  if (a-(a/b)*b)==0 then\n"
	"    return 0\n"
	"  end\n"
	"  return 1\n"
	"end\n"
  );
 
	for ( int i=0; i<10000; ++i )
	{
		luabind::call_function<int>(pMyLuaState, "mf", i, 32 );
		mf( i, 32 );
	}
  lua_close(pMyLuaState);
  return 0;
}

Profiling results are these (WinXP with VS2005 on a rather antique Pentium M with 1.3GHz):

Release-mode (optimized)
5478 microseconds for 10000 calls to c++-mf
29952 microseconds for 10000 calls to lua-mf

Debug-mode:
5672 microseconds for c++-mf
98005 microseconds for lua-mf

That's 5.5 times slower with optimizations turned on and about 17 times slower without optimizations.

As a next step I'm going to look how more complex operations perform (lua-function calls c or other lua functions). If I figure out how to get the just-in-time-compiler up and running, I'll have a look at that too.