BeamdogScott

On a scale of 1-27, I'll go with -1 because the int overflowed.

It was built with several main threads that share the list of game objects, and properly locked before use, etc. The problem is that none of the original developers had multi core CPUs, and few had dual CPU machines, so only one thread was actually really running at a time.

Also, it was built to run on machines with 16 MB of ram. This means that you can never store anything in memory, you need to read it off disk all the time.

On a modern machine, the original Infinity engine spends most of it's time locking and unlocking data.

There are general "Engines" which manage what screen you are on, so there is a World Engine, Journal Engine, Mage Book Engine, World Map Engine, etc. The separation is relatively ok, but there is not a good GameStateManager, or anything like that. This means that there are three copies of code for moving players from one area to another. When you click on the World Map, it's one bit of code, when you transition va a script, it's some other code, and when you click on a door, it's a 3rd version of transitioning players. There is a lot of duplicated duplicated duplicated code as you could expect.

We've generally taken an approach of fixing what we can, where we can, and replacing entire systems if possible, but some times it's very hard to actually find out what a system is doing.

The current infinity engine(not EE) when running in OpenGL mode will do a texture upload and draw per 64x64 background tile, or piece of the GUI.

In the EE versions, all the texture uploads happen during the frame, and then at the end of the frame all the draw calls happen. This is what fixed our performance issue on the Intel GPUs, and helped out the iOS and Android ports a lot.

The current infinity engine does a disk seek twice per string of text you see on screen. The EE versions memory map the .bif files, and dialog.tlk.

We refer to it as code spelunking. Some times you end up standing in a pile of bat guano, sometimes you find a treasure. Most of the time it's the guano.

Archaeologists is actually probably a better way of putting it.

In the example of disk seeking while loading strings: It's easy to look at that code and exclaim how bad it is, how you should never do that when loading a bunch of data, etc.

When you have 5 mb of text, and you are targeting machines with 16 mb of ram, it would be silly to use up 30% of your ram just for text, so their approach makes sense with those constraints.

Thankfully we have way fewer constraints these days. For example a raspberry pi has 512 mb of ram and costs $35.

One of the major constraints we have, is both iOS and Android have 2GB file limits. There are ways to work around it, android gives us two 2GB files we can use, and iOS does some compression so we can fit a bit more then 2GB of data into the package. I think that in 10 to 15 years, a 2GB file limit will be laughable, and the compression we've done to fit things into 2GB will be looked at similar to reading the text strings off disk.

The BG:EE quick loot bar has a multiplayer bug that lets you duplicate items by having multiple clients clicking as fast as they can. In IWD:EE clicking on the item in the quick loot bar is the same as clicking to pick it up out of a ground pile.

This also fixes things not stacking automatically when you pick them up from quickloot.

Looking at the code, this should be included in the BG2EE 1.3 patch.