l 24 to 266
These are the tables from iconv. Could you confirm that they are pointers ? When a char is read in the xml, it loads in this specific pointer relative to the pagecode used ? So the DLL can grab it by identifing pointers associated to the char. Am i right ?
No. They are tables. The CodePage contains 256 characters using the IDs 0-255. The tables show which unicode ID each character has. For instance cp1252:
Code:
/* 0x80 */
0x20ac, 0xfffd, 0x201a, 0x0192, 0x201e, 0x2026, 0x2020, 0x2021
The first is 0x80 or 128 in CP1252. However it is 0x20ac in unicode meaning whenever the XML text has a character ID 0x20ac, it should be stored as 128 in the string given to the exe file.
Some IDs are skipped, which mean the characters use the same ID on the CodePage as in unicode. This goes for 0Xa0-0Xff in cp1252.
l 291, 298 & 299
I don't understand the notation "&=" (pointers address?) neither where does these address comes from "0x7F" / "0x40".
A += B is the same as A = A + B. Likewise A &= B is the same as A = A & B.
& is binary add meaning it goes through each bit in both variables and sets the resulting bit to 1 if it's 1 in both inputs.
b0111 1111 = 0x7F
b1000 0000 = 0x80
In UTF8, if the first bit i 0, the character uses just one byte. If the first is 1, then the rules for multi byte characters applies.
l 326
"iBuffer = conversion_table_gamefont[iBuffer];" The table "conversion_table..." is not defined anywhere in the dll code. Where does that come from ?
line 268
Code:
static unsigned short conversion_table_unicode[128];
It is the unicode IDs of the 128-255 characters in the currently active CodePage. It is filled with data from the arrays from iconv before it's used. The characters 0-127 are standard ASCII characters and are the same in unicode as in all CodePages, hence no reason to make a conversion array.
Once conversion_table_unicode has been set, the code will use that one exclusively and not care for the iconv tables or which CodePage it is using.
l470->510
I don't understand at all this specific part of the code. I suppose these codes make reference to a position into the gamefont, but where can i find such numbers ? How did you found them ?
In CvEnums.h:
l 1156
In this file, there are a lot of variables (constants?). I guess they are manipulated by C++ functions into the DLL then usable by python as the comments seem to indicate.
You defined "enum GameFontTypes" with several types. The previous code in FontConversion seems to define the offset + value of each char and initialize before the main menu.
Then, what are all these variables made for ? To be used in advisors which cannot render the fonts from the codepage but from the gamefonts ?
GameFont IDs are rather hard to figure out. I have a heavily modified Domestic Advisor for colo, which will loop through the IDs and display whatever is stored. I have planned to make something similar for vanilla BTS, but never got around to actually do it.
Line 469 states that it is vanilla characters. It's actually a fix for a vanilla bug. Line 80 and 90 in
cp1252 will not appear on city billboards. Presumably the code can just be copied because a vanilla bug affects all mods. I can't remember precisely how I ended up with the numbers I wrote, but they are the numbers, which should make it display correctly.
The enum is used together with an array to tell the ID of the first yield, building, whatever. Vanilla hardcodes those, which limits the number of icons you can use in each category. Using custom values (which should be configurable from XML) gives the freedom to set a virtually unlimited number of icons in GameFont. The city billboards can handle 286 characters or something, but icons used in city screen, pedia or whatever can be placed outside the range of billboards. This may or may not be useful depending on the size of the mod. Remember that this code is written with multiple mods in mind meaning it should be configurable to handle more or less whatever the XML modders throws at it.
In Civ4, we have "CvInternalGlobals", which seems to make the link between python and the dll (from what i understand). When you prefix a call with "gc." it asks for CvInternalGlobals but you've made reference to CvGlobals each time in your code. I don't know how to adapt that.
Writing GC (it's uppercase in C++ and lowercase in python) is a shortcut for getting a pointer. GC goes to one class to get a pointer to another class or something like that (can't remember the specifics offhand). Storing the resulting pointer locally makes the code a little faster than looking it up each time. Most likely it makes no real difference. I just got picky with performance because... let's just say that after I joined M:C, performance has increased so much that it's hard to believe that it's mostly still the same code.
