Recent Posts

1

SCI Development Tools / Re: Wolfenstein 3D fizzlefade (SCI-related)

« Last post by Kawa on May 05, 2021, 02:07:58 PM »

Similar  in technique, at least. You be the judge exactly how similar.

Code: [Select]

word  i, j, x, y, rand = 1234;
rand &= RANDMASK; //#define RANDMASK 0x240
for (j = 0; j < 64; j++)
{
for (i = 0; i < 16; i++)
{
if (rand & 1)
rand = (rand / 2) ^ RANDMASK;
else
rand /= 2;
x = rand % 40;
y = rand / 40;
//reveal or black out rect (x * 8, y * 8, (x * 8) + 8, (y * 8) + 8)
}
}

Code: [Select]

long rndval = 1;
short x, y;
do
{
y =  rndval & 0x000FF; //Y = low 8 bits
x = (rndval & 0x1FF00) >> 8; //X = High 9 bits
unsigned lsb = rndval & 1;
rndval >>= 1;
if (lsb) rndval ^= 0x00012000;
//black out pixel (x, y)
} while (rndval != 1);

2

SCI Development Tools / Wolfenstein 3D fizzlefade (SCI-related)

« Last post by lskovlun on May 05, 2021, 01:38:33 PM »

So today I learned why Sierra's DISSOLVE algorithm (aka dpOPEN_CHECKBOARD) works. Shame on me for not realizing earlier, but I'm not a graphics guy. It is described here in terms of Wolfenstein 3D, but it is easy to see that it is the same thing.

https://fabiensanglard.net/fizzlefade/index.php

3

AGI Development Tools / Re: conWAGI.exe output redirection fails

« Last post by Kawa on May 04, 2021, 04:45:48 AM »

We can only hope.

4

AGI Development Tools / Re: conWAGI.exe output redirection fails

« Last post by AGKorson on May 03, 2021, 09:47:40 PM »

Thanks for the tip Kawa! Maybe this will be easier than I thought.

5

AGI Development Tools / Re: WinAGI: feature request - batch import/export

« Last post by AGKorson on May 03, 2021, 09:38:41 PM »

I'll see what I can do. Exporting should be really easy. Importing might be a bit more work, because of the need to handle possible errors.

6

AGI Development Tools / WinAGI: feature request - batch import/export

« Last post by ZvikaZ on May 03, 2021, 02:45:06 PM »

Hi.

If it's feasible, it'd be nice to have batch import/export feature from the console.

Example possible APIs:

Code: [Select]

conWAGI.exe /export_all
conWAGI.exe /export View6 /export Picture12

conWAGI.exe /import c:\some\directory\with\importable\files
conWAGI.exe /import View6.agv /import Picture12.agp

BTW, our PQ1 Hebrew translation project is now in beta testing, and you have an important part of it, so, thanks again

7

AGI Development Tools / Re: Should WORDS.TOK have even number of bytes?

« Last post by ZvikaZ on May 03, 2021, 02:38:14 PM »

The trailing zero is required. That's how the word search function knows it's reached the end of the file. If you strip that off, the word search function will continue looking at data from the heap that immediately follows the words.tok file (the OBJECT file), thinking it's valid word data; eventually, a null value will be found, which AGI interprets as the end of words. In most cases, this will happen without the player ever even knowing, because there is almost always a zero value (0x00) byte in the OBJECT file's header. That byte will cause the word search to end.

Even in the unlikely event that you have more than 85 inventory items (which means the header WON'T have a zero value byte), it would be even more unlikely that the rest of the OBJECT file header and item data would contain the exact characters needed to create a false word match before a zero value is eventually encountered.

I don't know the exact algorithms, but I would not be surprised if NAGI and SCUMMVM ignore the trailing null character; they most likely use array indices to keep track of the end of the word list (this is just speculation on my part though).

So, technically, you could have a WORDS.TOK file without the null character at the end, it will work 99.99999% of the time. But it's better to have that ending character, so WinAGI enforces it.

Thanks for the detailed explanation, you've convinced me
Can you add that trailing zero to WinAGI help's description of WORDS.TOK format?

And does anyone here have write permission to http://agi.sierrahelp.com/Documentation/Specifications/8-2-WORDS_TOK.html and can update it there?
Or maybe there is somewhere more updated copy?

8

AGI Development Tools / Re: conWAGI.exe output redirection fails

« Last post by Kawa on May 03, 2021, 01:35:18 PM »

This looks promising: http://www.vbi.org/Items/article.asp?id=4

9

AGI Development Tools / Re: conWAGI.exe output redirection fails

« Last post by AGKorson on May 03, 2021, 12:07:58 PM »

Console apps are not my strong suit. There's probably a compile switch that is needed to allow output redirection? Or maybe I'm supposed to include something in the source code to enable it? I don't know for sure.

I'll add it to the bug list, but unfortunately, it will be way down at the bottom.

10

AGI Development Tools / Re: Should WORDS.TOK have even number of bytes?

« Last post by AGKorson on May 03, 2021, 12:05:04 PM »

The trailing zero is required. That's how the word search function knows it's reached the end of the file. If you strip that off, the word search function will continue looking at data from the heap that immediately follows the words.tok file (the OBJECT file), thinking it's valid word data; eventually, a null value will be found, which AGI interprets as the end of words. In most cases, this will happen without the player ever even knowing, because there is almost always a zero value (0x00) byte in the OBJECT file's header. That byte will cause the word search to end.

Even in the unlikely event that you have more than 85 inventory items (which means the header WON'T have a zero value byte), it would be even more unlikely that the rest of the OBJECT file header and item data would contain the exact characters needed to create a false word match before a zero value is eventually encountered.

I don't know the exact algorithms, but I would not be surprised if NAGI and SCUMMVM ignore the trailing null character; they most likely use array indices to keep track of the end of the word list (this is just speculation on my part though).

So, technically, you could have a WORDS.TOK file without the null character at the end, it will work 99.99999% of the time. But it's better to have that ending character, so WinAGI enforces it.