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 - EricOakford

Pages: [1] 2 3 ... 5
1
An idea could be to move to SCI0.1 (which is what QFG2 uses).
This is an interesting idea, and I have to say the addtional heap and path functions are of interest to me. I wonder how cumbersome the transcription of my project to that would be?

In fact, I don't really know how to do that at all, as the options when creating a game with Companion is SCI0 or SCI1.1.

Am I missing something?

No, you just need to download the template here. As Kawa said, you can then put it in the TemplateGame folder, and it'll be there in the New Game dialog.

Quote
I wonder how cumbersome the transcription of my project to that would be?

You'd have to change from Studio to Sierra script. I designed my templates to be as close to the original Sierra source as possible.
Also, keep in mind that the 900 script range and script 255 are specifically intended for system scripts, which should not be edited (except for the Menu script). If you need to make custom properties for things like the inventory or ego, you should instead create subclasses and instances in the game-specific scripts.

2
Why not also move onto SCI1.1 for it?
My primary reason is just that those were my favorites of the Sierra games. I always liked the parser and I enjoy the limited palate.

Secondary reasons would be that I will get to reuse a ton of resources from the previous game and that I'm already very familiar with the tools.

An idea could be to move to SCI0.1 (which is what QFG2 uses). It fully supports SCI0 views and pics, but sounds will need to be upgraded to the SCI1 format. It also manages memory much more efficiently - between my SCI0 and SCI01 templates, SCI0 has 20618 bytes of free heap space in the test room, while SCI01 has 29456 bytes of free heap - nearly a 9000 byte difference!
SCI01 also has the doVerb method, which can be mapped to parser commands, as used in KQ1SCI and QFG2, as well as support for polygon-based paths.

Just an idea if it turns out heap space will be a problem.

3
Major update on the SCI1.0 template: it has been redone, using the Mixed-Up Fairy Tales demo as the base. That means the interpreter and system scripts are newer, and it has separate drivers for music and digital audio! With that, GMBLAST is not needed any longer. Ego is now played by the white boy from MUFT, and his head moves normally in real-time (as opposed to using cycle speed like in SQ1VGA and SQ4).

Now I see why those timer bugs were present in the CD-ROM version of SQ4, but not the floppy version - it all comes down to the Game class's doit:, which had things like a "gameTime" global added in around late 1991. Unfortunately, the game-specific scripts were not adapted for this upgrade, thus you get things like Roger's head moving super-fast, for example.

You know, I think the SCI16 series of game templates is ready for action.

4
SCI Syntax Help / Re: Loading External Scripts on the Fly?
« on: August 12, 2019, 11:57:15 PM »
cramming things like the game's icon bar, control panel, and inventory
All of these will be required often to semi-often in normal use. There's a risk in not being able to pull them up if you're low on memory because their memory footprint was not accounted for earlier. What if you're prevented from saving/restoring/quitting? Putting up a death message? Using a critical object?

They will still be initialized in the game's init using the ScriptID kernel function (so they will still be loaded in heap at startup), so I don't think that will be a problem.
I just thought it was a good idea given that by the time of SCI1, it became standard for the inventory to be placed in its own script, and the control panel soon followed, then the icon bar in the SCI32 era.

Though, admittedly, from SCI01 on, the way heap was stored had been changed.

08/13/2019 UPDATE: I've decided to just move the inventory for SCI0 and SCI01 back into MAIN.SC. It's more memory-efficient that way.
I've further been making sure that the free heap and largest pointer are as close as possible (only a 2 byte difference!)

