Well, after months of work, the secret Tony Tough project has finally hit the trunk. It's nice to see yet another game engine that I worked so hard on make it into the trunk. The only downside is that now that it's been announced, I feel obligated to finally make a blog posting. Whilst the project was on, I could procrastinate on making any postings, since most of my time went into working on it, and it was a secret. Now that's it's public, I've lost my good excuse to be lazy. Even so, I've still managed to procrastinate on making this blog posting for a few weeks. :) . Looking back, it looks like it's been nearly a year since my last post. Definitely past time.
So, I've finally got myself together to talk about what I've been up to, and what's happening in the near future.
Tony Tough:
My work on the Tony Tough engine has more or less finished now that we've got the game in a pretty solid state. In addition to other members who've made/making commits to polish up the last rough edges, kudos. Tony Tough actually took longer to convert than might otherwise have been the case because the game was originally multi-threaded. Each in-game action was done on a separate thread, which could be interrupted as necessary. So, for example, if you started an action to talk to a parrot, that action could be temporarily blocked if the parrot was currently already speaking, and then resume once it was finished. This caused issues for support in ScummVM, given the large numbers of systems we have to support.
As such, I utilised the existing coroutine framework that we set up for the Tinsel engine. Our coroutine framework is like a poor man's threading system. Using it, I was able to gradually convert the engine source to a single thread application. This did mean, though, that each and every method used within threads had to be converted to our coroutine macros. This took quite a bit of work to get done, in addition to expanding the function of our coroutine manager to also simulate the semaphores and other synchronisation mechanisms the game used. But now, particularly thanks to some recent polishing up by Fuzzie, we've got the running reliably running in a single thread.
Geekwad 2:
I've been spending some time working on another of the TsAGE game titles, Geekwd 2: Games of the Galaxy. Whilst it's more a set of mini-games that an adventure, it utilises the common TsAGE core. I've currently been focusing on the first minigame, Spaced Solicitors (aka Space Invaders) to get the feel of how the minigames have been set up, and am currently at the stage that the minigame is playable. It still needs some tweaks to control the speed, and for when the player either wins or loses the game. Once I've finished with that minigame, I anticipate the remaining minigames will be somewhat easier to implement, being abler to use that first minigame as a guide for how their minigame scenes work.
Return to Ringworld:
I admittantly hadn't done much work on the R2R sub-engine, since the bulk of my time previously was working on the Tony tough engine. I had spent a bit of time occassionally working on the dissassembly though. Our work on the game is likely to be a longer term project.. several of the remaining areas of the game are fairly complicated mazes and simulators, so the code associated with them will have to be painfully and gradually disassembled and re-implemented. Likely, most of my efforts on it in the near future will be invisible work on decoding the scenes in IDA, rather than making regular code commits.
Hopkins FBI:
Hopkins FBI is the new game I'm also currently experimenting with. Strangerke identified that the publically available Linux demo was actually compiled with some debug information embedded, which gave both method names and the names of global variables. Both the gdb debugger and IDA were able to read it directly, so IDA was able to produce an annotated disassembly. From this, the Hex-rays tool was able to provide a C disassembly of the entire demo. It's not as a good as having original source, since we're missing method parameter names, structures, and any formatting and comments the original had, but it's a great base to work from. The full game executable, whilist not having any debug information, is similiar in size, so we're hopeful that if we can properly support the demo, the full game would only require minor changes.
I've been slowly going through the program flow, converting over methods as I go. The disassembly isn't perfect, and sometimes gets things wrong. This is particularly the case for structures, since it doesn't realise that they're present.. I have to replace all the raw memory accesses to proper array indexes and structure offsets, gradually building up my understanding of the structures as I go. Overall, though, the decompiled code has proven a great aid in understanding the overall game, and particuarly dealing with all the smaller methods.
In the first week alone, I already had the first title screen showing! This is a pretty big deal, considering that I hadn't even looked at the game's internals until Strangerke brought it to my attention. Just showing the screen required conversion and fixing up a lot of the game's graphics framework to use the ScummVM framework, since that also included all of the game's initial setup code.. not just a quick hack to showing a particular screen. Following that, I started working on the animation manager, and again after about a week's worth of work, I had the basic animations of the introduction sequence playing, although it will still need a bit of work to exactly match the speed of the original, and have a proper display of frames within ScummVM. Following that, I put asside fine tuning the animation in favour of working on the main menu, so I'd have something interactive to show for my efforts, and now have the basic menu up and running.
Pretty great progress overall for just a few weeks worth of effort in my spare time. What's next? As fun as it is getting rapid results in what I've done so far, I think I'll spend some time powering through the initial conversion of the bulk of the remaining game methods, except for sound, which I still hate. :), and worry about testing the code afterwards. That way I can be more confident that any bugs aren't just that necessary code somewhere hasn't been implemented yet.
DreamMaster.
So, I've finally got myself together to talk about what I've been up to, and what's happening in the near future.
Tony Tough:
My work on the Tony Tough engine has more or less finished now that we've got the game in a pretty solid state. In addition to other members who've made/making commits to polish up the last rough edges, kudos. Tony Tough actually took longer to convert than might otherwise have been the case because the game was originally multi-threaded. Each in-game action was done on a separate thread, which could be interrupted as necessary. So, for example, if you started an action to talk to a parrot, that action could be temporarily blocked if the parrot was currently already speaking, and then resume once it was finished. This caused issues for support in ScummVM, given the large numbers of systems we have to support.
As such, I utilised the existing coroutine framework that we set up for the Tinsel engine. Our coroutine framework is like a poor man's threading system. Using it, I was able to gradually convert the engine source to a single thread application. This did mean, though, that each and every method used within threads had to be converted to our coroutine macros. This took quite a bit of work to get done, in addition to expanding the function of our coroutine manager to also simulate the semaphores and other synchronisation mechanisms the game used. But now, particularly thanks to some recent polishing up by Fuzzie, we've got the running reliably running in a single thread.
Geekwad 2:
I've been spending some time working on another of the TsAGE game titles, Geekwd 2: Games of the Galaxy. Whilst it's more a set of mini-games that an adventure, it utilises the common TsAGE core. I've currently been focusing on the first minigame, Spaced Solicitors (aka Space Invaders) to get the feel of how the minigames have been set up, and am currently at the stage that the minigame is playable. It still needs some tweaks to control the speed, and for when the player either wins or loses the game. Once I've finished with that minigame, I anticipate the remaining minigames will be somewhat easier to implement, being abler to use that first minigame as a guide for how their minigame scenes work.
Return to Ringworld:
I admittantly hadn't done much work on the R2R sub-engine, since the bulk of my time previously was working on the Tony tough engine. I had spent a bit of time occassionally working on the dissassembly though. Our work on the game is likely to be a longer term project.. several of the remaining areas of the game are fairly complicated mazes and simulators, so the code associated with them will have to be painfully and gradually disassembled and re-implemented. Likely, most of my efforts on it in the near future will be invisible work on decoding the scenes in IDA, rather than making regular code commits.
Hopkins FBI:
Hopkins FBI is the new game I'm also currently experimenting with. Strangerke identified that the publically available Linux demo was actually compiled with some debug information embedded, which gave both method names and the names of global variables. Both the gdb debugger and IDA were able to read it directly, so IDA was able to produce an annotated disassembly. From this, the Hex-rays tool was able to provide a C disassembly of the entire demo. It's not as a good as having original source, since we're missing method parameter names, structures, and any formatting and comments the original had, but it's a great base to work from. The full game executable, whilist not having any debug information, is similiar in size, so we're hopeful that if we can properly support the demo, the full game would only require minor changes.
I've been slowly going through the program flow, converting over methods as I go. The disassembly isn't perfect, and sometimes gets things wrong. This is particularly the case for structures, since it doesn't realise that they're present.. I have to replace all the raw memory accesses to proper array indexes and structure offsets, gradually building up my understanding of the structures as I go. Overall, though, the decompiled code has proven a great aid in understanding the overall game, and particuarly dealing with all the smaller methods.
In the first week alone, I already had the first title screen showing! This is a pretty big deal, considering that I hadn't even looked at the game's internals until Strangerke brought it to my attention. Just showing the screen required conversion and fixing up a lot of the game's graphics framework to use the ScummVM framework, since that also included all of the game's initial setup code.. not just a quick hack to showing a particular screen. Following that, I started working on the animation manager, and again after about a week's worth of work, I had the basic animations of the introduction sequence playing, although it will still need a bit of work to exactly match the speed of the original, and have a proper display of frames within ScummVM. Following that, I put asside fine tuning the animation in favour of working on the main menu, so I'd have something interactive to show for my efforts, and now have the basic menu up and running.
Pretty great progress overall for just a few weeks worth of effort in my spare time. What's next? As fun as it is getting rapid results in what I've done so far, I think I'll spend some time powering through the initial conversion of the bulk of the remaining game methods, except for sound, which I still hate. :), and worry about testing the code afterwards. That way I can be more confident that any bugs aren't just that necessary code somewhere hasn't been implemented yet.
DreamMaster.
