Google Summer of Code with ScummVM

 Hello! GSoC has officially ended, and I'm in the final stage - submitting my work for the entire summer to Google! When I first received the acceptance letter in May, I was very much baffled. It was exciting and a bit scary at the same time, because I have never ever worked on a project of this scale. Well, first time for everything I guess :) So, what have I been doing this past week? Last week I left off saying my U32 PR was showing some activity, and this week, @criezy helped out a lot by reviewing my U32 PR, and providing much feedback. He also helped out pretty much entirely towards the MacOS/iOS platforms, because it was quite not an area (Objective-C) I was comfortable in. It was really a huge help. Apart from that, I mostly spent the entire week looking at the PR to see what could be changed, fixing my mistakes, and making the PR ready for merge. It has improved quite a lot!  Criezy pushed an update for iOS, which led me to believe that there might be many more missing are

 Hello! Because I think I am mostly done with the new feature implementation, this week was mostly cleaning up the tree, and getting it ready for a PR! Last week, I mentioned some special engines which were ported a little differently, so let's start with those. The MetaEngines in ScummVM uses game detection to detect these games and then uses MetaEngineConnect to instantiate an engine and run it. However, if we fail at the very first step, i.e detecting a game - what happens then? For this, ScummVM uses "fallbackDetection" to approximately find the closest match to the game engine that could be used. The AGI engine was one of my first test engines because it had an additional dependency on fallback detection, which I wanted to test from the get-go. Turns out that the resources for fallbackDetection were only used by the detection features in this case, so the object file was shifted to the DETECT_OBJS variable which would eventually be linked with the executable. However

Hello! Some very nice progress this week I can't wait to tell you about. Let's just jump right into it! So, last week I shared that even though I had something cooked up that was somewhat correct, it wouldn't really be suitable as a proper solution. I also discussed briefly on what was the approach I was taking on next. Because the new work would require cleaning up a lot, I just set up a new branch and cherry-picked some of the commits that would be relevant. The plan did work out, and after laying out the brief structure I explained last week, some engines started to show life again. For some engines, the story was a little different though.. but we'll get to that next week because these might not be final, and I used my best judgment for them. Once the few engines were working well, I got started with porting all the engines over, and this week - I managed to convert them all to the new infrastructure! 79 engines in total, including the ones that are unstable! A very

Hello! What a busy week it has been, and I have some good things to share. In just over a little 3 days of time, I worked for a lot of time to implement the new idea I mentioned I had last week, and it was actually working quite well! I managed to implement the entire basic structure of it, as well as port over 8 of ScummVM's 79 engines to adapt to it! So, what's the deal with this, and what did I do? The "idea" was just me getting a basic understanding of how things "could" work in a way. Well, we were at the "createInstance" bridge where I left off last week. This is a member function of either a MetaEngine or an AdvanedMetaEngine class. The problem with this was this had engine code in it, so it couldn't be included in the executable. The basic idea around this was simply to remove it as a class - member function, and instead mark it as an export symbol. What we could then do, is in base class, provide a default functionality. These function