Brianetta wrote:That's an important point, and too important to ignore. Its state is minimal. It's a tiny virtual machine, tightly integrated into the game. There's no issues with interfaces, because the machine was written into OpenTTD with OpenTTD in mind, and the same will undoubtedly go for the Patch. LUA is a big, general purpose language. KUDr is, I believe, contemplating its use for a competitor AI. Newgrf was devised by Patchman as a way to integrate arbitrary game information and code into the game without losing performance.
If I'm wrong, please correct me, but I think the newgrf-thing is older than ottd. Obviously, the ttdpatch-developer don't have access to the source code, so they had to cope with what the executable offers and what can be hacked into it. The newgrf format is not as it is because it is clever or fast or has any other hidden benefits, but because the ttdpatch-executable understands it.
XML and LUA cannot hope to perform as well as NFO with inline sprite information can (correct me if that's not quite what a newgrf is). We don't need a relatively heavy general purpose VM in the game. We need an integrated, lightweight, optimised one. One that was written with a sprite- and tile-based transport game in mind. Funny thing is, we have that. What's there works. It isn't broken, and it doesn't need fixing.
You're saying that whatever newgrf for whatever entity in ttdpatch that works correctly in ttdpatch will work correctly in ottd ?
As for performance, most of the nfo-processing seems to be done upon loading the newgrf, and that's effectively free time.
Noone says that a lua script is not allowed to create a map<cargo_id,spriteset> (living in the game, not the vm) by recolouring a single spriteset depending on the types of cargoes that exist. But it does so upon loading, so it is not required to do in realtime. The game then uses map<cargo_id,spriteset>::operator[] to lookup the correct spriteset (std::map is quite fast, O(log N), I think - but you could use any data structure here, I just want to illustrate things).
This could be the default behaviour (in the xml-file a lua-script is specified that creates a map<>). However one strange trainset could define a car whose sprite depends not on the cargo but on the actual background bitmap. So it would say (in xml, essentially it's going to be kind of a callback-table) "hey, I don't create precoloured sprites, call this lua-script instead and pass it a reference to the bitmap your painting everytime you want to draw me". This object would draw A LOT slower than other objects, but it could draw
anything. This will be needed quite rarely, because there can be different prerendering schemes as new behaviour in newgrfs shows up, only the newest, most innovative ones would be self-drawing.
The only other thing we need is a full-spec NFO compiler. It might compile LUA scripts to NFO, or it might do Scheme, or Python, or a custom language. That shouldn't matter, and it's a choice that is entirely made by the compiler's designer. Heck, we could have two competing compilers with different languages.
Then we could even make the source of GPL newgrfs available... amazing.
That would solve some (most ?) problems, but it means stopping half way. You can still only do what newgrfs can do in ttdpatch.