Category: Software Development

Categories
Games Software Development

A Return to Strange Adventures in Infinite Space

Strange Adventures in Infinite Space is a game I remember fondly from the early 2000s – a simple and small game that could be played in the space of 20 minutes and was a lot of fun.

Screenshot of Strange Adventures in Infinite Space GPL, from the Linux port.

In 2005, the authors released the source code under the GPL, and I threw out a quick port of the demo only for Linux and promptly got distracted by other things. This port grew up into a more fully featured port by another individual.

A few months ago, I picked up a clean copy of the source and decided to tackle porting it properly. I also got in touch with the original authors and secured permission to redistribute the game data (since they had started releasing it for free) and was given their blessing to do so under the CC-BY-NC license.

The result is Strange Adventures in Infinite Space GPL, which now has it’s first set of public binaries available which include both a build of the game for modern 64-bit systems and the game data in a single, easy to deploy, bundle.

It’s been a interesting run – I’ve dug a lot deeper into the Infinite Space source code than I did last time and I know more about multi-platform porting, and especially about C++, than I did 15 years ago having been the steward of XSquawkBox for the past 5 years.

About the New Port

The new port started from pristine sources, so nothing from my original effort was kept.

The big goals were:

  • To eliminate local directory writing where possible.
    • When SAIS came out originally, it was perfectly acceptable for a game or application to write into its installation directory for save state or computed data – since Windows finally tightened up their default security, as has macOS, this is not a good solution anymore and needed to be addressed.
    • This is the likely the main source of the “You need to run it as Administrator” myth that exists around many game titles on Windows – running the game as Administrator avoids the permissions issues, but really, the game shouldn’t be writing into it’s installation directory anymore.
  • To modernise the codebase so it could run as a 64-bit native executable on 64-bit systems without issue.
    • This was needed as macOS has eliminated 32-bit binary support from it’s most recent release (10.15), meaning 32-bit builds can’t be produced anymore, let alone run. Also, with the rise of arm and aarch64, native 64-bit support would be useful to be able to support aarch64 in the future.
  • To try to untangle the codebase along the way.
    • In the original Read Me file, the original developer (Iikka Keranen) comments “The code is hideous. Sorry. This was my second Win32 app.” He wasn’t kidding – some bits have taken quite a bit of effort to work out what they’re actually doing so I could plot a path forward with modernisation.

Right now, the 1.6.0 release ports deal with points 1 & 2. They build on modern systems and have some adjustments to make life more pleasant on said modern systems.

The binaries are all native 64-bit and should run on the lastest releases of their respective operating systems without significant issues.

Untangling the codebase is harder and is still underway when I get a bit of time and inspiration to come back to it.

Will there be a Web Version?

Whilst it is a bit of a cool party trick to build things using emscripten so they can run in a browser, it’s actually quite a large amount of work to do that to SAIS right now.

It’s not off the cards, but it needs a significant internal rework to address one big issue: SAIS’s code base has multiple main loops, one for each scene.

This is a big no-no in the emscripten interface as the main loop has to be yielded so the browser can continue to run and process events, and ideally you need one super main loop which calls event handlers in the scene code. Refactoring the game’s scene tree and navigation to support this flow is not a trivial piece of work, and there’s other bits and pieces I want to sort out before then.

If emscripten had resolved the fundamental requirement by having a yield function instead of a main callback, this would have been a lot easier to do.

(Ed: I’ve just noticed ASYNCIFY on the emscripten page which seems like it’s new vs when I first assessed the work required – this provides a yield-like function, so maybe it’ll happen sooner after all)

Future Work?

I’m a lot busier right now than when I started this – I mostly did this is a bit of a space filler between tasks and to get a quick personal victory in the game porting space to help deal with my tendency towards suffering from imposter syndrome as I try to change my professional focus. I doubt I’ll be able to seriously return to this for a few months, so the big stretch goals won’t be happening anytime just yet, but I should be able to find the time for general maintenance stuff.

Categories
Software Development

Detecting Transaction Failures in Rails (with PostgreSQL)

So, Rails4 added support for setting the transaction isolation level on transactions. Something Rails has needed sorely for a long time.

Unfortunately nowhere is it documented how to correctly detect if a Transaction has failed during your Transaction block (vs any other kind of error, such as constraints failures).

The right way seems to be:

[ruby]
RetryLimit = 5 # set appropriately…

txn_retry_count = 0
begin
Model.transaction(isolation: :serializable) do
# do txn stuff here.
end
rescue ActiveRecord::StatementInvalid => err
if err.original_exception.is_a?(PG::TransactionRollback)
txn_retry_count += 1
if txn_retry_count < RetryLimit
retry
else
raise
end
else
raise
end
end
[/ruby]

