Author Topic: Hacking SQ1VGA with SCICompanion v3  (Read 2398 times)

0 Members and 1 Guest are viewing this topic.

Offline spiffythedog

Re: Hacking SQ1VGA with SCICompanion v3
« Reply #45 on: March 27, 2017, 05:31:38 AM »
Very nice!
Thanks!

Why is this patch not compatible with ScummVM? I can try to reach out to them and see if they're interested in importing those fixes directly into ScummVM.
Now that you mention it, the release version of the patch actually works rather well with ScummVM, barring a few niggles here and there (the intro is slow and out-of-sync, sometimes the screen doesn't shake when a rumbling is heard on the Arcada, the graphics for the new Warbird sequence completely glitch out, etc.). The last time I tested the patch-in-progress with ScummVM, the game would randomly display text from Sarien.sc as part of the background picture, but now that no longer happens. I've just reached the Deltaur, and so far the game seems entirely finishable.

As for the ScummVM developers importing the new fixes, I guess you could try, but it seems very unlikely that NRS would be willing to cooperate or provide any assistance if they reached any major roadblocks. NRS has made it very clear to me that his new fixes were designed entirely with DOS/DOSBOX in mind, and that he wants nothing to with ScummVM or its team. Which is fair enough: a great chunk of this patch is his work, and therefore his prerogative, which I will ultimately respect.

Also,
have you considered sharing your annotated scripts so the community can learn from it?
There were a few scripts that didn't compile properly with SCI Companion (causing weird anomalies during gameplay), which necessitated NRS to use some original developer tools in order to properly implement the new fixes. If we work our way backwards through our correspondence, we should be able to pinpoint which specific scripts got borked and what effects this produced. I'll just have to get in touch with NRS again.

Offline OmerMor

Re: Hacking SQ1VGA with SCICompanion v3
« Reply #46 on: March 27, 2017, 08:35:36 AM »
Non/badly compiling scripts are fine as well.
It could help troflip improve SCI companion.

Offline troflip

Re: Hacking SQ1VGA with SCICompanion v3
« Reply #47 on: March 27, 2017, 10:54:17 AM »
Yeah, that would be very useful.
Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline Collector

Re: Hacking SQ1VGA with SCICompanion v3
« Reply #48 on: March 27, 2017, 11:00:20 AM »
As I mentioned on VOGONS I am curious as to why you did this as a binary difference patch instead of just loose patch files? This is probably why ScummVM does not recognize it. The map file has been changed.
KQII Remake Pic

Offline NewRisingSun

Re: Hacking SQ1VGA with SCICompanion v3
« Reply #49 on: March 27, 2017, 12:07:40 PM »
Quote
This is probably why ScummVM does not recognize it. The map file has been changed.
Good.

Quote from: troflip
Yeah, that would be very useful.
I'll do a write-up, but it might take a while. Is there a binary build available with these issues corrected? Then I would only report those issues that persist.

Quote from: spiffythedog
There were a few scripts that didn't compile properly with SCI Companion (causing weird anomalies during gameplay), which necessitated NRS to use some original developer tools in order to properly implement the new fixes
I only used three original developer tools: SMF.EXE, View Editor 256, and MAKEVOLS. MAKEVOLS would claim that some view resources that were saved by SCI Companion were "corrupt". I loaded them in View Editor 256, where they displayed without problems, then immediately saved them, which produced somewhat different files that MAKEVOLS would then accept. I used SMF.EXE to reconvert Standard MIDI Files to .SND files after I made some changes to them (in particular, adding the choreography triggers to the Madonna music).
« Last Edit: March 27, 2017, 12:35:42 PM by NewRisingSun »

Offline OmerMor

Re: Hacking SQ1VGA with SCICompanion v3
« Reply #50 on: March 27, 2017, 01:34:57 PM »
Hi NRS,
thank you too for working on this!

MAKEVOLS would claim that some view resources that were saved by SCI Companion were "corrupt". I loaded them in View Editor 256, where they displayed without problems, then immediately saved them, which produced somewhat different files that MAKEVOLS would then accept.

That's very interesting. Do you still have the "corrupt" and the "right" views? It would be interesting to dissect the difference between them.

Offline NewRisingSun

Re: Hacking SQ1VGA with SCICompanion v3
« Reply #51 on: March 29, 2017, 02:40:18 PM »
Attached find one example. 572bad.v56 was saved by SCI Companion and was rejected by MAKEVOLS as "corrupt". Loading that file in Sierra's original View Editor 256 and immediately saving it produces 572GOOD.V56, which MAKEVOLS does accept.

Offline Kawa

Re: Hacking SQ1VGA with SCICompanion v3
« Reply #52 on: March 29, 2017, 05:50:42 PM »
Question. SMF.EXE was mentioned and that got me curious. Given a semi-random MIDI file with two piano tracks (left and right hand), it complains that these tracks have no device designation (true) and there's only a tempo track left.

How, then, does one designate devices to tracks? A quick glance in the EXE file suggests it's encoded in the name of the tracks...

Offline NewRisingSun

Re: Hacking SQ1VGA with SCICompanion v3
« Reply #53 on: March 29, 2017, 08:50:35 PM »
The track name must start with a list of devices that should play this track and a few other things in square brackets, followed by the regular track name if wanted:
*: Applies to all devices, typically channel 16 defining loop points.
a: Track played by ADL.DRV
j: Track played by CMS.DRV
g: Track played by MTBLAST.DRV
h: Track played by GENMIDI.DRV or Windows 3.1 Extended MIDI ("High synth")
l: Track played by Windows 3.1 Basic MIDI ("Low synth")
m: Track played by MT32.DRV
s: Track played by STD.DRV
t: Track played by TANDY3V.DRV
A sound driver's function number 0 returns in CH its device letter minus ASCII 61h ('a') to the interpreter, i.e. MT-32 returns 0Ch ('m' minus 'a'). In some games, MTBLAST.DRV plays 'm' rather than 'g' tracks, and in games composed for MT-32 but with a GENMIDI.DRV added after-market, or after composition (PQ1, Laura Bow), GENMIDI plays 'm' rather than 'g' tracks as well while remapping program change numbers based on 4.PAT information.

Special characters:
!: Do not remap channel ("Locked channel"). Required for MT-32 rhythm tracks (MIDI channel 10).
#: Track is initially disabled ("Ghost channel"), but can be enabled by game. Used for multiple melody lines, for example in LSL6.
Number 0-9 before "/": Initial voice allocation (i.e. number of voices used by MIDI channel)
Number 0-9 after "/: Pre-emption priority. Channels without it cannot be pre-empted, i.e. will never be disabled for the benefit of MIDI sound effects. Sierra's MIDI code is too confusing for me to tell whether it's a higher or a lower priority that makes a channel more or less likely to be pre-empted.

Example:
"[ajmt2/1] Melody": Played by AdLib, Game Blaster, MT-32, Tandy; initially allocate 2 voices, pre-emption priority 1.
"[gm!] Rhythm": General MIDI/MT-32 rhythm track.
« Last Edit: March 29, 2017, 09:11:14 PM by NewRisingSun »


SMF 2.0.11 | SMF © 2015, Simple Machines
Simple Audio Video Embedder

Page created in 0.126 seconds with 21 queries.