Community
AGI Programming => AGI Development Tools => Topic started by: MusicallyInspired on April 18, 2020, 10:30:56 AM

I'm working on a command line tool that will read Sierra AGI Pic resource draw commands and recreate them with ImageMagick draw commands.....in HD (sort of, scale of up to 5 times). It's coming along but still a ways to go. How it works is it reads the binary PIC file data (extracted from a game via AGI Studio or WinAGI) and creates ImageMagick draw commands in a BASH script which you can then run in an ImageMagickinstalled CYGWin terminal window and create an "HD" PNG recreation. I replaced the flood fill commands with point brush commands instead because the lines are full of gaps and the image is destroyed by flood fills. Some smarter algorithm changes necessary...
This is not so much an "upscale" as it is a redrawing of the art but simply at higher resolutions. I don't know what practical use this could have (perhaps if ScummVM ever implements supporting replacement art assets like a high resolution pack), but it could be nice to look at at least. :)
(http://i.imgur.com/ZZFboBLl.png) (https://imgur.com/ZZFboBL.png)
(http://i.imgur.com/gNqYyBXl.png) (https://imgur.com/gNqYyBX.png)

Okay, can some of you math whizzes or programming gurus help me out here? I'm trying to program in behaviour for drawing Relative Lines/Pen. Bit different from Absolute Lines. It gives a set of coordinates and then every subsequent single byte is a relative displacement that determines what direction and how far from the origin it draws to and I can't for the life of me figure this out. I found this bit of information in the WinAGI help file but I can't make heads or tails out of it.
0xF7: Relative Line
Function: Draw short lines, using relative values. By relative we mean that the byte value gives displacements which are relative from the current location. The first two arguments are the starting coordinate. Each subsequent byte that follows determines the relative displacement to the next coordinate according to the following format:
Sign XDisp Sign YDisp
7  6 7 4  3  2 1 0
This gives a displacement range of between 7 and +7 in the Y direction and 6 and +7 in the X direction (if the x displacement were 7, and the sign bit is set, this would correspond to a value >= 0xF0, so 7 is not possible for the x displacement.) This action does not end until a byte of 0xF0 or above is encountered. A line is drawn after each pair of coordinates is encountered.
Example:F7 10 10 22 40 06 CC ...
This sequence draws a line from (16, 16) to (18, 18) to (22, 18) to (22, 24) to (18, 20)
I don't understand what "Sign" is supposed to mean. Is that Sine as in trigonometry?

That is a byte which consists of 8 bits. The first 4 bits on the left represent the x coordinate and the 4 last bits represent the y coordinate.
If the sign bit is 0 or 1 it means that the number is either positive or negative. + or 
Let's look at this example:
For the hex code "CC" if you convert it to binary you get this:
11001100
Now let's separate that into 2 halves to get the x and y:
X: 1100
Y: 1100
Now let's separate the sign:
X sign: 1
X rest: 100
Y sign: 1
Y rest: 100
Since the sign for both the x and the y are "1" that means negative. If the sign were 0 it would mean positive.
So if we look at the values for binary 000 to 111 means between 0 to 7. That is why it says between 7 and 7, if the sign is 1 it's negative. Or if it's 0 it's positive. Now converting 100 to decimal gets you the number 4.
So finally what happens is that X = X  4 and Y = Y  4. We use minus because of the sign being 1.
So for example if we had this:
01000100
Then it would be X = X + 4 and Y = Y + 4
Hope this helps make it easier to understand.

Ahhhhh. The bits! Binary! I get it now thank you. :)

@MusicallyInspired,
That looks like an interesting idea. There are certainly a lot of challenges. I noticed in your rendering, you can see where in some cases they like to use lines as a way to 'fill' smaller areas (like the blue console on the right for example); that'll be a tough one to figure out.
The image has a really cool 'concept art' feel to it though. I like it!
Regarding the Help file entry for Relative Lines  sorry for not making that clearer; I should have been more specific about the individual bits and exactly what they mean. I will include that in the next version of the Help file.
If you come across anything else in the file that is not clear, please ask. If not me, you can always count on the other AGI 'regulars' to help clarify anything that I didn't explain well in the Help file.
cheers!
Andrew

This looks like a typo to me:
Sign XDisp Sign YDisp
7  6 7 4  3  2 1 0
should be
Sign XDisp Sign YDisp
7  6 5 4  3  2 1 0
right?

Oops! ;D Good catch!
I've probably read that a million times and never noticed it. Goes to show that the best proof reader is someone OTHER THAN the author! :)

Ahhh I was so confused lol. Was wondering where the 5 was.