What is the simplest way to export AGI resource pics to bitmap?

[lance.ewing]

I am trying to demake original "King's Quest I" for C64 using Quill/Illustrator.
AGI line, fill etc "vector" commands are easily translatable to Illustrators. Just there is a problem with colors at char matrix (only 3 allowed at each 8x8pix). But graphics could even be improved somewhere, because of high resolution mode (width is 320 instead 160pix)

Would love to see this when it is finished. I had thoughts of doing something similar on the VIC 20 at one point, but rather than convert the game to another tool, I was thinking about taking the Apple IIe AGI interpreter and hack it to make at least some parts of it work on the VIC 20. The graphics routines would be completely different, and the VIC 20 had a fairly primitive graphics chip, so would be difficult to render an AGI picture. But I was interested in seeing what could be done these days on an old computer like that that had such limited resources. I've written three separate VIC 20 emulators over the years, so understand the machine quite well. The project would have been bringing together two of my interest areas in to some sort of hybrid.

The C64 would fair much better with such a project. The 6510 was almost the same as the 6502 (which was used by the Apple IIe). I really think it could be made to run an AGI game like King's Quest 1. It was comparable to the Apple IIe. The C64 was after all where games like Maniac Mansion and Zak McKracken first began.

[Crispin]

I am trying to demake original "King's Quest I" for C64 using Quill/Illustrator.
AGI line, fill etc "vector" commands are easily translatable to Illustrators. Just there is a problem with colors at char matrix (only 3 allowed at each 8x8pix). But graphics could even be improved somewhere, because of high resolution mode (width is 320 instead 160pix)

Would love to see this when it is finished. I had thoughts of doing something similar on the VIC 20 at one point, but rather than convert the game to another tool, I was thinking about taking the Apple IIe AGI interpreter and hack it to make at least some parts of it work on the VIC 20. The graphics routines would be completely different, and the VIC 20 had a fairly primitive graphics chip, so would be difficult to render an AGI picture. But I was interested in seeing what could be done these days on an old computer like that that had such limited resources. I've written three separate VIC 20 emulators over the years, so understand the machine quite well. The project would have been bringing together two of my interest areas in to some sort of hybrid.

The C64 would fair much better with such a project. The 6510 was almost the same as the 6502 (which was used by the Apple IIe). I really think it could be made to run an AGI game like King's Quest 1. It was comparable to the Apple IIe. The C64 was after all where games like Maniac Mansion and Zak McKracken first began.

Hi Lance, thanks for your kind words. I really admire your work.
I am sorry I didn't notice your post before, somehow missed it. Anyways:
Yess, my wet dream is to get AGI interpreter as native as could be at C64. But too many folks mean that "if it's possible, it will be done already".
So I decided to start KQproject with Illustrator, just to point out it could be done, to make a showcase and find somebody interested enough to get involved.
More about it later.
Yes, you're right, 6502 is almost the same as 6510, which means it could be possible.
For example, Mr. Andreas Varga (aka Mr. SID) made excellent port of Apple II version of Prince Of Persia in 2011, by disassembling source code and using reverse-engineering skills, 6 months (!) before Mr. Jordan Mechner recovered POP source code, which was being lost for  - 22 years!
https://www.c64-wiki.com/index.php/Prince_of_Persia
There is an interesting conversation between those two, at comments section (bottom of page), at Mr. SID's POP64 dev blog:
http://popc64.blogspot.hr/2011/10/prince-of-persia-for-commodore-64128.html
...and Jordan's blog post about finding and archiving the source http://jordanmechner.com/blog/2012/04/source/
I suppose that POP64 was more complex project (or equal, at least) then AGI64 should be. Also, benefits could be much greater, because of existing AGI game library, and because there are already ready to use tool-sets (such as your PICEDIT) to modify (or even produce brand new) games, possibly to make it portable between 8-bit platforms.
Btw, Mr. SID made later exact port of Donkey Kong Junior from Atari 7800 to C64 (also 6502>6510)

