Community
SCI Programming => SCI Development Tools => Topic started by: Kawa on August 15, 2015, 04:40:57 PM
-
Technically you don't "import" SEQ files like you would other resources, no?
*studies ScummVM's seq_decoder.cpp*
Edit: Full frames would be the easiest to get started with. The other option is RLE.
-
The LSL6 interpreter does not support the ShowMovie kernel call. So we'd have to switch interpreters (again) to get it.
-
Guess I was right about kSeqFrameFull being easy to work with.
Edit: I can play RLE frames now. The entire file renders perfectly as far as I can tell.
-
Technically you don't "import" SEQ files like you would other resources, no?
*studies ScummVM's seq_decoder.cpp*
Edit: Full frames would be the easiest to get started with. The other option is RLE.
Well the SEQ files were generally outside of the main resource/map files if that is what you mean, but there has to be a way to create the SEQ files, whether frame by frame in an editor (perhaps like the VIEW editor for each frame) or by conversion of an external file encoded with a standard video format, hence "importing". The interpreters that support SEQ have a flag for the path to the SEQ files called in the RESOURCE.CFG.
-
I know enough to make SEQ files now. A converter that does naive fully-uncompressed output is easy at this point. Maybe dirty rectangles too.
-
Gentlemung, I present you... a custom-made SEQ file, confimed to run equally well in ScummVM and my player. It's this big because it's naively-made, as described above. Next challenge is cropping out the changed bits. But as far as proofs of concept go...
Update: now does top/bottom clipping, reducing theend.seq to only 229 KB.
-
Cool!
-
Cool!
I'll do you one better. Here's the actual program, with the bitmap source data I used to make that seq file.
It's .Net, but I don't think it does anything untoward that would prevent any ol' Mono installation from running it. In fact, I just tested both it and my player in a Mint VM to resounding success.
-
Sweet! This deserves its own thread, really. Can a mod split it?
-
Sweet! This deserves its own thread, really. Can a mod split it?
I am a mod.
-
Source?
-
Man, between this and the old OpenPok? map editor, I'm on a source-releasing roll here.
-
Thanks!
-
Sweet! This deserves its own thread, really. Can a mod split it?
I am a mod.
Oh! So you are...
-
Here's an interesting twist.
As Iskovlun suggested, the LSL6 terp doesn't do ShowMovie. So I dropped in all the files that came with KQ6CD -- not just SIERRA.EXE, but all the drivers and other such files too, and the config file for good measure. Given two testing videos -- FS1 and my THEEND -- I get a pretty weird result. It's all tiny and staggering. Whereas if I do the opposite, replacing KQ6's FS1 with THEEND, I get a color problem.
Neither of these things happen in ScummVM, be they Template or KQ6. The part where it takes so freakin' long to get FS1 to play in KQ6 doesn't make testing for fixes any easier.
-
It's possible that the KQ6 version simply does not support that video mode. KQ6 switches to a different video mode (some sort of Mode-X, 360x480 perhaps?) using a kernel call before playing the intro. I wanted to try this in SCI32, but my GK1 installation is acting up at the moment (due to my ScummVM work I often have weird files lying around in my game directories that sometimes break things; no jokes please). I even wanted to say I'd tried it, but then it occurred to me that that was ScummVM, and it works there, as you note.
What video mode is your SEQ authored for? I guess 320x200?
-
320x200, yes. Video mode, huh? I can't imagine that being an issue with KQ6 switching between SEQ and pic/view like that... Too bad I can't research this until I wake up tomorrow.
Also, I didn't specify but Template played THEEND in tiny thumbnails too.
Edit: another thought. If KQ6 changed to 360x480 (what kinda res is that?) DOSBox's window would've resized. And the SEQ files seem to be 320x200. Or rather, FS1 is and the others work fine in my player, which is 320x200.
Edit?: It is a SetVideoMode call, but it's not 360x480.
-
320x200, yes. Video mode, huh? I can't imagine that being an issue with KQ6 switching between SEQ and pic/view like that... Too bad I can't research this until I wake up tomorrow.
Also, I didn't specify but Template played THEEND in tiny thumbnails too.
Edit: another thought. If KQ6 changed to 360x480 (what kinda res is that?) DOSBox's window would've resized. And the SEQ files seem to be 320x200. Or rather, FS1 is and the others work fine in my player, which is 320x200.
Edit?: It is a SetVideoMode call, but it's not 360x480.
360x480 was just something I wrote. Mode X is typically either 320 or 360 times 240 or 480. Someone commented elsewhere (I can't recall where) that an additional benefit in that Mode X is planar, unlike standard VGA, and that this could be beneficial for a video player. Mode X is actually a standardized name:
https://en.wikipedia.org/wiki/Mode_X
EDIT: It could just be planar 320x200... If the file format does not reflect the planarity of the display mode (as would seem to be the case), then nothing needs to change apart from the two added calls to SetVideoMode. If it does, well maybe that is the source of your color problem.
-
It is possible to enable planar memory in standard 320x200 mode, which became informally known as "Mode Y" in the Usenet rec.games.programmer group.
Considering the resolution in KQ6 doesn't seem to change (DOSBox stays the same size) and the SEQ files are most certainly 200 pixels tall, this struck me as minorly relevant.
At any rate, it seems you can run the whole damn game in planar mode, but that breaks transitions. Perhaps other things too, like... scaling, maybe? I haven't tried. There's a bit of an interlace-like ghosting effect sometimes where you can kinda see the planar layout, but other than that and the lack of transitions, things seem playable enough in planar mode.
-
Don't know if this will help, probably not, but the DOS SEQ intro has a stuttering problem in DOSBox. This can be fixed by using the VGA320.DRV from the GK1 demo.
-
Confirmed on both counts.
-
Bump. What do you suppose the framerate of a SEQ would be?
-
I think it depends on the parameter you pass, but considering a few things, 15 or thereabouts sounds good.