OTTD Unlimited?
Moderator: OpenTTD Developers
- belugas
- OpenTTD Developer
- Posts: 1507
- Joined: 05 Apr 2005 01:48
- Location: Deep down the deepest blue
- Contact:
Looks, Behaviours, Properties, Decision processes, and more...
And a dll is not multi OS...
And a dll is not multi OS...
If you are not ready to work a bit for your ideas, it means they don't count much for you.
OpenTTD and Realism? Well... Here are a few thoughs on the matter.
He he he he
------------------------------------------------------------
Music from the Bloody Time Zones
OpenTTD and Realism? Well... Here are a few thoughs on the matter.
He he he he
------------------------------------------------------------
Music from the Bloody Time Zones
- belugas
- OpenTTD Developer
- Posts: 1507
- Joined: 05 Apr 2005 01:48
- Location: Deep down the deepest blue
- Contact:
OpenTTD is.
If you are not ready to work a bit for your ideas, it means they don't count much for you.
OpenTTD and Realism? Well... Here are a few thoughs on the matter.
He he he he
------------------------------------------------------------
Music from the Bloody Time Zones
OpenTTD and Realism? Well... Here are a few thoughs on the matter.
He he he he
------------------------------------------------------------
Music from the Bloody Time Zones
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.Haukinger wrote: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.
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?Haukinger wrote:Wanna bet I can ? Just define a hook that calls a script-function that looks like this:DaleStan wrote:No, it can't. You simply cannot write a language that supports things that no one has yet thought of doing.Haukinger wrote:Lua could be allowed to do everything from the beginning.
If you want to claim otherwise, make sure your proposed spec includes a way to set train property 2B.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.Code: Select all
do_vehicle( vehicleid )
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.Haukinger wrote: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?Patchman wrote:Don't reinvent the wheel just because you want to put a pretty hubcap on it.
You *SAY* that it does.Haukinger wrote:If you ask it to specify the looks and behaviour of objects in ottd, then, yes it does the job.
However, you haven't yet written anything that even begins to compete with NFO's abilities.
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.Haukinger wrote:So what ?belugas wrote:And a dll is not multi OS...
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Considering the game redraws the screen area containing the vehicle whenever it moves, limiting it to screen updates is not going to do much.Haukinger wrote: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 ?
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.
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).
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).
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
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):
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.
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;
}
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.
Who is online
Users browsing this forum: No registered users and 1 guest