Faxanadu

After going through 6 of the 7 main rules from the sprite description table last time it's now time to turn to the last and most complex rule, the main rule with ID $02. What makes this rule more complicated than most others is that it has it's own set of sub-rules. Depending on a value from the sprite description table one of eight sub-rules is chosen once main rule $02 is executed.

Continue reading "Faxanadu collision detection - Part III (Sprite behaviour III)"

I probably won't have a lot of time in the next weeks or even months to continue my Faxanadu disassembly. Therefore I've decided to upload all disassembly files in the hopes that someone else can continue my work.

Click here to get the archive including all files

Files in the archive:
*.html - HTML disassembly of important ROM banks
*.bin - IDA Pro databases
*.nl - Name list files for FCEUXD SP
idc*.idc - Various IDC scripts used while disassembling the Faxanadu ROM file
memmap.txt - Notes about the RAM section of Faxanadu; Use only in combination with the newer initram.idc

Seven of the eight top-level rules from the sprite description table will be discussed in this update, the most complicated one gets an update for itself.
Continue reading "Faxanadu collision detection - Part III (Sprite behaviour II)"

After last time's slow start into the collision detection code things are going to be more interesting this time. The second function call from the main collision detection code contains quite a lot of code (at least indirectly because it calls lots of other functions). So much in fact that a decently sized chunk of ROM bank 15 contains nothing but code and data that's used from that function. Thankfully it's not necessary to explain all, or even most of it because a lot of code is very similar and I can skip over it without explaining it any further. You'll see later why exactly that's the case.

Continue reading "Faxanadu collision detection - Part III (Sprite behaviour I)"

The first function call in the main loop of the collision detection code goes to a function that handles sprites that were hit by the player's magic shortly before the current sprite update. The code of that function is located between the offsets $8151 and $81A6.

The first sprite array that's accessed right in the first line should be familiar. It's already been used in the main loop to determine if the function at $8151 should be called or not. It contains the ID of the magic the sprite was hit by. As only three (Deluge, Thunder, Fire) of the five different kinds of magic throw the enemy back only these three types need to be handled in this function.

Continue reading "Faxanadu collision detection - Part II (Enemies that were hit by magic)"

In the last update there was some talk about an eight byte long array starting at offset $2CC which contains the sprite IDs of the sprites visible on the screen. There's one pre-defined ID for each kind of sprite, not for each individual sprite (two monsters of the same type will share the same ID).
Today's update is very short, in fact it only contains an overview over these sprite IDs. They are the same IDs that are used in the level data to specify the monsters present on each screen. This was not yet discussed on this website but it's explained in Vagla's document.
Continue reading "Faxanadu - Sprite IDs"

After the random Faxanadu factoids of the last updates it's about time to make some more structured updates again: It's time to begin a new series of updates about a certain topic. And it's going to be quite a large series, so large in fact that I can't yet estimate how many parts this new series will contain. Anyway, the topic of this new series of updates is the collision detection code of Faxanadu. What exactly is going to be part of the next updates will become more clear after you've finished reading this update as the topic of this update is the main collision detection function from where all other functions dealing with collision detection are called.
Continue reading "Faxanadu collision detection - Part I (A first overview)"

In one of my first updates about the level data of Faxanadu levels I've explained how to decode the compressed screen data of the screens of a level. What I didn't mention back then was how the game itself actually decompresses that data. That's what this update is all about and I have to admit that the decompression code of the original game is better than the one I wrote. To my defence I want to mention that the original code uses nice tricks with the carry flag which wouldn't have been easy to use in my C++ code.
Continue reading "Faxanadu internals - The screen data decompression algorithm"

Besides the wing boots there's a second equippable item which has an effect limited by time: The hour glass. The hour glass freezes enemy sprites for a given amount of time. Unlike using the wing boots, using the hour glass has a negative effect. It decreases the player's health by 50% making it rather costly when the player still has a lot of health. Nevertheless the code for activating the hour glass is remarkably similar to the code for activating the wing boots. The hour glass code also follows right after the wing boots code.

Continue reading "Faxanadu internals - Hour glass"

When playing Faxanadu the wing boots allow a player to fly. Let's have a closer look at how they work under the hood. Wing boots are an item the player can buy or find and once it's in the player's inventory the player can select the item and use it. For a brief amount of time the player can fly then.

The code responsible for equipping wing boots can be found between the offsets $C579 and $C598.
Continue reading "Faxanadu Internals - Wing Boots"

Now that all necessary parts of parsing Faxanadu level data have been explained it's time to end this mini-series. The final step is to combine the knowledge gathered in the first five parts of the mini-series which in turn allows us to draw the entire Faxanadu world in the level editor.

Let's recall what we have so far. Drawing a screen from the Faxanadu world is a process that is comprised of several different steps: The first step is to read and parse the actual level data from the Faxanadu ROM file (see update one). The second step is to find the four 8x8 pixel tiles belonging to the 16x13 block that form one screen (see update two). Then it's necessary to find out which color the pixels in the individual tiles have (see update five) but because the color is stored independently from the tiles and because of some other oddities of the Faxanadu level data it's necessary to know how doors and scrolling work (see the updates three and four). And that last step, finding the correct color for the tiles and drawing the screens is what this update is all about. Continue reading "Faxanadu level data VI - Putting it all together"

The mini-series about Faxanadu level data is slowly coming to an end. Today's update might be the second-to-last part of the series if I counted correctly. In this update I'm going to explain how to find the correct palette for a given screen. In one of the last updates I had already hinted that choosing the proper palette for a screen is an inductive process, the color palette used in screen N depends on the color palette used in screen N-1 and some other information.

Continue reading "Faxanadu level data V - Palettes"

Here comes another post that's required reading to understand the Faxanadu level structure. Today I'm going to explain how scrolling between screens is implemented in Faxanadu, at least in so far as it's relevant to understand the level structure of the game. Vagla's document already explains one of the three different ways of scrolling in Faxanadu, this update will also contain the other two ways.

Continue reading "Faxanadu level data IV - Scrolling"

This Faxanadu update is non-technical in nature. I just want to clarify something. In the last updates I refered to the different levels of the game by name even though there are no official level names for that game. To make absolutely sure it's clear what I'm talking about this update contains a series of screenshots of the various levels and how I intend to call them from now on.
Continue reading "Faxanadu - Level names"

In my last Faxanadu update I had already hinted at the fact that you need to understand how to leave screens if you want to understand which tiles are used for a certain screen. This is because the level design of Faxanadu is an inductive process. The tiles used in a screen depend on the tiles used in the screen before. The same is even more true for the colors used to paint a screen. Before going on with explaining how a screen is drawn it's therefore necessary to know about the different ways of entering and leaving a screen. This update deals with the doors, the next update will deal with scrolling.

One might assume that there are just two ways to leave a screen, through a door or on one of the four edges of the screen. Nothing is that simple in Faxanadu though. There are (at least) five different ways to leave a screen, three of them are about leaving screens through a door, the other two are for leaving a screen on one of its edges. That's the five ways I've uncovered so far at least and they're sufficient to draw all screens correctly in my level editor.
Continue reading "Faxanadu level data - Part III (Doors)"