#8687 closed patch (fixed)
AGI256 starting point and information
| Reported by: | bluegr | Owned by: | |
|---|---|---|---|
| Priority: | normal | Component: | Engine: AGI |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
In this patch, I don't plan to implement AGI256, but just provide a starting point for it, plus any information I have found concerning it.
AGI256 and AGI256-2 are two hacks done on the original Sierra AGI interpreter ver. 2.936. AGI256 was the first hack made on it and it allows the AGI engine to use 256 color background images (known as "pics" in AGI). AGI256-2 was the second hack made, based on AGI256, which also allows actors (known as "views" in AGI) to be 256 colors as well.
More information can be found at: http://agisci.classicgaming.gamespy.com/agi256.shtml http://agisci.classicgaming.gamespy.com/agipatch.shtml http://www.agigames.com/forum/index.php?topic=593.0
The original AGI256 was made by Dark Minister and AGI256-2 by Brian Provinciano.
The interpreters are: - Original Sierra interpreter: http://www.agidev.com/dl_files/agi_gameidx_2_936.zip - AGI256 hack: http://dl.fileplanet.com/dl/dl.asp?ClassicGaming/agisci/agi-256c.zip - AGI256-2 hack: http://dl.fileplanet.com/dl/dl.asp?ClassicGaming/agisci/agi256-2.zip
The AGI256 and AGI256-2 hacks are used by their respective demos. AGI256 is also used by the 256 color version of the fanmade game "Dashiki"
AGI256 and AGI256-2 are solely hacks on Sierra's binary, and there is no source code provided. There are three tools that can be used for AGI256-2: - AGI256 View Editor - probably the best tool out there for this purpose. It's a Windows tool (whereas the other ones are for DOS) and it can handle both pictures and views - savepic - Converts 256 colour PCX images to 256 colour AGI picture resources - Show Pic 256 (aka "PCX -> 256 PIC", at least the download is the same) - Displays 256 colour AGI picture resources
All those tools can be found here: http://agisci.classicgaming.gamespy.com/agiutil.shtml
The AGI256 picture files are bitmap images, in comparison to normal picture files which have instruction and data bytes (i.e. "Draw a line with that color"). Therefore, all we need to do is copy their contents on the screen buffer, without parsing them. An AGI256 picture's dimensions are 160x168, or 26,880 bytes. The palette used in AGI256 is static and is not stored in the picture files themselves. Those pictures are loaded from logic scripts using a modified version of the set_simple/unk_170 command. I figured out that unk_170 is set_simple from this Sarien commit: http://sarien.cvs.sourceforge.net/sarien/sarien/src/core/op_cmd.c?r1=1.91&r2=1.92 and by looking at the logic scripts of the AGI256 demo with AGI Studio
With a byte comparison between the original interpreter and the hacked AGI256 interpreter, we can see that references to CGA_GRAF.OVL, JR_GRAF.OVL, EGA_GRAF.OVL, HGC_GRAF.OVL, VG_GRAF.OVL, IBM_OBJS.OVL and HGC_OBJS.OVL have been changed to AGIGRAF.OVL and AGIOBJS.OVL
I've managed to extract the AGI256 palette by saving a bitmap as an AGI256 picture using the AGI256 View Editor. It seems the colors in the palette follow some sort of a pattern, but I wasn't able to figure it out.
Also, with this hack, two files are needed for each room: one file contains the 256-color picture and another contains the priorities
I'm attaching a patch which can serve as a starting point for AGI256. It loads the AGI256 pictures correctly, but it still needs a lot of work on the following points: - The palette is not set correctly, and only the first 16 colors are set. I've tried setting _renderMode to Common::kRenderDefault instead of Common::kRenderEGA, but that didn't help - The palette colors I've extracted seem to be following a pattern, but I haven't figured out what it is. Perhaps they can be generated using an algorithm instead of written by hand - All pictures are treated as AGI256 pictures when loaded. This is not correct, as normal pictures are also needed to set the priorities of the picture. Therefore, only the pictures loaded from the set_simple/unk_170 opcode should be treated as AGI256 pictures - Perhaps the code for assigning picture priorities should be modified, as with this hack two files are needed to describe a scene instead of one (the 256 color picture and the priorities picture). Currently, priorities are loaded incorrectly for AGI256 games - I haven't done any work on AGI256-2, where the views (actors) are set to be 256 colors as well as the pictures. This is a different and more difficult hack - Currently, the only way of detecting if the target game is using the AGI256 hack is by the features specified for it in the detector. Perhaps a file-based approach can be used to detect if the game is using the AGI256 hack, based on the file differences described above, i.e. we could determine if an AGI game is using the AGI256 hack from the existence of AGIGRAF.OVL and AGIOBJS.OVL
Some of the above can be achieved much more quickly with a good disassembly of the changed instructions in the AGI256 and AGI256-2 hacked files
Ticket imported from: #1728713. Ticket imported from: patches/792.
Attachments (2)
Change History (6)
by , 17 years ago
| Attachment: | agi256_start.patch added |
|---|
comment:1 by , 17 years ago
Attaching an updated version of the AGI256 patch. In this version, only pictures loaded with set_simple/unk_170 are treated as AGI256 pictures. Pictures loaded using the normal load_pic, show_pic, draw_pic etc opcodes are treated as normal AGI pictures. This fixes the third TODO from the original submission, the other 5 still remain.
Also, I've updated the set_simple/unk_170 opcode a bit, as it's supposed to do 3 opcodes: load a picture (load_pic), decode it (decode_pic) and show it (show_pic). File Added: agi256_start_v2.patch
comment:2 by , 17 years ago
Closing, as the AGI engine now supports the AGI256 and AGI256-2 hacks thanks to Buddha^ :)
comment:3 by , 17 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:4 by , 6 years ago
| Component: | → Engine: AGI |
|---|
AGI256 starting point