Community
SCI Programming => SCI Development Tools => Topic started by: EricOakford on November 27, 2021, 12:34:44 PM
-
I have put together two template games for SCI32:
SCI2.0 (https://github.com/EricOakford/SCI2.0-Template)
SCI2.1 (https://github.com/EricOakford/SCI2.1-Template-Game)
SCI2.0 Interpreter: Jul 01 1994 10:29:44 (KQ7 demo)
SCI2.1 Interpreter: Jul 11 1995 10:14:08 (Torin demo)
SCI2.0 still has support for 320x200 resolution, while SCI2.1 only supports 640x400.
The view editor does not properly edit SCI2 views, so any alterations can cause graphical glitches that don't appear in the view editor, but do appear in the game.
Still, these barebones templates are a good start.
-
Woo!
-
Okay, so I've discovered that a pic's height cannot be changed to anything higher than 200. This made sense during the SCI16 era, where all pics were 320x200. Since the target resolution for the SCI21 template is 640x480, this needs to be addressed. (SCI2 can still support 320x200 resolution, so there's no problem there.)
This naturally results in imported images missing the bottom half. The View editor actually does allow for each view's resolution to be either 320x200, 640x400, or 640x480.
-
Enrico Rolfi developed his "FotoSCIhop" PIC/VIEW editor for his TraduSCI 2.4 SCI translation package that does SCI32. Not sure if it might be of any help for adapting Companion' editors. https://erolfi.wordpress.com/tradusci/ Looks like he just updated it last month. https://erolfi.wordpress.com/tradusci/
-
That's great!
I'm really happy to see SCI32 support.
I thought that SCICompanion couldn't do SCI32 (de)compilation.
(See http://sciprogramming.com/community/index.php?topic=2006.0 , on the other hand, Lars' reply at the end of http://sciprogramming.com/community/index.php?topic=2005.0 gives important information...)
Is it something that was recently added to SCICompanion? I haven't seen relevant commits in Kawa's fork (and I was glad to see a recent commit in Phil's branch, but it doesn't seem to be related).
Or is it simply that SCI2 support for (de)compilation was always there (even in Phil's "classic" release), and it's only SCI3 that's troublesome?
-
SCI2 support was already there, though some games have RESSCI.000 and RESMAP.000 instead of RESOURCE.000 and RESOURCE.MAP, and may not play nice in various ways. SCI3 simply won't work.
Besides the picture editor not letting you import high-res stuff, there's another issue involving priority maps that'll need to be addressed.
-
Ah yes. Priority maps are totally different.
-
Specifically, SCI Companion can render the backgrounds fine and well and the Fake Ego feature proves it handles the priority screen. But you can't place individual background parts.
-
Well, after researching some SCI32 game demos, I figured out their interpreters' version stamps. Now I know why some don't trigger Error 42 after the resource file is modified - they have the stamp 0 or -1, which allows it to match any game!
LSL6 SVGA: 0
LSL7 demo: 11
RAMA demo: -1
Torin: -1
Torin demo: -1
SQ6: 1465
SQ6 demo: 1352
SWAT demo: 1402
KQ7 demo: 0
GK1 CD: 0
PQ4 CD: 0
QFG4 CD: -1
QFG4 disk: 869
QFG4 disk (German): 933
-
Any idea what the LSL7 stamp will be? Not that it works with SC anyway.
-
Any idea what the LSL7 stamp will be? Not that it works with SC anyway.
Here's the initial DOS interpreter's build date and version:
Oct 18 1996 04:09:07 3.000.000The version stamp number is 18.
And here's for the interpreter included in the official patch:
Nov 08 1996 17:46:12 3.000.000HOWEVER... the stamp number in the patch's interpreter is -1! That means no version stamp check! ;D
By the way, you can input the interpreter's name with any argument, and it will give the version number and stamp.
-
By the way, you can input the interpreter's name with any argument, and it will give the version number and stamp.
Thank you. I tried this with a few games but couldn't get it to output the info in DOSBox.
"c:\KQ4\sierra version" outputs "Can't find configuration file" and "c:\KQ4\sierra -version" boots the game with no output. I must be doing something wrong.
Edit: No problem. Thank you for clarifying!
VVVVV
-
By the way, you can input the interpreter's name with any argument, and it will give the version number and stamp.
Thank you. I tried this with a few games but couldn't get it to output the info in DOSBox.
"c:\KQ4\sierra version" outputs "Can't find configuration file" and "c:\KQ4\sierra -version" boots the game with no output. I must be doing something wrong.
This doesn't work on SCI16 interpreters before version 1.001.095 (which is nearly all of them). I guess I should have noted that.
-
I managed to put in an older-style status line. Since the DrawStatus kernel call no longer exists in SCI32, this required making a special plane with text. QFG4 did a similar thing, but with views to represent current health, stamina, and mana.
-
It seems like the reason the views tend to be garbled when edited may be related to SCICompanion not properly modifying RESOURCE.MAP. That may explain why the views look okay in the view editor.
And adding in the control panel is tougher than in SCI16, since the GameControls and Slider classes appear to have been deprecated. SCI2's control panel will be based on that of GK1 and SCI2.1's on SQ6.
-
It seems like the reason the views tend to be garbled when edited may be related to SCICompanion not properly modifying RESOURCE.MAP.
That's interesting. The more details you can get me and/or Phil, the better.
-
It seems like the reason the views tend to be garbled when edited may be related to SCICompanion not properly modifying RESOURCE.MAP.
That's interesting. The more details you can get me and/or Phil, the better.
Specifically, if the resource files are modified, SCICompanion later mistakenly detects the map format as SCI 1.0, when it should be SCI 2. The package format and actual resources are still detected correctly, however.
In SCI Viewer, the resources themselves display fine, so it appears the view editor is not causing the problem; modifying the map file is.
-
I am in full support of getting sci32 implemented with proper view and pic editing support. I will look for ways I can contribute. What is currently in the works or in the que for working through these next steps?
-
* queue and uh... as far as I know, nothing is in it. I've looked into loading RESSCI volumes without having to rename them but the code scared me off. As far as picture editing goes, the main deal is that you can't change the position and priority of a given "draw image" command.
(Note that the position part of that sentence also applies to Jones in the Fast Lane because that is a strange, strange game.)
Anyway, I for one welcome any and all PRs about this.
-
* queue and uh... as far as I know, nothing is in it. I've looked into loading RESSCI volumes without having to rename them but the code scared me off. As far as picture editing goes, the main deal is that you can't change the position and priority of a given "draw image" command.
(Note that the position part of that sentence also applies to Jones in the Fast Lane because that is a strange, strange game.)
Anyway, I for one welcome any and all PRs about this.
Is priority mapping working in 1.0 / 1.1 scicompanion editing, or is it just the sci32 or higher resolution p56 files that are having issues? I can definitely see issues when loading a < 640x480 p56 file that the priority mapping seems off. I cant say I have tried editing any 1.x or 320x200 files.
Although this would be nice to have working, I do know how to use the OEM tools method to build p56 files with proper priority mapping already so there is at least an alternative out there. However, any thoughts on the condition of view files managing links and loops?
-
Far as I can tell, literally the only 16-bit game resource that uses an un-editable feature is the game board in Jones in the Fast Lane. There's nothing illegal about it, SCI Companion just assumes you have one "draw image" command, making it unclear how to add more and if you do have multiple you can't change their position like in Jones. Priorities seem to be fine, being drawn the old vector way in all 16-bit SCIs.
It's 32-bit SCI where the fun begins, since its priority screen isn't vectors at all -- you need a clear way to add multiple bitmap layers, and position and prioritize them. That this would let you reproduce the Jones game board is just a bonus. But from what I can tell, what it shows is basically correct. Not that it matters much if you can't edit it to check...
Of course, that's just pictures, and discounts any weird but obvious bugs like views coming out all black or obviously with the wrong stride.
-
Ok thank you for helping explain this. Trying to make sure we are on the same page with this and following you.
So sci companion has no issues rendering resource files for sci1 compatible games which use the vector based rendering and priorities. But for later sci1.1 and sci2 when sci starts using bmp style backgrounds, it has no way of saving the draw cells from the priority map? It seems that when I pull up resources from a game like QFG4 and pull up the pic file, the priority map is shown and recognized by sci companion. But when I export / save that resource as a patch file it is corrupted. My thoughts were maybe it was a conversion issue from p26 p56 but I was not sure.
View files seem to be a whole other thing I am finding in general. It seems there are many changes of how a view works between sci2 and the different variations of sci21 that I am hoping can be sorted through. A lot of these things were fixed and are now supported with the recent photoscihop update so it gives me hope. I have also had issues with the embedded palette saving v56 with sci companion, but that could also be to how I have things in sci companion palette config.
-
Ok I will just correct myself about saving the QFG4 p56 file. It seems to open fine in SCI Resource Viewer but not photoscihop. I have not tested it in game to see if it works in context or not yet. I am curious to see if I can open the original resource file in photoscihop and see compare the export with sci companion export.
-
So sci companion has no issues rendering resource files for sci1 compatible games which use the vector based rendering and priorities. But for later sci1.1 and sci2 when sci starts using bmp style backgrounds, it has no way of saving the draw cells from the priority map?
Considering how the priority and control maps work...
In the original SCI 0.0 and 0.1, you had three bitmaps (visual, priority, control), painted in by vector commands. These can be freely edited in SCI Companion.
SCI 1.0 added a "draw image" command which painted a bitmap in the same format as a single View cel to the visual bitmap, but you could still draw on the visual bitmap in the old style, just in 256 colors instead of 16, and there was no more dithering. Some SQ4 screens are entirely vector-drawn, and the Jones game board has its inside border drawn that way. All of this also goes for the 16-color SCI 1.0 games. This is why most SCI 1.0 Picture resources have one big "draw image" command and then draw the priority and control bitmaps the old way.
Around SCI 1.1, the control bitmap was deprecated -- you could still use it, but the later games used Polygon objects exclusively for both walkable areas and Feature hotspots.
In SCI 2.0, the control bitmap was removed, along with every single vector drawing command. You could no longer directly draw on the priority bitmap; instead each layer of the image would have its own "draw image" command, with a position and priority value:
(https://helmet.kafuka.org/logopending/wp-content/uploads/2019/03/Image2-1.png) (https://helmet.kafuka.org/logopending/wp-content/uploads/2019/03/a.gif)(https://helmet.kafuka.org/logopending/wp-content/uploads/2019/03/b.gif)
So what SCI Companion needs to properly and fully support SCI 2.x Picture resources is a way to change these position and priority values.
It seems that when I pull up resources from a game like QFG4 and pull up the pic file, the priority map is shown and recognized by sci companion. But when I export / save that resource as a patch file it is corrupted. My thoughts were maybe it was a conversion issue from p26 p56 but I was not sure.
There was a bug involving exported pics that may be in play here. Past tense.
-
Ok I am following you and also experience it when trying to modify the priority locations. I will take a look at some of the code and see if I can think of any solutions. Although I have OEM tool to build these pic files, it would be nice to have something with a full on editor that supports modern os.
-
Just wanted to touch base and let you know that I have been working on a set of tools outside of sci companion to help aid in p56 and view file modifications. Some examples that are currently finished and / or in the works.
A tool that will take any image file (png, jpg, etc) and convert it into a p56 file with complete support for multi-cell and priority mapping. This tool can either map to a particular palette which is very important to matching to the sci palettes, as well as a palette quantizer which will limit the palette index for use in creating new pics with their own palettes. This is 100% sci32 compatible up until the latest sci version from what I can tell. I have been using this tool to create new rooms, as well as upscale previous p56 files to 1080p for an upscaling project I have been working on.
I have also been working a FotoScihop fork that is becoming pretty heavily modified. I have added a CLI support to allow to add support for direct modifications to view files as well as process in batches. This is useful for making changes to header files as well as positions / links in views. I have accompanied this modified fork with a set of tools that will batch upscale / swap images in views by whatever % of scale. It can process hundreds / thousands of view files in a matter of minutes. This again has 100% compatibility with the most recent versions of sci as far as I know.
I have many more ideas for tools in the works as well, but this is what I currently have working. I plan on releasing these tools to public as soon as they are a little more defined and established for casual use. I also plan on implementing the CLI modification tools to the FotoScihop GUI once they are finished as well. My forked version of Fotoscihop has a lot of the back end revamped to allow easier support for modifying things. Currently, I have added the ability to add / duplicate cells and loops to views which will also aid in creating new views for use in sci32. I have a pretty good understanding of how the view files are put together now, so I am hoping I can also start implementing support into sci companion.
I will keep everyone in touch as development continues.
-
I would be interested your GIT repo as soon as you set it up. I would like to think that this could also be added to Companion to fully extend it to SCI32 support.
-
Sounds good I hope to have something released soon. Lots of work is going in to fotoscihop. I have been trying to organize it in a way that makes it easy as a reference to understand how a v56 file is working and is broken into parts. I think this could definitely be useful is helping implement support to sci companion, though its been while since I have looked at the sci companion code in these areas to verify how they relate. My thoughts is implementing the main parts may not be so trivial, but setting up the user interface with the editor and maintaining compatibility with earlier pic versions may take a little sorting out. But hopefully it can be done. I will try to find some time to start reading it over in sci companion to start getting some better ideas on how it might merge over.
-
I tried going through FotoSCIhop's source, but my C++ skills are sorely lacking. I have not even recently looked to see if Enrico has a newer version of it. When I asked him about it quite a while back he seemed to be mostly done with any further development of it. Nice to see you take it up.
-
Maybe it's just me but for SCI32 Picture support, I think being able to change positions and depths from inside the Picture Editor itself would be preferable. Are we all just too intimidated by how hairy the source code is to make the point editor (fills, lines, polygons) also work on cels? Cos I know I am.
-
I tried going through FotoSCIhop's source, but my C++ skills are sorely lacking. I have not even recently looked to see if Enrico has a newer version of it. When I asked him about it quite a while back he seemed to be mostly done with any further development of it. Nice to see you take it up.
Actually Enrico finished it up at the end of last year, which basically meant finishing linkpoint compatibility. So for him it is done and finished for the scope of what he designed fotoscihop for in the first place which is for translating sierra games and not necessarily graphical editing. This is partly why I decided to keep it going from where he left off as I need it for development in with a current sci32 project I am working on.
-
Maybe it's just me but for SCI32 Picture support, I think being able to change positions and depths from inside the Picture Editor itself would be preferable. Are we all just too intimidated by how hairy the source code is to make the point editor (fills, lines, polygons) also work on cels? Cos I know I am.
Yes I think that would be very ideal and I have a strong interest in tackling all that as well. Not having actually looked at how the Picture editor is working though I can't say for certain whether its easy or difficult to do yet. In the mean time though I am trying to get as familiar as I can with how pictures and views work in code. Ill try to take a look this evening just to start getting the context of sci companion code in my head.
-
I have some curious thoughts about about the sci decompilation projects and the sci32 games that have come from that like SQ6 and KQ7 demos. I have not looked into it much, but are those able to be compiled and used in sci companion?
I have been wanting to play around with modifying and recompiling some of these games and also maybe earlier titles to test out some tools.
-
I believe that GK1 is about the first SCI32 game and to go in the other direction, Phantasmagoria 2 would be about the last SCI game.
-
I believe Phantas 2 was about the only 16-bit colour SCI game too, no? I have a feeling all the others were 8-bit but I can't be sure.
-
I believe that GK1 is about the first SCI32 game and to go in the other direction, Phantasmagoria 2 would be about the last SCI game.
Sounds about right, with the exception of the Realm which is sci32 that is still in use today. I think it branched from sci 2.1 or so and was modified for windows and network play. But all the resources and scripts are still very much sci.
-
I believe Phantas 2 was about the only 16-bit colour SCI game too, no? I have a feeling all the others were 8-bit but I can't be sure.
As far as I can tell, truecolor was reserved for video playback only. I have not seen any evidence of a pic or view file being truecolor though so Phantas 2 was probably mixed with both elements.
-
The Realm is LSCI (Large-model SCI), a variant of SCI with networking built in, like TSN/INN.
-
The Realm is LSCI (Large-model SCI), a variant of SCI with networking built in, like TSN/INN.
Yes exactly. I knew it forked off of INN and some later sci32 variants but I did not know it was termed LSCI. Good to know! I have actually been working on modifying resources for the realm which required full sci32 compatibility.
-
So far after examining a bit of the code for sci companion and views / pics, I am feeling pretty overwhelmed by the difference in how it handles the code for this. Not only is the code a little over my head and will need some studying, but it doesnt seem to be broken down into a familiar structure I am used to seeing in both fotoscihop, sci32, or scummvm. For example a view file is generally structured as a view header, loop headers, cell headers, then a sequenced offset of image data / scan lines / links. Im not following exactly how it is structured in sci companion yet. Maybe I am not seeing it in context yet.
-
a user here, Aftertaste, was tinkering with the Realm trying to build some tools for it. https://code.google.com/archive/p/sci-palette-convertor/
-
a user here, Aftertaste, was tinkering with the Realm trying to build some tools for it. https://code.google.com/archive/p/sci-palette-convertor/
Ahh yes I am in a friends / circle with Aftertaste. Group of fellow Realm lovers :D. Never spoken with him directly but I hear he has some pretty fun tools.
I think its intriguing that there is potentially some modern sci code still being used out there. If there was access to a modern sc, makevols, and an interp that could compile and run on modern windows, what do you think could be possible for sierra games? Not to mention having access to networking. A multiplayer quest for glory 4 maybe?
-
Kawa has played around with the source of the interpreter, but I don't think he has made that major of any modifications. Of course he can speak for himself. Also, I do not believe we have any source for any of the SCI32 interpreters, either.
-
Kawa has played around with the source of the interpreter, but I don't think he has made that major of any modifications. Of course he can speak for himself. Also, I do not believe we have any source for any of the SCI32 interpreters, either.
https://github.com/OmerMor/SCI32/
-
Kawa has played around with the source of the interpreter, but I don't think he has made that major of any modifications. Of course he can speak for himself. Also, I do not believe we have any source for any of the SCI32 interpreters, either.
Actually it does exist. Though not publicly available any where that I have seen.
-
I have indeed Played Around.
I've messed with views, mostly, to correct a bug where color #255 was considered remappable (it's not) and ended up skipped over. This also affected backgrounds as they share a format with view cels and thus share a render function. And since scaleSignal had most of its bits unused I uplifted that to add some more remap effects like "replace every non-skip pixel with #0", "draw them as #253", or "draw them as if #253 is drawn on top", which would usually darken them, SCUMM-style.
I've been working on color table remapping like in TSN, too, for a bit.
But compiling on Windows? Well, no. And no multiplayer.
-
I have indeed Played Around.
I've messed with views, mostly, to correct a bug where color #255 was considered remappable (it's not) and ended up skipped over. This also affected backgrounds as they share a format with view cels and thus share a render function. And since scaleSignal had most of its bits unused I uplifted that to add some more remap effects like "replace every non-skip pixel with #0", "draw them as #253", or "draw them as if #253 is drawn on top", which would usually darken them, SCUMM-style.
I've been working on color table remapping like in TSN, too, for a bit.
But compiling on Windows? Well, no. And no multiplayer.
Interesting. You are doing this with Omar's sci32 source? Do you have it compiling in DOS? Has it worked in recompiling for any games yet?
-
I have indeed Played Around.
I've messed with views, mostly, to correct a bug where color #255 was considered remappable (it's not) and ended up skipped over. This also affected backgrounds as they share a format with view cels and thus share a render function. And since scaleSignal had most of its bits unused I uplifted that to add some more remap effects like "replace every non-skip pixel with #0", "draw them as #253", or "draw them as if #253 is drawn on top", which would usually darken them, SCUMM-style.
I've been working on color table remapping like in TSN, too, for a bit.
But compiling on Windows? Well, no. And no multiplayer.
What do you mean by you are working on color table remapping like in TSN?
-
I'm not sure if it was The Sierra Network or some later incarnation, but it had an avatar creator that included the ability to change colors. Except instead of having the exact same hairstyles several times over for different hair colors, they just had the one cel for each hairstyle and such, and remapped it on the fly. I think the DrawCel call was extended to take an Array pointer.
So what I've been doing first is porting SCI32's Arrays to SCI11+ (https://github.com/Kawa-oneechan/SCI11-Plus/blob/master/EXT/array.c).
Edit: found it was the LSCI scripts that use a DrawCel kernel that takes a clut argument instead of scale factors, and a Clut of ByteArray, which in turn is just an Array with its type preset.
-
Interesting. You are doing this with Omar's sci32 source? Do you have it compiling in DOS? Has it worked in recompiling for any games yet?
Missed this post. Everything I just described is based on Omer's SCI16 source, version 1.001.100.
I tried to recompile SCI32, but that wouldn't run anything and the code had implied int all over so no semi-modern compiler would take it as-is.
-
I'm not sure if it was The Sierra Network or some later incarnation, but it had an avatar creator that included the ability to change colors. Except instead of having the exact same hairstyles several times over for different hair colors, they just had the one cel for each hairstyle and such, and remapped it on the fly. I think the DrawCel call was extended to take an Array pointer.
So what I've been doing first is porting SCI32's Arrays to SCI11+ (https://github.com/Kawa-oneechan/SCI11-Plus/blob/master/EXT/array.c).
Edit: found it was the LSCI scripts that use a DrawCel kernel that takes a clut argument instead of scale factors, and a Clut of ByteArray, which in turn is just an Array with its type preset.
Ahh yes i am very familiar with this. This is how the Realm manages its characters as well, and uses a clut system for remapping. I could probably help give you some insight into this.
-
Interesting. You are doing this with Omar's sci32 source? Do you have it compiling in DOS? Has it worked in recompiling for any games yet?
Missed this post. Everything I just described is based on Omer's SCI16 source, version 1.001.100.
I tried to recompile SCI32, but that wouldn't run anything and the code had implied int all over so no semi-modern compiler would take it as-is.
Ahh ok I see in your sci11 repo now. Thats cool I might play around with that.
-
Ahh yes i am very familiar with this. This is how the Realm manages its characters as well, and uses a clut system for remapping. I could probably help give you some insight into this.
No need, I've studied it well enough. The hard part would be to actually do the remapping thing.
-
Any interest in some INN source?
-
Any interest in some INN source?
Definitely!
-
Here is the interpreter and some system stuff.
-
Here is the interpreter and some system stuff.
Thank you! I am excited to check it out!
-
A little update with the progress of my FotoSCIhop fork. Right now I have the restructuring finished for both view and picture files. I have a modify properties window that allow to modify pretty much every aspect of the view file. This even allows for adding and subtracting loops and cells, and support for editing 10 link points. Right now it is pretty raw, as I plan to clean up the ui a little more before releasing. But I am already having some fun modifying view files to see what everything does exactly. I have also implemented link point drawing so I can we finally see what those vectors are doing and how they work. The pic files need a little more work, but I was able to finish the main restructuring today. I have some ideas to allow for full cell and priority editing directly in fotoscihop.
(https://i.ibb.co/7ykDCTt/devenv-t6-DQQw-MUo-B.png)
-
Here is the interpreter and some system stuff.
Have you been able to build this yet by any chance?
-
Have you been able to build this yet by any chance?
This is the SCI16 interpreter code and system scripts, and LSCI system scripts but no interpreter. There is source code for the video drivers and such though, which includes a cel renderer that takes remap tables (cluts).
So for me, the answer is "most of it, yes".
-
Have you been able to build this yet by any chance?
This is the SCI16 interpreter code and system scripts, and LSCI system scripts but no interpreter. There is source code for the video drivers and such though, which includes a cel renderer that takes remap tables (cluts).
So for me, the answer is "most of it, yes".
What compiler/toolchain do you use?
-
Here is the interpreter and some system stuff.
Have you been able to build this yet by any chance?
I haven't tried. It is used for the development of the INN Barn project. There is more, but there is personal stuff included and promised to not release anything with that.
-
What compiler/toolchain do you use?
For the stuff in the SCI16 folder, I use a very specific old version of Microsoft's C compiler (CL 8.00c), combined with a slightly newer version of their assembler (ML 6.11). Both of these, just the files needed to compile SCI16, are included in the SCI11+ source tree because IDGAF, along with the make (PolyMake 3.3) that came with SCI16.
-
Anyone have the oem tool WinVE?
I ask because I have not see it referenced or listed here so I am not sure if it is available or even known of.
Its the only official Sierra windows version of view editor that I am away of, and it seems it might be compatible some where up to sci2.1. It seems to be a native win95 program so my testing has only been a little use on windows xp.
It does not work with the views that I am working on, so I am not sure exactly where compatibility lies, and I have not really tested it on anything else. But there is evidence that it was being used to edit LSL6 views in 640x480 mode.
Not sure if anyone is familiar or knows a little more details about it and it's capabilities?
-
Well then :D ...
https://drive.google.com/file/d/1JsT75aNEL05bmv63rLpEdq4nUZFOwYHh/view?usp=sharing (https://drive.google.com/file/d/1JsT75aNEL05bmv63rLpEdq4nUZFOwYHh/view?usp=sharing)
-
That does not seem to be included with the in-house tools that Omer posted. On a side note, this 16-bit program will run via WineVDM.
-
That does not seem to be included with the in-house tools that Omer posted. On a side note, this 16-bit program will run via WineVDM.
Thanks for the tip on WineVDM, this will be very helpful. I have also learned that this has full support for sci view files around 1995 - 1996 and even supports link points. In WVE they are referred to as registration points.