Ultimate Filmation Maths.

[uglifruit]

This link might be old news to you all, but this discussion of how the 'filmation' technique, and the mathematics behind it, was used in Ultimate games is rather good. And points out why the KnightLore glitch that appears, appears.

http://bannalia.blogspot.com/2008/02/fi ... math.html

[Joefish]

Interesting discussion on the maths, but that's the theory rather than the actual programming. I very much doubt anyone's computing hexagons - it'll all be rectangles. And the archways are just split in two down the middle - I've seen the sprite data.

What surprises me in that sorting glitch is that the whole table is redrawn in the bugged instance, rather than just the area immediately surrounding the player.

I've heard that Head Over Heels isn't subject to the terrible slowdowns you get in the Ultimate games when multiple objects move because it's very good at just isolating the part of the screen where the moving object is, only layering and redrawing the objects that impinge on that small area into a small back-buffer, then copying that little bit of back-buffer to the screen.

Whereas something like Kirel is a bit crap because it's redrawing the whole level every frame.

Ultimate's 'Filmation' is presumably doing something in-between. As it looks good, but has horrible slowdown at times.

[DouglasReynholm]

Ultimate's 'Filmation' is presumably doing something in-between. As it looks good, but has horrible slowdown at times.

My first memory of frame rate problems, even if I didn't understand the concept at that young age. But I certainly remember noticing it. They really were pushing that machine to its limit.

[what_the_wasabi]

Apologies for resurrecting this thread but it came up when searching for Filmation. I've been looking at how the Knightlore 3D engine works and found a few interesting things that might explain why it slows down so much.

1. It renders internally to a back buffer, arranged as a linear buffer. Same size as the main screen, taking 6K of space
2. Objects are not stored in depth order, it sorts the objects every time it needs to render something
3. When an object moves it finds all the objects that could potentially overlap the sprite, sorts them and draws them all in depth order to the back buffer. It then just blits the area of the sprite bounding box to the actual screen.

I modified Knightlore to blit the whole back buffer to see which objects are rendered as the player moves around. Below is a video with the modified version running (at 28Mhz!)



The sorting and drawing of so many objects seems to be the main cause of slowdown. There has been some attempt at making the object rendering code run fast. It uses a 3.5K look up table for pre-computed shifted values and the stack pointer to read the source data.

[Joefish]

Fantastic bit of work!

So it is optimising to only redraw around anything that moves. And it's interesting how that sometimes leaves further away objects overlapped in the wrong order, but those glitches are outside of the rectangle being copied to update the screen. So not much different to what I was told Head Over Heels does - although that may not be keeping a full-screen buffer going.

Doesn't explain why Knight Lore and Alien8 have so much more slowdown though.

[GRC7800]

Apologies for resurrecting this thread but it came up when searching for Filmation.

Thanks for this! I, too, am fascinated by Filmation. Would you mind sharing some of your sources, please? That is, what exactly are you studying to help you understand the engine? I would love to study it further myself. Thanks in advance!

[what_the_wasabi]

The main difference is Knightlore (and Alien8) draws all objects completely that are overlapping the moving object, into the back buffer.

Where as HoH has a much smaller 256 byte buffer, which is arranged to be 6 bytes x height of object. Everything gets shifted, clipped and drawn into this small buffer. So the calculations are more complicated but the actual drawing is much less.

HoH drawing routines are optimised for a set of fixed sizes, Knightlore as very general routines that can handle different sprite width and heights.

9K is used by Knightlore for back buffer and shifting tables, so less space for unrolling loops etc.. HoH has lots of similar routines optimised for specific use cases.

Also, I think HoH keeps everything in a sorted linked list and re-arranges it when objects move. So it doesn't have to do much sorting as the game plays. Knightlore keeps objects in a table and generates a temporary sorted list every time it has to draw an object.

[what_the_wasabi]

Thanks for this! I, too, am fascinated by Filmation. Would you mind sharing some of your sources, please? That is, what exactly are you studying to help you understand the engine? I would love to study it further myself. Thanks in advance!

I found some source code at https://github.com/mrcook/zx-spectrum-g ... c7.lst.txt I think it originates from the person who ported it to the TI-99. There's loads of comments in the disassembly.

I converted it to assemble with sjasmplus and from there I started hacking away trying to speed it up by optimising some of the simpler drawing routines. Unfortunately there's not much free RAM left which the large back buffer and lookup tables.

I've uploaded my work in progress to https://github.com/jonsole/knightlore/b ... htlore.asm

[GRC7800]

@what_the_wasabi Thanks, so much! This looks like it will be very helpful. I appreciate you sharing your work.

[equinox]

I modified Knightlore to blit the whole back buffer to see which objects are rendered as the player moves around. Below is a video with the modified version running (at 28Mhz!)

I love this — like seeing an X-ray of the Penrose stairs illusion.