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
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.