AFAIR, the videos is playing at half size in the DOS version of Torin's Passage. Only Windows version is having full-size videos. The game is coded by this way, unfortunately.

The videos definitely play at a small size natively. I'm wondering if there might be a way to edit the game so that it plays them in a larger window. I do understand that when the games came out the impetus was to ensure compatibility across a wide array of computers with specs far below those of modern computers, and thus playing videos in a tiny window was probably a great idea.

I guess my goal in creating this thread was to see if there might be any way to improve the experience today, even if it might not be 100% faithful to the original.

To this end I've done some more research. I'll divide my findings between the two games as they are different in how they were constructed (even though the issue at hand is pretty much identical.

Torin's Passage: DOS Version

The movies are in Sierra's own .VMD format (Video and Music Data, apparently) and have a native resolution of 316x158, thus being twice as wide as it is high. According to http://wiki.multimedia.cx/index.php?title=VMD the data determining how to display the video is contained in a header that would seem to be part of the .VMD file itself. Other games utilized the VMD video format, and videos extracted from these games can be played using a vmdplayer which can be downloaded from http://vagsoft.chat.ru/sci.html. Another game I own, Leisure Suit Larry 7, uses this format AND plays the videos in full screen. Though the game utilizes SVGA graphics, the videos are 320x240, thus the player IS stretching them to fit the screen; this gives me hope that the same can be done for Torin's Passage (although the aspect ratio of the Torin's Passage videos will mean there will always be black bars above and below the videos).

Things I have tried so far:
1. Replaced the vesa drivers with various other ones from the CD (located in D:\INSTALL\VESA\VESA). No difference (not that I really expected this to work...)
2. Ran the UVCONFIG.EXE program in the TORINDOS directory and increased the video RAM and set the machine type to think I had a Paradise card in the UVCONFIG file and in the DOSBox config file. No difference (again, not that I really expected it to work...)

Things I think might work:
1. Editing the .VMD files to reconfigure the size and screen location of the videos

King's Quest 7: Dos Version

The movies in this game are encoded in .AVI format, and thus can be viewed using utilities such as VLC media player. The version of the game that I have came from the King's Quest Collection DVD. I copied it to my hard drive and play from there; I don't have any other version of the game and therefore can't test another version.

Things I have tried so far:
1. Using an external program to re-encode the videos from a frame size of 320x168 to 640x332 (double the original size). No difference. I kind of thought this might work, but it would seem that either the game disregards the file data in the .AVI file, or it is forcing the video to remain at 320x168 anyways.

Things I think might work:
1. ??? This one has me flummoxed. Perhaps there is a different DOS AVI viewer that can be loaded before launching the game and which can be edited into the RESOURCE.CFG file as the default video viewer for the game to use?

Additional thoughts
A number of other games used the .VMD format for videos, as noted by the website detailing the format. Could it be possible to adapt the improvements discussed here to games such as Phantasmagoria?

I'd like to state that I'm not a developer, programmer, or coder of any sort. I can move around files and edit text with the best of them, but that's about it. I'd love to assist in any capacity I may with anyone who takes an interest in this project, but unfortunately this probably will never get done if it's just me thinking about it and working on it. If you do read this, then you have my appreciation, and if you contribute anything beyond that you already have my gratitude.

Alright, more research and more experimenting. The DOS version of King's Quest 7 uses videos encoded in the .RBT file format, not .AVI. Additionally, I have no idea how to get any info from the file types at this time.

As for Torin's Passage: I tried simply copying the SIER.EXE file from the Leisure Suit Larry 7 install directory to the TORINDOS directory and running it to start the game (hoping that the SCI1 SIERRA.EXE variants could be interchanged like the old AGI-era SIERRA.COM files), but this didn't work, as it threw out Error 42: this game has not been version stamped. I tried copying over the VERSION file as well, but got the same error.

...the research continues

I'll bump this, as I had the same problem with Torin's Passage but found the solution, which I'm posting here for all to see. It involved running the installation setup with core=full, so it wouldn't crash during the video speed test phase. Now the videos are in full screen!

The resulting RESOURCE.CFG:

1videoDrv  = VESA.DRV
2soundDrv  = MIDNONE.DRV
3audioDrv  = DACBLAST.DRV
4joyDrv    = NO
5directory = \sierra\torindos
6minCPU=486
7minDOS=572
8mode=real
9minEMS=200
10CD=yes
11CPU=0
12VideoSpeed=5481
13CPUSpeed=100
14CDROM=0
15mouseDrv  = NONE
16memoryDrv = NONE
17language  = 1
18audioSize = 22k
19
20cmd       = .\torin.bat
21                                 
22resSfx= D:\                      
23resAud= D:\                      
24resMap= D:\                      
25movieDir= D:\movie               
26patchDir= C:\sierra\torindos;D:\patches       
27ÿÿÿ

Simply edit RESOURCE.CFG so that VideoSpeed is 5481.

Hrm, mine still crashes even with core=full, but thanks for the needed config revision.

Is there even still a "full" core? The 0.74 conf shows "auto", "dynamic", "normal" and "simple". I would think that using "full" would result in core=auto. The crash is during the video test, which can be skipped. The actual error is a DOS/4GW "divide by zero" error,which can be avoided by lowering cycles to no more than 20000. Simply editing the RESOURCE.CFG to the above values will not work since the selection seems to be stored in the generated preferences file.

One thing to keep in mind is that while lowering the cycles enough to pass the video test will give you full video, the video will be interlaced. It might be possible to create a script patch to give full non-interlaced videos like Endroz did with GK2, but this gets outside of my abilities.

I am using DBGL as a DOSBox front end and it does give an option for core=full, and when I used this setting and did a fresh install with the cycles set to auto it simply maxed out during gameplay but DID give me full screen video as promised with the editing of the config file. It would be great if the video was not interlaced similar to the GK patch, but this is also above my capabilities. To be fair, I think even the quarter screen video is interlaced so it still looks better to me. I do intend to play with the cycles in order to get rid of stuttering during the video.

You have to go back to 0.65 to find full listed as an option in the dosbox.conf. If you set it to full in the conf, start it and query what core is being used at the prompt, it will report it as auto, just as you would expect if you specify full, since dosbox will ignore invalid values and use the default value. If DBGL still includes the full option, it is probably because either Ronald intended it for backwards compatibility or it was an oversight to not remove it. Regardless, it does not change the value you have set for cycles.

The interlacing is added when the VMD is stretched to full screen. When it is not, it is not interlaced. This would indicate that the interlacing is introduced from a script the same way as it is in GK2.

Outside of that I don't think that there are any other speed bugs in Torin's, so you should be able to set it to core=dynamic and cycles=max. I have found no stuttering with cycles=max, which is why I use it as default for the conf my installer writes.

I used Ykhwong's build, which has the full core option... I didn't realize it wasn't in the official builds anymore.

But yeah, I think the key factor was right speed. Full core, being slow, aparently slowed the setup enough to prevent the speed crash while still being fast enough to allow fullscreen videos. One of the things I tried was keeping cycles at 3000, but that resulted in tiny videos.

And yes, the VideoSpeed parameter in RESOURCE.CFG is apparently what decides the video size. I had an old installation (with some save files from a playthrough in progress) that had tiny videos, did a new test installation in which I managed to get large videos, compared the RESOURCE.CFG files, noticed VideoSpeed was different and copied the value to the old installation. Voilà! Videos became large in it too.

Yes, the crash does seem to be related to cycle speed. 20000 as suggested above was still too fast for me and still resulted in crashes. 10000 seemed to be OK to pass through the install successfully.

Tried to get this fix (VideoSpeed=5481) in GoG version - still get small video screen 😒

Edited only the 'VideoSpeed=5481' thing from my CD version and it worked : get full size videos on DosBox, thanks 😀