5
SCI Syntax Help / Re: Loading External Scripts on the Fly?
« on: August 10, 2019, 09:33:40 PM »
Loading external scripts on the fly... that's the approach that I've been using for my templates recently. Instead of cramming things like the game's icon bar, control panel, and inventory into MAIN.SC, why not just put them in their own individual scripts? That's what Sierra did later on, and it makes the main script (which will always be loaded in memory) use significantly less memory. In the case of a game intialization script (so long as it doesn't need to use objects in the main script), it can just erase itself from memory afterwards, since it will not need to be used again.

6
My memory must be faulty then because I thought I remembered interchanging sound files between SCI0 and SCI1 games without an issue but ran into problems with SCI1.1. I'm assuming the SCI0 format is also used by/compatible with SCI01.

If by SCI01 you mean QFG2 or Seasoned Professional, those games actually use the newer SCI1 sound format, if SCI Resource Viewer is right. The DOS version of KQ1SCI does still use the older SCI0 sound format, though that was upgraded to the SCI1 format for the Amiga version.

7
SCI Development Tools / Re: Decompilation Archive
« on: July 29, 2019, 08:26:22 PM »
Here's a new and improved decompile for QFG1EGA!

A major change here is that all of the system scripts and globals are based on the original SCI0 source, which is much more accurate. As a result, there should be no compatibility or decompiler issues on that side

The game generally seems to work okay, but the game crashes in certain areas (entering Meep's Peep, working at the stables, dispelling the bear), which seem to be related to decompilation errors.

Oh, yeah, there's also new decompiles for Seasoned Professional (EGA and VGA use exactly the same scripts) and the QFG2 demo. Both have been fully tested to completion.
7/31/2019 EDIT: Oops! I goofed up with the SCI01 decompiles, as I worked at adapting the original SCI0 header files for them, but uploaded incomplete versions. That has been fixed. Now they really have been tested to completion.

8
And here it is - SCI0 Template Redux! Fully in Sierra Script, built off of the Codename Iceman demo, and no assembly blocks anywhere!

Feel free to fix any bugs that you may notice - that's why I put it up on GitHub in the first place.

9
Eric,
I've created a github repo for the SCI0 system scripts:
https://github.com/OmerMor/SCI0

It has 2 commits for the 2 versions I have.
You can use that to create better SCI0 template.

Cool! I'd better examine these scripts. One set's from November 30, 1988 (close match to LSL2), the other's from October 25, 1989 (close match to LSL3).
I guess I'd better start working on that SCI0 template and touch up the SCI01 and SCI10 templates, since it may be a while before SCICompanion properly supports SCI2.1.

10
Here's my prototype of a new SCI1.1 template game!
It's built on top of the ImagiNation Network demo, whose interpreter is an exact match for the interpreters included in the SCI16 source. Said demo also has a complete set of system scripts, and lots of fonts.

This new template is in Sierra Script right from the start, and uses original Sierra names for defines, globals, scripts, and procedures. Various game-specific subclasses (the inventory and icon bar, for example) are now in their own scripts (this became standard in the SCI32 era). There is no assembly code in any of the scripts. Basically, the code is much simpler, cleaner, and more accurate to Sierra's original code.

The graphics are the same as the existing template, but it's quite a different beast script-wise. Then again, Sierra's programmers all had different ways of implementing things.

I was going to do a new SCI0 template, but why bother? My SCI01 template fills that niche just fine, and has additional features (doVerb method, improved memory management, and scrolling styles, to name a few).

Now to bring this to SCI2.1...

11
Might I suggest making it look a bit less like Space Quest 5, with the font and status bar being as they are in the template? It can be as simple as replacing some font resources and swapping most of statusLineCode::doit for a DrawStatus call.

You know, it's not unlike the SCI0 template having Larry 3's color menu item, but somewhat more in your face.

I have actually been working on a whole new SCI1.1 template. It's built on top of the ImagiNation Network demo, whose interpreter is an exact match for the interpreters included in the SCI16 source. Said demo also has a complete set of system scripts.

The new template is in Sierra Script right from the start, and uses original Sierra names for globals, scripts, and procedures. Various game-specific subclasses (the inventory and icon bar, for example) are now in their own scripts (this became standard in the SCI32 era). There is no assembly code in any of the scripts. Basically, the code is much simpler, cleaner, and more accurate to Sierra's original code.

I plan to upload the template soon. I also plan to create an SCI2.1 template.

12
SCI Development Tools / Re: Decompilation Archive
« on: July 14, 2019, 01:20:46 PM »
Here's another one: the Gabriel Knight 1 demo. It seems to have been based off a beta version of the game, judging by the large amount of placeholder messages and the fact that it uses SCI1.1 rather than SCI2 like the full game does. Expect some bugs, but thankfully there are only two asm blocks (in proc211_0 and QScript). There's the needed script and interpreter to debug this thing.

I wonder why the demos for GK1, QFG4, and PQ4 used SCI1.1 instead of SCI2? My guess is that the 32-bit engine was not yet ready to be used, so the designers used the older 16-bit engine during development, then ported it to SCi2 when the full games were completed.

13
SCI Development Tools / Re: Decompilation Archive
« on: July 03, 2019, 11:21:53 PM »
Regarding PQ2demo's graphical error: No, it's actually related to the SWAT team arriving at the motel. One cop erases part of the police car. I think it's related to a decompilation error in the "swatArrives" script.

In any case, here's more decompiles! They are of the demos for LSL2, The Colonel's Bequest, SQ3, and Astro Chicken. All have been tested to completion.

14
SCI Development Tools / Re: Decompilation Archive
« on: July 02, 2019, 10:14:36 PM »
Here are some deconmpiles of the demos for Conquests of Camelot, QFG1VGA, PQ2, and the Fun Seeker's Guide!

They all fully compile and have been tested to completion. The only issue I found was a graphical error in the PQ2 demo; specifically, at the motel scene.

15
SCI Development Tools / Re: Decompilation Archive
« on: June 18, 2019, 08:40:14 PM »
Here is the decompile for the SQ6 demo! It includes a specific interpreter (taken from the SCI tools here) which has an internal debugger and no version stamp check. The latter part is important, as the original interpreter will refuse to run if the RESOURCE file has been modified, saying that it has not been version-stamped.

The game has been tested to completion, and seems like a good basis for a possible SCI32 template.

All of the system scripts are based from the newest SCI32 source from 10-12-1995, with the exceptions of:
   ACTOR.SC (06-28-1995)
   TALKER.SC (decompiled original)
   MESSAGER.SC (decompiled original)
   PLANE.SC (decompiled original)
   DTEXT.SC (06-28-1995)
   STYLER.SC (06-28-1995)

The reasons:
   Plane causes the title bar to lose its custom font.
   Talker is incompatible with the game, causing a "Not an Object" error when someone talks.
   Messager is incompatible, as anyone talking just gives a small "ALT" character and no voice.
   Actor and Styler are incompatible with the game, causing a "Not an Object" error at startup.
   DText causes the ComPost text's lines to leak out of the ComPost screen.

With Actor, Styler, and DText, it was just a matter of using the earlier script revisions from June 1995, more closely matching the game's release.
On the other hand, Plane, Talker, and Messager appear to have been specially modified for SQ6's custom talker and messager, which, in turn, seem to be based on the ones for LSL6 hr-res (to the point that some views for LSL6 are hidden in the resource files!).

There's only one bug that I can find. Specifically, the game's icon bar stops working after closing the control panel. It seems to be a decompilation error in the icon bar's doit, which can't be decompiled and thus is in assembly. For this reason, I've intentionally prevented it from compiling until it can be fixed.

Pages: [1] 2 3 ... 5

SMF 2.0.14 | SMF © 2017, Simple Machines
Simple Audio Video Embedder

Page created in 0.094 seconds with 21 queries.