And now the music room puzzle finally falls to my leet reversing skills :). Turns out the whole set of classes used for the puzzle weren't quite as inscrutable as I'd been anticipating. There was actually some pretty cool parts, such as a parser class that takes in a specially formatted string for each instrument and produces a raw data array containing data for synchronising instrument movements with the music of the song. There were a few hairy moments when I was implementing all the code that mixes together the instruments and plays them back.. all previously played sounds were coming straight from wave (.wav) files, so I'd ditched the code the original had for streaming sound data on the fly, in favor of just passing the entire wave files to the playback code. Now, with the music room, I finally had to implement some of that code.

Anyway, the puzzle more or less works. I still need to go over it in detail at some point to make sure all the animations and frame calculations are precisely correct against the original. But I think that can wait.. I'm getting closer and closer to the game being completable, so I want to plough ahead and get there. I'm just in the middle, now, of fixing some issues with the phonograph for recording the sound, then I just need to ensure the Maitre'D arms and getting the mouth work, and then it's on to Titania and the endgame. :)

The last week has been fairly straightforward in terms of fixes. I've now gotten to the bridge, and both fixed and cleaned up the code for the bridge steering wheel, buttons, and horn. Loved the touch of bizarreness to put a horn on the controls of a spaceship. :). There were also some issues with the endgame credits that I've mostly fixed.. they still tend to jerk somewhat, but at least they're more or less displaying correctly.

So now, really, the one remaining puzzle is, of course, the starfield. As I've previously mentioned, the starfield uses over 30 unique classes just for that one puzzle, which include various rendering and matrix classes for calculating the starmap. Currently, the starfield isn't even displaying yet. I'll try my best to implement it all, but particularly given all the floating point calculations being done, which are harder to deal with, I may end up having to just show a message and bypass the puzzle. We'll have to see.. I originally similarly thought the music room puzzle classes were going to keep me frustrated for ages, and they turned out okay in the end.

Fingers crossed :)

Lookng forward to seeing this finished - good stuff.

No more so than me. :). The last two weeks I've been busy implementing some of the easier parts of the various classes, and am now getting stuck into the more difficult areas that use floating point calculations. I think that the class I'm currently working on implements the big globe in the starmap, since it uses a big pre-calculated table of sine values, and a whole mess of floating point calculations.

And this is the one thing that's going to slow me down the most.. the damn way floating point numbers are handled on PCs, and how expressions are optimized. The floating point unit, or FPU, is basically a stack of values that get pushed on, and then operations are done on the top of the stack. For example, it might push on "3.0", then "2.0", and then do an add operation that removes both values and replaces them with a "5.0". That would be all well and good, but it also as an exchange opcode that allows values from the top of this stack to be exchanged with any existing value. And therein lies the problem.

The optimizing compiler used to compile their original source would find common subsets of expressions used in more than one statement, and do the calculation first, then keep it on the stack for as long as it was needed. Some values also get added to the FPU stack ages before they're needed for obscure optimization reasons. What this meant is that values on the FPU stack are frequently a random mixture of values needed for the current statement, as well as for statements being used at some point in the future. In reverse engineering the statements, I have to be very careful to keep track of all the values and their order, because even a single mistake will screw up the expressions for potentially dozens of following statements. :P

There are tools available to help somewhat; I'm lucky that a fellow developer has a copy of the Hexrays Disassembler. Unfortunately, it doesn't do too good a job with the more complicated sets of floating point formulas like what I'm currently working on. So in the end, I have to deal with a slow, laborious process of figuring out all the formulas.

Okay, that's enough unloading of my frustrations for one day. Despite all the annoying float point code, I'm gradually working my way through the classes. Progress is gradually being made.

Finally, after two weeks of intensive effort, I've finally implemented all the floating point heavy methods of the star control puzzle. Being as this was the last puzzle of the game, it means that the engine is now code complete. The engine has code for the entire game. Yay. \o/

