Community
SCI Programming => SCI Development Tools => Topic started by: troflip on June 26, 2015, 01:53:22 PM
-
I'll use this thread to summarize/discuss any further changes to the template game.
-
For 3.0.0.7, there are the following changes to the template game. The polygon editor won't work properly without these changes.
main.sc has two more exports:
13 AddPolygonsToRoom
14 CreateNewPolygon
They look like this (add them after DebugPrint):
(procedure (CreateNewPolygonHelper polyBuffer nextPoly)
(var newPoly, pointCount)
(= newPoly (Polygon:new()))
(= pointCount (Memory(memPEEK (+ polyBuffer 2))))
(send newPoly:
dynamic(FALSE)
type(Memory(memPEEK polyBuffer))
size(pointCount)
// Use the points directly from the buffer:
points(+ polyBuffer 4)
)
// Tell the caller the position of the next poly, if they care:
(if (> paramTotal 1)
Memory(memPOKE nextPoly (+ polyBuffer (+ 4 (* 4 pointCount))))
)
return newPoly
)
(procedure public (AddPolygonsToRoom polyBuffer)
(var polyCount)
(if (< polyBuffer 100)
TextPrint("polyBuffer is not a pointer. Polygon ignored.")
)(else
(= polyCount Memory(memPEEK polyBuffer))
(+= polyBuffer 2)
(while (polyCount)
(send gRoom:addObstacle(CreateNewPolygonHelper(polyBuffer @polyBuffer)))
--polyCount
)
)
)
(procedure public (CreateNewPolygon polyBuffer nextPolyOptional)
(var polyCount)
(if (< polyBuffer 100)
TextPrint("polyBuffer is not a pointer. Polygon ignored.")
return NULL
)(else
(= polyCount Memory(memPEEK polyBuffer))
(+= polyBuffer 2)
return CreateNewPolygonHelper(polyBuffer nextPolyOptional)
)
)
In your rooms, this:
SetUpPolys_110()
should become:
AddPolygonsToRoom(@P_Default110)
(replace with the right pic number of course)
To get the .shp files converted, open the pic in question and re-save it, and the polygons will be in the new format (local vars instead of procedures). Version 3.0.0.8 will remove support for reading the old-style polygon format, so make sure to use 3.0.0.7 to convert.
There are other minor changes to the template game (just updating constants and variable names). Nothing that really needs updating if you already have a game.
https://github.com/icefallgames/SCICompanion/commit/78c1643573a661c2220d178ded8ee564fd4b5697
-
This bit of the diff
+(local
+ P_Default110[27] = (2 PBarredAccess 6 197 60 269 68 286 85 267 101 225 101 202 89 PBarredAccess 5 0 63 45 67 47 87 22 96 0 97 )
+ P_Bottom[10] = (PBarredAccess 4 79 146 220 155 204 168 59 166 )looks a bit odd. The first one has a count of polygons at the very beginning, the other one does not. So I would expect one to be suitable for AddPolygonsToRoom and the other one (not in the default set) to be passed to CreateNewPolygon. There is no other indication of this - perhaps put a comment?
Other than that, it looks good.
-
Yeah, originally I had a 1 in there to have both forms be consistent, but for some reason I changed it. I might change it back and just have CreateNewPolygon throw up a warning if it's passed one with more than 1 polygon.
-
Another thing, you're making a new dynamic polygon out of something that is almost guaranteed to remain in memory anyhow. The point list is in local variables now, and unless you want to protect against changes in the local array, memory is being allocated (= possible fragmentation) here for no apparent reason. For most purposes, setting dynamic to FALSE and pointing points inside the original array should be sufficient.
-
Good point. Originally I figured that someone could create multiple of these polygons and edit the points of just one of them? That's not a common scenario I suppose (and I suppose there is still a way for them to do that if they want). And the way I was creating the polygons before (from immediately values passed as parameters, which is how some Sierra games do it) was also causing the same kind of fragmentation - so I figured this wasn't too bad.
But yeah, seems like it might be better to just use the points directly.
Changes made as per Lars' suggestion.
-
For version 3.0.0.7, the global palette has also been changed to that of KQ5.
I added a pretty low-tech solution if you want to remap existing views to the new palette:
- make sure both palette resources exist in the game. You can make the new palette the global palette after, or now, doesn't matter.
- open the view resource
- if you want, remove the embedded palette from the view resource (view->remove embedded palette). They seem pointless anyway, and if you leave it in, you'll need to modify it to have the colors from the new global palette.
- choose Remap Palette from the view menu
- choose the "from" and "to" palettes and hit ok
- Now the view should be converted. You can see what the results look like by selected the "to" palette in the left-hand pane.
-
Sounds like a pretty straight forward way of doing it.
-
Embedded palettes for views aren't entirely pointless. They're great for animated sections of a background that need to utilize the background's palette. Like the animated fading in of the "IV" in KQ6's title screen, for instance, or closeup cutscene/dialogue sequences in many games. Otherwise they'd stick out like a sore thumb using the default global 64 colour palette. Love this functionality, though. Thanks!
-
Embedded palettes for views aren't entirely pointless. They're great for animated sections of a background that need to utilize the background's palette. Like the animated fading in of the "IV" in KQ6's title screen, for instance, or closeup cutscene/dialogue sequences in many games. Otherwise they'd stick out like a sore thumb using the default global 64 colour palette. Love this functionality, though. Thanks!
Hmm... I still don't get it. I just tried removing the embedded palette for the IV, and it still looked the same (since the background pic sets the palette, and it uses the same palette as the one embedded in the view).
I still don't see a case where it would be useful. And most of the embedded palettes in the views in SQ5 are just copies of the global palette. Maybe it was only useful as an editing tool, to see what the view will look like on a particular background? Or if a background is totally blank (and has no palette), then the view's palette will be used?
-
Well yeah, you can't create a view animation that looks like the background without the background's palette. Otherwise it'd only be black. While you're editing, anyway.
-
Idea for a tutorial: how to use views as animated/moving backgrounds. i.e. export palette from the pic, add a palette to a view, import that palette to the view's palette.
-
Idea for a tutorial: how to use views as animated/moving backgrounds. i.e. export palette from the pic, add a palette to a view, import that palette to the view's palette.
I like that idea.
-
Yeah, that works great. I wasn't looking for extra functionality, just pointing out that embedded palettes in Views have a purpose, even if it's only when editing.
-
A small contribution. I recommend using this version of the test inventory coin item that uses the orange-ish hues as opposed to the current yellow conversion which caused some colour loss. The image is based on the coin from SQ4 which uses the same colours.
-
Everytime I think of the line "cash, money, spendola," I think of the Powerpuff Girls.
This is not just because it's 02:21 AM.
-
For the next version of the SCI Companion (3.0.0.10), you can change the following template game code in main.sc:
(procedure (CreateNewPolygonHelper polyBuffer nextPoly)
(var newPoly, pointCount)
(= newPoly (Polygon:new()))
(= pointCount (Memory(memPEEK (+ polyBuffer 2))))
(send newPoly:
dynamic(FALSE)
type(Memory(memPEEK polyBuffer))
size(pointCount)
// Use the points directly from the buffer:
points(+ polyBuffer 4)
)
// Tell the caller the position of the next poly, if they care:
(if (> paramTotal 1)
Memory(memPOKE nextPoly (+ polyBuffer (+ 4 (* 4 pointCount))))
)
return newPoly
)
(procedure public (AddPolygonsToRoom polyBuffer)
(var polyCount)
(if (< polyBuffer 100)
TextPrint("polyBuffer is not a pointer. Polygon ignored.")
)(else
(= polyCount Memory(memPEEK polyBuffer))
(+= polyBuffer 2)
(while (polyCount)
(send gRoom:addObstacle(CreateNewPolygonHelper(polyBuffer @polyBuffer)))
--polyCount
)
)
)
(procedure public (CreateNewPolygon polyBuffer nextPolyOptional)
(var polyCount)
(if (< polyBuffer 100)
TextPrint("polyBuffer is not a pointer. Polygon ignored.")
return NULL
)(else
(= polyCount Memory(memPEEK polyBuffer))
(+= polyBuffer 2)
return CreateNewPolygonHelper(polyBuffer nextPolyOptional)
)
)
to the following:
// Returns the position of the next polygon in the buffer
(procedure (CreateNewPolygonHelper polyBuffer newPolyAddress)
(var newPoly, pointCount)
(= newPoly (Polygon:new()))
(= pointCount (Memory(memPEEK (+ polyBuffer 2))))
(send newPoly:
dynamic(FALSE)
type(Memory(memPEEK polyBuffer))
size(pointCount)
// Use the points directly from the buffer:
points(+ polyBuffer 4)
)
Memory(memPOKE newPolyAddress newPoly)
return (+ polyBuffer (+ 4 (* 4 pointCount)))
)
(procedure public (AddPolygonsToRoom polyBuffer)
(var polyCount, newPolygon)
(if (< polyBuffer 100)
TextPrint("polyBuffer is not a pointer. Polygon ignored.")
)(else
(= polyCount Memory(memPEEK polyBuffer))
(+= polyBuffer 2)
(while (polyCount)
(= polyBuffer (CreateNewPolygonHelper(polyBuffer @newPolygon)))
(send gRoom:addObstacle(newPolygon))
--polyCount
)
)
)
(procedure public (CreateNewPolygon polyBuffer)
(var polyCount, newPolygon)
(if (< polyBuffer 100)
TextPrint("polyBuffer is not a pointer. Polygon ignored.")
return NULL
)(else
(= polyCount Memory(memPEEK polyBuffer))
(+= polyBuffer 2)
CreateNewPolygonHelper(polyBuffer @newPolygon)
return newPolygon
)
)
This is to handle the crash in ScummVM
-
The next iteration of the template game will have some major name changes, in an attempt to get rid of all the "SQ5" stuff littered everywhere.
First, the global variable names:
gSq5Win -> gWindow
gSq5Music1 -> gMusic1
gSq5Music2 -> gMusic2
gSq5IconBar -> gIconBar
gGSq5IconBarCurIcon -> gCurrentIcon
gSq5IconBarCurInvIcon -> currentInvIcon (main.sc only, it's actually not a global)
gSq5Inv -> gInv
gSQ5Narrator -> gNarrator
Then, some of the class names:
SQ5 -> Template (game class name)
sq5StatusLineCode -> statusLineCode
Sq5InvItem -> InvItem
SQ5ControlItem -> ControlItem
And two of the files:
sq5invitem.sc -> InvItem
sq5ControlItem.sc -> ControlItem
And other files will have their internal variables changed to remove sq5.
If you have a game you're working on, you don't really need to change anything. The only "incompatibility" you might have with SCI Companion is the Insert Object functionality might refer to global variables.
-
To think I just replaced all my Sq5 with Cd.
-
What's Cd?
-
What's Cd?
An acronym for the name of a game I'm working on, like Sq5. But not unlike Police Quest 4 Open Season, it doesn't match what's actually shown.
-
Cat something? Oh, I am so looking forward to this. I loved the Katta in the QfG series.
-
Playing around with my "explore SCI1.1" game, I found it would be nice to have the "case" property on Features (and Views/Props/Actors). This lets you display a different message (when interacting with an object) depending on the state an object is in, without having to override the doVerb method and calling gTestMessager:say directly (or changing the noun at runtime).
I was able to get it to work by adding the case property (actually _case), changing a couple of lines of code in Feature.sc, and using the LSL6 994.voc (instead of the SQ5 994.voc, which is what the template game is currently using). What do people think about making these changes in the template game?
-
Playing around with my "explore SCI1.1" game, I found it would be nice to have the "case" property on Features (and Views/Props/Actors). This lets you display a different message (when interacting with an object) depending on the state an object is in, without having to override the doVerb method and call gTestMessager:say directly (or changing the noun at runtime).
I was able to get it to work by added the case property (actually _case), changing a couple of lines of code in Feature.sc, and using the LSL6 994.voc (instead of the SQ5 994.voc, which is what the template game is currently using). What do people think about making these changes in the template game?
Curious. Why would you need to replace 994.voc?
-
Curious. Why would you need to replace 994.voc?
It's the one that defines the offsets at which certain property selectors are found in objects (you were the one who explained it to me!).
If I add the "case" property to Feature, it will change the offsets of all the properties that follow it.
With "case" added, the property layout now looks like LSL6, hence the need for the LSL6 994.voc. If I use the SQ5 994.voc, the first (noticeable) error I get is related to the interpreter interpreting the yStep property as the view resource to use.
-
That sounds like a pretty good feature to have, actually.
-
Curious. Why would you need to replace 994.voc?
It's the one that defines the offsets at which certain property selectors are found in objects (you were the one who explained it to me!).
Ha ha, yes I did. I think the question I was getting at is why does the version from LSL6 work? Coincidence?
-
Lsl6 Features have a case property following the noun property. So, this makes the template game property layout just like the lsl6 layout. I guess that's the only difference between the two games? I dunno... I'm using it for my little project and it works so far. We'll see if I run into any problems...
-
There's a few things named lb2 in the template too -- lb2DoVerbCode, lb2FtrInit, lb2ApproachCode... reused from Laura Bow 2, it seems.
-
For version 3.0.0.12:
To make your existing game support speech, do the following:
- open your game, and go to Game->Version Detection
- Set Audio volume name to "aud/sfx"
- Set Audio36 map format to "Sync map late"
- Check "Supports message audio"
- Click on Reload game
- Go to the Messages tab and open message 110
- Click on an entry in there and use the record button to assign a wav to it (if you have a microphone), or "browse" for a wav file to assign to it.
- Save the message 100 resource
- Click the "repackage audio files" button at the top of the message editor (or just run your game, which will do a repackage automatically)
- Now you should be able to close your game and re-open it and it will be detected as a game that supports message audio (if you close your game before completing all these steps, you'll have to start over at step 1 again).
Finally, you need to replace Talker.sc and Messager.sc with those from the latest SCI 1.1 template game.
Then, in your game's init method in main.sc, where it says:
= global90 $0001
change this to
= global90 $0003
(changing it to $0002 means speech only, $0003 means both speech and text)
Recompile things and you should be good to go.
-
There is a decompilation bug in the template game. In PAvoider.sc, change this:
= temp16 MergePoly((send temp17:points) (send ((send clientMover:obstacles)):elements) (send ((send clientMover:obstacles)):size))
(if (temp16)
= newPolygon (Polygon:new())
(send newPolygon:
points(newPolygon)
size(localproc_042b(newPolygon))
type(PBarredAccess)
dynamic(1)
)
)
to this:
= temp16 MergePoly((send temp17:points) (send ((send clientMover:obstacles)):elements) (send ((send clientMover:obstacles)):size))
(if (temp16)
= newPolygon (Polygon:new())
(send newPolygon:
points(temp16)
size(localproc_042b(temp16)
type(PBarredAccess)
dynamic(1)
)
)
(Guess no one has used PAvoider yet!)
-
The icon/inv renames, if you care to do it:
Steps:
- save IconI.sc as IconItem.sc and rename the class
- rename file in explorer and delete iconi.*
- name IconI to IconItem everywhere
- Replace InvI's doVerb with InvItem's doVErb, and add (include "Verbs.sh") to the top of the file.
- Now InvItem is empty. Delete it.
- save InvI.sc as InventoryItem.sc and rename the class
- rnemae file in explorer and delete invi.*
- replace usages of InvI with InventoryItem. Recompile InventoryItem, then recompile all
- In InventoryItem.sc, rename Inv to Inventory. Recompile it, then recompile all
- Copy class Inventory from InventoryItem.sc into ScrollableInventory.sc, rename it InventoryBase and add the necessary use statements. Also copy localproc_0814 and the local0 script var
- recompile InventoryItem.sc and ScrollableInventory.sc, then recompile all (you'll need to add (use "ScrollableInventory") to Game.sc
- Save InvItem.sc as Inventory.sc and rename in game explorer. Delete InvItem.*
EDIT:
- Also, ControlItem is removed, and its select method gets folded into ControlIcon.
-
If the renaming proves to be too problematic it might be good to have a list of what each one is. This could be put in any tutorials or references here and on the Wiki. Most should catch on quickly enough, so this would probably be in a beginner tutorial.
-
Class renames:
*DNKR -> DisposeNonKeptRegion
*Fwd -> Forward
*CT -> CycleTo
*End -> EndLoop
*Beg -> BegLoop
*Osc -> Oscillate
*ROsc -> RangeOsc
*Rev -> Reverse
*MCyc -> MoveCycle
*Obj -> Object
*Rm -> Room
*Rgn -> Region
*Collect -> Collection
*Blk -> Block
* SQEgo -> GameEgo
*Grooper -> GradualLooper
*Grycler -> GradualCycler
Procedure renames:
*GetTotalLength -> FindFormatLen
*EditPrint -> GetInput
*DoesRectContain -> InRect
*Perform -> Eval
*IsFacing -> CantBeSeen
*GetMouseRelease -> MouseStillDown
*TextPrint -> Prints
*FormatPrint -> Printf
Script file renames:
* Osc -> Oscillate
* MCyc -> MoveCycle
* Blk -> Block
* SQEgo -> GameEgo
* Obj -> System (yikes!)
* ROsc -> RangeOscillate
* Rev -> Reverse
* Helpers -> Sight
* MessageObj -> Conversation
Lots of global variable renames:
- global81 -> gSyncBias.
- global17 -> gTextCode.
- global34 -> gUseSortedFeatures
- global67 -> gEgoUseObstacles
- gFont_2 -> gInputFont
- global86 -> gTickOffset
- global90 -> gMessageType
- gLastTicks -> gGameTime
- gOldCast -> gCast
- gOldATPs -> gAddToPics
- gRoomNumber -> gNewRoomNumber // NOTE the next one below... proceed in this order
- gModNum -> gRoomNumber
- gNewSet -> gCuees
- gCursor -> gNormalCursor
- gInvisibleCursor -> gWaitCursor
- gOldFeatures -> gFeatures
- gCastMotionCue -> gDoMotionCue
- gNewSync -> gTheSync
- gNewEventHandler -> gFastCast
- gTestMessager -> gMessager
- gPrintEventHandler -> gPrints
- gOldWH -> gWalkHandler
Game::changeScore is gone.
AddToScore no longer takes a flag, just a number
ScoreFlag is what AddToScore was previously
in sci.sh:
noCycler has become skipCheck
csFOCUSED has become csEXIT
csDISABLED has become csFILTER
kernels:
CanBeHere renamed to CantBeHere
Removed: class SL
-
Will these be added to an auto complete?
-
I'm not sure what that means?
-
Like the VS Intellisense. I don't know if the control for your script editor includes it. In other words start typing and at certain points there will be a dropdown of possible key words/class names, etc. that match.
-
Oh yes, it supports it. It's not affected by renames though, it compiles scripts in the background to resolve names.
-
Oh, I realize that the renames would not affect it, just that with the longer names it would be nice to have them added to the autocomplete so you don't have to fully type them out every time. That reminds me, I still have to add the NSIS keywords to the autocomplete for my NSIS script editor. At least I have the syntax highlighting mostly done.
-
Bug fix:
The two places in Main.sc that have:
(if (< polyBuffer 100)
should become
(if (<u polyBuffer 100)
Otherwise you may get erroneous "polyBuffer is not a pointer. Polygon ignored." messages when adding polygons to a room.
-
Remove this from both the init and the doit method of the Game class in Main.sc:
(if (== gColorDepth 256)
Bset(0)
)
-
I added message case support to the template game:
https://github.com/icefallgames/SCICompanion/commit/20d8f2ab3f09c9ba23e76125738db2f8ddceefb1
(this change also contains some defines for the scale signal of features... you can ignore those, since the needed defines are in sci.sh, which is part of Companion).
That means that - in addition to setting the noun - you can set the _case property of an feature, actor, prop, room etc. And only messages with the matching noun/case will be shown. You might use this, for instance, if you have a cup (N_CUP, C_INTACT), and then it gets broken. Set the _case property to C_BROKEN). It's still the same cup, but in its broken condition you could have different messages displayed for it.
You'll need the LSL6 vocab 994 resource in order for this to work, since it changes the property layout of several important base classes. It is attached.
You'll need to recompile several times for this to "propagate" to all the classes (e.g. for a change in Feature.sc, recompile once and Actor.sc will pick it up. Recompile another time and ego.sc will pick it up. Recompile another time and GameEgo.sc will pick that up. Yes, the compile behavior is kind of broken - so much for "use" statements).