### Author Topic: What are we working on?  (Read 94765 times)

0 Members and 1 Guest are viewing this topic.

#### AGKorson

##### Re: What are we working on?
« Reply #75 on: May 03, 2017, 01:36:48 PM »
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:
Code: [Select]
`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:
Code: [Select]
`//read starting pattern from picture data streampattern = pattern | 1//set starting pixel to first pixel on top row of desired pen shapedo {    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 orderwhile !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.

#### lance.ewing

##### Re: What are we working on?
« Reply #76 on: May 03, 2017, 06:16:05 PM »
The one little bit of different, is that I *also* made it able to spit out a control-lines only image.

I've done something similar in the AGI interpreter I'm working on at the moment, with the exception that the priority screen doesn't show any control lines at all. Instead it uses the original AGI interpreter's algorithm for determining what the priority of a control line pixel should be. I haven't actually looked at it visually yet but my interpreter is using the resulting priority pixel array to make priority decisions and control screen pixel array to make control line decisions and it all seems to work functionally. I was planning to make the debug "show priority" feature show both screens one after the other but have yet to implement this.

Still don't know what I'll do with it after this. I doubt I have it in me to write a full-blown AGI interpreter, but I'd like to take this somewhere too. It's certainly been giving me a lot of ideas.

I'm hoping to work on the C# AGI interpreter to a point where it becomes a kind of reference implementation. The idea is to progressively refactor it over various iterations until it all kind of makes intuitive sense, with everything named and documented cleanly. I was then hoping that at some point in the future (once done) I could pick another language to learn and converting the code would be a matter of replicating the various classes and methods in that language and voil?!  you've have an AGI interpreter in that language. - Edit: If you were to think about a full-blown interpreter, you could hopefully make use of it as a guide. I'm trying to cross reference it against the original AGI source code fragments (found on a SQ2 game disk) as much as possible as I go along.

I will second AGKorson with regards to the line drawing algorithm. The example code in the AGI specs is the original version I came up with over 20 years ago using (literally) trial and error. It seemed to work at the time for all the pictures I tried but was quite inefficient. I wasn't in the habit of actually disassembling code in those days, in fact the first AGI picture drawing program I wrote was in GWBASIC under DOS 3.3 (which I really must dig out and try to run again).
« Last Edit: May 03, 2017, 06:29:45 PM by lance.ewing »

#### Kawa

##### Re: What are we working on?
« Reply #77 on: May 03, 2017, 06:22:49 PM »
and viola!
A viola is a slightly larger violin. Did you mean "voil?"?

#### lance.ewing

##### Re: What are we working on?
« Reply #78 on: May 03, 2017, 06:26:08 PM »
Indeed I do    Was just in the process of editing it for another reason, so will correct this now while I'm at it.

Edit: I'm somewhat distracted this evening with a break-in we've had at home. I'm up later than I would be, waiting for an emergency glazier to come and board up a ground level window. Have to keep myself occupied with something while I wait.
« Last Edit: May 03, 2017, 06:34:27 PM by lance.ewing »

#### Kawa

##### Re: What are we working on?
« Reply #79 on: May 03, 2017, 07:09:37 PM »
Goddamn. Anything gone besides the window and your sense of security?

#### lance.ewing

##### Re: What are we working on?
« Reply #80 on: May 03, 2017, 07:20:20 PM »
Yeah, a macbook air, surface pro 4, ipad 3, and a couple of phones (both of which were older models not being used anymore). That's what we know about at the moment. It must have been a quick fill a bag and run I think. Larger items left alone.

#### Nicktatorship

##### Re: What are we working on?
« Reply #81 on: May 03, 2017, 08:33:30 PM »
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:
Code: [Select]
`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:
Code: [Select]
`//read starting pattern from picture data streampattern = pattern | 1//set starting pixel to first pixel on top row of desired pen shapedo {    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 orderwhile !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?
---
Nick/Tarison/Nicktatorship
Aka "The Lost Planet" person

