@CBJ, I'm not fixated on the XML, I think something may be getting lost in translation, so I'll try asking a different way.
Whether it's XML or a different programming language doesn't really matter, game logic is game logic.
It's essentially an
AST that needs to get processed somehow.
The how it gets processed is the question and argument here.
Say, something like this:
Code: Select all
<do_if value="(not this.ship.pilot.$st_sector?) or (this.ship.pilot.$st_sector != this.ship.sector)">
Does the game translate the above directly to bare metal machine code like:
Code: Select all
LDR R0, <this>
LDRi R0, R0, #[offset this.ship]
LDRi R1, R0, #[offset ship.pilot]
LDRi R1, R1, #[offset pilot.st_sector]
Bz #[if body]
LDRi R0, R0, #[offset ship.sector]
TST R0, R1
Bne #[if body]
B #[else body]
Or, does it simply process the AST through a VM?
If the answer is that the game runs the AST through a VM, then I stand by my earlier statements that a lot more performance could be squeezed out of the game logic. Getting that 7.5ms to sub 1ms would be within reach.
Granted, there is a nuance here.
Given the architectural decision to stick with a VM, I'll take your word that the VM's C++ has been thoroughly optimized and is as good as it can get, so optimizing the VM further will produce diminishing returns.
However, that begs the question whether a VM is still the right architectural decision.
Maybe when the game was first started decades ago, it was absolutely the best decision.
However, times change.
With the advent of open compiler technologies like LLVM or Mono, it may worthwhile to look at ditching the current VM and directly generating CPU instructions from the game logic.
Considering that you've ditched your old physics engine for a new one, maybe this suggestion isn't that far fetched, and I know it will result in major performance gains.
I'm just planting an idea for X5 or version 7
To quote the Musk dude: