Messages

16

The Games and other Sierra Adventure stuff / Re: I just wanted to record some MIDI...

« on: September 29, 2020, 06:51:01 PM »

Who is Ravi Iyengar?

Looking at his comments, I see now that the data are already in MIDI format. OMG, it's been 15+ years since I studied MIDI when I was looking at AGI sounds! I didn't recognize it at first.

The actual music is stored in a series of events. The generic form for an event is:

<delta time> [byte - status] [byte - p1 [p2]]

Delta time is the number of ticks to wait after executing the previous event before executing this event. Ticks occur at 60 Hz. The delta time value is usually a single byte. However, longer delays can be produced by using F8h any number of times before the delta time value. Each F8h byte causes a delay of 240 ticks before continuing playback. For example, the sequence F8 F8 78 FC waits 600 ticks then stops the sequence because of the FCh status. The fact that F8h waits F0h ticks makes me think that E9h is the largest technically allowable delta time.

The number of ticks per second is defined by the MIDI header, and can be any number. Do all SCI MIDI sounds use the same value of 60 Hz? It sounds like that's Ravi's assumption. Unless there's a definitive specification statement from Sierra saying that's true, it's probably not wise to just assume it's so. Should be easy enough to confirm for any given sound resource though.

Also, Ravi is incorrect in how he's interpreting delta time. Delta time is passed as a 'variable-length' value, meaning it can be 1,2,3 or more bytes long depending on how large the time value is. The value is broken up into 7-bit chunks; each chunk is passed as a byte, with the most significant bit set to indicate that there is another chunk to follow. The last chunk has its most significant bit cleared. To actually get 600 ticks, the bytes passed would be  0x84, 0x58. His example of 0xF8, 0xF8, 0x78 would actually give a delta time of 1,981,560 ticks.

Again, that's assuming the data are really in true MIDI format. If so, then based on Ravi's explanation of track events, I still wonder if the tools are converting the sound data correctly.

17

The Games and other Sierra Adventure stuff / Re: I just wanted to record some MIDI...

« on: September 29, 2020, 10:37:54 AM »

it's well known that the original tools used to convert AGI sounds to MIDI had a timing issue as well. They used a tick duration of 1/64 sec instead of the correct value of 1/60 sec. Is it possible that a similar error exists in the SCI tools? That equates to an error rate closer to 6%.  IDK how sounds are stored in SCI resources, and/or converted to MIDI so this might not be relevant.

18

SCI Development Tools / Re: SCI Companion V3 - alpha build notes/bugs/feature requests

« on: September 25, 2020, 06:39:30 PM »

 DISCLAIMER: I'm an AGI guy, and have never used any of the SCI tools, so this may be of no help at all!

Renaming is probably not the hardest thing to do. In WinAGI, that functionality has been around for awhile now. If you change resource IDs, or rename globally defined variables, it will automatically update all your source code. CosmicR is right that it's more than just find/replace text; you have to find/replace tokens. Whole word search is not the answer, because that will also grab words in strings, words in comments, etc.

I didn't have anything like the Crystal Edit control available in VB, so I wrote my own custom control for the text editor. I figured out it wasn't too hard to add token search (as opposed to word search) by using an approach similar to what the parser uses when it compiles the source. I imagine something similar could be added to your SCI editor - a custom find/replace token function that uses a similar strategy to the compiler to identify tokens.

19

AGI Development Tools / Re: NAGI is not working properly on Windows 10

« on: August 27, 2020, 11:48:50 AM »

SDL2.DLL is not drop-in compatible with SDL.DLL. You likely wouldn't even get an application window if you tried.

I didn't even think of that, thx for pointing it out. I've been doing some reading on SDL to see if I can use it in next version of WinAGI. Obviously I still have a lot to learn! 

20

AGI Development Tools / Re: NAGI is not working properly on Windows 10

« on: August 24, 2020, 03:16:56 PM »

The most recent version of SDL is 2.0.12. NAGI was built using an earlier version.. The SDL wiki says that there are a lot of changes from SDL1 to SDL2, specifically in the graphics area that are not backwards compatible. It could be that notebook has SDL2 on it, but your desktop has SDL1.

21

AGI Community How To's & Tutorials / Creating a Custom Status Line

« on: June 24, 2020, 05:03:00 AM »

I got asked by a new user for help with creating a custom status line, as part of an effort to translate AGI games into other languages.  I thought I'd post my reply here in case anyone else has the same question.

It's not too tough to create a custom status line, but there are a few things that you need to consider to have your custom status bar behave exactly the same as the built in one.

To start with, you need a way to let AGI know whether or not you want the status line to show up or not. A flag is the obvious choice - say fStatusOn. 

With this flag, you can add code that runs in every interpreter cycle that uses the display() command to show your custom status line when fStatusOn is set, or clear it when the flag is not set.

While this is a good start, you will find that your status line will flicker, because it gets drawn in every cycle, even when there are no changes. To solve this, a second flag, fUpdateStatus, can be used to control when to draw the status line.  You can check this flag, and then only display or remove the status line when fUpdateStatus is true.

When you do need to update the status line (for example, score has changed), set fUpdateStatus to true.

This solves the flickering problem. And the result will work almost exactly the same as the built in status line. But there are still a couple more things you need to do to handle a few edge cases.

The first is dealing with the menu. When the menu.input() command is called, AGI will display the menu at the start of the next interpreter cycle. Assuming your menu is on the same line as your status line (as is the case with almost all Sierra AGI games), it will overwrite your status line. After dismissing the menu, your status line is erased. The way to solve this is to use fUpdateStatus after the menu.input() command. To reduce flickering, you also should place your code that draws your status line BEFORE the menu.input() command.

The second thing to consider is any code that implements the text mode. That would be the status() and text.screen() commands. You will need to force your status line to redraw after either of these commands run, because your status line will get erased when AGI switches modes.

A sample logic is attached that contains code (with lots of comments) that demonstrates this. Using this approach, you can create your own status line that is as complex or as simple as you like.

22

AGI Development Tools / Re: WinAGI Version 1.2.5

« on: May 14, 2020, 11:06:18 AM »

OK. I'll send you a PM with a test app.

23

AGI Development Tools / Re: WinAGI Version 1.2.5

« on: May 13, 2020, 01:28:04 AM »

Definitely very strange. All other file operations use lowercase file extensions, so maybe that is the problem. I could try using "words.tok" (lower case) as the filename.

I can build a small test app that tries opening/closing a file with different versions of the file name and extension (upper, lower, title) - if you could run that, it would least confirm or reject the hypothesis that it's related to file extension case. Let me know if you're interested in testing.

24

AGI Development Tools / Re: WinAGI Version 1.2.5

« on: May 11, 2020, 01:24:08 PM »

OK, that message is the WinAGI generated error message. That confirms what I thought was happening; something is maintaining an open file handle to WORDS.TOK, preventing it from being deleted.

I went through all the code again, line by line; there is just no place in WinAGI where that file is opened for longer than three lines of code; it gets opened, data copied to memory, then closed before anything else happens. It's the same process used for all files, including VOL files, DIR files, and OBJECT, also individual resource files. I can't explain why it would behave differently for WORDS.TOK. I also feel confident that the only direct references to "WORD.TOK" are all upper case; there's nowhere in code where it's referred to by lower case letters. I will continue to look to see if I'm missing something - there is a lot of code to look through.

Are you seeing any problems with updating/modifying any other game files? Can you make changes to OBJECT? What about a full recompile? Does that rewrite all the game files correctly?

25

AGI Development Tools / Re: WinAGI Version 1.2.5

« on: May 10, 2020, 01:21:55 PM »

That's certainly odd. To be clear, the error you got was "WORDS.TOK compile error(55: File already open)"? if it was formatted differently then it's not coming from WinAGI.