#### Nicktatorship

##### Re: What are we working on?
« Reply #82 on: May 03, 2017, 08:34:11 PM »
Yeah, a macbook air, surface pro 4, ipad 3, and a couple of phones (both of which were older models not being used anymore). That's what we know about at the moment. It must have been a quick fill a bag and run I think. Larger items left alone.

Really sorry to hear that.
---
Nick/Tarison/Nicktatorship
Aka "The Lost Planet" person

#### MusicallyInspired

##### Re: What are we working on?
« Reply #83 on: May 03, 2017, 08:39:44 PM »
Geez, Lance, that's terrible I'm sorry that happened.

#### troflip

##### Re: What are we working on?
« Reply #84 on: May 03, 2017, 08:48:43 PM »
Check out my website: http://icefallgames.com

#### Collector

##### Re: What are we working on?
« Reply #85 on: May 04, 2017, 02:44:04 PM »
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?

The talk about heap limits in the Cascade Quest thread was making me think of the problem that many fan AGI devs encountered with a blown stack that NAGI was able to deal with, too. I am a bit torn between accuracy of the new interpreter and the ability to work around the original limitations of the stack, but it might be worth while to at least think about addressing the blown stack problem with the C# interpreter.

#### Kawa

##### Re: What are we working on?
« Reply #86 on: May 04, 2017, 02:58:33 PM »
Out of heap space!

[Increase and retry] [Halt and catch fire]

#### MusicallyInspired

##### Re: What are we working on?
« Reply #87 on: May 04, 2017, 10:55:10 PM »
Out of heap space!

[Increase and retry] [Halt and catch fire]

*selects Increase and retry*

"Oops! You tried something we didn't think of!"

#### Kawa

##### Re: What are we working on?
« Reply #88 on: May 05, 2017, 02:17:23 PM »
I've been working on a backgrounds collection for no good reason.

I have more games, but no tools to rip their background material without resorting to screenshots. This is an issue here because I want just the backgrounds, without any sprites. Sometimes, sprites never move out of the way, and sometimes what you think is part of the background is not (such as the missing facial features in Loom EGA's closeup shots), or vice versa (such as certain characters' bodies in the Goblins games).

As you may notice, I only have a folder for Kyrandia 2. Kyra1 is... challenging. I have the artwork files, but have to manually match them to palette files and some don't seem to have proper matches...

I can record sprites from the Gob games through ScummVM hacks, but the backgrounds are apparently made of separate pieces and I can't quite find a good place to record them from... and recording doesn't do the palette quite right, but what can you do? And of course it requires playing through the whole damn game, so Goblins is right out.

Thankfully, SCI and SCUMM are easy as all hell, and AGI just needed a few more steps.

#### OmerMor

##### Re: What are we working on?
« Reply #89 on: May 05, 2017, 02:48:20 PM »
I've been working on a backgrounds collection for no good reason.

I have more games, but no tools to rip their background material without resorting to screenshots. This is an issue here because I want just the backgrounds, without any sprites. Sometimes, sprites never move out of the way, and sometimes what you think is part of the background is not (such as the missing facial features in Loom EGA's closeup shots), or vice versa (such as certain characters' bodies in the Goblins games).

As you may notice, I only have a folder for Kyrandia 2. Kyra1 is... challenging. I have the artwork files, but have to manually match them to palette files and some don't seem to have proper matches...

I can record sprites from the Gob games through ScummVM hacks, but the backgrounds are apparently made of separate pieces and I can't quite find a good place to record them from... and recording doesn't do the palette quite right, but what can you do? And of course it requires playing through the whole damn game, so Goblins is right out.

Thankfully, SCI and SCUMM are easy as all hell, and AGI just needed a few more steps.

That's cool.
But some backgrounds are still missing their complementary views (http://helmet.kafuka.org/backgrounds/sci/police-quest-3/65.p56.png). Do you plan to add these?

Page created in 0.164 seconds with 25 queries.