A few misunderstandings here.
Marco Tarini added MD3 support to OpenBRF because there aren't that many generic
authoring formats that support vertex animations. Same thing for Valve's SMD. It's a smart way of reusing other people's DCC plugins for similar things. That way we don't have to make our own Blender/Maya/3ds Max extensions and keep them up to date. Why reinvent the wheel?
But again, this is only something that is used for importing into BRF files in this particular software made after the fact by a modder that doesn't have anything to do with TaleWorlds. The game doesn't read anything other than the formats Armagan and the rest of the team made. TaleWorlds originally used their Blender plugin to generate TRF (
text resource) files, the game reads them and spits BRF (
binary resource) files during startup. A bit like baking a cake, reading tailored binary files is always going to be faster than parsing text. It can copy the data structures directly from disk to RAM and use them straight away without much shuffling or conversion.
The good thing about text is that it can be pretty, humans can read and write it easily. But it's slow, heavier and takes significantly more space. That's why
TRFs are only read once (or when modified) and cached into
BRFs. Best of both worlds.
--
The game doesn't know anything about Python either; the Module System is a
.txt bytecode compiler that is made out of Python scripts and data. You can make your own
.txt generators in any language. Python was a good choice because of the handy way of assembling tuples and having macros and syntactic sugar on top.
Personally, I think it was a very smart idea. It's both easy to tweak (tables of tables of data right next to logic) and customizable from the inside out. I love it. Without that Mount&Blade wouldn't have been half as successful. They went for C# for the sequel, and I don't think it was a great call, it raises the bar significantly and adds unneeded complexity. Maybe Lua would have been better. But we'll see.
--
From what I know, the RGL engine grew out of a DirectX sample project, but it's otherwise custom made, barring some libraries. And the internal organization isn't particularly pretty, but that's normal for every single game out there; requirements in real life change all the time, so there are some shortcuts taken here and there.
@cmpxchg8b and
@K700 know all this way better than me, but it's clearly programmed in C++, with classes, custom data types, constructors and that kind of thing. Maybe some small third-party files are C.
The subsystem that reads the mod
.txt files and interprets the triggers and operations is custom C++, that's for sure.
Technically, I'd say that the game has always been more impressive than it looks. Art and visual effects have always been the main issue, maybe caused in part by bad tooling. But this is just guesswork.
You only need to compare Native with any modern Warband mod. Just by adding Gutekfiutek's props you improve the mood tenfold. Thank Marco Tarini, Thorgrim and the others for giving us great tools, or at least better than the official ones.
Hope it helps. Let me know if I messed up somewhere.
