Changes to SCI 1.1 template game

[troflip]

I'll use this thread to summarize/discuss any further changes to the template game.

[troflip]

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:

Code: [Select]

    13 AddPolygonsToRoom
    14 CreateNewPolygon

They look like this (add them after DebugPrint):

Code: [Select]

(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:

Code: [Select]

SetUpPolys_110()

should become:

Code: [Select]

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

[lskovlun]

This bit of the diff

Code: [Select]

+(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.

[troflip]

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.

[lskovlun]

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.

[troflip]

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.

[troflip]

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.

[Collector]

Sounds like a pretty straight forward way of doing it.

[MusicallyInspired]

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!

[troflip]

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?

[MusicallyInspired]

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.

[troflip]

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.

[Kawa]

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.

[MusicallyInspired]

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.

[MusicallyInspired]

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.