id,summary,reporter,owner,description,type,status,priority,component,version,resolution,keywords,cc,game 8687,AGI256 starting point and information,bluegr,,"{{{#!Markdown 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 }}} {{{#!div style=""font-size: 75%"" Ticket imported from: !#1728713. Ticket imported from: patches/792. }}}",patch,closed,normal,Engine: AGI,,fixed,,,