1
AGI Development Tools / Re: Sierra had keys to control sound volume in Tandy
« on: April 05, 2021, 10:51:02 PM »
Cool, thx. I'll include this in the next update of the help file.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
2
AGI Development Tools / Re: Sierra had keys to control sound volume in Tandy
« on: April 05, 2021, 12:28:18 AM »
I think this is pretty much well known in the AGI community. Support for volume control has been included in template games going back to the early AGI Studio days.
I have not tested on original hardware, but using DOSBox, (while writing the first versions of WinAGI) I confirmed that both PCJr and Tandy do in fact control sound by using reserved variable v23. I assume that the DOSBox implementation of the Tandy and PCJr machines is accurate. You can easily test this by creating a template game, and set platform to DOSBox, and then use platform command line switch option to use "-machine pcjr" or "-machine tandy". I never had access to any other platforms or game files for testing (Amiga, Apple, Atari, PS2), so I only included information that I learned from other sources, mostly from the source code provided here over the years.
I don't know for certain if any Sierra games included sound volume control for any machine types other than Tandy, but as I said, I do know it works for PCJr as well. I would assume it would also work for some of the other platforms, but again, I've never been able to test it.
I have never heard of machine type 20 being referred to as 'AmigaOld'; that's a new one to me. (I never spent a lot of time with ScummVM; I always preferred NAGI when I needed a modern AGI engine (and I usually prefer to use the original Sierra binaries in DOSBox anyway). If someone has some more definitive information to confirm it, I don't mind adding it to the help file for completeness.
As far as differences between Tandy and 'regular PC', the binary files are the same; when AGI loads on either platform, after determining the type of machine its running on, the same graphics overlays get loaded for both machines; in the binaries, there are separate functions in various places where graphics are handled that use the appropriate video control codes and interrupts to correctly display images. But at the AGI resource level, there are no differences. Sound is handled the same way; internally, the interpreter uses different functions to handle playback of sound depending on which machine type is present even though the same program and overlay files are used on both systems.
It is strange that they (Sierra) didn't include the sound controls in their help screens. The template files do.
I have not tested on original hardware, but using DOSBox, (while writing the first versions of WinAGI) I confirmed that both PCJr and Tandy do in fact control sound by using reserved variable v23. I assume that the DOSBox implementation of the Tandy and PCJr machines is accurate. You can easily test this by creating a template game, and set platform to DOSBox, and then use platform command line switch option to use "-machine pcjr" or "-machine tandy". I never had access to any other platforms or game files for testing (Amiga, Apple, Atari, PS2), so I only included information that I learned from other sources, mostly from the source code provided here over the years.
I don't know for certain if any Sierra games included sound volume control for any machine types other than Tandy, but as I said, I do know it works for PCJr as well. I would assume it would also work for some of the other platforms, but again, I've never been able to test it.
I have never heard of machine type 20 being referred to as 'AmigaOld'; that's a new one to me. (I never spent a lot of time with ScummVM; I always preferred NAGI when I needed a modern AGI engine (and I usually prefer to use the original Sierra binaries in DOSBox anyway). If someone has some more definitive information to confirm it, I don't mind adding it to the help file for completeness.
As far as differences between Tandy and 'regular PC', the binary files are the same; when AGI loads on either platform, after determining the type of machine its running on, the same graphics overlays get loaded for both machines; in the binaries, there are separate functions in various places where graphics are handled that use the appropriate video control codes and interrupts to correctly display images. But at the AGI resource level, there are no differences. Sound is handled the same way; internally, the interpreter uses different functions to handle playback of sound depending on which machine type is present even though the same program and overlay files are used on both systems.
It is strange that they (Sierra) didn't include the sound controls in their help screens. The template files do.
3
AGI Development Tools / Re: WinAGI Version 2.1.10
« on: April 02, 2021, 11:10:43 AM »
Unfortunately, I know very little about SCI games. I spend enough time studying AGI, and have never had the time or interest to delve into the world of SCI.
As for converters, I'm not sure what exactly you mean. WinAGI is able to extract both MIDI and PCM sounds from IIgs games, which you can then export (i.e. convert) to the corresponding modern format. I admit that I don't have definitive answers as to exactly what each byte of data means in the sound headers, but using the assumptions I made, all IIgs sounds I've extracted sound legitimate. Here are my notes on both sound types, and how WinAGI handles them for doing the extraction:
I figure it's a good idea to make this public information so others who are interested or are working on this can compare notes and (hopefully) improve on it.
Maybe this will be of use to you? Let me know if you become aware of any further information, especially if it affects how to correctly extract and convert the sounds for true replication. That way I can update WinAGI as well.
As for converters, I'm not sure what exactly you mean. WinAGI is able to extract both MIDI and PCM sounds from IIgs games, which you can then export (i.e. convert) to the corresponding modern format. I admit that I don't have definitive answers as to exactly what each byte of data means in the sound headers, but using the assumptions I made, all IIgs sounds I've extracted sound legitimate. Here are my notes on both sound types, and how WinAGI handles them for doing the extraction:
Code: [Select]
' IIgs MIDI sounds:
' this function extracts the raw MIDI data from the IIgs sound
' and creates a new MIDI stream that is compatible with modern
' MIDI player format
' length value gets calculated by counting total number of ticks
' assumption is 60 ticks per second; nothing to indicate that is
' not correct; all sounds 'sound' right, so we go with it
' the raw midi data embedded in the sound seems to play OK
' when using 'high-end' players (WinAmp as an example) but not
' Windows Media Player, or the midi API functions; even in
' WinAmp, the total sound length (ticks and seconds) doesn't
' calculate correctly, even though it plays;
' this seems to be due to the presence of 0FCh commands
' it looks like every sound resource has them; sometimes
' one 0FCh ends the file; other times there are a series of
' them that are followed by a set of 0Dyh and 0Byh commands
' that appear to reset all 16 channels
' eliminating the 0FCh command and everything that follows
' plays the sound correctly (I think)
' a common 'null' file is one with just four 0FCh codes, and
' nothing else, so ANY file starting with 0FCh is considered empty
' time values are supposed to be a 'delta' value
' but it appears that AGI used an absolute value; so if time
' is greater than 07Fh, it will cause a hiccup in modern midi
' players (we need to convert them to a valid delta time value)
' treat 0FCh as an end mark, even if found in time position
' 0F8h also appears to cause an end
' IIgs PCM (wav file) sounds:
' this function extracts the raw PCM data from a IIgs sound and
' adds a properly formatted WAV file header to it
' AGI header is 54 bytes for pcm, but its purpose is still mostly
' unknown; the total size is a word value at positon 08h; the rest of
' the header appears identical across resources, with exception of
' position 02h- it seems to vary from low thirties to upper 60s,
' maybe it's a volume thing?
' at position 06h is a word value of 02Ch = 44; this might be size
' of an internal header; there are 44 bytes of data, followed
' by 00-00 before the raw pcm data starts? (probably not - because at
' position 02Ah, there are six word values; 0C07Fh, 0236h, 0000h,
' 0C07Fh, 0236h, 0000h; this has the feel of two channel info,
' where both channels use the same data; 0C07Fh=49279; 0236h=566;
' 0C0h=192; 07F=127; 036h=54 not sure if any of these values
' are significant)
' at position 022h, there is a word value of 0203h = 8195; this
' might be the actual sample rate? it's close to 8000 (which was my
' original assumption) and it's really hard to tell the difference when either
' value is used for the exported sound
' all resources appear to end with a byte value of 0; not sure
' if it's necessary for wav files, but we keep it anyway
I figure it's a good idea to make this public information so others who are interested or are working on this can compare notes and (hopefully) improve on it.
Maybe this will be of use to you? Let me know if you become aware of any further information, especially if it affects how to correctly extract and convert the sounds for true replication. That way I can update WinAGI as well.
4
AGI Development Tools / Re: WinAGI Version 2.1.10
« on: March 30, 2021, 10:55:55 AM »
That's a tough one. I know very little about Apple IIgs and how AGI actually works on that platform. I do have the binary files, and if I could find a decent dissassembler, I could probably figure it out. I did some searching, but haven't come across anything like IDAPro Free that would be useful. So unfortunately, I can't help much. I suspect there are some people out there who know more about Apple IIgs who might be able to answer that question for you.
5
AGI Development Tools / Re: WinAGI Version 2.1.10
« on: March 26, 2021, 10:50:12 AM »
You can use the export feature to extract those sounds. It's on the Resource menu. You can choose to export them as an AGI resource file, which keeps all the AGI formatting (you could then add them to another game if you wanted to), or you can export them as a MIDI/WAV file, depending on the type of sound.
Let me know if this helps, or if you still have questions.
Let me know if this helps, or if you still have questions.
6
AGI Development Tools / Re: WinAGI Version 2.1.10
« on: March 07, 2021, 05:11:13 PM »
I sent you a PM.
I found FastColoredTextBox a month or so ago. It's pretty impressive. I was able to modify it to handle extended characters properly, which is important for working with AGI logics. I haven't added it to my project yet, though. I want to get the core functions and preview features to a more stable state before I begin working on the resource editors. But certainly I'll be using FastColoredTextBox once I do build the logic editor.
I found FastColoredTextBox a month or so ago. It's pretty impressive. I was able to modify it to handle extended characters properly, which is important for working with AGI logics. I haven't added it to my project yet, though. I want to get the core functions and preview features to a more stable state before I begin working on the resource editors. But certainly I'll be using FastColoredTextBox once I do build the logic editor.
7
AGI Development Tools / WinAGI Version 2.1.10
« on: March 06, 2021, 02:29:37 AM »
The console mode that I added in version 2.1.6 was a bit of a hack, and I just couldn't leave it that way. So here's an update that includes a separate executable, conWAGI.exe for running a windowless console mode. It's a much cleaner implementation and it supports importing games (creating WinAGI game files from an existing AGI game) and all three compile options. (The main app also includes a couple minor bug fixes.)
You can get the latest version from the AGI wiki. Here's a direct link to the install file:
http://agiwiki.sierrahelp.com/images/8/8b/WinAGI_2_1_10.zip
I am still working on a C# version of WinAGI. I got the all the basic AGI library functions moved over, and have a working app that can display all resources. There are no resource editors or tools added yet, and it's not real stable; there are a ton of bugs, and it's easy to crash right now.
If anyone is interested, I guess I could share a link to the git files. Just don't make fun of my poor C# coding skills...
You can get the latest version from the AGI wiki. Here's a direct link to the install file:
http://agiwiki.sierrahelp.com/images/8/8b/WinAGI_2_1_10.zip
I am still working on a C# version of WinAGI. I got the all the basic AGI library functions moved over, and have a working app that can display all resources. There are no resource editors or tools added yet, and it's not real stable; there are a ton of bugs, and it's easy to crash right now.
If anyone is interested, I guess I could share a link to the git files. Just don't make fun of my poor C# coding skills...
8
AGI Development Tools / Re: WinAGI: feature request - don't write object names in decompilation
« on: March 06, 2021, 01:59:45 AM »
I found a couple bugs that I felt had to fixed, so I threw in this request at the same time. New version 2.1.10 is available here.
9
AGI Development Tools / Re: WinAGI: feature request - batch mode
« on: February 17, 2021, 12:58:24 PM »
One more bug I noticed, when using the /r or /d options, you don't get an error message if the game file doesn't load. Using the /c option does give you an error message when the game file doesn't load.
So you just have to be a bit more careful with the /r and /d options.
So you just have to be a bit more careful with the /r and /d options.
10
AGI Development Tools / Re: WinAGI: feature request - batch mode
« on: February 17, 2021, 12:11:23 PM »
Sorry - I didn't do a lot of testing, so there are a few 'glitches' you need to be aware of. I probably shouldn't have released this without doing extensive testing first. Oh well...
The second line is correct; you need to invoke WinAGI, then follow it with the switch '/d', and then your game file. It doesn't matter what directory you run it from, as long as the WinAGI executable is reachable (using the included directory information, or by using your DOS PATH environment variable). If the path to the executable includes spaces, the entire executable command needs to be included in quotes, as in your example.
BUT the game file argument MUST be quote-free. (The function that opens a game expects no quotes, and I forgot to make sure the argument passed from the command line was 'de-quoted' -
)
Also, you must include the full path to your game file (again, I didn't do a lot of testing, and didn't consider how it would work if a path was not included in the argument value).
So this should work for you:
Also keep in mind that if you configure WinAGI to use the Splash Screen at start up, you will get the GUI to load even if you use command lines; I didn't want to screw with the program initialization too much to get this to work, so I chose to process the command line AFTER reading the configuration file, which means you will get a splash screen if that setting is active. It's not a big deal though - the GUI automatically closes after the compile is done, or more simply, just disable the splash screen and you should be GUI free. (mostly...
)
I also discovered that if you run a command prompt window that uses elevated privileges, WinAGI doesn't read the game configuration file correctly, so you get the splash screen even if you've disabled it. I have no idea what's going on there. Just be aware of it.
I tested these instructions again this morning on a clean install, and it worked for me. So hopefully, once you get the syntax correct, you should be able to successfully run the compiler in whichever mode you want (c/d/r). If it succeeds, then the program will just terminate, with no exit code, and no output at all. If the compile fails, you should get one message box popup that tells you that. But it won't give a lot of detail. You will need to run the GUI to get a detailed explanation of why it can't compile.
The second line is correct; you need to invoke WinAGI, then follow it with the switch '/d', and then your game file. It doesn't matter what directory you run it from, as long as the WinAGI executable is reachable (using the included directory information, or by using your DOS PATH environment variable). If the path to the executable includes spaces, the entire executable command needs to be included in quotes, as in your example.
BUT the game file argument MUST be quote-free. (The function that opens a game expects no quotes, and I forgot to make sure the argument passed from the command line was 'de-quoted' -
)Also, you must include the full path to your game file (again, I didn't do a lot of testing, and didn't consider how it would work if a path was not included in the argument value).
So this should work for you:
Code: [Select]
"C:\Program Files (x86)\WinAGI GDS\WinAGI.exe" /d C:\Zvika\Games\AGI\PQ1.wagAlso keep in mind that if you configure WinAGI to use the Splash Screen at start up, you will get the GUI to load even if you use command lines; I didn't want to screw with the program initialization too much to get this to work, so I chose to process the command line AFTER reading the configuration file, which means you will get a splash screen if that setting is active. It's not a big deal though - the GUI automatically closes after the compile is done, or more simply, just disable the splash screen and you should be GUI free. (mostly...
)I also discovered that if you run a command prompt window that uses elevated privileges, WinAGI doesn't read the game configuration file correctly, so you get the splash screen even if you've disabled it. I have no idea what's going on there. Just be aware of it.
I tested these instructions again this morning on a clean install, and it worked for me. So hopefully, once you get the syntax correct, you should be able to successfully run the compiler in whichever mode you want (c/d/r). If it succeeds, then the program will just terminate, with no exit code, and no output at all. If the compile fails, you should get one message box popup that tells you that. But it won't give a lot of detail. You will need to run the GUI to get a detailed explanation of why it can't compile.
11
AGI Development Tools / Re: WinAGI: feature request - batch mode
« on: February 15, 2021, 10:25:50 PM »
Yeah, probably a good idea.
12
AGI Development Tools / Re: WinAGI: feature request - batch mode
« on: February 15, 2021, 01:52:38 PM »
It only gives you a message if it encounters an error. if you don't get any error message, then you know it compiled correctly.
This was the easiest way to implement the feature. Adding a logging feature would require more work than I currently have time for. I might take a look at it later, but I can't make any promises as to when.
This was the easiest way to implement the feature. Adding a logging feature would require more work than I currently have time for. I might take a look at it later, but I can't make any promises as to when.
13
AGI Development Tools / WinAGI Version 2.1.6
« on: February 14, 2021, 11:31:06 AM »
OK, here's an update that addresses a couple bugs found in 2.1.5 and also adds a couple requested features.
Link to install file
- Fixed bug in settings functions that would not save MsgByNumber value
- Added menu item and toolbar button to show character map dialog on logic and text editors
- Modified error messages when read-only files are encountered so it is more clear to user
- Added command line switches to compile games without running the user interface
- Modified the GameID property to allow lower case letters
Link to install file
- Fixed bug in settings functions that would not save MsgByNumber value
- Added menu item and toolbar button to show character map dialog on logic and text editors
- Modified error messages when read-only files are encountered so it is more clear to user
- Added command line switches to compile games without running the user interface
- Modified the GameID property to allow lower case letters
14
AGI Development Tools / Re: WinAGI: feature request - lower case GameID
« on: February 13, 2021, 02:25:29 PM »
Ah, I see. I kind of like leaving it all upper case, but I suppose it doesn't really matter. I'll see if I can include this option in the next fix.
15
AGI Development Tools / Re: WinAGI: feature request - lower case GameID
« on: February 12, 2021, 10:44:41 PM »
Hmm, I guess I could. Every Sierra game I know of uses all upper case for GameID (even though the check in the set.game.id function is in fact case sensitive). It's just one of those long standing traditions I guess.
I assume the ScummVM check is also case-sensitive? Meaning, if you use 'PQ1', ScummVM will think it's the original Sierra version? Why not just use 'PQ1H' or something like that? The GameID property isn't actually linked to the AGI game - you can set it to anything you want despite what the game logics actually use for the set.game.id command.
In the meantime, let look into what it will take to implement lower case GameIDs.
Oh, and I did drop a comment on your pull request. Hope it helps.
I assume the ScummVM check is also case-sensitive? Meaning, if you use 'PQ1', ScummVM will think it's the original Sierra version? Why not just use 'PQ1H' or something like that? The GameID property isn't actually linked to the AGI game - you can set it to anything you want despite what the game logics actually use for the set.game.id command.
In the meantime, let look into what it will take to implement lower case GameIDs.
Oh, and I did drop a comment on your pull request. Hope it helps.
SMF 2.0.14 |
SMF © 2017, Simple Machines
Simple Audio Video Embedder
Page created in 0.09 seconds with 21 queries.