Sierra AGI Interpreter Update February 2024

[Manannan]

Hi All,

Like I said in my previous update I have been working on a Sierra AGI Interpreter to run old Sierra Adventure games like King's Quest.

Christmas plus a COVID lockdown gave me a lot of extra time, and as of this date I have now got sprites displaying and moving correctly.

You can see this here: https://www.youtube.com/watch?v=yd_LWDhv8RI

Note:
- Sprite to background priority needs to be done, but sprite to sprite priority works fine.
- Also there is no boundary checks on the chickens yet, which is why they have escaped the pen
- I have edited out some loading time from the video, I have it on my to do list to implement a faster scanline based drawing routine as recommended by DragWx

[desertfish]

Great stuff! is the drawing done while the "LOADING" is displayed? i.e. you cannot see it happen?

[Manannan]

Great stuff! is the drawing done while the "LOADING" is displayed? i.e. you cannot see it happen?

Yeah. You are right it is happening then. It is easier to hide the drawing than it is to do it over multiple VBLANKs.

[cosmicr]

Incredible work!

For what it's worth, the original pcJr version (also Tandy etc) didn't have super fast loading either - with no loading indicator (apart from the pleasant buzz of your disk drive). The Apple II version showed the drawing happening on the screen IIRC. So I think it adds charm, no need for the loading screen.

Just for fun and a learning exercise I had a go at writing a scanline flood fill (rather than the 4-way diamond fill). Here's what I came up with (ignore the palette - I was learning/playing). I had an idea you could have custom palettes depending on the game.



I was pretty happy with 12 seconds, which includes drawing the priority in another part of VERA memory at the same time too - you can see a big pause near the start which is doing a flood fill in the priority screen. I reckon I could get it even faster by in-lining more code and shifting some parts to pure asm.

I've been toying with the idea of continuing my own version of the interpreter. I started implementing opcodes, but I'm also learning 65c02 assembly, the VERA, the Kernel, and C89 all at the same time! Mine is significantly different to yours. You appear to be storing program data in bank memory, whereas I haven't needed to do that yet - I have reserved bank memory for resources only, with about 128k spare. It looks as though you're trying to match the memory layout from the original interpreter? I don't know much about that... I've been learning from the WinAGI documentation and AGI Wiki.

My screen layout is like this:
4-bit mode (with custom EGA palette)
Layer 0 - Background + (hidden) Priority (Bitmap mode)
Sprite Layer
Layer 1 - Text (Tiled mode)

I haven't learned enough about sprites yet but I'm not sure if the transparent colour needs to be 0 on them, if that's the case I might struggle to work out how to make sure black stays black. Similarly for Layer 1. I tried putting layer 1 into 256c mode but I'm not sure you can mix and match bit depths. Worst case, I draw a temporary black box on layer 0 behind each sprite or text box. Visual/priority overlays etc should be fairly easy as I already have a pretty fast getpixel routine and views (sprites) aren't very big mostly. Apparently views can be up to 256x256 but I don't think any game ever had them that big (especially since it's larger than the screen res).

If anyone's interested I can post my code on github too, but I'm not promising that I'll continue, but it might be helpful for reference.

[Manannan]

Incredible work!

For what it's worth, the original pcJr version (also Tandy etc) didn't have super fast loading either - with no loading indicator (apart from the pleasant buzz of your disk drive). The Apple II version showed the drawing happening on the screen IIRC. So I think it adds charm, no need for the loading screen.

Just for fun and a learning exercise I had a go at writing a scanline flood fill (rather than the 4-way diamond fill). Here's what I came up with (ignore the palette - I was learning/playing). I had an idea you could have custom palettes depending on the game.



I was pretty happy with 12 seconds, which includes drawing the priority in another part of VERA memory at the same time too - you can see a big pause near the start which is doing a flood fill in the priority screen. I reckon I could get it even faster by in-lining more code and shifting some parts to pure asm.

I've been toying with the idea of continuing my own version of the interpreter. I started implementing opcodes, but I'm also learning 65c02 assembly, the VERA, the Kernel, and C89 all at the same time! Mine is significantly different to yours. You appear to be storing program data in bank memory, whereas I haven't needed to do that yet - I have reserved bank memory for resources only, with about 128k spare. It looks as though you're trying to match the memory layout from the original interpreter? I don't know much about that... I've been learning from the WinAGI documentation and AGI Wiki.

My screen layout is like this:
4-bit mode (with custom EGA palette)
Layer 0 - Background + (hidden) Priority (Bitmap mode)
Sprite Layer
Layer 1 - Text (Tiled mode)

I haven't learned enough about sprites yet but I'm not sure if the transparent colour needs to be 0 on them, if that's the case I might struggle to work out how to make sure black stays black. Similarly for Layer 1. I tried putting layer 1 into 256c mode but I'm not sure you can mix and match bit depths. Worst case, I draw a temporary black box on layer 0 behind each sprite or text box. Visual/priority overlays etc should be fairly easy as I already have a pretty fast getpixel routine and views (sprites) aren't very big mostly. Apparently views can be up to 256x256 but I don't think any game ever had them that big (especially since it's larger than the screen res).

If anyone's interested I can post my code on github too, but I'm not promising that I'll continue, but it might be helpful for reference.

Hi

Thanks for your encouragement.

I would love to have your algorithm. I have yet to draw the priority screen, and I hate to think just how slow my diamond method drawing would be if I add the priority drawing as well.

As for drawing the flood filling without the loading screen; my only concern is that it would cause screen tearing, because there is no way you are going to draw both the background and the priority in 1 VBLANK.

I would be really surprised if you could get away no code in the banked RAM. AGI is really complicated, and once your main program executable hits around 19kb you start to get weird corruption issues, which I think is the C stack colliding with your program code.

There is an Excel spreadsheet called allocation.xlsx which describes in detail how I lay out the memory.
- I reserved 17 banks for code
- 10 for precalculated floating point division
- 19 for dynamic memory (I have a malloc like memory management system which allocates on these banks)
- 9 for a flood queue
- 3 for static data (I have a to do item to merge these with the code banks)

I am not trying to emulate the original memory layout, I don't think there is a compelling reason.


I have a very different system of layers to you.

Layer 0 16 colour bitmap
Layer 1 4 colour tile mode
A sprite layer, obviously

As for transparancy when a sprite has a non black tranparent color, I add a palette using a really simple dynamic palette allocation mechanism.

The scrolling credits, are made up of multiple sprites, which I split using computationally.

If you are interested in contributing Cosmicr please drop me a private message.

My repo is here for the record: https://github.com/wizardmanannan/CX16Agi