Author Topic: SCI Companion V3 - alpha build notes/bugs/feature requests  (Read 73322 times)

0 Members and 1 Guest are viewing this topic.

Offline Collector

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #885 on: October 16, 2018, 09:28:40 PM »
As mentioned on Twitter and related to the above post, my SCI Companion now has special handling for the File class. Assuming script 996 is always File.sc and Class_996_0 is File, it'll notice if it's that or gamefile_sh and call it File after all.

Astro Chicken names script 993 as File.sc with you build. the only error is "Error: (Main.sc) Unknown class 'gamefile_sh' .  Line: 759, col: 9"
KQII Remake Pic

Offline Kawa

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #886 on: October 17, 2018, 03:36:03 AM »
Right, forget that feature then. Between that and the endless redeco loop I encountered it might be better to just not enable those hacks.

Offline Kawa

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #887 on: October 21, 2018, 04:25:13 PM »
So apparently there's a bug where expressions like (+= [array someThing] 5) don't compile right. This has been fixed in the latest Experimental-branch commit, and I just integrated it in my own builds.

New MILD release: http://helmet.kafuka.org/sci/SCICompanion.exe

Included hacks: some vocab resource preview stuff, Display argument massaging.
Not included: the globals and script names thing... and the latest compiler feature, the &exists keyword. If you want the ability to say (if (&exists someParm) ...) instead of (if (>= argc 2), let me know.

Offline MusicallyInspired

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #888 on: October 27, 2018, 03:59:14 PM »
I wish you could get past your differences with GIT. It would make tracking your additions it easier.

I don't know if this influences anyone's decisions to use it one way or the other, but I've just learned today that Github was purchased by Microsoft for $7.5 billion. The co-founder has already stepped down.
Brass Lantern Prop Competition

Online lskovlun

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #889 on: October 27, 2018, 04:30:51 PM »
I don't know if this influences anyone's decisions to use it one way or the other, but I've just learned today that Github was purchased by Microsoft for $7.5 billion. The co-founder has already stepped down.
GitHub is not Git. Just sayin'.

Offline MusicallyInspired

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #890 on: October 27, 2018, 08:10:37 PM »
Oh. Please ignore my ignorance.
Brass Lantern Prop Competition

Offline Collector

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #891 on: October 27, 2018, 08:54:59 PM »
there are other GIT services. All of my stuff is on Bitbucket.
KQII Remake Pic

Offline Kawa

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #892 on: October 28, 2018, 05:13:02 PM »
Well, gentlepeople, I hope you're happy. Despite previous experiences with keys and shit, I found a way to git Git to work.

Which means yes, my horrible, horrible changes are now exposed to all the world.

Offline Collector

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #893 on: October 28, 2018, 08:41:28 PM »
Thanks for that.
KQII Remake Pic

Offline Kawa

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #894 on: November 06, 2018, 08:51:56 AM »
If you were to look at a random polygon-using Sierra game's decompilation, you'd see something like this.
Code: [Select]
(method (init)
(gRoom addObstacle:
((Polygon new:)
type: 2
init: 150 108 114 115 ...... 187 80 191 102
yourself:)
)
)
(super init:)
...
)
That's quite unlike what a Companion game would have.
Code: [Select]
; from (include 200.shp)
(local
[P_Default200 29] = [1 PBarredAccess 13 150 108 114 115 ...... 187 80 191 102]
)

(method (init)
(AddPolygonsToRoom @P_Default200)
(super init:)
...
)
Especially when you consider that the resulting bytecode is nothing alike, and the raw polygon data remains in the heap throughout the room's lifetime as locals. And you get a limit on how many points you can have under a single name.

In that light, I've been sitting on an idea that I implemented this morning, inspired by Phil's foreach keyword and my own "make it iterate through a Collection" hack. I made a getpoly keyword.

Giving each individual polygon a distinct name because reasons, you can now remove the include line, add a (use Polygon), and do this:
Code: [Select]
(method (init)
(gRoom addObstacle: (getpoly {Beach}) (getPoly {Path}) ...)
(super init:)
...
)
When compiled, each getpoly will expand into a ((Polygon new:) type: X init: ... yourself:) statement matching the .shp file. Convert all rooms and you can throw away those helper functions entirely.

This feature is available now on Github.

Edit: (getpoly {}) is now acceptable and will grab the "Default" poly. The internal thing that the polygon editor uses doesn't expose that with a name, hence the empty text box in the editor. This also allows the New Room dialog to generate something with minimal fuss.
« Last Edit: November 06, 2018, 01:08:55 PM by Kawa »

Offline EricOakford

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #895 on: January 15, 2019, 12:16:33 AM »
It would be a good idea to add support for non-integer defines. Sierra themselves used such defines, as seen in the SCI16 source scripts. These defines include complex equations. The SMOOPER script uses these defines extensively.

Also, the "repeat" statement tends to cause problems with the decompiler. The best example of a function that uses this is "death message" procedures.

Offline OmerMor

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #896 on: January 15, 2019, 03:30:24 AM »
It would be a good idea to add support for non-integer defines. Sierra themselves used such defines, as seen in the SCI16 source scripts. These defines include complex equations. The SMOOPER script uses these defines extensively.

Also, the "repeat" statement tends to cause problems with the decompiler. The best example of a function that uses this is "death message" procedures.

I added a feature request for the define statements:
https://github.com/icefallgames/SCICompanion/issues/19

I'd open one about the repeat statements, but I don't understand what the issue is. Can you formalize it a bit?

Offline OmerMor

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #897 on: January 15, 2019, 03:33:37 AM »
BTW, here's Sierra's documentation about repeat statements:

Quote
(repeat code)

     Continually execute the code until some condition in the code (a
     break) causes the loop to be exited.  This is equivalent to
          (while TRUE code)
     or
          (for () TRUE () code)
[/tt]

Offline Kawa

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #898 on: January 15, 2019, 03:38:05 AM »
The basic issue with repeat is that the decompiler can't hack it, gives up, and makes it an asm block instead. This also affects things like save-restore and asking for a new path.
« Last Edit: January 15, 2019, 03:58:27 AM by Kawa »

Offline OmerMor

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #899 on: January 15, 2019, 10:10:54 AM »
The basic issue with repeat is that the decompiler can't hack it, gives up, and makes it an asm block instead. This also affects things like save-restore and asking for a new path.

Thanks. Here's the bug report: https://github.com/icefallgames/SCICompanion/issues/20

You might want to add a comment there with an example of a repeat statement, the resulting bytecode, and what the decompiler outputs for it.
« Last Edit: January 15, 2019, 01:02:39 PM by OmerMor »


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

Page created in 0.126 seconds with 23 queries.