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.


Messages - doomlazer

Pages: [1] 2 3 ... 33
1
SCI Development Tools / Re: Looping Audio in SCI1.1?
« on: April 28, 2026, 06:57:22 PM »
(using unused numbers, as Sound and Audio assets share a namespace).

I believe that despite seeming to share the same resource numbers you can differentiate between sound and audio by prepending a 1 before the number to use digital audio.

For example, in LB2 most songs are MIDI, but "The Archaeologist Song" has both a MIDI version and an audio version with lyrics. So you can call the MIDI version with 312 or the digital version with 1312.

2
SCI Development Tools / Re: Converting Pics from SCI1 to SCI1.1 format
« on: April 15, 2026, 10:33:40 AM »
Isn't that the expected behavior? There should only be one palette available per room. Loading a pic and view with conflicting palettes is going to overwrite the previous colors.

That's why you can't transition between rooms with conflicting palettes without distortion or fading to black. This was often the case with EcoQuest where they would use checkerboard transitions between rooms with incompatible palettes and it looked terrible.

I believe it's also the reason most actors keep to the first 16 (or 32) colors so they can move between all rooms without issue. The rest of the colors are then used for pics or per room objects.

As an aside, with scummvm you can do some palette tricks, like overriding the static SCI0 palette. You're still limited to 16 colors, but you can assign them to any RGB value, allowing for a monochromatic effect with a dozen shades of a single color.

