Workshop log / FABULA C64 & Amiga
From the workshop.
What changes in FABULA, day by day: in the engine and in the workshop, for the Commodore 64 and for the Amiga. The C64 version is well advanced; the Amiga version is in the middle of development.
-
No more bright tone after a step
After every footstep a small bright tone rang on. A sound borrows a voice from the music and gives it back afterwards. But the step ended after 80 milliseconds, in the middle of its envelope, and the rest kept sounding with the music's release: a good 300 milliseconds long, at the pitch the music had last used on that voice. A recording of the SID registers in the emulator found it. The same recording also disproved the first guess, that the note was being struck again.
Now the sound hands the voice back without a release, and the music's next note sets its own. The tone is gone within a few milliseconds. The obvious fix, simply muting the voice, would have cut off held notes. This applies to every sound, but you heard it mostly on the footsteps.
-
Twelve things in the bag
The character now carries up to twelve things instead of eight, and six are visible per page. You page with arrows at the ends of the dividing line: right for the second page, left to go back. The arrows only appear when there are more than six things. A version with three rows and no dividing line, nine things at once, had already been built and tested in the emulator. It was dropped, because the bag and the verbs should be kept apart by a border.
The room for it came from the tightest part of the program: the names and look texts of carried things now live elsewhere, which frees around 800 bytes there. The save game has a new version as a result. The engine rejects older ones instead of reading them wrongly.
-
Towards the viewer and away
A wish from the forum: characters should be able to walk into the depth of the picture too, because otherwise a long corridor leading into the screen is off limits. Until now front and back were standing images only, and every character turned sideways before its first step. Now a player character walks towards the viewer and away. It needs its standing images from the front and back, plus one or two step frames per view. The walk goes standing image, step 1, standing image, step 2.
The character turns to the front or back as soon as it is only moving vertically and has at least ten pixels left to go. Otherwise the short end of a diagonal path would turn it towards the viewer before every single thing. At the destination it stays that way. Without step frames nothing changes, and supporting characters walked by a script still move sideways. Found along the way: when the player character was switched, the copy of its sprites wrote past its space. Whatever lay there, a side standing image for instance, was overwritten. That is fixed too.
-
Front and back in the character window
Below the frame buttons there is now a second row: frames 8 and 9 are steps from the front, 10 and 11 from the back. Step 1 from the front and from the back is enough, and step 2 makes the walk smoother. The preview runs from the chosen view, the onion skin puts the matching standing image underneath, and a red line tells you when painted steps do not count. Next to it is a new Mirror button that flips the chosen frame left to right, because step 2 from the front is usually step 1 mirrored.
A supporting character that only stands now gets its front and back views as well. The two buttons used to be greyed out for it, although the engine and the check both know those views. The room view now shows such a character that way too, instead of from the side. And the workshop's windows open where they were last, at the size you dragged them to, even after a restart.
-
The mouth where it belongs
Characters facing left moved the back of their head when they spoke. Facing left, the engine shows mirrored sprites, but it put the mouth where it sits in the right-facing image. In the mirror image that spot is in the hair. This affected player and supporting characters alike, in every game, ever since the talking mouth was added. Now the build mirrors the mouth position as well.
Seen from the front, a character used to speak at the spot taken from its profile, next to the middle of the face. Now the build reads the mouth from the front view. If a short mouth line is painted there, the mouth opens one row below it. Before, the search found the tip of the nose instead. The day before, the search for the face had already improved: it now finds skin in the second shared sprite colour too, and with hair in the character's own colour it looks for the face where an eye is. Before, such characters moved two dots in their hairdo when they spoke.
-
You can see who is speaking
Until now every spoken line was white, so you could not tell whether the player character, a supporting character or the narrator was talking. Now the player character speaks in white, every supporting character in its speech colour and the narration in a colour of its own. The speech colour is set in the character window, and its default, “automatic”, gives every character a readable colour. The narration colour is in the settings, light grey by default.
Older project files stay byte for byte what they were. The tightest part of the program even got eleven bytes smaller, because the colouring now happens outside it.
-
No more characters in the credits
At the first credits roll of a game in the making, the names scrolled over a black screen, and in the middle stood the characters from the last room. The credits did switch the sprites off in every frame. But since the sprite multiplexer of 13 September, the raster interrupt switched them straight back on from its last plan. Now it treats the credits like a full-screen picture: no sprite changes, all sprites off. That costs three bytes.
Measured in the emulator on a real credits roll: without the fix, sprites were on in 10 out of 279 samples, and with it in none. Incidentally, the first test never started real credits and saw nothing but zeros by chance. That only came to light on an honest second attempt.
-
Music from fast RAM, without dropouts
During playtesting on the Vampire V4SA, the music in the intro broke off with every picture and then took seconds to come back. The cause was the loading pause. While data is being read, the engine hands the hardware back to the operating system, and in doing so it also switched off Paula's sound channels. They only came back on with the next note. With a recording played in sections of 7.68 seconds, that can take up to eight seconds. Now the sound channels keep running through every pause.
That raised a second question: why keep everything in chip RAM? Until now the whole piece of music sat there, 723 KB for 69 seconds. A recording in sections does not need that. It now lives entirely in fast RAM, and chip RAM holds just two buffers of 80 KB each. Paula plays one while the other is already queued and gets picked up seamlessly on the next pass. The engine then fills the freed buffer with the next section. The music plays centred on two channels, which leaves two free for sound effects. Such a piece is recognised from the module itself, so the workshop needs no switch for it. One last stutter during cutscenes came from the master switch for all DMA channels, which the pause briefly turned off as well. It now stays on.
-
A line stays as long as it takes to read
On the V4SA the texts ran by too fast. Measured in the script, almost every line was followed by a pause of just over a second. The engine would have kept the line up longer, but by then the next one had already arrived. That is not a mistake in one script. It is simply the easiest way to write one, and it would happen again in every game.
So the rule FABULA found on the C64 now applies here too: at most eight seconds for a full line of 76 characters, shorter lines in proportion, and never less than 1.8 seconds. The build lengthens a pause that is too short after a line on its own, and the engine keeps the text on screen just as long. Because the workshop goes through the same build, this holds for every game without anyone touching a number. A click still cuts any pause short.
-
The dashed line across the middle of the room
Sometimes a dashed line ran across the room at the height of its middle, and in a full room it was there in every frame. That is where the raster interrupt switches to the second character set, and in some frames it came too late. At exactly that moment the VIC fetches the data of the sprites crossing that line and halts the CPU to do so. The more characters stand at that height, the longer it takes. No fixed timing helps, as measured with six values: a timing that writes too early in an empty room still comes too late in a full one.
So the fix is not a timing but the content. Under every character in character row 7, the build places one in the second set with the same bottom pixel row. The line where the switch happens then looks the same with both sets, and the exact moment no longer matters. Measured in the emulator and on the Ultimate 64: in the full room the line used to appear in all 16 frames, and now it appears in none. It costs anywhere from a handful to a good twenty characters in the lower half of the room. The import already counts them, and if a room overflows the build names the room and the number. Fixed during the same search: in rooms wider than the screen, animations wrote their character too far to the left. The light of a lantern glowed in the middle of a house wall.
-
On time, even with a crowded room
In a room with many characters, the switch to the second character set came a few lines late. The result was a strip in the wrong character set at the middle of the room, and under overload a striped floor and a control bar full of garbage. Measured with breakpoints in the emulator, the middle arrived at line 117 to 124 instead of 113, even in a setup the check had no complaint about. The cause was that a sprite change worked out its registers bit by bit and took four to five raster lines in busy lines. It was allowed to run into the fixed stage anyway.
Now every change is worked out in advance and takes half as long, and none runs into a stage any more. In every measurement the stage came on time. In return, a band that starts just after such a stage gets no sprite whose change would only come after it. The check now also accounts for the time a change takes. It warns when the player character itself loses a band, separately with and without the cursor. This was cross-checked with seven setups: wherever it predicted a missing band, exactly that band was missing, and no other.
-
Three supporting characters side by side
Sprites are now handed out by line, no longer in the order in which characters register. The head and leg bands of a 63-pixel character share one sprite, and characters standing at staggered heights are shown in full, where they used to lose bands. Next to a 63-pixel player character, three supporting characters of the same size now fit side by side. Before, the third had no head and torso. Only when the cursor is at their height does it lose its leg band.
This brought two faults in the raster interrupt to light. If a sprite change fell just before the middle of the room, every further change in that frame was lost. And a change whose line had already been reached was pushed back to the control bar, too late for any character. Both are fixed. The new allocation costs not a single byte in the tightest part of the program. The check works it out exactly and tells you whether bands are missing, or only when the cursor is next to them.
-
Supporting characters live in their room
So far the sprite pool of 47 blocks had to hold every character in a game. With a 63-pixel player character that left three supporting characters of the same size, or two with an action image, and a game in the making needs seven. The fix copies nothing. Each room's block had only empty space between the colours and the second character set, and the VIC can read sprites there directly. That is where a room's supporting characters now live: 35 sprite blocks at 40 columns, 30 at 50 and 24 at 63. In a 40-column room that is enough for five standing 63-pixel characters or eight 42-pixel ones, in any number of rooms. Only the cursor and the player characters stay in the pool.
A character that is drawn but does not appear anywhere yet no longer costs any space. Before, the build stopped and reported that there was no room left. Existing projects look the same, compared frame by frame against the old version in the emulator. More room turned up in a second place as well: the engine's fixed sentences no longer sit with the game data but in free memory behind the credits. They include the reply when something cannot be taken, the speed announcements and the save menu messages. That gives around 500 more bytes for rooms, things and flags, which had been getting tight at two dozen rooms.
-
The standard character walks in profile
In the forum it was pointed out that the character could only be seen from the front, even while walking. That was true, and the engine was not to blame, the drawing was. In the old walk cycle only the head was in profile. The torso, both arms and the crossing legs were still drawn from the front, like someone walking towards the camera. Now the character has a narrow torso, one arm, legs in mid-stride and a shoe pointing forward.
The arm swings forward with the step, half, then full, then half again, and hangs down when standing, as with the character Ron. A first version swung it against the leg and let it go behind the back. That is right for a person, but in a sprite it looked backwards: both legs have the same colour, and nobody can tell which one is nearer. The new character applies to every new project and to the examples, and your own project keeps its character. There is also a new example, Promenade, an empty catwalk with four posts for scale. It is there so you can watch a character walk.
-
The W key can be switched off
In a game with several player characters, W cycles through all of them. A story in which a second character is played only in certain passages, and is somewhere else the rest of the time, had no way to lock that. Now the settings have a switch, The player switches with W. When it is off, only a script changes the character, and the key handling drops out of the cartridge entirely at build time. That saves 40 bytes in the tightest part of the program. If W is off and no script switches the character, the check says so, because the second character could then never be played.
-
The tools catch up
Since 13 September a room has had two character sets of 256 characters each. The image import still counted the whole room against 256, though, and simplified pictures the engine could have shown unchanged. Now it counts and simplifies per half of the room, and the result lists the top and bottom separately. Measured with 26 source images: twelve used to need cells merged, up to 220 of them, and now none do. Title and cutscene pictures still have a single character set.
Found along the way: the import never set characters aside for animations, because it looked up their size under a name an animation does not have. It now counts one character per animation cell. And the character window cut 63-pixel characters off after 42 rows, because the painting area kept the size it had when the window opened. The character itself was always saved in full, and now the painting area grows with it.
-
A side standing image, learned from Ron
The engine can really make a character walk sideways, and it all comes down to the drawing. To show that, Ron moved into FABULA: the character WebFritzi from Forum64 drew for a design of his own. He came over unchanged, with three sprites stacked on top of each other, four walking frames and a standing image of his own. WebFritzi has given permission to keep using Ron as a demo. The engine learned something lasting from him, because a character can now have an eighth image: how it stands, seen from the side. Until now a character at rest showed its first walking frame. That frame had to be both a step and a pose at rest, or the character stood with one foot in the air. With the standing image the walk cycle can have four real steps. It is painted facing right, the build mirrors it for facing left, and supporting characters use it too.
Ron also uncovered a bug. Since 13 September the engine had read the colour after the first band from the wrong place. Ron's legs turned light grey, and in another game one character wore another's trousers. Everything was painted and saved correctly, and only the game showed it wrong. The automatic comparison of built files could not see that.
-
The first room's opening never came
At the start a game enters its first room — and starts its start script right afterwards. But the engine has only one slot for a running script, so one overwrote the other: whoever had an intro silently lost the opening of their first room. There was nothing to see, something was simply missing. Now the room script is noted down and runs when the start script has finished — in whichever room you are standing in by then.
-
Sound for the title screen
The title screen used to just sit there. Now a small script may run while it is up — for a sample, a sound, a piece of music. A click ends it and the game begins. Deliberately nothing but sound: the first room is not loaded at that time, and anything that needs one is stopped by the check before the build starts.
-
Whoever speaks moves their mouth
When a character says something, two dots in their face jump from the skin colour to the outline colour and back — six times a second, for as long as the sentence lasts. It costs no drawn talking frame and no second sprite block: the engine changes a single byte in the head band and puts it back first thing in the next frame. Where the mouth sits is read from the standing image at build time; whoever has no face — a moon, a figure under a hood — gets none.
By itself the player character speaks when they answer, and the supporting character you are talking to; a room script narrates and moves no mouth. For everything else there is a command: Who is speaking. A cutscene then reads like a screenplay — every line preceded by who says it.
-
No more blink when putting something back
Putting something back in a wide room used to cost a whole room change: eight kilobytes out of the cartridge, and the screen was off meanwhile — a blink in the middle of a narrative moment. Now only the cells the thing covers are fetched, a few dozen bytes. Measured in the emulator: before, the screen was off in 17 out of 7,214 samples; now in none out of 7,894.
-
An intro like 1987
Maniac Mansion opens with a meteor falling on a house. The question was whether the engine could do that — so it was rebuilt: the meteor crosses the hill, the flash strikes, the moon rises behind the hill and the house builds up piece by piece while the camera pans along. Three things were needed: a script command Camera that moves the window of a wide room to a spot and leaves it there; supporting characters that can stand behind the background — a moon behind the hill, someone behind the counter; and a walking character that survives a “Show” instead of jumping back to where it started. The example project comes with every package.
-
Four supporting characters, and nobody owns a sprite any more
Sprite 0 belonged to the cursor, 1 to 3 to the player character, the rest to the supporting cast — fixed, whether needed or not. In a cutscene the cursor held its sprite anyway (and stood there for all to see), a character with two bands held on to its third, and three characters side by side were impossible.
Now everyone registers what they need, once per frame, and the engine hands the sprites out — the order of registration is the priority. Whatever goes beyond eight is multiplexed: a sprite whose character is finished at the top gets a second one further down. That helps characters at different heights; side by side on the same line it stays eight, and no trick changes that. The check now works it out and says so.
-
Twice 256 characters per room
A room consisted of 256 different characters — for the background, the things you can pick up and the animations together. Import a photo or build a wide room and you ran into it. Now there are 256 for the upper half of the screen and 256 for the lower; the raster interrupt switches over in the middle of the picture. Older projects look the same pixel for pixel, measured.
-
An impact that really bangs
Besides the eight built-in sounds a game can now play samples: a blow, a scream, thunder, up to a good two seconds. They come into the workshop from a WAV file, and what the C64 makes of them — sixteen steps, 7,882 values per second — the window shows as a curve. You do not preview them on this computer but in the emulator or on real hardware, with the same player the game uses: here you would hear the recording, not the SID.
-
What you see is what is stored
A dropdown in the script editor displayed something that was never saved: for “change room” the Room field visibly showed the first room — but none had been chosen. You only noticed when the build stopped with “script names room '', which does not exist”. A fixed list cannot display anything that is not in it, and handing it the empty value simply did nothing. Now what you see is what is stored, and old commands heal as soon as you click them.
-
The build now says where
Its messages named what was missing, not where — and with an empty name nothing was left to go by. Now the room, the thing and the verb come first: start2/light switch 2 / Push: script names object 'TV', which does not exist in this room.
And it does not even start when the check finds a gap — a script pointing at a name that does not exist. No bytecode can be made of that. The check knew all along; it was just only allowed to say so after a successful build, and after a failed one you never saw it. Ordinary hints still leave the build alone.
-
A demonstration room to look things up in
The new example project shows every ability of the engine in two rooms, and the character explains them as you look at things. If you want to know how a counter, a dialogue or a living cell is built, you look there instead of in the manual. It ships with every package.
-
The dead-end check
Lucasfilm's house rule was “no dead ends, no death” — and it was a rule, kept by hand. Now it is measured: the check reports a thing being used up although somewhere else still needs it. That the second door stays locked may be intended — the check only says there is an order of play after which nothing works any more.
And a second one: a thing meant for the bag that has no layer of its own. It would be invisible in the room. On its first run it promptly found a real case in TIEFENRUF.
-
More than one player character
As in Maniac Mansion: a game may have several player characters, each with their own place and their own bag. The world is shared — switch off the power downstairs and the light goes out upstairs. You switch with W or from a script.
The room for it came out of the cartridge: three full characters would be 48 sprite blocks and the VIC has 47. So all player characters share one slot and their pictures are reloaded on each switch — the same way rooms, pictures and music travel anyway.
-
The character reaches out
Every character now has a seventh image: reaching, bending down, lifting the lamp. A script shows it, and it holds until they walk off. Before, a door opened without anyone stretching out a hand.
-
Counters, and a question about the bag
Flags are on or off — “turn the wheel three times” cost three of them, and a supply running low was not possible at all. Now there are eight counters from 0 to 255, with the six comparisons. They stop at the ends instead of wrapping: an empty supply that kept giving would otherwise stand at 255.
And a script can finally ask whether the character is carrying something. Until now you had to set a flag when picking it up and remember to — which is exactly where flags that are set and never tested come from.
-
Cutscenes can be skipped
RUN/STOP skips a scene. Skipped does not mean cancelled: the script runs all the way through, only without the waiting, and on foot the character moves eight times as fast. Everything the scene sets and takes away still happens — otherwise you would be left in a world where it never took place.
-
Music and sound at the same time
A sound borrows a SID voice for its duration and gives it back — the engine could always do that, you just could not choose which voice. Now you can, per game and per room. The borrowed voice loses its running note: on the melody that tears a hole, on the drums nobody notices.
-
The capitals with umlauts are back on the line
Until now the engine built Ä, Ö and Ü out of A, O and U: the letter one row lower, two dots above. Readable — but they sat lower than every other capital and bumped into the line below. The three are now drawn and sit on the same baseline as everything else, just like the ß, which never could be derived. The price is real: draw your own A and you no longer get a matching Ä for free. For the lower-case ä, ö, ü the derivation stays, and there it is right.
-
The pen erases without a right mouse button
In the character-set editor you could paint pixels but not take them away: the right mouse button was the only eraser, and nothing in the window said so. Now the first dot of a stroke decides what it does — if there is already a pixel there, the whole stroke erases, otherwise it paints. In the character and cursor editors such a toggle does not fit, as there are four values rather than on and off; instead they now say that the value “transparent” is the eraser.
-
The workshop knows which version it is
Version and build now appear in the window title and under “About” — before there was no number to quote in a bug report. While a version is a preview, it says so clearly in four places, so that no test build passes for a finished one. And the menu bar finally reads FABULA instead of “Python”.
-
Aligned text and an inventory in three columns
The sentence line was offset by one character against the verbs below it; now it lines up. The inventory sits in three columns under the verbs, six things are visible at once, and the whole column is clickable instead of just the name. Two old faults came to light on the way that nobody had reported: on a picture change the control bar flashed briefly in the colour of the room, and one row above the bar stayed in that colour. Both are gone — measured on real hardware, not only in the emulator.
-
Verbs on the inventory
When tested on the V4SA, “Look at postcard” only highlighted the postcard, and nothing else happened. A click in the inventory put the item in your hand, whatever the verb. The items' scripts were there, but nothing could reach them. It now works as in Monkey Island 2 and Indiana Jones 4. If an item has a script of its own for the verb, or the verb only needs one object, it runs at once. With “Use” or “Give” the item goes into your hand and waits for the second object. Clicking the same item again puts it away, and the right mouse button on an item means “Look at”.
In the same test a car boot could be opened without anyone being able to see that it was open. The engine lacked two things. A closed state was not painted again when you re-entered the room. And an object coming back into the picture brought its original image with it, including everything that had long since been pocketed. Now, when an object reappears, the layers of the other objects that are gone or changed are repainted over it in their proper order. That holds for any object lying on top of another.
-
The picture decides how tall a figure is
At the edge of town the player character was taller than the town gate. How tall a figure gets at the front and back of a room used to be one setting for every room: 70 pixels at the front, 58 at the back. But a room painted from close up needs tall figures and a wide shot needs small ones. How tall a person appears is a property of the picture.
Now every room has its own depth: a front and a back floor row, each with the figure's height there, and the engine divides the space in between. The workshop shows two measuring figures in the picture for this, because you can only tell whether a person fits through the gate by looking at a person. The blitter does not scale, so the engine picks from the figure's ready-made size steps, and a room painted far away needs smaller steps. Older game files still work. A room without its own depth looks exactly as before: photographed in the emulator before and after the change, not a single pixel differs.
-
The Guru on quitting
The game ran on the V4SA but threw a Guru every time it was quit. The emulator reproduced it: crash, reboot, and the game started again from the beginning. The bug had been in the source since the second milestone. A call that belongs to intuition.library went to graphics.library instead. At the same number there is a function that sets up a memory structure, and on quitting it wrote that structure over the lowest 40 bytes of memory. That is where the pointer to exec.library and the exception vectors live, and after that every reach for them went into the void.
It stayed hidden for so long because the one build used for hunting it, the one with logging, happened to have a valid pointer in that register. It wrote its 40 bytes somewhere nobody needed any more and ran through cleanly. Now the call goes to the right library, every other library call in the engine has been checked, and quitting on the V4SA is clean.
-
Things in the bag
Carried things now have scripts of their own. You can talk to them, use them on their own and combine two of them — if the combination works, both vanish from the inventory and the new thing remains. For that a script may pick up a thing from a completely different room; that is also how a game can put something in the character’s bag right at the start. Checked in the emulator and by playing SENDESCHLUSS from the title to the end.
-
Room to breathe
The engine was nearly full in two places: below the graphics one game had 60 bytes left, in the game data another had 28. Two moves solved it without rewriting a line of game code — the credits text now sits in free memory behind the state of the rooms, the note table with the game data. Afterwards more than 500 bytes are free below the graphics again and up to 1000 in the game data. Checked by playing SENDESCHLUSS from the title to the end.
-
The right mouse button gets a job
Two more wishes from the forum. A right click on a thing carries out a verb at once — “Look at” by default, selectable or switched off in the settings. And the remembered thing can now be seen: if the pointer is on nothing, it stands in the sentence line; if it is on another thing, that one does, as in the later classics.
-
The characters turn to things
Until now the characters only knew the side view. Now they also have a picture from the front and one from behind, and the player character turns to whatever they are dealing with — at the wall clock you see their back, as in Zak McKracken. Other characters can face front or back the same way, and for cutscenes there is a script command that turns the player character towards the viewer. The workshop works out the direction from where the thing sits; where it gets it wrong, you set it on the thing itself.
-
Fewer clicks, fewer verbs
Two wishes from the forum. The last thing you touched stays picked: look at the mug, then click “Take”, and you do not have to click the mug again. And a game may do with fewer than nine verbs — leave a field empty in the settings and the others close up in the bar. The scripts of a verb you leave out are not lost; they apply again once it comes back.
-
No more flashes at start-up
Between the title picture and the intro, things used to flash up briefly that do not belong there: the control bar, the first room, a “Walk to” in the sentence line. If a game starts with a picture or a scene, the screen now stays calm until it is there. Measured frame by frame in the emulator, before and after.
-
Inventory pictures are drawn, not cut out
Until now the build cut the inventory picture out of the room picture, 32 × 24 pixels around the centre of the hotspot. What came out was a piece of background with an object in it, such as a key on a car boot lid rather than simply a key.
Now every object has its own inventory picture, 32 × 24 pixels on a transparent ground. The workshop shows it with a preview on the object, along with a small painter: ten times enlarged, sixteen colours plus a picker for others, pencil and fill, with the right button erasing. It is deliberately not a second big paint editor. The big one paints rooms, the small one paints items, and each is the size of what it paints. The build converts all inventory pictures together to the bar's ten colours. An object without a picture of its own is cut out as before.
-
Two languages in one game file
Everything that shows words in the game fetches them by number from a text store: verbs, object names, lines, conversation options, the end credits and the engine's own texts. A second language is therefore a second store with the same numbers, and switching means moving three pointers. The rest of the engine does not need to know. Up to three further languages fit into one game file. Anything without a translation stays German, and the build counts it. The check measures the translation against the same limits as the original.
In the game, the menu then gets a fifth entry naming the other language: “English” in German, “Deutsch” in English. In the workshop, a window shows every visible text next to its translation and counts how many are still missing. That is how WILLKOMMEN ZURÜCK got 921 of its 931 texts in English. The remaining ten are names.
-
Played through on real hardware
On the evening of 9 September an automated run made it through all of SENDESCHLUSS for the first time. On the way it hit a crash nobody had seen, because nobody had got that far. The main loop takes the back drawing buffer at the start of a frame and paints into it at the end. If a room change to a room of a different width happened in between, new buffers were allocated and the old ones freed, and the rest of the frame painted into memory that was already free again. It only showed at the system's next memory operation, as a Guru or as a machine frozen on a black screen. After the fix, the game ran from the first scene to the last.
On 10 September SENDESCHLUSS was then played through by hand on the Vampire V4SA. The first line of the feedback: no crashes. Along with it came notes that turned into rules. Once the game was over, there was no way out. On the C64 the power switch is the usual exit, on the Amiga it is not. The rule now is that if a picture stands that no click will clear and no script is running, the menu and mouse pointer come back. Also, the sentence line now shows “with …” only after verbs that really take a second object in that particular game. This is read from the scripts, not from a list somebody has to maintain.
-
Pointer, font, figures and music
A comparison with the C64 editor, command by command and menu by menu, showed two things. The engine can do everything the C64 engine can, plus three commands. The workshop, however, lacked four tools, and the engine had its own lines built into the program, so an English game would have had a German menu. That was the most serious point, so it came first. The engine's fourteen texts, from the line when you pocket something to the words of the menu, now belong to the game, and every game can replace them.
Then came the tools. The mouse pointer was not even in a file but inside the program. Now it lives in the game file and has its own painter. The font painter shows a sample line under the grid, because a single character tells you nothing: only next to its neighbours can you see whether it sits too tight. The figure painter does not paint into the finished figure file but into the individual frames it is built from, since otherwise the next build would wipe everything out. For music there is no editor of its own but an import for MOD and XM. Whatever an XM can do beyond a ProTracker module is reported, not made up.
-
The crash after quitting
On the V4SA the machine froze after quitting through the menu, or showed a Software Failure. In the emulator the same path was clean. A log was meant to show how far quitting got, but no file arrived, not even a screenshot taken long before. So the first check was whether the program could write anything at all on this machine. Only once a marker arrived, written before the engine takes over the hardware, did the missing second file tell us something. A measurement that delivers nothing has to check itself first.
The cause was one missing line. The engine runs for minutes with interrupts disabled while Paula keeps playing her sound channels, and their interrupt requests pile up. The moment the operating system got its interrupts back, they all fired at once, straight into the handlers of the audio driver, which knew nothing about those channels. Now the pending requests are cleared first. Three more runs on the V4SA, with no measuring at all and only that one line: no Guru.
-
Importing Koala pictures and characters
The workshop now reads Koala files, the exchange format of many C64 paint programs. Nothing is scaled and no colour is guessed — only where Koala allows more colours in a cell than FABULA does, one has to give way. For rooms there is a crop that cuts out instead of shrinking. And characters no longer have to be painted dot by dot: import a picture, the workshop suggests the colours and shows next to each one how much it actually colours.
-
The conversation editor
There was no way at all to create a conversation line in the workshop. An object's details only counted how many lines it had, so anyone wanting to build a game with conversations had to write them somewhere else. Everything underneath was ready: the build, the engine and the check had known about conversations for a long time. Only the interface was missing, and that was the biggest gap compared with the C64 editor.
Now there is a fourth tab on the right, next to Details, Scripts and Animated. A separate window would be the wrong place, since a conversation belongs to an object just like its hotspot. The lines are at the top, then “only if”, “as long as not”, “can be said only once” and “ends the conversation”, and below them the answer. The answer uses the same script view as the neighbouring tab. A second, smaller answer editor would sooner or later have been able to do less than the big one, and nobody would have known why. On the same day the door became a field, as on the C64, and “Use X with Y” can now be created directly.
-
A test that really plays the game
The puzzle check says that a game can be solved. It does not say whether the sentences along the way fit together. For that there is now a test piece that plays SENDESCHLUSS from the title to the end with real clicks and reads the sentence line before every click — like a person would. It still does not replace a person: whether a sentence feels like a dead end, only someone sitting in front of it notices.
-
One package per system
FABULA can now be built as a finished package: for the Mac a standalone app, for Apple Silicon and for Intel, for Windows a folder that starts without installation. The bundled SENDESCHLUSS becomes the same cartridge on all three systems, byte for byte.
-
What the forum found
A thing you can use on its own now reacts on the very first click on “Use” — before, the game always waited for a second one. If the same thing also has a combination, it keeps waiting, or nobody would ever reach the solution. And the manual has a new chapter, “Can it be done?”: seven typical wishes, each with the shortest script that fulfils it, plus a section on what cannot be done.
-
SENDESCHLUSS moves over
The honest question for an engine and a workshop is not whether a test runs, but whether a finished game runs. So SENDESCHLUSS was brought over from the C64: eight rooms, 58 objects, 385 script commands. All 19 kinds of command it uses exist on both sides, and the check ran without a single message. What was missing made a list of five points, and it was worked through the same evening.
Wide rooms now scroll smoothly, pixel by pixel. To make that possible, room and bar share a single bitmap, one above the other, so nothing has to be switched at the seam. Whether a figure disappears behind a railing is decided by a mask, pixel by pixel, not by a colour rule, because in a dithered picture with 192 colours a colour rule gives you a sieve, not a fence. Figures, music and all eight sound effects were calculated from the C64 data. Whatever the SID changes every frame and Paula cannot do, such as filter and pulse-width modulation, is dropped. The rooms also got an Amiga coat of paint: from the same pictures come around 190 colours instead of seven, with coloured shadows, volume and glow, and nothing invented along the way.
-
The first real machine
Until now the emulator had been the only judge. Since 6 September FABULA has also been running on a Vampire V4 Standalone. It is not the target machine: a 68080 with a gigabyte of memory tells you nothing about loading times on an A1200. But it answers the other question, whether it runs at all.
Loading worked straight away, including unpacking and matching checksums. The engine, though, stopped. The raster counter never went past line 262, so the machine was running in NTSC. The whole display, however, is built for PAL. The same would have happened on any NTSC Amiga, only the emulator was set to PAL and could never show it. Now the engine switches to PAL on start and restores the previous setting on exit. That setting is measured from the raster counter, because the register in question cannot be read. Two waiting loops that would have spun forever on an unexpected machine got an emergency brake. After that the game ran for thirty minutes without a break, played by hand.
-
The workshop takes shape
The workshop is a program for modern computers, written in Python with Qt. The Amiga gets the finished game, not the tool. A second workshop on the Amiga would mean the same logic existing twice, forever, with every new command and every check rule having to go into both. To keep that door open anyway, the project file is a plain block format that another tool could read too. The proof: the saved project file produces a game file identical byte for byte to the one built from the original source.
The room view, script editor and paint editor followed that same day. The room view does not show the PNG but the converted room picture, because hotspots dragged onto a picture that does not exist like that in the game end up in the wrong place. The paint editor works on colour numbers, not RGB, because an editor that converts on saving changes the artist's colours. Finally the workshop was tested on itself by building a game from nothing. That turned up a dead end: a freshly created object had no scripts, and the list only showed existing ones, so a new object got you nowhere. Now every verb is listed there, with the empty ones marked “(still empty)”. By the afternoon animated patches had followed, along with a single undo stack for everything, the manual and key list in the window, and an English interface.
-
The whole engine runs under WHDLoad
TheA500 Mini, MiSTer and the usual collections expect a WHDLoad package. So FABULA got its own slave, written in assembler, because WHDLoad requires a single, fully relocatable block of code. Behind it runs the same engine, built without an operating system and without a C library: files come through WHDLoad, and memory through a small allocator of its own. Room, figure, bar, scripts, inventory and room changes with loading, unpacking and checksums all work. What gets shipped is one drawer with both builds and a single game file.
The next morning showed what was not right yet: under WHDLoad the screen stayed black for twelve seconds on every room change. The first suspect was chip RAM, and fixing that gained eight percent. The real reason was the instruction cache. WHDLoad switches it off on machines without an MMU so that old games that modify their own code keep working, and a 68020 without a cache fetches every single instruction from memory. The slave now switches the instruction cache on, but not the data cache, and asks for fast RAM. Twelve seconds became just under three.
-
One bit, 54 percent less time
On the first day the toolchain was set up inside the project and the first AGA picture appeared: 320 × 256 pixels in eight bitplanes, every line in a colour of its own. Soon after came a real room picture with 256 colours of its own, two drawing buffers and a figure the blitter places masked and pixel-exact. By midnight walk areas, pathfinding, a walk cycle and size by depth had been added, then the control bar below the room and an inventory with pictures as in Monkey Island 2.
Things were measured from the start, on an emulated A1200 without fast RAM. Clearing and redrawing three figures every frame cost 178 of 313 raster lines. With a palette range of their own, which leaves the figures five bitplanes instead of eight, it was 129. Then came a single bit that gives the blitter priority over the CPU on the chip bus. Without it, the loop waiting for the blitter was stealing exactly the cycles it was waiting for. With the bit it took 59 lines, which is 54 percent less time.
-
The manual in English
The whole manual is now available in English as well. It was not translated word for word but against the English interface: every command and every field is called in the manual what it is called on screen.
-
SENDESCHLUSS is out
The game for the engine is available today, free — an EasyFlash cartridge for a real C64, the Ultimate 64 or an emulator. Eight rooms, a good half hour. The engine it was built with follows later.
-
The workshop has become a real application
FABULA now starts like any other Mac application — with its own name in the menu and its own icon, instead of out of a terminal window. For the work itself this changes nothing; for how it feels to use, everything.
-
SENDESCHLUSS has been played through once, completely
The small sample game has grown into a showcase: a radio studio, a cellar, a roof, a phone call that really rings, and an ending only those find who went downstairs first. Playing it through turned up five inconsistencies — all fixed. A game you can play from beginning to end is the best test an engine can get.
-
The mouse no longer trembles
In the emulator the pointer twitched. The first suspicion fell on the emulator — wrong, as it turned out. Measuring now happens at the start of the frame, and the pointer sits still. The mistake and the hasty explanation are both written down in the manual.
-
Many small annoyances in the workshop
An undo deleted a whole script. A button did nothing. While drawing you could not see what you were painting. Without a mouse you could not get past the intro. Things like these only show up in real use — and they are the reason the game gets played through carefully once more before release.
-
No more Java needed
FABULA now translates its C64 code with a self-written tool. Before that it needed Java and someone else's program — nobody who works with FABULA later has to install either. That the swap changed nothing is proven: the finished games are byte for byte the same as before.