Very smart solution at POP64 was to put whole game in (virtual) cartridge, surpassing 128 KB needs, and which could be run by e.g. VICE emulator easily.
This is *the solution* for AGI interpreter memory needs, to override RAM limitation (POP64 has half MB, more info at rgcd). Actually, by using this technique, AGI could be ported to VIC20 (and so on).

One other thing that comes to my mind is DotBASIC+, which is 100% downward compatible with existing CBM BASIC, but also has a native support for joystick/mouse, graphic/sprites, sound, memory handling, I/O etc, by clever use of "object oriented" ASM modules - and it is expandable. Also, DB+ programs do not need DB+ interpreter to run (standalone, transportable).
What I found interesting here is that DB+ has very similar vector graphic commands as AGI. So, in theory, whole thing could be run from DB+. Or at least AGI res tools (or just resources) could be done by using it (viewers, converters, editors... such as your PICEDIT, again). Similar stands for View>Sprite, Picture, Sound resources (native 3+1 sound support but DB+ can play SID songs also!).
These modules are used selectively; only those that are needed, which means that modular engine saves your RAM without sacrificing possibilities.
New one could be added when there is a need for it (I'm not a coder so I can't be sure how hard is it). It means that for porting DB+ programs to VIC20 only specific library ASM modules should be rewritten (well there are also different memory addresses etc).
I like that concept, but it should be proved in praxis. Unfortunately, DB+ exists only for C64 afaik.
I would be very pleased if somebody took a look at it and approve that.

[Crispin]

I stucked with my AGI KQ1 demake for Quill&Illustrator @C64, mainly because of hdd crash. Still I have some work and resources, but now I changed approach. Main picture (first screen/room - "Castle") still will be made from scratch, by hand (initiall work is done) but all other (pics) will be dummy... until I found a way to translate (convert) AGI PIC data (drawing commands) directly to file format of Illustrator graphics database ("drawstrings").
My plan is to use DotBasic+ as a tool to make conversion from one data file format to another (DB+ because it is simple, but also has low level commands e.g. for byte manipulations). As I found out, all 3 "dev enviroments" share similar "drawstring" (vector graphic) commands.
If I manage to convert AGI PIC data > DB+ PIC data, it will be lot easier to convert it from DB+ > Illustrator then directly AGI > Illustrator.
Benefit is also that, in that case, I will get AGI PIC interpreter for C64 - which is a big milestone in a conversion process at all.
Actually, then it will be possible to make rudimentary AGI PIC editor in DB+ - e.g. to make simple corrections of possible incompatibilities and glitches.
For example, AGI pictures are compatible with DB+ Multicolor mode, but Illustrator is in Hi-Res (double resolution but lesser colors): it means that slant lines at some angles are counted differently.
What I have to do now is to study AGI PIC file format and find a way to read those files at C64 as seq data-files.
I did not manage to do it before, probably because of some error with i/o devices at old version of VICE emulator. It refused to read it's own data files in some occasions... so I gave up then (1Y before). Right now there is a new version of VICE and I hope I'll manage it now.
If I manage to make basic reading of AGI PIC data @C64, I will probably need help to "decode" hex strings of commands, and so on.

I hope that somebody here will be able to help me to convert it, if I stuck (again). Unfortunately I'm not a programmer, nor have experience with that kind of conversion. But I do have some theoretic knowledge and I messed up with hex editors and machine code before... and I'm willing to learn about.

[lance.ewing]

I've never used The Quill, although I do remember seeing the adverts for it in computer magazines of the 80s, and I did drool a bit whenever I saw the adverts. I had a VIC 20 though, and as far as I know, it never came out on the VIC 20. Not surprising really. I was a text adventure game junkie back in the 80s, so the idea of a tool that let you easily create such a game was something that certainly caught my interest.

Although I remember the ads for The Quill, I don't think I have previously heard of The Illustrator. Having just read up on it, I see that it was an add-on for drawing pictures for The Quill system. I'm very familiar with the format of the AGI Picture resource, but know nothing about The Illustrator format. Is there some documentation on the format that you can point me at? - I could take a look and see what I think might be involved. I could also answer questions on the AGI picture format.

