Author Topic: Changes to SCI 1.1 template game  (Read 19358 times)

0 Members and 1 Guest are viewing this topic.

Offline Kawa

Re: Changes to SCI 1.1 template game
« Reply #15 on: July 11, 2015, 08:22:22 PM »
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.

Offline troflip

Re: Changes to SCI 1.1 template game
« Reply #16 on: July 12, 2015, 06:29:12 PM »
For the next version of the SCI Companion (3.0.0.10), you can change the following template game code in main.sc:

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

to the following:


Code: [Select]
// 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
Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline troflip

Re: Changes to SCI 1.1 template game
« Reply #17 on: July 20, 2015, 12:23:55 AM »
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.
Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline Kawa

Re: Changes to SCI 1.1 template game
« Reply #18 on: July 20, 2015, 04:42:00 AM »
To think I just replaced all my Sq5 with Cd.

Offline troflip

Re: Changes to SCI 1.1 template game
« Reply #19 on: July 20, 2015, 04:47:42 AM »
What's Cd?
Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline Kawa

Re: Changes to SCI 1.1 template game
« Reply #20 on: July 20, 2015, 07:12:04 AM »
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.

Offline lskovlun

Re: Changes to SCI 1.1 template game
« Reply #21 on: July 21, 2015, 01:15:05 AM »
Cat something? Oh, I am so looking forward to this. I loved the Katta in the QfG series.

Offline troflip

Re: Changes to SCI 1.1 template game
« Reply #22 on: July 22, 2015, 03:27:17 AM »
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?

« Last Edit: July 22, 2015, 05:13:47 AM by troflip »
Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline lskovlun

Re: Changes to SCI 1.1 template game
« Reply #23 on: July 22, 2015, 03:50:05 AM »
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?

Offline troflip

Re: Changes to SCI 1.1 template game
« Reply #24 on: July 22, 2015, 04:34:35 AM »
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.
Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline Kawa

Re: Changes to SCI 1.1 template game
« Reply #25 on: July 22, 2015, 04:58:58 AM »
That sounds like a pretty good feature to have, actually.

Offline lskovlun

Re: Changes to SCI 1.1 template game
« Reply #26 on: July 22, 2015, 05:20:44 AM »
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?

Offline troflip

Re: Changes to SCI 1.1 template game
« Reply #27 on: July 22, 2015, 05:39:01 AM »
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...
Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline Kawa

Re: Changes to SCI 1.1 template game
« Reply #28 on: July 22, 2015, 07:03:54 AM »
There's a few things named lb2 in the template too -- lb2DoVerbCode, lb2FtrInit, lb2ApproachCode... reused from Laura Bow 2, it seems.

Offline troflip

Re: Changes to SCI 1.1 template game
« Reply #29 on: October 14, 2015, 08:37:44 PM »
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:

Code: [Select]
= global90 $0001

change this to
Code: [Select]
= global90 $0003

(changing it to $0002 means speech only, $0003 means both speech and text)

Recompile things and you should be good to go.
Check out my website: http://icefallgames.com
Groundhog Day Competition


SMF 2.0.19 | SMF © 2021, Simple Machines
Simple Audio Video Embedder

Page created in 0.047 seconds with 23 queries.