The compile (save) function for WORDS.TOK is not complicated; it creates a temporary file, adds the content, then replaces the existing WORDS.TOK file with the newly created temporary file.

If the existing WORDS.TOK file has an open handle, then the OS can't delete it in order to copy over the new file. That seems to be what you are experiencing. But WinAGI doesn't hold the WORDS.TOK file open - when the file is loaded for any reason (editing, previewing, etc) it opens the file, extracts the data to memory, then immediately closes the file.

So I don't know why the file has an open handle. If you are doing something else with it (maybe it's selected in a file explorer?) that may be holding it open. Is there anything else you were doing with any of the game files when this happened?

I'm pretty sure it's not being held open within WinAGI. There is literally only one place where a file handle is opened for WORDS.TOK - in the Load function - and it only opens it long enough to copy the file data into memory. Also, even if there was an error on opening, the error handler makes sure the file is closed and the handle released.

Oh, and regarding the .agw format, don't bother- it's basically a text dump of the words. Fifteen years ago, when I first made this program, I had this idea of creating an updated AGI interpreter, that would support improved graphics, sound, mouse support, etc. I've long since given up on that idea. The alternate formats for words and inventory objects were one of the first things I played around with. I left them in, but they really don't have any useful purpose, other than providing a human-readable version of words and objects.

26

AGI Development Tools / Re: AGI2HD Picture Redrawing Script Creator

« on: April 22, 2020, 03:17:54 PM »

Oops! 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! 

27

AGI Development Tools / Re: AGI2HD Picture Redrawing Script Creator

« on: April 22, 2020, 12:32:30 PM »

@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

28

AGI Syntax Help / Re: AGI and changing font

« on: March 07, 2020, 05:21:36 PM »

I tried out the latest version of WinAGI - great AGI-ide. One thing though - I want to localize some strings in my Kings Quest translation with non ASCII like ?,?,?, Is this possible with an AGI-game, and how do i do it - with WinAGI if possible. Thankful for any help.

As of now, YES, it is possible. See this thread for an explanation and source code to do it.

29

AGI Community How To's & Tutorials / Re: AGI CAN support Extended Characters

« on: March 07, 2020, 04:55:55 PM »

It was much easier than I thought to include character 80h. It only takes a couple tweaks to have AGI use character ffh (which is nonprintable anyway) instead of character 80h to manage shading and inverting. Here's a revised logic that does that.

So ALL printable characters are now available ALL the time for ALL foreground/background/shading combos.

Enjoy.

30

AGI Community How To's & Tutorials / AGI CAN support Extended Characters

« on: March 07, 2020, 02:30:02 PM »

I've been experimenting more with the use of the StringHack to improve AGI's functionality. For those of you who wish to use extended characters in messages (for example, French or Spanish), I have written a logic that will modify how AGI displays characters so that the extended characters display correctly.

All you need to do is add the logic (see next post, below) to your game, and run it once when the game first loads. After that, all characters, including extended characters will display correctly in print() messages.

Here's some sample output to see it in action:






A couple of caveats:

• this will ONLY work with the original DOS interpreter (through DOSBOX or running on native DOS system); it won't work with NAGI, SCUMMVM or any other modern interpreter.
• this will ONLY work with AGI interpreter verison 2.917. Each version has slightly different addresses for its internal functions; this logic is hard coded to version 2.917. (If you want to use this on a different interpreter version, let me know; I can help you tweak it so it works).
• There is one character, 0x80 (which is a capital 'C' with cedilla[that's the squiggly tail]) that won't display; it will always show as a black box. This is because AGI uses that code to manage the shading and inversion of characters on menus; the code needed to fix that is too complicated (at least for now). All other extended characters display correctly.no longer a restriction; see post below

Finally, WinAGI v1.2.7 is the only dev environment that supports the use of extended characters while authoring a game. Use CTRL+INSERT to display a popup window in the logic editor to insert any extended character. You can also use "\x" codes to insert hexadecimal characters (which is what I typically do when using string hacks; it's just easier to read and manage code).