It is interesting that Sierra never ported their AGI games to the Commodore 64. I can see that the graphics side of things might have been difficult. The multi-colour mode, although supporting the 160 width required, wouldn't have been able to give the option of 16 colours to each pixel, unless they used dithering. I recall you already mentioning something like this as well. It is possible to mix and match the hires and multi colour modes across each character, so perhaps some convoluted picture could be generated in that way, in conjunction with dithering. I think the C64 also has support for raster effects, right? i.e. changing the colours in use partway down the screen. That's an option as well, but I doubt The Illustrator will be using that technique.

[Crispin]

Thanks for reply. I've got interesting stuff & infos to share, but I'm not home. I'll reply you asap, when I get back home (probably tommorow).

[lance.ewing]

I did some searching and found this:

http://www.mocagh.org/miscgame/quillpack-illustrator-manual.pdf

I haven't had a chance to read through it yet. I have been thinking a bit though and I've started to wonder whether there will be issues with the line drawing. I recall in the early days that my line drawing routine for AGI pictures didn't exactly match what was being used in the AGI interpreter. A pixel here and there along the line was placed in a subtly different position. This is because there are different line drawing algorithms. When there is a 50:50 call on where to place a pixel, some algorithms might put it in one pixel position and some in the other. It might sound like that isn't such a big deal, but it actually turns out to have quite a big impact on the end result. A fill command can quite often be positioned right next to a line, and if that line happens to be drawn slightly different, the fill position may end up landing on top of the line. It is also possible that a line drawn differently may end up exposing a small hole in what is intended to be a closed area through which a fill might spill in to another area it isn't meant to.

So fingers crossed that we'll find that the line drawing algorithms produce the same result. If they don't, you might need to skip the fills and place those yourself.

[Collector]

I have wondered about an import/export function that could be used with AGI or SCI0 pic resources with a standard vector format. Since most vector graphics programs don't seem to care much about order (outside of the order of objects and whether or not an object is closed before filling) would this create translation problems between the pic resource and standard vector graphics files?

[lance.ewing]

Back in the 90s, I had a go at trying to scale an AGI Picture up to a higher resolution. Through that it became obvious that the AGI Picture vector format is not scalable.

http://web.archive.org/web/20001017033212/http://www.123.co.nz/lance/grpic1.gif
http://web.archive.org/web/20001017061059/http://www.123.co.nz/lance/kq4pic6.gif

It might look nice, but really it's just a whole lot of workarounds to stop fills going where they shouldn't. And you'll notice that that whole picture looks quite messy.

Similar reasons apply here. Even if you're using the same line drawing algorithm when drawing at the higher scale, the pixels will obviously be placed in different pixel positions, I mean that's the whole point of scaling really. So that makes it quite difficult to handle the fills. You can't just place them in the scaled up position as they'll suffer from the two problems I mentioned in my previous message. There is a new problem in this case though where the ends of the lines no longer close an area. When a shape is drawn in AGI, it quite often doesn't end back at the exact starting position. It might end at the pixel next to it. Visually it looks like it is closed at the normal AGI resolution, but when scaled up, you can see that it isn't. - What all this means is that you'd need to come up with other ways of handling these issues. You'd need to use not only the AGI picture command data but also some kind of analysis of the original bitmap version of the picture in AGI resolution to make some decisions.

Having said all that, I realise now that this scaling issue might apply to The Illustrator app on the C64. It depends on whether it can be forced to use multicolour mode for the whole picture. If it can then the resolution would be 160 across, so that would be fine. But if it draws parts in hi-res mode, then the line would be drawn finer and therefore have these issues with fills.

[AGKorson]

HI there. If you're still around, I'm the creator of WinAGI, and while it's true the last release did not include an export to bmp (or any other format) did not exist, it's pretty simple to add that. (I've already added an export to .gif feature for views!) I'll probably be releasing a new version very soon, and will add export of pics to bmps.

[MusicallyInspired]

Good to have you here!