Imogen disassembly

[TobyLobster]

Imogen is a puzzle platforming game from 1986 with 16 levels, charming graphics and animations in a cartoon style, and a darkly twisted sense of humour. You may have seen it feature recently in Colin Hoad's top 85 games for the BBC Micro series.

SteveF and I have been collaborating to disassemble Imogen. It was a much much larger game than I realised at the start, but it's now complete! Thanks to SteveF for starting it all off, and for helping disassemble along the way with me.

Imogen is around 58K of code and 26K of compressed sprite data. That's pretty big for a machine with 32K of RAM.

I've written some notes at the start of the main file 'g' (see https://github.com/ZornsLemma/Imogen/bl ... urce/g.asm) about how it works, and this includes fully documenting all the cheat codes.

From a programming perspective it has a very feature rich sprite plotting routine, interesting sprite compression, and an object management system that allows multiple masked sprites to overlap each other and still update only the sprites that need to erase and redraw in the correct order to leave no corruption.

Since it was made using py8dis, this is a reassembly too, meaning it can be assembled into files that match the original binaries byte for byte.

https://github.com/ZornsLemma/Imogen

Merry Christmas and a Happy New Year to all,

Toby

[spanners]

Brilliant!

D.

[fizgog]

Excellent work, one of the last few games I bought for the Beeb, before moving onto the Archimedes

[Diminished]

Very nice. I would not have expected that the level data was in fact mostly code.

The sprite routine sounds particularly hardcore. Citadel's sprite routines are quite fully-featured, but even those don't have the mentioned background-storage capability (instead tending to rely on exclusive-OR plotting).

[TobyLobster]

Very nice. I would not have expected that the level data was in fact mostly code.

Yes - not as 'data driven' as I would expect. Each level has separate code to draw each room for instance, and code handles which room exits to which other room.

The sprite routine sounds particularly hardcore. Citadel's sprite routines are quite fully-featured, but even those don't have the mentioned background-storage capability (instead tending to rely on exclusive-OR plotting).

I'll have to take a look at Citadel's sprite code.

[lurkio]

This is brilliant work! Well done, TobyLobster and SteveF!

So, would it be correct to say (in simple terms, for a simple fella like me), that even with this brilliant disassembly to hand, it would be "non-trivial" for anyone to produce a "new level" for Imogen..?

[TobyLobster]

This is brilliant work! Well done, TobyLobster and SteveF!

So, would it be correct to say (in simple terms, for a simple fella like me), that even with this brilliant disassembly to hand, it would be "non-trivial" for anyone to produce a "new level" for Imogen..?

Thanks Lurkio!

It would take a good working knowledge of 6502 assembly, and study of the existing levels code to understand what's going on and to mimic the basic template. Replacing an existing level would be a little easier than adding another one on the end since the levels currently only go from A-P, with Q as an epilogue, and this is an assumption in a number of places in the code. But this too could be overcome of course. The sprites are defined in a text file (JSON format) and are compressed and appended to the level file as part of the build process so that part at least is handled automatically, but recreating the the graphics and animation style is a separate kind of challenge.

If anyone fancies a go - please do! SteveF and I have only generically floated the idea of more levels being a 'good idea', but have not started anything.

[Diminished]

I'll have to take a look at Citadel's sprite code.

I found it telling that in the various different versions of the game engine that we found on Michael Jakobsen's development floppies, Citadel's sprite module was completely unchanged from the first extant build to the last. There was a definite inference there that he worked on the sprite code first, and laboured away at it until he was 100% satisfied it was right -- it was never modified again.

[Iapetus]

Wow that was a lot of work! Congrats

It will be very interesting to study the sprite engine for example.

[Cybershark]

The sprite routine sounds particularly hardcore. Citadel's sprite routines are quite fully-featured, but even those don't have the mentioned background-storage capability (instead tending to rely on exclusive-OR plotting).

An even more impressive routine can be found in the arcade/adventure section of Pantheon - by Jakobsen's countrymen, Lars Østerballe and Benny Lonstrup. The player exists in the midground and passes both in front of and behind scenic decoration

[MarkMoxon]

Very nice. I would not have expected that the level data was in fact mostly code.

Yes - not as 'data driven' as I would expect. Each level has separate code to draw each room for instance, and code handles which room exits to which other room.

This is fascinating - thanks to both of you for the analysis. It’s a bit like the extra track files in Revs, which contain more code than data, but this takes it to a whole new level. Literally!

Awesome work.

Mark

[bob147]

That is a very rich set of cheat codes, unusual for a bbc micro game.

[TobyLobster]

That is a very rich set of cheat codes, unusual for a bbc micro game.

Yes, there is an unusual amount of cheats. Much of the code to handle them are in code that's only loaded when the user enters a password, and then immediately discarded afterwards, so it can be more extensive than most BBC games that don't access the disk after the initial load of the game. This 'overlay' code overwrites some static sprite data that is reloaded after the password code is done.

[colinhoad]

This is wonderful, thank you so much for doing this!