That looks really good. I can still see a few pixels here and there that aren't quite right.
What are you using for your line drawing algorithm? The exact algorithm used by Sierra in AGI is pretty simple, and uses only integers. If you implement that algorithm, you'll get lines that come out exactly as Sierra drew them.
Here's a pseudo-code example of the Sierra line algorithm:
void drawline(int X1, int Y1, int X2, int Y2)
{
//assumes X1 != X2 and Y1 != Y2
//assumes pset knows correct color to set
int xPos, yPos, DX, DY, vDir, hDir;
int XC, YC, MaxDelta, i;
//determine delta x/delta y and direction
DY = Y2 - Y1; vDir = (DY<0? -1, 1);
DX = X2 - X1; hDir = (DX<0? -1, 1);
//set starting pixel
pset(X1,Y1);
xPos = X1; yPos = Y1;
//invert DX and DY if they are negative
if(DX < 0) DX *= -1;
if(DY < 0) DY *= -1;
//set up the loop, depending on which direction is largest
if(DX >= DY) {
MaxDelta = DX;
YC = DX / 2;
XC = 0;
}
else {
MaxDelta = DY;
XC = DY / 2;
YC = 0;
}
//draw line
for(i == 1; i == MaxDelta; i++) {
YC += DY;
if(YC >= MaxDelta) {
YC -= MaxDelta;
yPos += vDir;
}
XC += DX;
if(XC >= MaxDelta) {
XC -= MaxDelta;
xPos += hDir;
}
pset(xpos, ypos);
}
}
For plotting, there's good information in the WinAGI help file that explains how to code that, including brush sizes and shapes. For splatter plotting, the actual algorithm that Sierra used is a lot simpler than the bit array in the AGI specifications that has been used for years. Here's the actual Sierra algorithm:
//read starting pattern from picture data stream
pattern = pattern | 1
//set starting pixel to first pixel on top row of desired pen shape
do {
newPatt = pattern >> 2
if ((pattern & 1) == 1) {
newPatt = newPatt ^ 0xB8
}
pattern = newPatt
if ((pattern & 3) == 2) {
//draw this pixel
}
}
//move to next pixel, in left-to-right, top-to-bottom order
while !done //loop until all pixels in desired pen shape are tested
If you haven't already done it, make sure your fill algorithm handles cases where the visual and priority pens are set/not set; if only visual pen is set, fill will use boundary lines it finds in the visual picture; if only priority pen is set, fill will use boundary lines it finds on the priority screen; if both pens are set, fill will set pixels in both images, but will only use the visual screen boundaries it finds.
If you have any questions about AGI resources, take a look at the WinAGI help file - it's got a ton of information. Or you can message me/post here.
I did see Lance's line-draw algorithm in the picture specs, though this one is literally just using the default line function in the Python Imaging Library. I was lazy, though, so there are a few differences. Also been doing some refactoring (which I may have mentioned) to get things into a separate class that could be used almost standalone in something else.
I'll have to try the method for the brush to see how close I can get - I have a few test PICs I've created to test out the actions my existing art didn't have (e.g. x/y corners or relative lines) so will do the same there. Start making a shell of a View decoder last night, though this time incorporated some improvements to the structure of how bytes are parsed (e.g. making a function to take two bytes, flip the order and scale up the big end appropriately).
-- Interlude --
A long time ago, though not as long ago as my original AGI days, I used to work with a bunch of people to make mods for Lionhead's The Movies, which meant writing python scripts for blender to move information back and forth, to make creating new content for the game much more accessible. I'm sort of using them as a reference/framework for how to structure my scripts, particularly for the new View one.
-- End Interlude --
I've definitely been hitting the wiki and the AGI Help files over the past few weeks, though the latter was more trying to reverse-document my original code for The Lost Planet (since I no longer had the logic text files).
One of the things that's important to me with how I'm approaching the classes, is I'd like to make it so you can programmatically create a resource, whether by adding code or reading from an xml or even just import a PIC and export it back out.
And y'know, since Lance is doing a C# AGI Interpreter (though probably distracted right now because of awful people doing crappy things), and you're doing a new version of WinAGI, here's what's on my mind - is there any thought at the moment to putting together a hypothetical 'v4' interpreter?
Like, incorporating the Hercules-like/(SCI0) interpreter from the start, maybe resolution improvements, or at least, less restrictions on resource numbers? The one that comes to mind is we've had AGI Mouse additions, and certainly we've had it catered for (even in our own games) through ScummVM, but instead of replacing existing 'unknown' commands as the original AGI Mouse implementation did, it'd be plausible for new v4-only ones to be added?
Even things like having a toolset (WinAGI) that didn't have a limit on PIC resource sizes, with an interpreter that didn't either, would be amazing. Nothing I'd be banking on, but is there a potential discussion to be had there?
