Community
AGI Programming => AGI Development Tools => Topic started by: Crispin on September 06, 2015, 03:10:17 PM
-
Hi guys,
I am trying to demake (https://en.wikipedia.org/wiki/Video_game_remake#.22Demakes.22) original "King's Quest I" for C64 using Quill (https://en.wikipedia.org/wiki/The_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)
I managed to convert multi-color pics to hi-res (by hand, but ConGo (http://www.editorix.org/congo/) is of great help)
It should be some kind of proof that porting of AGI engine to C64/128 is possible.
I suppose that real conversion should be done with DotBasic+ (http://dotbasic.cbm8bit.com/) but... that's another story.
Where I'm stucked is converting of 80+ agi resource pics to bmp (I'm using GIMP).
So, my question is:
What is the simplest way to export agi pics to bmp (.tga, .png...)? Batch conversion if possible.
I forgot how I did it, probably by taking screenshot of WinAGI, PicEDit or so.
-
You can use the latest of the Sierra Resource Viewer, but only one-by-one.
-
You can use the latest of the Sierra Resource Viewer, but only one-by-one.
Thanks for that!
I missed that "Also works with AGI games" :D
Hm, does not work for me :( seems that it can not recognize agi pics (I disabled auto recognition then, tried to change AGI "version control" but nothing).
I suppose that SCI Res Viewer can open multiple pictures at ones (open dir)?
It is possible at PicEdit.
Btw, does any other tool at "SCI Resource Utilities" work with AGI? e.g. "SCI Graphic Studio"?
-
I have always just used the "copy to clipboard" button in AGI Studio and then pasted the image.
-
The SV command line tool can dump the AGI resources from the VOL files, but they would have to be converted to a standard format. With a command line tool you could easily do batch processing of AGI VOL files to extract the Pics as BMP, PCX, etc.
-
I have always just used the "copy to clipboard" button in AGI Studio and then pasted the image.
Thanks for suggestion.
I have to test it, I can c&p text (even between Wine & Linux), but I didn't manage (yet) to copy pics between 2 apps in Wine. Actually, I think that every app in Wine has its own enviroment. But there is solution for that too, I'll post it when I have some news about it.
The SV command line tool can dump the AGI resources from the VOL files, but they would have to be converted to a standard format. With a command line tool you could easily do batch processing of AGI VOL files to extract the Pics as BMP, PCX, etc.
Thanks for that, it will be *the way* I suppose.
This should be solution, from CLI. I'm rusty with that (DOS batching), but I'll manage it.
Btw - MY MISTAKE: I tried to open pics resource with SCI Res Viewer that were - already extracted.
However, there is another problem: when I open dir (VOL?), I can see only words & objects (text).
I hope I'll manage to do it with SV CLI tools (Graphics.exe & Resource.exe).
(http://lookpic.com/O/t2/870/MQi3j9W.jpeg) (http://lookpic.com/O/i2/870/MQi3j9W.jpeg)
Guys, don't be mad if I don't replay immediately: I'm busy right now and messing with AGI is my hobby project, so please allow me some time to study things and answer.
EDIT: forgot to mention, funny thing: when I open PicEdit from AgiStudio, WINE starts DOSBox - it shows up and just close. However, it is funny that one emulator calls another one :D
-
To extract resources from an AGI VOL file use the following:
Resource.exe VOL.0
You will have to do this for each VOL file.
As far as PicEdit, use Lance's newer Java port rather than his old DOS version.
-
WINE starts DOSBox - it shows up and just close. However, it is funny that one emulator calls another one :D
But... Wine is not an emulator :D
-
WINE starts DOSBox - it shows up and just close. However, it is funny that one emulator calls another one :D
But... Wine is not an emulator :D
ZING (http://instantrimshot.com/index.php?sound=rimshot&play=true)
-
WINE starts DOSBox - it shows up and just close. However, it is funny that one emulator calls another one :D
But... Wine is not an emulator :D
ZING (http://instantrimshot.com/index.php?sound=rimshot&play=true)
OMFG stop trolling... technically, of course it is not. But purpose is the same. Be sure that I know what VirtualBox, QEMU, VMware are and what is the difference between vm & WINE. Of course that you can't jump from one "sandbox" to another just by (virtual) system call.
WINE is ("just") a "compatibility layer" capable of translating "Windows API calls into POSIX calls on-the-fly (https://www.winehq.org/about/)".
(edit btw even 2 vm could exchange data between, so it is regardless of "is WINE emulator or not")
You're missing the point: possibilities of running another one "strange" process (such as DOSBox). Because both lie on same file-system, it is possible to change files outside of WINE and reload it in same app (same session) that made request for.
Of course, it is not possible without extra settings and without giving extra permissions, because of architecture of *nix systems. But there is a possibility, and I find it amusing.
-
To extract resources from an AGI VOL file use the following:
Resource.exe VOL.0
You will have to do this for each VOL file.
As far as PicEdit, use Lance's newer Java port rather than his old DOS version.
(Of course I'm using Java PicEdit. Btw WINE can open DOS PicEdit by forwarding it to DOSBox, but it works only from command line.)
I did extract picture resources with Resource.exe (I already extracted them before with WinAGI with same result).
However, I have not luck with Graphics.exe ("Error processing picture.xx").
Maybe it got something with missing *.pal according to this message:
"If you want pictures to be exported exactly as seen be sure to use -v (and probably -pal) options."
...but this is beyond my scope. And it should be optional. All I find about is this message (http://sciprogramming.com/community/index.php?topic=1081.msg5449#msg5449) at forum.
Then I tried with SCI picture resource and it just works. It works from Sci Res viewer (gui) too, of course.
Unfortunately, "SCI enhanced" version has a totally different graphics from AGI so it does not helping me.
I've got interesting WINE system messages about missing .NET dependencies before cli started, maybe I'll find a way to fix it.
Btw if somebody's trying to run those cli @Linux don't bother with DOSBox (common mistake - it is Win32 app), or just click on it - it won't work.
First invoke WINE cmd from terminal (~ $ "wine cmd"), as you should start "cmd" from "Run" @Windows I suppose.
-
The Resource Viewer is too new to be DOS tools, so yes the CLI tools are Win32 console apps. I have had issues with many of the specialty tools, so I usually just use Resource.exe. If I invoke it from a batch file or one of my frontends I just have it dump the output to a new folder and delete all of the type of resources other than what I am working with. I really wish the author of SV had released the source before fading into the woodwork, but he said that he no longer had the source when I asked.
-
The Resource Viewer is too new to be DOS tools, so yes the CLI tools are Win32 console apps.
Actually it is easy to run Win32 console apps from plain DOS (DOSBox...). Just some DOS extender is needed. DOSLFN (long filenames support) is of great help too.
I did it with HX DOS Extender (https://web.archive.org/web/20141003032417/http://www.japheth.de/HX.html); resource.exe and graphics.exe both works.
(There's even more, it is possible to run some basic OpenGL/DirectDraw/SDL Windows apps.)
-
Cool! I assume DOS4GW and CWSDPMI work as well? Why haven't I thought of this before...
-
Yes, DOS4GW and CWSDPMI do work.
If you specifically need DOS4GW, it is smart to replace it with DOS/32 (http://dos32a.narechk.net/index_en.html) and just rename DOS32A.EXE to DOS4GW.EXE (or use some other method, all explained at DOSBox Wiki (http://www.dosbox.com/wiki/TOOLS:DOS32A)).
Because it is designed to be faster and more stable with modern systems than the original. And it is free (open source).
HX (https://web.archive.org/web/20141003032417/http://www.japheth.de/HX.html) is also good option, and it comes with it's own HDPMI server (host) which is fully compatible with CVSDPMI (more info about it at DrDos Wiki (http://www.xaver.me/drdoswiki/index.php?n=Main.HX-DOS)).
For more info:
- There is a short comparision of DOS4GW and alternative DOS extenders at MaximumHoyt (http://maximumhoyt.blogspot.hr/2008/12/dos4gwexe-version-201a-and-alternative.html)
- Some list of DOS extenders and DPMI hosts at TheFreeCountry (http://www.thefreecountry.com/programming/dosextenders.shtml)
EDIT: Just to be precise, DOS(Box) with HX DOS expander handles Sierra Resource Viewer command line tools, but it is still not possible to export AGI picture/view files to easily readable bitmap format with graphics.exe. At least not for me. But it works with SCI files.
-
I am trying to demake (https://en.wikipedia.org/wiki/Video_game_remake#.22Demakes.22) original "King's Quest I" for C64 using Quill (https://en.wikipedia.org/wiki/The_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.
-
I am trying to demake (https://en.wikipedia.org/wiki/Video_game_remake#.22Demakes.22) original "King's Quest I" for C64 using Quill (https://en.wikipedia.org/wiki/The_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 (http://csdb.dk/release/?id=134342) 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 (http://www.rgcd.co.uk/2011/10/prince-of-persia-c64.html)). Actually, by using this technique, AGI could be ported to VIC20 (and so on).
One other thing that comes to my mind is DotBASIC+ (http://dotbasic.cbm8bit.com), 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.
-
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 (http://vice-emu.sourceforge.net/) 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.
-
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.
-
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).
-
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.
-
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?
-
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.
-
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.
-
Good to have you here!