AGI Interpreter Update

[Manannan]

I wanted to provide another update on my progress of building an AGI Interpreter from the CommanderX16. If you don't already know this will let Sierra adventure games like King's Quest run.

I mentioned previously that I had built the interpreter portion.

The lastest news is that I am successfully drawing backgrounds, and making textboxes. More optimisation for background graphics drawing will need to be done though, as they don't draw as fast as the Apple II version.


This is demonstrated in this Youtube video:
https://youtu.be/IDdc890T_oY


The next major pieces of work will be:
- Use IRQ to get more accurate timing
- Optimise the background drawing routine
- Create loading screen to hide background image while drawing to avoid any flicker
- Sprites
- Test more games
- Make an SH script to allow building from Linux

My Github repo is: https://github.com/wizardmanannan/CX16Agi

[kelli217]

It certainly looks like the diamond fill is a slow way to go about things.

Assuming you don't want to try a VERA FX fill, I did find an article with some interesting flood fill routines. They aren't in 65C02 assembly, but they do seem to be fairly low-level so maybe it wouldn't be too hard to implement them.

https://www.codeproject.com/Articles/53 ... lood-Fills

[Manannan]

Hi Kelli217,

Thanks for your feedback.

I like the look of the Queue-Linear Flood Fill as I already have a queue, and it looks like it can be good use of the Vera's auto increment.

I have a question regarding VERA FX. I may be being thick here, but I couldn't see anything useful for filling planes, only polygons.

Am I missing something here?

Would you use FX for flooding if it was your project, or would you simply implement one of those algorithms?

[kelli217]

I don't know. It seems that with VERA FX cache writes, since they do 4 bytes at a time, you would need to check 4 pixels in each horizontal direction for a boundary before writing. That might not help as much. I could be looking at it the wrong way. As far as I know, right now it's being most commonly used for pre-defined areas. Your use case is not so easily defined, as you need to be able to fill arbitrarily-shaped regions.

[voidstar]

Well, despite the diamond issue, I wanted to say:

VERY COOL!


Very neat to see the progress. One question, how are you doing the font? That's "Sierra style" font right? Is it that text mode over graphics, so just update the in memory font tables?

Having this working means potentially running many other "AGI-engine" based games, so this is really neat

[Manannan]

Hi VoidStar,

Thanks for the encouragement.

It's so much more fun then the standard boring stuff I am paid to do at work .

The font is the CX16 ISO font. The text is on layer 1 and it is a 2bpp tileset.

I just did some basic binary operations to convert the standard 1bpp text characters from the ROM.

On reflection, maybe I should have just left it as a text layer, I will need to think about that.

As for the diamond issue, I am trying to improve things by doing some general optimisations: unrolling loops, using registers instead of memory, or ZP if I can't avoid it etc.

I can't claim to be an algorithm expert, so if someone can suggest a better one, I am open to it.

[DragWx]

If you're still looking for ways to improve your flood-fill algorithm, I've had good luck with the Span filling algorithm from Wikipedia (specifically scroll down to the "combined-scan-and-fill" algorithm).

It still uses a stack or a queue, but instead of operating on individual pixels, it operates on line segments, which I think is friendlier for the VERA (just the plain address auto-increment makes it easy to draw straight lines).

[Manannan]

Hi DragWx,

That looks like a fairly simple algorithm.

I will try and implement that.

Once I have implemented it I will repost. . .

[cosmicr]

Hi Manannan, I just discovered your project after I had the same idea recently!

Looks like you're making great progress. I see you're basing it off of MEKA, but have you considered reviewing the source for NAGI?
https://github.com/sonneveld/nagi

NAGI was written from actual disassembly of the Sierra AGI Interpreter, it's aim was to be accurate, but still might provide an insight into some better ways to do some things.

There's also the SCUMMVM source too, but I don't know much about it.

I know a bit of C (I'm a C++ programmer) and have written quite a few of my own utilities for AGI so have a good understanding of how it works. Too bad I don't really know 6502 asm yet...

Anyway, great work so far!

[Manannan]

Hi Cosmicr,

Thanks for your encouragement .

It means a lot to see people encouraging my work.

It was a while ago, and I hope my memory isn't too hazy, but I did look at Nagi a long way back.

I think the problem was that it was written in a newer version of C. CC65 only supports C89, which Meka is written in.

However I expect that it is a good frame of reference.

I have also referenced Sarien. I may switch to using their line algorithm, but we will see.

Please don't dispair that your favourite project is taken. ScummVM implements many different engines, and there is zero chance of a ScummVM port for the CommanderX16 for many good reasons.

Because of this I suggest that you pick another of the many engines implemented by ScummVM and write an implementation in the Commander.

ScummVM is a C++ project, so if you use that as your base a rewrite will be required.

If you could pull off Sierra SCI (engine for newer games like King's Quest VI) I would be really impressed. Not sure if there is enough VRAM.