Of course, that's not to say that the Star Control code didn't completely crash the first I finally tried running it. I at least fixed a problem that was preventing the game from starting at all, so now I'm at a point of having to debug the initial putting of the photograph into the slot. There's some validation from the original that guards against division by zero that's being tripped. It looks like one of the matrixes isn't properly initialised. So I'll have to start debugging the original against my version, and see if I can figure out where things go wrong. It's slightly made more difficult because the puzzle uses some random numbers for positioning some of the vectors, so figures may end up different every time it's run.

But we'll see how I go. I'm just stoked that I was able to implement all the methods to begin with; way back when I started looking at them, I slightly despaired of every understanding all the floating point gobbledegook, and having to simply skip the puzzle. But now all the methods are done, bugs notwithstanding. Lets hope bug hunting doesn't take too long.. my first complete playthrough of the game in my own engine is within my grasp :)

Yes! Wonderful news and congrats.

Agreed. Can't wait.

I'm finally starting to see some results from my laborious debugging of the implemented star control code. The first milestone was to get the actual rendering of the initial starfield working. There are actually four different versions of the star drawing code, though luckily only one of them is being used for the initial starfield. I'm not sure why this is - I do know that two are for giving the 3D perspective, and two aren't. But I'm not sure yet what the difference between the two 3D ones are. In any case, it meant I could focus on the one method, and compare values in the original executable vs mine to figure out where formulas were implemented incorrectly, and correct them accordingly.

This actually proved a slight problem at first, since the starfield picks a random orientation initially, so all the perspective matrix calculations were different each time the original executable was run. In the end, I hacked the method for generating random floating point numbers to always return a specific value, and the random number method that returns a random 32-bit number to always return 42424242 in hex. I thought it appropriate, given the game. :). Once that was done, it was easier to run the game side by side with ScummVM on another laptop, and gradually work my way through the code, until I had the starfield being rendered correctly.

Then I moved onto mouse movement handling, which handles changing the perspective angle you're viewing within the starmap. Again this proved a little annoying, as the change in angle depends on where the mouse was. I ended up setting a breakpoint in the original executable, determining what the mouse position was, and then manually changing the mouse position values in mine when the similar breakpoint was hit. Then I slowly worked my way through all the calculations until finally mine matched what the original did.

Then with trepidation I removed the breakpoints in mine and tried running it at full speed. And it sort of worked. I could see the stars being drawn as I moved the mouse, but the previously drawn stars weren't being erased. Oopsie. Luckily, a brief investigation revealed that it was calling a "clear" method on the picture surface it was using before it drew the stars each time, and the method in question had an empty implementation - and it seems like the starfield was the first thing to actually use that method. So after a quick implementation and re-running the game, it worked as expected. Now i can pan around the starfield freely. \o/

The upshot is that I'm starting to get traction in my implementation of the puzzle. Next I'll move onto further functionality of the puzzle, such as switching to the photo view, and clicking on stars to get the globe close-up. Hopefully it won't take too long to get this puzzle working completely, and finally be able to finish the game.

PS: Oh, and I added a new action to to the PET remote to let Titania figure out where Earth is on her own. So for those of you, like me, who don't want to bother with this last puzzle, you'll be able to skip it entirely. :)

Huzzah! Keep up the good work!

Thanks for the encouragement. :) Knowing that there'll be people, other than me, able to use it to enjoy the game more easily helps make all the work on it worthwhile.

Still making progress, albeit slowly. Extensive debugging, and I finally got the animation of movement when I click on a star more or less working. It's not at the same exact same rate as the original yet, and it doesn't quite follow the correct path to the selected star, but at least the movement is being animated. Working on figuring it how it all worked actually helped give me traction on understanding a whole bunch of previously anonymously named classes, which I've dubbed "camera movers". At the moment, without the photograph fed in, it's using what I'm calling a "straight line" mover. The other movers are presumably for the more complicated movements when you start locking in reference points.

