Polygon Zones, and why not?

[volvo_0ne]

I wonder why there wasn't a polygon zone command in Amos Pro?, I sure could use one just now.

[ReadOnlyCat]

Originally Posted by volvo_0ne

I wonder why there wasn't a polygon zone command in Amos Pro?, I sure could use one just now.

What kind of kitten is this?
Do you mean a clipping rectangle for drawn polygons?

[volvo_0ne]

No, you can only have rectangular screen zones (for limiting or collision detection with background), but polygon flavour ones would be a nice thing to have, for more accuracy.

Maybe one of the accessories support this idea, but I've not noticed it yet.

eg: Set Zone Z,x1,y1 To x2,y2 To x3,y3 ....... etc making enclosed detection polygons rather than just rectangular zones

[Dunny]

Well, the "point in polygon" test is quite a lot harder than the "point in rectangle" test - so you'd not be wanting to do this in a complex, fast-moving situation.

That said, zones are traditionally only used when coupled with user-input, so speed isn't necessarily of the essence. It's do-able, but probably more complex than the author was willing to invest time in.

You could always rasterise your polygon and create many zones...

D.

[volvo_0ne]

Rasterise?

In Amos? please tell cos I'm lost now lol

[idrougge]

You could make bobs out of your poligons and use the collision commands.

[Dunny]

A very simple polygon filler would be your friend here:

http://alienryderflex.com/polygon_fill/

However, instead of drawing lines... Add a zone which occupies that line!

It's totally pointless though, as I don't suppose AMOS allows enough zones for it to be useful!

D.

[Lonewolf10]

There were a few features that were pulled and or left buggy due to time pressures from the publisher, as I understand it.

Polygon zones would be substantially harder to do and the involved maths would no doubt make a game significantly slower.

I'm not sure what the maximum number of zones is.

[Leffmann]

It's relatively simple to check if a point is inside a polygon, and you can do it using just integer math so it doesn't necessarily have to be costly, but if your polygon zones are static then try the easy solution first: use Bar, Polygon, Circle, etc. and draw your collision zones into a separate screen, and check the relevant pixel to see whether you hit something or not.

[volvo_0ne]

Maybe someone can come up with a solution to my problem....

Say I have a background like this.....
(Ignore the "-" dashes as spaces wouldnt work)

-----B------------------ /background graphics
-----O-----------------/background graphics
-----B----------------/background graphics

and the BOB is moving left to right
as it is, it would be ok because the bottom left of my rectangular zone around my background graphics would coincide with the lower "B" of the bob and trigger a collision

however consider if the bob were one or two lines higher up the screen, of course it would trigger a collision much earlier the higher up it was, thus being further away from the background gfx

Basically I'm looking for a bob to background collision detector I suppose?

[Samurai_Crow]

The BOB mask has all the bits set that are overdrawn by the BOB. All the clear bits are transparent. If you don't see any command to give you access to the mask plane, check the AMCAF instructions to see if it has one.

[Mrs Beanbag]

you could just use a separate screen (hidden) for the collision tests, use different colours for different regions (use Point(x,y) to get the colour from the other screen) and combine it with rectangular Zones as bounding boxes, so you'd only need maybe a 4 colour screen.

[volvo_0ne]

Originally Posted by Mrs Beanbag

you could just use a separate screen (hidden) for the collision tests, use different colours for different regions (use Point(x,y) to get the colour from the other screen) and combine it with rectangular Zones as bounding boxes, so you'd only need maybe a 4 colour screen.

Now that is a GREAT idea, thanks

[volvo_0ne]

Next question.....

I read that procedures are slower than gosubs, is it very noticable in tight loops?

eg 50fps bob/sprite routines?

ATM I'm writing a prog which loops in 1 vbl, but it's going to get tighter as things are added.

Without re writing, it's difficult to judge.

[Samurai_Crow]

Originally Posted by volvo_0ne

Next question.....

I read that procedures are slower than gosubs, is it very noticable in tight loops?

eg 50fps bob/sprite routines?

ATM I'm writing a prog which loops in 1 vbl, but it's going to get tighter as things are added.

Without re writing, it's difficult to judge.

The reason gosub is faster is that it doesn't allocate space on the stack for local variables and parameter passing. Whether it's fast enough for your code or not depends on the code and the purpose for which it is being done.

[Mrs Beanbag]

in my experience, AMOS procedure calls are very slow, even on compiled code. i don't know exactly what it is doing. Just pushing a few variables on the stack isn't enough to explain it (unless you're passing strings, which are expensive to copy, requires heap memory allocation). Allocating stack space is just a matter of subtracting an offset from the stack pointer, and adding it on again before the rts.

The only way to know if it's "fast enough" or not is obviously to try it, but if you're having speed problems you know what else to try instead.

[volvo_0ne]

Thanks Samurai_Crow & Mrs Beanbag I'll use gosub for now just in case

Next question........

In the AP manual it states.....

Note that AMAL expressions can include all of the normal arithmetic operations, except MOD. So a logical AND
(&) and a logical OR (|) may be used in AMAL expressions.

so why doesn't this test work?
This is a BOB by the way

AM$=AM$+"H: Let R1=7 ; If X+R0>RC | Y+R0>RD then Jump I ; Let X=X+R0;Let Y=Y+R0 ; P ; Jump Loop ; "

Where H: is just a label, R1=the direction flag Right/Down movement (set up for next iteration) R0=movement step(2) RC=X Limit(191) RD=Y Limit(191) X&Y obviously the Bob co-ords Loop Is a label to redo the whole thing depending on the value of R1.

Problem= The Bob moves in the correct direction BUT ignores the limits

By my reckoning "If X+R0>RC | Y+R0>RD" is "If X+R0>RC OR Y+R0>RD" then it should Jump to I: but it doesn't .

Basically it's a pre test to make sure the Bob isn't going to go out of bounds on the next move, however it seems to ignore the bounaries.

TIA
V1

[Mrs Beanbag]

what is I?
and what is P?

[volvo_0ne]

Originally Posted by Mrs Beanbag

what is I?
and what is P?

Sorry .....

I is a label (Which deals with changes of direction should the offending command be deemed true) and P is the Amal Pause instruction (basically wait VBL)

It's difficult to explain without posting the whole code, which obviously I don't want to do.

[Mrs Beanbag]

ah, manual actually says "Do not try to combine several tests into a single AMAL expression using the ampersand (&) or upright(|) characters."

Hmm... seems a bit of a limitation. I never actually used AMAL for animation, it seems more trouble than it's worth tbh...