Community
SCI Programming => SCI Syntax Help => Topic started by: MusicallyInspired on June 17, 2015, 11:25:22 PM
-
I'm trying to alter the colours to my GUI. I've done all this perfectly but I cannot for some reason change the colours of the text or the background behind the text. It remains black for foreground and grey for background. I've looked through the Print class but I'm not seeing anything related to colours (and there's a lot of strangely named variables, like a million "theTheTheGModNum"'s). The printed text seems to ignore the colour settings I set for "back" and "colour" in the BorderWindow class.
-
Ha, that's funny. That was the *only* thing I could change when I was playing around with stuff. I changed the value of global159 in script 12.
Definitely feels like the SQ5 code was kind of hacked together... or rather, it had "decayed" over several iterations of games, with methods to change similar things spread out across different code.
-
Ah nice. Also found where I could change the text colour. I can't find where the text button colours are handled, though.
Incidentally, the "buttons" in SQ5 are fairly boring compared to those of SCI0 and the like. They're not even real buttons, they're just text that highlights. Where could I go to change this behaviour? I'd also like to be able to line them up horizontally on the same line instead of vertically.
-
Well, you can use the message resource to set the color (and font)... or do you mean the highlight color? Or I guess the default color?
You could try to play around with the dialog editor (in dlgwindow.sc) to see if you can generate code that lines things up horizontally.
As for changing them to look like "real buttons"... you're on your own! Poke around and figure it out :-)
-
Definitely feels like the SQ5 code was kind of hacked together... or rather, it had "decayed" over several iterations of games, with methods to change similar things spread out across different code.
Don't forget that SQ5 was not developed in-house. Outside of Mark Crowe most of the developers would have been Dynamix developers. You could consider SQ5 a "learner project" to help Dynamix developers become familiar with SCI.
-
Perhaps SQ5 wasn't the best choice to base the template game on? lol Maybe LSL6, keeping in trend with how Brian based his template games (SCI0 was based on LSL3, right? And his VGA SCI1 template game was based on LSL5 or LSL1VGA, can't recall). Also, if we based it on LSL6 to begin with we wouldn't be having these driver issues that we do now.
-
Oh, I'm sure LSL6 is just as messy. And I think there'd be a lot more work to do around fixing up the user interface, since I think it's less applicable to a typical adventure game than than SQ5's interface.
Which driver issues are you talking about?
-
I was thinking KQ6, just because of the icon bar being a relatively standard set. Rather than trying to work backwards with the command etc in SQ5.
I tried to get the speedtest script from kq6 going in the template, looks like it sets the detail and game speed at game startup, but my first attempt failed miserably
-
I don't understand ... why would you need speedtest? Doesn't that set detail level/speed/whatever based on some performance measurements? I'm pretty sure we can just set it to max detail given today's hardware.
-
The driver issues I'm talking about regarding AUDBLAST.DRV not working properly and producing noise.
-
I don't understand ... why would you need speedtest? Doesn't that set detail level/speed/whatever based on some performance measurements? I'm pretty sure we can just set it to max detail given today's hardware.
Just for fun really. It is basically a black room prior to the title screen with a transparent actor. The actor is then moved from one point to another point and timed. Based off of the time then you are correct that the detail and speed are set.
-
I would guess that it would be easier to modify the the bar and the UI in general in LSL6 than to track down audio resources and driver incompatibilities. The burden of UI modifications might be something that could be partially shifted to the community.
-
So is it the AUDBLAST.DRV from LSL6 that won't work or the one from SQ5? We switched interpreters with LSL6 right? But kept the SQ5 source. Could just go back to SQ5's interpreter, I suppose, or whichever AUDBLAST.DRV works. I'm speaking for keeping compatibility for older computers. I'd sacrifice 44100Khz audio for that.
EDIT: I'm speaking for myself, switching back. Not the template game for everybody. I'm not suggesting going back on what might have been a lot of work.
-
It's the LSL6 audblast.drv that doesn't work (is it a known issue with DOSBox or something?).
At any rate, the other audio drivers work, so it doesn't seem like this is actually a real problem. I can understand the need for different MIDI drivers working, since the instruments sound different. But for the audio drivers, isn't one as good as another?
[edit:] Oh, but it looks like the other drivers only support 8-bit sound?
-
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).
-
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...
-
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.
-
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 :P
-
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.
-
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 :P
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.
-
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.
-
To answer the original question, how to change Print windows' background color, the answer is, just like the icon highlight gray border thing (http://sciprogramming.com/community/index.php?topic=1439.0), in SQ5 init:
(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.
-
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.
-
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...