SCI1.1 Print - Change default text display colours?

[MusicallyInspired]

I was under the impression that only AUDDISNY.DRV worked. I'm just not 100% sure that AUDDISNY.DRV works on older conventional computer hardware. I'm not in this for DOSBox compatibility because DOSBox is compatible with everything anyway. I'm not worried about that.

My whole viewpoint is that if I can get these games as 100% compatible with older hardware as Sierra's games were and to look and play the same as Sierra's games then that insures the best quality game in my opinion. That's why I don't like taking shortcuts to take advantage of modern hardware like using ScummVM for undithering or sciAudio for digital MP3 playback. Not that those are bad things I think they're amazing and the people who made them moreso, I just prefer the classic approach. It is a retro engine. Let's face it, no matter how much we can pretty up SCI or how many advancements we can add to it, we can always do FAR more and with FAR better modern compatibility with AGS. The novelty is fun to do it with SCI, but it's still old and I like treating it that way. That's why I use it. I'm probably the only one who looks at it this way, though. But that's why I strive for compatibility with "debunked" hardware like the MT-32 and Adlib, even though the tools are still lacking for proper support (PATCH creation for one, huge drawback). I also like doing interesting things with MIDI. Things you just can't do with digital, or at least can't do very easily.

Anyway, that's why I dislike the idea of using hack-ish shortcuts that break things and deciding that's ok because it "works in DOSBox/ScummVM" as if that's all that matters, which seems to be the general consensus lately. It just doesn't feel true to the spirit of it all to me and doesn't feel like we're doing it "right".

By the way, as I'm typing I'm realizing this may all be coming off harder than it's intended. Just know this isn't directed at anybody or anything in an antagonistic way, just my thoughts....at 11pm.

Guys, the DoAudio kernel call has a subfunction for setting the output sample rate. I see that the template game doesn't call it - perhaps it is required? A number SCI32 and SCI1.1 games call it once on startup.... there are also functions for setting the number of bits/sample and mono/stereo (but those are not present in LSL6).

Interesting...

[Collector]

It is the LSL6 SB driver that does not work, but LSL5's does. This is the same thing that happened with the sound at the start of SQ5 when using the AUD resource that troflip posted if you used the packed SB driver from the SQ5 setup. It is very typical result from trying to swap audio drivers between SCI games. That noise, initialization lockups or endlessly looping sound are common symptoms. I doubt that DOSBox could have anything to do with it as this even was the case in pure DOS. It would be interesting to see if Lars' suggestion helps the LSL6 SB driver work with the the new template game.

[troflip]

That's certainly an interesting viewpoint. My viewpoint is that DOSBox/ScummVM is really all that matters, because most (?) Windows installs these days can't run 16 apps anyway. Having to use DOSBox/ScummVM is kind of an extra step, but I haven't used a computer that's been able to run the sierra exe's natively for many years now. So I kind of forget that that's a thing

[Collector]

I'm not quite sure what you are getting at. My point was that the driver mismatch is not because of DOSBox, but simply that the mismatched driver exhibits the same behaviors in DOSBox as it did in pure DOS. If the LSL6 SB driver got broken with the template game then it is something that was removed or changed from LSL6.

[MusicallyInspired]

I think he was replying to me, Collector.

That's certainly an interesting viewpoint. My viewpoint is that DOSBox/ScummVM is really all that matters, because most (?) Windows installs these days can't run 16 apps anyway. Having to use DOSBox/ScummVM is kind of an extra step, but I haven't used a computer that's been able to run the sierra exe's natively for many years now. So I kind of forget that that's a thing

And that's fair. It's not like I really have much of a say. I'm in the minority and after all it's YOUR IDE that you spent countless hours updating and perfecting, both years ago when you first started with SCI0 and again now and for no other reason than you felt like it. I can't complain, especially when we've been waiting for 15 years for this! You've done a phenomenal job. I don't want to come across as snarky or obnoxious. My opinion matters little in this instance.

[troflip]

I'm not quite sure what you are getting at. My point was that the driver mismatch is not because of DOSBox, but simply that the mismatched driver exhibits the same behaviors in DOSBox as it did in pure DOS. If the LSL6 SB driver got broken with the template game then it is something that was removed or changed from LSL6.

Yeah, I was replying to MI.

I'm not sure if the LSL6 SB driver works with LSL6 or not. For some reason, I can't get any audio resources to play when I try that game. Everything (to my ear) seems to be the "sound resource" version of sounds, even though I've set prefer_digitalsfx=true in the resource.cfg file. So it's not that it's hanging or making weird noises, it just always uses the midi stuff instead of the sfx.

[Kawa]

To answer the original question, how to change Print windows' background color, the answer is, just like the icon highlight gray border thing, in SQ5 init:

Code: [Select]

(send gSq5Win:
color(0)
back(global159)
)Just like with the other problem, the game's overriding things. If you remove this block, sq5Win will use its default colors -- 0 on 5, inherited from BorderWindow.

[MusicallyInspired]

I managed to change the background of print windows, but not of colorbuttons. But now that I see we can have the old buttons it's probably not necessary, unless the old buttons also set their own colours. Will look into it.

[Kawa]

unless the old buttons also set their own colours. Will look into it.

I don't think they do. I think they don't have any background color. At least in the sense that if I change a window's background the buttons reflect it and nothing about them indicates they have a background color.

Of course, you could probably make your own DButton that adds a background color property and fills a rectangle before (super:draw()), if you want them to have their own background...