tile.cpp<\/code> by getting rid of any remaining traces of their memory manager rmem<\/code>. Then we adopt some debug methods and use them inside of the main run function.<\/p>\r\n\r\n\r\n\r\nvoid testTileRendering() {\r\n\ttileRes = resFile->newContext(MKTAG('T', 'I', 'L', 'E'), \"tile resources\");\r\n\tlistRes = objResFile->newContext(MKTAG('L', 'I', 'S', 'T'), \"list resources\");\r\n\tresImports = (ResImportTable *)LoadResource(listRes, MKTAG('I', 'M', 'P', 'O'), \"res imports\");\r\n\r\n\tinitResourceHandles();\r\n\tmainPort.setDisplayPage(&protoPage);\r\n\tinitPanelSystem();\r\n\tinitDisplayPort();\r\n\tinitDisplay();\r\n\tinitGameMaps();\r\n\ttestTiles();\r\n}<\/code><\/pre>\r\n\r\n\r\n\r\nAlong with the actual tile debug blitting function testTiles<\/code>, I also call a lot of initialization methods. These methods are supposed to be called the game’s own initialization tower procedure, located in a file called towerfta.cpp<\/code>. However, since we’re trying to blit tiles without going through the initialization, we have to call these methods manually.1<\/sup><\/p>\r\n\r\n\r\n\r\nvoid testTiles() {\r\n\tinitTileCyclingStates();\r\n...\r\n\tsetCurrentMap(0);\r\n\tPlayModeSetup();\r\n\r\n\t\/\/ draws tiles to tileDrawMap.data\r\n\tdrawMetaTiles();\r\n\r\n\tuint8 *img = tileDrawMap.data;\r\n\tPoint16 size = tileDrawMap.size;\r\n\tdebugC(3, kDebugTiles, \"img = %p, size = %d,%d\", (void *)img, size.x, size.y);\r\n\r\n\tGraphics::Surface sur;\r\n\tsur.create(size.x, size.y, Graphics::PixelFormat::createFormatCLUT8());\r\n\tsur.setPixels(img);\r\n\tsur.debugPrint();\r\n\tg_system->copyRectToScreen(sur.getPixels(), sur.pitch, 0, 0, sur.w, sur.h);\r\n...\r\n}<\/code><\/pre>\r\n\r\n\r\n\r\nThe testTiles<\/code> method has quite some stuff going on, but the important parts here are setCurrentMap(0)<\/code> and drawMetaTiles()<\/code>. drawMetaTiles<\/code> takes in the current map, which we set with setCurrentMap<\/code>, and then blits it into gPixelMap tileDrawMap<\/code>. It is analogous to OSystem’s Graphics::Surface<\/code>.<\/p>\r\n\r\n\r\n\r\nAbout 3 or 4 hierarchies below the drawMetaTiles<\/code> call, we have a call to drawTile<\/code>, which is defined in assembly. Thus, this is probably the method we need to implement.<\/p>\r\n\r\n\r\n\r\nThankfully, SAGA engine has a method of the same name implemented in saga\/isomap.cpp<\/code>. After implementing it inside of SAGA2, commenting out irrelevant blocks and changing values to FTA2 standards, we get the following result:<\/p>\r\n\r\n\r\n\r\n\r\n\r\n![\"\"](\"https:\/\/blogs.scummvm.org\/ayyg\/wp-content\/uploads\/sites\/7\/2021\/06\/1.png\")
<\/a>Never did squares look so beautiful.<\/figcaption><\/figure>\r\n<\/figcaption>\r\n<\/figure>\r\n\r\n\r\n\r\nIt blits mostly<\/em> correctly. Here we see horizontal stripes throughout the image, which we later learn is the result of the tile width constant. Spoilers.<\/em><\/p>\r\n\r\n\r\n\r\nScripts<\/h2>\r\n\r\n\r\n\r\n
We run the same methodology on scripts:<\/p>\r\n\r\n\r\n\r\n
\r\n- Clean up
interp.cpp<\/code><\/li>\r\n- Find a way to test it out.<\/li>\r\n<\/ol>\r\n\r\n\r\n\r\n
For item 1 however, we have to be careful of these kinds of expressions too:<\/p>\r\n\r\n\r\n\r\n
return strSeg + ((uint16 *)strSeg)[strNum];<\/code><\/pre>\r\n\r\n\r\n\r\nThe problem with this expression is that we’re trying to read a WORD (2 bytes) from a byte array that is loaded from an external resource (i.e. files). The result will change depending on whether the machine is Big Endian or Little Endian. For this reason, we use READ_LE_16<\/code> to specify 16 bits to be read in Little Endian:<\/p>\r\n\r\n\r\n\r\nreturn strSeg + READ_LE_INT16(strSeg + 2 * strNum);<\/code><\/pre>\r\n\r\n\r\n\r\nViva OSystem! Portable code has never been so easy.<\/p>\r\n\r\n\r\n\r\n
For item 2 we do the following:<\/p>\r\n\r\n\r\n\r\n
void testScripts() {\r\n\tscriptCallFrame scf;\r\n\t\/\/for (int i = 1; i < 100; ++i)\r\n\t\/\/\trunScript(i, scf);\r\n\trunScript(1, scf);\r\n}<\/code><\/pre>\r\n\r\n\r\n\r\nWe also confirm it is trying to run scripts through debug statements:<\/p>\r\n\r\n\r\n\r\n
Scripts: op_enter: [SagaObject].WriteName \r\nScripts: op_return<\/code><\/pre>\r\n\r\n\r\n\r\nInitialization<\/h2>\r\n\r\n\r\n\r\n
I will mostly just skim over the procedure, but many of initialization steps deserve their own posting.<\/p>\r\n\r\n\r\n\r\n
Now that we have the basic resource loading and image displaying working, it is time to the proper tower initialization I mentioned before. The entire structure is as follows<\/p>\r\n\r\n\r\n\r\n
TowerLayer tower[fullyInitialized] = {\r\n\t{ nothingInitialized, &initTowerBase, &termTowerBase },\r\n\t{ errHandlersInitialized, &initErrorManagers, &termErrorManagers },\r\n\t{ delayedErrInitialized, &initDelayedErrors, &termDelayedErrors },\r\n\t{ activeErrInitialized, &initActiveErrors, &termActiveErrors },\r\n\t{ configTestInitialized, &initSystemConfig, &termTowerBase },\r\n\t{ memoryInitialized, &initMemPool, &termMemPool },\r\n\t{ introInitialized, &initPlayIntro, &termPlayOutro },\r\n\t{ timerInitialized, &initSystemTimer, &termSystemTimer },\r\n\t{ resourcesInitialized, &initResourceFiles, &termResourceFiles },\r\n\t{ serversInitialized, &initResourceServers, &termResourceServers },\r\n\t{ pathFinderInitialized, &initPathFinders, &termPathFinders },\r\n\t{ scriptsInitialized, &initSAGAInterpreter, &termSAGAInterpreter },\r\n\t{ audStartInitialized, &initAudioChannels, &termAudioChannels },\r\n\t{ tileResInitialized, &initResourceHandles, &termResourceHandles },\r\n\t{ palettesInitialized, &initPalettes, &termPalettes },\r\n\t{ mainWindowInitialized, &initDisplayPort, &termDisplayPort },\r\n\t{ panelsInitialized, &initPanelSystem, &termPanelSystem },\r\n\t{ mainWindowOpenInitialized, &initMainWindow, &termMainWindow },\r\n\t{ guiMessInitialized, &initGUIMessagers, &termGUIMessagers },\r\n\t{ mouseImageInitialized, &initMousePointer, &termMousePointer },\r\n\t{ displayInitialized, &initDisplay, &termDisplay },\r\n\t{ mapsInitialized, &initGameMaps, &termGameMaps },\r\n\t{ patrolsInitialized, &initRouteData, &termRouteData },\r\n\t{ spritesInitialized, &initActorSprites, &termActorSprites },\r\n\t{ weaponsInitialized, &initWeaponData, &termWeaponData },\r\n\t{ magicInitialized, &initSpellData, &termSpellData },\r\n\t{ objectSoundFXInitialized, &initObjectSoundFX, &termObjectSoundFX },\r\n\t{ prototypesInitialized, &initObjectPrototypes, &termObjectPrototypes },\r\n\t{ gameStateInitialized, &initDynamicGameData, &termDynamicGameData },\r\n\t{ gameModeInitialized, &initGameMode, &termGameMode },\r\n\t{ gameDisplayEnabled, &initTop, &termTop },\r\n\t{ procResEnabled, &initProcessResources, &termProcessResources }\r\n};<\/code><\/pre>\r\n\r\n\r\n\r\nWhile TowerLayer is a struct defined the following way:<\/p>\r\n\r\n\r\n\r\n
struct TowerLayer {\r\n\tint \t\t\tord;\r\n\tpPROGRAM_INITIALIZER\tinit;\r\n\tpPROGRAM_TERMINATOR\tterm;\r\n\tconfigProblem\t\tonFail;\r\n};<\/code><\/pre>\r\n\r\n\r\n\r\npPROGRAM_INITIALIZER<\/code> and pPROGRAM_TERMINATOR<\/code> are simply typedefs for function pointers. We don’t need to care about configProblem<\/code> right now.<\/p>\r\n\r\n\r\n\r\nYou may be able to guess how the initialization works now. We go through each step in the tower<\/code> table, calling the appropriate initialization functions (and vice-versa when terminating). So our plan of attack is to simply connect to the game’s main loop, reach the tower initialization process and fix the errors that pop up (and boy, will many errors pop up).<\/p>\r\n\r\n\r\n\r\nThese errors are mostly memory management ones related to rmem<\/code> (such as the use of RHANDLE<\/code>). Some others arise from the difference in architecture (such as different pointer sizes) or from writing into “packed” structs. Yet more errors result from their custom timer system.<\/p>\r\n\r\n\r\n\r\nrmem<\/code> related errors are easy to fix, but resource loading-related ones require direct writing into each resource struct, like this:<\/p>\r\n\r\n\r\n\r\nstatic void readGameObject(hResContext *con, ResourceGameObject &obj) {\r\n\tobj.protoIndex = con->readS16LE();\r\n\tobj.location.u = con->readS16LE();\r\n\tobj.location.v = con->readS16LE();\r\n\tobj.location.z = con->readS16LE();\r\n\tobj.nameIndex = con->readU16LE();\r\n\tobj.parentID = con->readU16LE();\r\n\tobj.script = con->readU16LE();\r\n\tobj.objectFlags = con->readU16LE();\r\n\tobj.hitPoints = con->readByte();\r\n\tobj.misc = con->readU16LE();\r\n}<\/code><\/pre>\r\n\r\n\r\n\r\nWe end up scraping this design later on though, opting instead to load resources in each struct\/class’s constructor or member functions.<\/em><\/p>\r\n\r\n\r\n\r\nFinally, the timer related errors caused headache for some time because it caused the game to stop progressing without us knowing. This particular example doesn’t happen at this moment in time<\/em>, but I’m gonna explain it here in order to not break the flow. I was running around in circles trying to figure out just why was the screen not updating<\/em>*, until I noticed there was a check like this in a routine that updates the screen:<\/p>\r\n\r\n\r\n\r\n\/\/ If it's time to do a new frame.\r\nif (frameAlarm.check()\r\n\t&& tileLockFlag == 0) {<\/code><\/pre>\r\n\r\n\r\n\r\nWe hadn’t implemented timers yet, so this check never passed. After that, sev (my mentor) rewrote the timers so that they made use of OSystem’s TimerManager.<\/p>\r\n\r\n\r\n\r\n
After fixing some more initialization steps, enabling the cursor and some other stuff, we eventually were into the event loop looking at this:<\/p>\r\n\r\n\r\n\r\n![\"\"](\"https:\/\/blogs.scummvm.org\/ayyg\/wp-content\/uploads\/sites\/7\/2021\/06\/2.png\")
<\/a><\/figure>\r\n\r\n\r\n\r\nDrawing UI<\/h2>\r\n\r\n\r\n\r\n
We knew some things were being drawn on the screen. We also knew we could draw images properly due to our previous test run. So why were we getting garbage?<\/p>\r\n\r\n\r\n\r\n
Well, spoilers ahead.<\/p>\r\n\r\n\r\n\r\n
1. The main surface on which the UI is drawn on was not initialized<\/p>\r\n\r\n\r\n\r\n
2. Our blitting functions were being ignored by a display check that returned false due to Windows DD not being present.<\/p>\r\n\r\n\r\n\r\n
After fixing both of those issues, things were properly drawing<\/p>\r\n\r\n\r\n\r\n\r\n![\"\"](\"https:\/\/blogs.scummvm.org\/ayyg\/wp-content\/uploads\/sites\/7\/2021\/06\/3.png\")
<\/a>Would you look at the progress.<\/figcaption><\/figure>\r\n<\/figure>\r\n\r\n\r\n\r\nBy clicking on the UI and fixing stuff that crashed, we eventually got other parts of the UI showing up too.<\/p>\r\n\r\n\r\n\r\n\r\n![\"\"](\"https:\/\/blogs.scummvm.org\/ayyg\/wp-content\/uploads\/sites\/7\/2021\/06\/4.png\")
<\/a>Tasty.<\/figcaption><\/figure>\r\n<\/figure>\r\n\r\n\r\n\r\nI went to sleep and left it to sev to implement the rest of the sprite related routines. He also fixed the tile width constant to the proper value.<\/p>\r\n\r\n\r\n\r\n![\"\"](\"https:\/\/blogs.scummvm.org\/ayyg\/wp-content\/uploads\/sites\/7\/2021\/06\/5.png\")
<\/a><\/figure>\r\n\r\n\r\n\r\nDrawing Platforms<\/h2>\r\n\r\n\r\n\r\n
So our next step was to figure out what’s going on with the game map. Cutting to the chase, something called DList<\/code> was the problem. I haven’t mentioned it much, but removing it completely is also one of our goals.
In FTA2, platform (map) fetching makes use of a cache<\/code> design, and after (haphazardly) getting rid of it I was greeted with this sight.<\/p>\r\n\r\n\r\n\r\n![\"\"](\"https:\/\/blogs.scummvm.org\/ayyg\/wp-content\/uploads\/sites\/7\/2021\/06\/6.png\")
<\/a><\/figure>\r\n\r\n\r\n\r\nThis sure seems like a lot of progress, but I later learned that the window was not updating properly when we fixed the problem mentioned above*.<\/p>\r\n\r\n\r\n\r\n
After that was fixed, we started seeing the map flickering:<\/p>\r\n\r\n\r\n\r\n
![\"\"](\"https:\/\/blogs.scummvm.org\/ayyg\/wp-content\/uploads\/sites\/7\/2021\/06\/fta2.gif\")
<\/a><\/p>\r\n\r\n\r\n\r\nI’m gonna spoil once again, but this was the result of not properly porting the cacheing in the platform fetching.<\/p>\r\n\r\n\r\n\r\n
Headache-inducing Scripts<\/h2>\r\n\r\n\r\n\r\n
This problem took a particularly long time to figure out. It deserves its own post, so I’m not going to explain the details just yet.<\/p>\r\n\r\n\r\n\r\n
Basically, we were crashing at a script execution. We thought of many possibilities, such as the wrong script being called. However sev checked against the original and confirmed that we were in the correct script call. The script call in question was this one:<\/p>\r\n\r\n\r\n\r\n
int16 scriptSelectNearbySite(int16 *args) {\r\n\tMONOLOG(SelectNearbySite);\r\n\tTilePoint tp;\r\n\r\n\ttp = selectNearbySite(args[3],\r\n\t TilePoint(args[0], args[1], args[2]),\r\n\t args[4],\r\n\t args[5],\r\n\t args[6]);\r\n\r\n\tif (tp == Nowhere) return 0;\r\n\tscriptCallFrame &scf = thisThread->threadArgs;\r\n\r\n\tscf.coords = tp;\r\n\treturn true;\r\n}<\/code><\/pre>\r\n\r\n\r\n\r\nParticularly, we crashed because the first argument, args[3]<\/code>, didn’t represent a valid WorldID<\/code>.<\/p>\r\n\r\n\r\n\r\nCutting to the chase, the problem was that their scripts access memory according to a 32-bit layout. In my 64-bit machine, the structs are different. In particular, pointer sizes are different. This difference caused the script to grab the wrong address.<\/p>\r\n\r\n\r\n\r\n
After noticing that (and feeling very smart about it), we fixed it by implementing a packed struct object containing all data in the expected address.<\/p>\r\n\r\n\r\n\r\n
Motion At Last<\/h2>\r\n\r\n\r\n\r\n
And with that, we were able to walk around.<\/p>\r\n\r\n\r\n\r\n![\"\"](\"https:\/\/blogs.scummvm.org\/ayyg\/wp-content\/uploads\/sites\/7\/2021\/06\/7.png\")
<\/a><\/figure>\r\n\r\n\r\n\r\nYou may see the tiles not loaded in the left side. The reason for that is because we are drawing at the wrong offset. After correcting for that and removing rmem<\/code> from speech.cpp<\/code>, we are able to see something resembling gameplay.<\/p>\r\n\r\n\r\n\r\n![\"\"](\"https:\/\/blogs.scummvm.org\/ayyg\/wp-content\/uploads\/sites\/7\/2021\/06\/8.png\")
<\/a><\/figure>\r\n\r\n\r\n\r\nWe also had our fair share of weird bugs.<\/p>\r\n\r\n\r\n\r\n\r\n![\"\"](\"https:\/\/blogs.scummvm.org\/ayyg\/wp-content\/uploads\/sites\/7\/2021\/06\/9.png\")
<\/a>This is… requiem.<\/figcaption><\/figure>\r\n<\/figure>\r\n\r\n\r\n\r\nThe above was the result of, again<\/em>, improper platform fetching. More specifically, I had removed some lines of code and forgotten about them. Oops<\/em>.<\/p>\r\n\r\n\r\n\r\nWe (aka sev) fixed the buckets on the inventory by extracting the method codes from the disassembly. After removing some more rmem<\/code> calls, we were able to learn skills, open our sack, open the map and much more.<\/p>\r\n\r\n\r\n\r\n\r\n![\"\"](\"https:\/\/blogs.scummvm.org\/ayyg\/wp-content\/uploads\/sites\/7\/2021\/06\/10.png\")
<\/a>Was this a game all along?<\/figcaption><\/figure>\r\n<\/figure>\r\n\r\n\r\n\r\nOne problem though, is that actors were either not spawning or not moving. The later was fixed by setting proper flags in assignment creation.2<\/sup> The former was fixed by fixing a typo. Cheers.<\/p>\r\n\r\n\r\n\r\nif (sect) {\r\n\tif (sect->isActivated())\r\n\t\tsect->activate(); \/\/ should be simply activate()\r\n}<\/code><\/pre>\r\n\r\n\r\n\r\nTasks3<\/sup> not being cleared was also another problem. That one was fixed by comparing the code with the original and putting delete<\/code> expressions where they were missing. Code refactoring is dangerous sometimes<\/em>.<\/p>\r\n\r\n\r\n\r\nPresent Day, Present Time<\/h2>\r\n\r\n\r\n\r\n