Author Topic: SCI1.1: The joy of Polygons  (Read 9996 times)

0 Members and 1 Guest are viewing this topic.

Offline troflip

Re: SCI1.1: The joy of Polygons
« Reply #15 on: June 19, 2015, 04:05:18 PM »
This should get a lot easier when I have the polygon editor working (keep getting distracted).
Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline MusicallyInspired

Re: SCI1.1: The joy of Polygons
« Reply #16 on: June 19, 2015, 04:12:34 PM »
Yeah, Ego is somehow escaping the polygon barriers I've created now so I'll just wait to do them until after. Hard working blind. :)
Brass Lantern Prop Competition

Offline Cloudee1

Re: SCI1.1: The joy of Polygons
« Reply #17 on: June 24, 2015, 11:37:02 PM »
So I have come to the conclusion that polygons really aren't as smart as I had anticipated them being.  I have had to resort to also including control lines and instructing ego to observe them in order to truly control the boundaries. I try to place the control lines just inside the polygon areas to let them do their thing if they are going to, but I am finding that they really don't. At least not to the extent that I thought they would.

I need to run a test with one of Sierra's rooms using their points and background and play the original and the template side by side to see if it is just my expectations that are too high.
Halloween Competition Brass Lantern Prop Competition Groundhog Day Competition

Offline troflip

Re: SCI1.1: The joy of Polygons
« Reply #18 on: June 25, 2015, 12:02:26 AM »
What are your expectations? What type of polygons are you using, and what do they look like?
Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline troflip

Re: SCI1.1: The joy of Polygons
« Reply #19 on: June 25, 2015, 12:14:21 AM »
Here are the polygons from a couple of rooms from LSL6.

I'd guess the top image has a single contained access polygon, while the lower one (lobby) has three barred access polygons.

What's clear from this is that I need to make it easy to extend polygons to the pic edges.

Also, it looks like only the ego's hot spot is checked against polygon boundaries, not the entire bounds rect like with control lines. So the ego's feet can easily extend into a barred access polygon, for instance.
« Last Edit: June 25, 2015, 05:49:34 AM by troflip »
Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline troflip

Re: SCI1.1: The joy of Polygons
« Reply #20 on: June 26, 2015, 05:08:12 PM »
I'm trying to figure out how I can avoid having to embed the pic number in the method for setting up the default room polygons and create new named polygons. Since I want to also support including multiple polygon header files in one room, and without embedding the pic number in the procedures, there would be name conflicts.

Here's an alternative proposal:

SetUpPolygons and CreateNewPolygon become global functions in main. Instead of taking a define that identifies the polygon, they take the address of a local variable from the script. The local variable would be an array of values that consist of: the number of polygons associated with that variable, followed by the following for each polygon: type, number of points, x/y for each point.

So the *.shp file might look like:

Code: [Select]
(local
    P_110[???] =  (2 PBarredAccess 3 212 68 45 67 47 88 PBarredAccess 5 12 68 269 68 286 85 267 101 225 101)
                  )
    P_SomeName[8] = (1 PBarredAccess 3 212 68 45 67 47 88)
)

Then in the room's init, you'd have:

Code: [Select]
AddPolysToRoom(@P_110)

and to create polygons dynamically (for path motions, or to add around new features that appear after room init:

Code: [Select]
(send gRoom:addObstacle(CreateNewPolygon(@P_SomeName)))

I'm trying to make this as easy as possible to code against, while still being flexible enough to accomplish any task.

Thoughts?
Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline Kawa

Re: SCI1.1: The joy of Polygons
« Reply #21 on: July 02, 2015, 12:51:42 PM »
Okay I gotta be misunderstanding something here.

I got my sample room that I've been working on. It has a Contained polygon outlining the floor and extending a bit into the doorway, and two Barred polygons surrounding the table and lamp. I also have control lines in the doorway like SCI Studio's version has, and white control lines surrounding the floor like the first polygon does. There is, as per default, an AddPolygonsToRoom(@P_Default110) statement, and Ego starts in the middle of the room.

I can't walk through the table or lamp. If I click the wall, Ego walks up to it and stops at the edge. But if I click near (not even in) the doorway, Ego walks over the wall to the nearest point inside the doorway.

Offline troflip

Re: SCI1.1: The joy of Polygons
« Reply #22 on: July 02, 2015, 01:07:38 PM »
Aha! Played around with this. Polygon winding order *does* matter. (I thought I read in the freessci intern polygon spec that it didn't). At least it matters for contained access polygons. Try drawing your contained access polygon with the points going counter clockwise and see if that works for you.

And it looks like barred-access polygons need to go in clockwise order.
« Last Edit: July 02, 2015, 01:11:26 PM by troflip »
Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline Kawa

Re: SCI1.1: The joy of Polygons
« Reply #23 on: July 02, 2015, 01:33:48 PM »
Aha! Played around with this. Polygon winding order *does* matter. (I thought I read in the freessci intern polygon spec that it didn't). At least it matters for contained access polygons. Try drawing your contained access polygon with the points going counter clockwise and see if that works for you.

And it looks like barred-access polygons need to go in clockwise order.
That solved it handily, yeah. Well, I guess you can have your sample room shortly then...


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

Page created in 0.107 seconds with 24 queries.