3
SCI Syntax Help / Re: QfGIVCD view corruption when editing 936.v56
« on: April 13, 2026, 12:34:56 PM »
I fixed a bug related to that many years ago (pull request #1467 if you're interested).

In which repo? Not seeing the PR in the IceFall or Kawa githubs.

4
SCI Syntax Help / Re: QfGIVCD view corruption when editing 936.v56
« on: April 09, 2026, 05:04:53 PM »
Seems to be. I've been working with ashlancer's qfg4-enhanced patches recently and everything appears to compile and work in game correctly. I've not encountered any issues and, so far, the translators using the patches haven't reported any problems. Probably why I didn't realize it was sci2.1 - it's working too well except for the views, which still seem to break randomly in different ways.

Edit: There are some issues I forgot about. KString (0x83) and KArray (0x82) will not compile in SCICompanion. KString should use the same hex value as String, so we can skirt that easily. KArray is only used twice in QfG4CD (array.sc and polyedit.sc), but that might require manual hex editing, because Array is a class in QfG4. None of the exported patches in Ash's repo contain KString or KArray, so I haven't actually dealt with them yet. Also pretty sure I've had issues compiling Phant and LSL7 scripts before, but too long ago to remember. QfG4CD seem mostly good, but since I'm only compiling/testing what Ash patched there certainly could be issues I haven't encountered.

I'm looking at Enrico Rolfi's Tradusci, but 2.4 was hosted in google drive, which blocked the downloads because of 'infection'; which is complete nonsense because a google 'scan' of .scr files always finds an infection, until you rename the extension and the virus magically disappears. /rant

Enrico removed the .exe from the source code for 2.4 this morning, so I'll try building it after work, but I understand it's not so much a view editor as a tool to replace cels of the same size with externally edited bitmaps. It will be interesting to see what its limitations are.

As for the original 936.v56 file I was working with in SCICompanion, changing a pixel adds 10k of bytes in four repeating blocks (view has 4 loops) to the end of the file. I'd like figure out what that extra data is supposed to be and if any loop or cel entries actually point to it. Also need to compare other views known to corrupt when saved, but time is in short supply at the moment.

5
SCI Syntax Help / Re: QfGIVCD view corruption when editing 936.v56
« on: April 08, 2026, 10:38:14 PM »
I finally looked up QfGIVCD on the sciwiki. Turns out it's SCI2.1, not SCI1.1 like I assumed.

I'm guessing SCICompanion just isn't able edit those views properly. It's not just 936, probably most the views have issue of some kind when edited. The corruption is expressed in seemingly random ways too based on the few I tested this afternoon.

PhotoSCIchop can modify these views with a bit of effort, but I can't really expect SC to.

SCI2 is also annoying that the Display kernel function was removed, so it's not easy to just print a string of text without a bmp background anymore. Oh, well

6
SCI Syntax Help / QfGIVCD view corruption when editing 936.v56
« on: April 04, 2026, 12:35:50 AM »
Here's a weird one.

If you make any changes to QfG4CD view 936, some of the cels get corrupted (see top three buttons in attached image). Doesn't matter if you change a pixel, alter the palette, export every cel to bmp and reimport them, move an origin point, etc.. Saving any change breaks the view in game. Adding new loops and moving cels around makes the corruption manifest differently, but in erratic ways based on my testing so far.

If you're wondering who cares about modifying some dumb shop buttons, the answer is, of course, translators.

I'm hesitant to blame this on a SCICompanion bug, because I'm told PhotoSCIhop complains about the view palette, though I haven't tested that myself.

7
SCI Development Tools / Re: Script issues with QFG1VGA
« on: February 26, 2026, 11:20:21 AM »
Are you compiling with a nightly Kawa build or the SCICompanion from the website?

If EO's decompile has any asm blocks in the script your working on, that's a likely source for recompile bugs. That can be replaced using Sluices repo as reference.

You could also post on the Spanish or French translation boards. I'm sure one of them has dealt with this already

Edit: invent.sc does have asm. That's a likely culprit

8
I believe it's the MT-32 ROM that would be a copyright concern, just don't include it. MT32.DRV and SCIV.EXE are in the SCICompanion template games, so I wouldn't worry about those.

9
Everything-Else / Re: What's up peeps!
« on: January 28, 2026, 04:58:29 PM »
What I'd been doing is AGI3 remasters of certain fan games...

Cool stuff!

I've got my hands on a few projects atm, so I'll just mention one. French translator Ulyssom is working on a QfGIV translation that integrated AshLancer's awesome QfGIV-Enhanced. Only problem is that he's run into a few bugs that are verifiably caused by AshLancer's patches. Unfortunately, the source code for Ash's work was never released and decompiling the patches with SC has major issues for various reasons.

Since Sluicebox released his decompiler, SCI-Tools, I thought I'd fork Ash's repo, start with Sluice's qfg4-cd-dos-1.0 decompile, then decompile the qfg4-enhanced patches with SCI-Tools. That should give me a near perfect picture of Ash's changes, right? Well there were a few issues with that, the worst of which the method order being different in Ash's patches produced nearly unreadable diffs.

I spent a few days reordering those methods and resolving the other issues. Now I've got a clear reference for Ash's fixes. I still need to address a few things about compiling the source in SC, but that process should remove some of the unfortunate issues that found their way into Ash's patch files.

Also working on some fun projects with Threepwang and Avo323 that I won't go into here. Thanks so much to AGKorson for his support on Threepwang's projects and the incredible AGI PowerPack. A very special thanks to Sluicebox for tolerating me bugging him several times about the Ashlancer stuff.

10
Adding support for SCI2.1 KString, KArry, & KList is likely a much bigger ask that probably isn't doable, but I might as well put it out there. Also I think there is a SinMult/TimesSin and CosMult/TimesCos thing.

Edit: well, turns out I'm not completely clear what's up with the whole KString thing, so I withdraw the request. ty

11
Can't quite imagine how it'd be an issue but it's reasonable and doable.

If there are a games worth of compile errors to work through, I compile all, and to click on the next error I often have to scroll through a bunch of warnings. Commenting out unused instances can lead to... other issues I don't want to talk about (shakes fist at LB2)

The relevant checkbox has been added to the Preferences dialog box that defaults to "true". Barring unforeseen consequences this feature should be available in the next nightly build.

You're the best. thank you!

12
Would you be willing to add an option to suppress the unused instance warnings for compile all? They can make things more difficult when working through a bunch of errors. Hopefully I haven't asked for this before, because it's been an issue for me several times in the past.

13
Sluicebox managed to trackdown the cause, at least for the code I originally posted about. It's from using case values with switchTo.

SwitchTo doesn't use case values; adding them compiles fine, but leaves behind the garbage. You can see switchTo was used in the LSL1VGA source with case values, which results in the extra values when decompiled.

switchTo is used quite a bit in lsl1vga, and not always incorrectly either!

edit: fixed link

14
Great. This will be a pattern I use in my own fan mods from now on. :)

15
Ok, that's a satisfying enough explanation for me. TY

Pages: [1] 2 3 ... 33

SMF 2.0.19 | SMF © 2021, Simple Machines
Simple Audio Video Embedder

Page created in 0.063 seconds with 19 queries.