16
SCI Development Tools / Re: SCICompanion: Is there a way to import the priory and control screens also?
« on: January 11, 2024, 02:02:35 PM »
Unfortunately, no. At least not that I know of.
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.
17
The Games and other Sierra Adventure stuff / Re: Japanese KQ7 Intro on YouTube
« on: November 07, 2023, 09:28:28 AM »
This is so cool. All the music has been rerecorded on a completely different synth than the English original's version for this dub!
18
SCI Syntax Help / Re: How does EcoQuest 1 allow to enter any code and not just the copy protected one?
« on: October 14, 2023, 11:35:42 AM »Before Companion 3 there were no decompilers. Brian had hand decompiled an SCI game (LSL2?) to make the original fan SCI template game and create his SCI Studio script.
It was LSL3.
19
SCI Community How To's & Tutorials / Re: How to easily convert SCI patches to ScummVM?
« on: October 14, 2023, 11:30:52 AM »Just because there's a deep and passionate community around DOSBox doesn't mean fluent commits are the same as stable versions.
While they are the same for "insiders", most population doesn't look behind stable versions which is why for example Wikipedia first and foremost mentions the last stable date.
[citation needed]
(speaking of Wikipedia)
Also, it doesn't matter what version or flavour of DOSBox you use (and there are many that are under active development, btw, and always will be), SCI games will work on all of them (old or new).
20
SCI Community How To's & Tutorials / Re: How to easily convert SCI patches to ScummVM?
« on: September 27, 2023, 08:38:41 AM »Either way by now most people will only use built-in patches
Yeah I'm gonna go ahead and disagree with you on that. I don't get your premise of thought process here. If people aren't going to know to go download patch files for their games how would you changing the ScummVM source code improve those chances when your code wouldn't be put into the main branch? Or are you pursuing having your SVM script patches actually added to the main branch?
And again, half the people who play Sierra games don't use ScummVM.
Quote
(in distribution or also inside ScummVM).
In distribution? In distribution of what? The easiest way to distribute is with replacement script files.
21
SCI Development Tools / Re: General MIDI vs MT-32
« on: September 19, 2023, 12:06:17 AM »
Pretty much every game using SCI1.1 and up was composed for General MIDI (SC-55 particularly) with MT-32 support added as an afterthought with a General MIDI-esque patch map. There are only a small few exceptions to this. Two being:
Those are the only two I ever remember offhand that were composed for the MT-32 and General MIDI was added later and the game itself was released in SCI1.1 (may have started out life as SCI1.0 games). If there are more there aren't many. SC-55 quickly took over and MT-32 was left in the dust, to sometimes less than appealing results.
SQ4CD has the same sound files from SQ4 floppy. It uses a special driver that remaps the MT-32 instruments to General MIDI on the fly (and it doesn't do a very good job as many instruments are missing, including drum kits).
KQ5CD is interesting in that it's SCI1.0, but it has a Windows interpreter which means it must also support General MIDI (specifically Extended and Base MIDI). As such, every sound file numbered 1000 and up are GM Ext/Base MIDI duplicates of the MT-32 sounds numbered under 1000. (incidentally, SQ4CD also does this for its Windows version)
SQ5 was made by Dynamix who used their own General MIDI MT-32 patch map with slightly better results than Sierra's.
Eco Quest 1 was released on both SCI1.0 and SCI1.1. The SCI1.0 version obviously supports only MT-32 (logically) so that's what it was composed for.
QFG1VGA uses the MT-32 sound files from the original game but also had new music written for it that's not in the EGA original. I'm unsure at the moment if these pieces were composed with the MT-32 or General MIDI. My guess is the latter.
That's all the edge cases I can think of right now. Basically, if it started life as an SCI1.0 game then it was composed for the MT-32. This is mostly obvious except in PQ1VGA's and LB2's cases.
Also, it may interest some here that on the Space Quest Historian Discord server we've started a community Google spreadsheet to chart every MIDI sound file in all the SCI games. The purpose being to identify which sound resources are which themes to make it easier to pick out the themes you're looking for easier. It's a community spreadsheet which means anyone can help go through the resources with SCI Viewer or Companion, listen to each resource, and mark down the song titles for each game. For bonus points, you can search the decompiled game scripts to find which scripts trigger each sound file. We've got a few games completed already for reference. You can also see in SQ4CD and KQ5CD's cases where the Windows duplicate sound resources start. It also lists for each game which device it was composed with/sounds best on.
https://docs.google.com/spreadsheets/d/1ECMTncmqfG__6lY5v5v1JhkviC8pxW_v0sX_ILwS-ZI/edit?usp=sharing
- Police Quest 1 VGA
- Laura Bow 2
Those are the only two I ever remember offhand that were composed for the MT-32 and General MIDI was added later and the game itself was released in SCI1.1 (may have started out life as SCI1.0 games). If there are more there aren't many. SC-55 quickly took over and MT-32 was left in the dust, to sometimes less than appealing results.
SQ4CD has the same sound files from SQ4 floppy. It uses a special driver that remaps the MT-32 instruments to General MIDI on the fly (and it doesn't do a very good job as many instruments are missing, including drum kits).
KQ5CD is interesting in that it's SCI1.0, but it has a Windows interpreter which means it must also support General MIDI (specifically Extended and Base MIDI). As such, every sound file numbered 1000 and up are GM Ext/Base MIDI duplicates of the MT-32 sounds numbered under 1000. (incidentally, SQ4CD also does this for its Windows version)
SQ5 was made by Dynamix who used their own General MIDI MT-32 patch map with slightly better results than Sierra's.
Eco Quest 1 was released on both SCI1.0 and SCI1.1. The SCI1.0 version obviously supports only MT-32 (logically) so that's what it was composed for.
QFG1VGA uses the MT-32 sound files from the original game but also had new music written for it that's not in the EGA original. I'm unsure at the moment if these pieces were composed with the MT-32 or General MIDI. My guess is the latter.
That's all the edge cases I can think of right now. Basically, if it started life as an SCI1.0 game then it was composed for the MT-32. This is mostly obvious except in PQ1VGA's and LB2's cases.
Also, it may interest some here that on the Space Quest Historian Discord server we've started a community Google spreadsheet to chart every MIDI sound file in all the SCI games. The purpose being to identify which sound resources are which themes to make it easier to pick out the themes you're looking for easier. It's a community spreadsheet which means anyone can help go through the resources with SCI Viewer or Companion, listen to each resource, and mark down the song titles for each game. For bonus points, you can search the decompiled game scripts to find which scripts trigger each sound file. We've got a few games completed already for reference. You can also see in SQ4CD and KQ5CD's cases where the Windows duplicate sound resources start. It also lists for each game which device it was composed with/sounds best on.
https://docs.google.com/spreadsheets/d/1ECMTncmqfG__6lY5v5v1JhkviC8pxW_v0sX_ILwS-ZI/edit?usp=sharing
22
SCI Development Tools / Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« on: August 20, 2023, 02:49:15 PM »It took some digging, but I found the problem with the sound previewer. I am right now chilling to the Tandy 3-Voice version of the Space Quest 3 theme, playing from the preview bar. I also went and normalized all user-visible instances of "midi" and "Midi" to "MIDI" while I was at it, correcting that "unknown" to "Base MIDI".
All this will be in the upcoming nightly.
Nice!
23
Everything-Else / Re: MIDI 2.0
« on: July 30, 2023, 04:20:08 PM »
Ah it's finally coming out. MIDI 2.0 has been in development/planning stages for YEARS. So long I stopped waiting for it.
24
SCI Development Tools / Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« on: July 30, 2023, 04:07:25 PM »
So I made a discovery today while perusing the SQ4CD sound resources that I wanted to share (unless someone else already knew this). We know that some early games doubled the sound resources for Windows starting with resource numbers 1000 and up (like KQ5CD and SQ4CD). The scripts add 1000 to the sound resource calls if running in the Windows interpreter. There are two "music devices" flagged in these sound resources much like the music devices in DOS (for PC Speaker, Tandy, Adlib, MT-32, etc). In the Windows resources it uses two flags. Flag $07 is for "Extended MIDI" (which uses MIDI channels 1-10) and flag $0b is for "Base MIDI" (which uses MIDI channels 13-16).
You probably well know that Extended MIDI and Base MIDI aren't something we deal with now, but in early Windows and the early days of GM and synth hardware/keyboards there were MIDI devices that used either only Extended or only Base as their implementation. Base puts percussion on channel 16 instead of 10. When installing Windows versions of Sierra games the setup utility outright asks you if you have extended or base MIDI and depending on which one you select it will save configuration to make the Windows interpreter use the appropriate "device". This is why the Windows resources are separate from the DOS resources because there aren't enough channels to delegate to share with PC Speaker, Tandy, Adlib, MT-32, etc and General MIDI Extended and General MIDI Base.
Now, if you inspect these sound resources you'll notice that the "Base MIDI" music device actually flags channel 11 for the percussion and not 16. Why? Because (in SCI sound resources) channel 16 is reserved for cue and loop data as well as program changes and other MIDI controllers and can't be used for melody. So the Windows interpreter must take the percussion MIDI notation from channel 11 and remap it to channel 16 on output when it's configured for Base MIDI.
So in light of that, we come to my feature suggestion. Currently device flag $07 in Companion is defined as "General MIDI" while $0b is defined as "Unknown" (in the SCI Sound driver dropdown menu when previewing/editing sounds). I propose changing the label for $07 to "General MIDI / Extended MIDI" and $0b to "Base MIDI" in those dropdown menus since we now know what they're for.
I'd also like to report an issue where when selecting an SCI Sound driver device in the dropdown menu of Game Explorer when previewing sound resources (not opening them in the sound editor), the selected device seems to be ignored when playing back. It doesn't do this in the sound editor, it seems to work properly there. I'm not sure if this is an old bug that's since been fixed or if we just never noticed it before.
You probably well know that Extended MIDI and Base MIDI aren't something we deal with now, but in early Windows and the early days of GM and synth hardware/keyboards there were MIDI devices that used either only Extended or only Base as their implementation. Base puts percussion on channel 16 instead of 10. When installing Windows versions of Sierra games the setup utility outright asks you if you have extended or base MIDI and depending on which one you select it will save configuration to make the Windows interpreter use the appropriate "device". This is why the Windows resources are separate from the DOS resources because there aren't enough channels to delegate to share with PC Speaker, Tandy, Adlib, MT-32, etc and General MIDI Extended and General MIDI Base.
Now, if you inspect these sound resources you'll notice that the "Base MIDI" music device actually flags channel 11 for the percussion and not 16. Why? Because (in SCI sound resources) channel 16 is reserved for cue and loop data as well as program changes and other MIDI controllers and can't be used for melody. So the Windows interpreter must take the percussion MIDI notation from channel 11 and remap it to channel 16 on output when it's configured for Base MIDI.
So in light of that, we come to my feature suggestion. Currently device flag $07 in Companion is defined as "General MIDI" while $0b is defined as "Unknown" (in the SCI Sound driver dropdown menu when previewing/editing sounds). I propose changing the label for $07 to "General MIDI / Extended MIDI" and $0b to "Base MIDI" in those dropdown menus since we now know what they're for.
I'd also like to report an issue where when selecting an SCI Sound driver device in the dropdown menu of Game Explorer when previewing sound resources (not opening them in the sound editor), the selected device seems to be ignored when playing back. It doesn't do this in the sound editor, it seems to work properly there. I'm not sure if this is an old bug that's since been fixed or if we just never noticed it before.
25
SCI Syntax Help / Re: [SOLVED] SCI0 - Autosave
« on: July 13, 2023, 10:26:49 AM »
ScummVM does allow the original save GUI but it grays out the Change Directory button.
Aldo, in Ryan's case it's a SCI0 game so debug is built in.
Aldo, in Ryan's case it's a SCI0 game so debug is built in.
26
SCI Development Tools / Re: Everybody drop everything and see this (100% SCI decompiled sources!)
« on: July 13, 2023, 10:22:27 AM »
Is that why the PQ2 intro with the highway was always so fast?
27
SCI Development Tools / Re: Everybody drop everything and see this (100% SCI decompiled sources!)
« on: July 05, 2023, 09:31:15 PM »
Nice finetuning there!
28
SCI Development Tools / Re: Everybody drop everything and see this (100% SCI decompiled sources!)
« on: July 05, 2023, 10:54:15 AM »I noticed the repo this morning. So this is what that's all about.
(There's no way he wrote his decompiler...)
Why the skepticism? He's one of the main SCI ScummVM devs.
29
SCI Development Tools / Everybody drop everything and see this (100% SCI decompiled sources!)
« on: July 05, 2023, 08:32:22 AM »
Sluicebox, a ScummVM developer, has created his own SCI decompiler that now can 100% decompile scripts (including blocks of code that up until now have currently fallen back to assembly) and also added commented annotations within the source to describe what each object is and what it does. It also puts strings from messages as inline comments so you can more easily see what's going on at a glance. I can't wait to play with this later tonight!
https://www.benshoof.org/blog/sci-scripts
Here's OneShortEye's video which just broke the news. SluiceBox has been working very closely with the Sierra speedrunning community to diagnose certain exploit behaviour etc. This is wonderful news!!
NOTE: He doesn't supply the decompiler itself, but he has shared all of the 100% complete decompiled sources for every version of every SCI game that he could get his hands on. He didn't create his decompiler in C++ so it's not compatible with SCI Companion, at least in its current state. But maybe we can convince him to release the source anyway and someone brave enough can adapt it
. There are a few other caveats he goes over in the article as well. One namely being that there might be a couple bugs that won't compile but could be fixed by going over the code. There was also something he said about a holdover bug from Sierra's original compiler.
https://www.benshoof.org/blog/sci-scripts
Here's OneShortEye's video which just broke the news. SluiceBox has been working very closely with the Sierra speedrunning community to diagnose certain exploit behaviour etc. This is wonderful news!!
NOTE: He doesn't supply the decompiler itself, but he has shared all of the 100% complete decompiled sources for every version of every SCI game that he could get his hands on. He didn't create his decompiler in C++ so it's not compatible with SCI Companion, at least in its current state. But maybe we can convince him to release the source anyway and someone brave enough can adapt it
. There are a few other caveats he goes over in the article as well. One namely being that there might be a couple bugs that won't compile but could be fixed by going over the code. There was also something he said about a holdover bug from Sierra's original compiler.Quote
Maybe! If SCI Companion fully supports the game, then it can compile most scripts. You may need to fix a Sierra bug or two, or make some other adjustments to make SCI Companion happy. My goal is to show what's really going on in the scripts, bugs and all.
30
SCI Community News / Re: Mega Tokyo Archive for AGI and SCI Finally Live
« on: June 15, 2023, 07:25:00 PM »
SMF 2.0.19 |
SMF © 2021, Simple Machines
Simple Audio Video Embedder
Page created in 0.045 seconds with 19 queries.