The transaction concurrency errors are all part of a specific family, which the current stable pg gem correctly reproduces in it’s exception heirachy. However, ActiveRecord captures the exception and raises it as a statement error, forcing you to unwrap it one layer in your code.

Categories
Software Development

On Python and Pickles

Currently foremost in my mind has been my annoyances with Python.

My current gripes have been with pickle.

Rather than taking a conventional approach and devising a fixed protocol/markup for describing the objects and their state, they invented a small stack based machine which the serialisation library writes bytecode to drive in order to restore the object state.

If this sounds like overengineering, that’s because it is. It’s also overengineering that’s introduced potential security problems which are difficult to protect against.

Worse than this, rather than throwing out this mess and starting again when it was obvious that it wasn’t meeting their requirements, they just continued to extend it, introducing more opcodes.

Nevermind that when faced up against simpler serialisation approaches, such as state marshalling via JSON, it’s inevitably slower, and significantly more dangerous.

And then people like the celery project guys go off and make pickle the default marshalling format for their tools rather than defaulting to JSON (which they also support).

Last week, I got asked to assist with interpreting pickle data so we could peek into job data that had been queued with Celery. From Ruby.  The result was about 4 hours of swearing and a bit of Ruby coding to produce unpickle. I’ve since tidied it up a bit, written some more documentation, and published it (with permission from my manager of course).

For anybody else who ever has to face off against this ordeal, there’s enough documentation inside the python source tree (see Lib/pickletools.py and Lib/pickle.py) that you can build the pickle stack machine without having to read too much of the original source.  It also helps if you are familiar with Postscript as the pickle machine’s dictionary, tuple and list constructors work very similarly to Postscript’s array and dictionary constructs (right down to the use of a stack mark during construction).

Categories
Software Development

Adventures in 64bit cleanup

I’ve been doing a bit of clean-up in linux/FOSS code for 64bit systems and it’s starting to scare me just how much crap filters into Linux distributions every now and then without anybody noticing it.

nss-mdns was today’s violator – the Multicast DNS NSSwitch module (Multicast DNS is sometimes better known as Bonjour or Avahi).

What’s particularly disturbing is that reading through the code reveals that the author suffered from the fatal “all the world is 32-bit” mindset when he wrote it.  I’m surprised nobody else picked up the unaligned access warnings flying up their console, then again, very few people use Itaniums or other 64-bit systems with strict alignment as a desktop system these days.

A small amount of hackery and fidgeting later, the error has gone away (yay!), and the bugfix was submitted.

The other fun fix was surpressing the unaligned access fix-up handler in parrot configuration tests so it could actually work out the correct pointer alignment size.  This little piece of magic is done by using prctl(). The fix was submitted here.

Categories
Software Development

ia64: Plan9, Compilers and ABIs

So, I have my second-hand HP vx2000 (Single-CPU Itanium2 workstation) running in my room.  (OK, this itself is a mistake – it’ll be moved into the home office once I get sick of the added head in my room).

For some bizare reason, I seem to have come up with the idea that trying to port Plan9 to it would be a good idea.

I’ve started studying the architecture and standard ABI documentation and I’m still trying to get my head around little details, but the whole thing seems pretty doable if I beat kencc into shape first.

The standard ABI register usage suggests a mixture of caller-save/callee-save conventions (some of the global registers are available as caller-save scratch) – this should only require minimal changes to kencc as it’s a case of teaching kencc to work out how many extra registers it thinks it needs for any given proc for optimal results, and allocating them dynamically via the appropriate mechanism, and then ignoring their save/restore on call/return.  That itself shouldn’t hurt kencc much (unlike on sparc32, etc, where you need to work almost exclusively in the callee-save model to get best results if you want to use register windows, and that’s fairly contrary to how kencc thinks and allocates registers), but will make context switching and debugging a bit more complicated.

Alternatively, we could just ignore register spill-fill and try to cram ourselves into the scratch registers only.  This would probably sit well with most plan9 developers.

Last (and equally insane option) is to meet minimum requirements for spill/fill (so EFI calls that allocate registers won’t kill us), but allocate all the registers and treat them as caller-save globals

This will make context saves even more expensive (saving 128 64-bit registers WILL suck), but is simple.

Anyway, this isn’t the really hard bit – as far as I can tell, the hard bit is fixing the 9 assembler/loader to produce good ia64 machine code and pick sensible optimisations.