I also spend a bunch of time debugging the code for setting up data needed for rendering the closeup of stars when you get close to them. I'm pretty sure the setup is correct, and I think the drawing is likely correct. I had hoped to have clicking on a star working to move me to it so I could see for sure, but it seems some incorrect calculations I alluded to in movement only briefly bring me into the vicinity of the star for a single frame, and then barrel me further off into interstellar space. ;P Hopefully I can figure out the remaining movement issues without too much work, and the star closeups work correctly, and then I can movement onto the actual puzzle solving. Honestly, despite gradual progress, this is all frustratingly slow and involved.. I'll be happy when it's finally done.

I'm away for the next two weeks overseas for work. I may not have much, if any, time to work on things. But then again, a slight breather may be just what I need to recharge my enthusiasm and come back to finish getting the game completable. :)

Have fun overseas - beware of bell-bots with an attitude!

It was back home to my birthplace of Australia, so I had more pressing concerns of avoiding the drop-bears :) I've been back now for three weeks, and hard at work trying to fix the remainder of the star control puzzle, and I'm now getting really close to finishing it.

The first major hurdle, ironically enough, was getting the rotation effect that occurs when you first click on a star to travel to it. Just getting all the calculations correct for all the matrix transformations involved was a real beast. Took me nearly two weeks to gradually trace through all the code and fix all the minor calculation errors. It was such a relief to finally get it working. After that, the movement to star destinations turned out to be fairly easy to fix.. previously it was going way beyond the destination. Debugging the original, it turns out that the game divides movement to a star destination into 32 segments, each with their own fractional "movement speed", using a calculated powers table. Turns out, I'd accidentally gotten the base and exponent mixed up when calculating the values, so my star trip was vastly overpowered, which is why it kept overshooting the destinations :)

With that done, I've spent the last week finally working on the actual puzzle part of the starmap. Some bugfixes were needed when first inserting the reference photograph, but nothing major. Most of the work involved getting both the crosshairs to show when stars are selected, as well as the markers for selected stars to show correctly in the starmap. A lot of it was previously unnamed classes, so it was nice to figure out what those classes actually did. I also needed to fix some problems with the marker bulbs in the PET area.

At this point, it's getting so close to completable, it's almost palpable. All that's left is to fix locking onto the stars so all three points can be defined. Not to mention the custom movement classes that kick in when you have some points defined. Whilst I hope that none of them will give me any challenge, I'm realistic enough to expect that it may take me a couple of evenings at least until they're all done. Then the game will be completable. \o/

What's next after that?

Well, the game can still do with some testing and polishing. My first step will be to play my way all through the game again, to make sure nothing new has been broken. After that, I'll do some further experimentation with the conversation parser. Most of my testing effort with it so far has been focused on the minimum topics needed to complete the game. So it can with some further general testing to make sure nothing is broken. Finally, there a few rare places in the game that use Indeo 4 encoded videos with transparency; notably, the SGT stateroom. I haven't yet figured out how to properly decode the transparency information - I'm currently just doing a best guess based on which parts of a frame have pixels, so the objects in the bedroom have jagged bits of black around the edges. It would be nice to fix that.

So, overall, I'm in the home stretch. Expect a call for testers sometime in the near future :)

Okay. It took me a bit longer than expected. Turns out there was custom calculation code for rotating the starview when the user move the mouse for when 0, 1, or 2 markers have been fixed. Likewise, there was a lot of code for the automatic movement done to move the crosshairs point to center on the marked stars when they're locked on. But after multiple nights of frenzied, albeit laborous debugging, of my ScummVM implementation vs the original executable, I was finally able to lock in all three stars. Starship Titanic is finally completable \o/

The plan is still more or less the same as outlined in my previous post. I'll look into fixing minor problems I've previously identified but hadn't gotten around to fixing, doing a full playthrough again, and fiddling around with the conversations. Having clean source for the NPCs may give me indications of different things I can say to them to get special responses :).

Thanks. Not long now I'm in the middle of fixing various minor bugs; all the better to catch any remaining problems when I do a full play-through again. For example, I only just fixed a problem where for a single frame the fires on the canal would show a black box, and some jerkiness in the end credits. Now I'm just looking into why the Bellbot won't bugger off if I say goodbye to it :).