unsticky focus, equations
 

When using setfocus, my equations didnt work perfectly at first to keep the screen from sticking off the edge of the levels. :(...

My final equations:
viewy=screenheight/32-1.5
viewy=62.5-screenheight/32
viewx=screenwidth/32-1.5
viewx=62.5-screenwidth/32

Why is -1.5 involved with the equations for setfocus in scrolling the sides of the level? I only figured this out by tweaking. Is this a bug? Where does the -1.5 come from? It confuses me :(...

screenwidth and screenheight measure the width and height of you screen not your level. that means that if your resolution is 800x600, screenheight returns 600 and screenwidth returns 800. likewise many computers use 1024x800, in which it would return a different value. screenwidth and screenheight return different values based on computer resolution.

the way you want to do it is based on tiles. the setfocus command doesn't work off of the position relative to the screen, it works off the position relative to the level. if you try setfocus 32,32; it should be centered in the screen. the reason your equation worked is because your screen size just happens to be the right size... for others it may not work so nicely :)

These are equations for when the view is on the outside border of the level, or at least that's what I want them to be, and they've worked so far (at least for me).

I did it on 1024x768 and 800x600, I checked it with at least 3 different window dimensions on both. 1024x768 is not proportionate to 800x600 although it is close, so I think I'll check on 800x600 again.

I do not want to do this based on tiles. The point of the script is to restrict the view to going into coordinates that are outside of the level (which causes the view to seem like it sticks to the side of the level), which you cannot do without something along the lines of these equations. If you do it by tiles then it is different for everyone with a different window size or resolution. If I'm incorrect with my equation, then I am close.

If screenheight and screenwidth are the size of the computer screen and not the window within which Graal is playing, I don't understand why this would work when you resize the window, although you're probably right about it because I know next to nothing about scripting, or at least that's what I say.

lol the 1.5 comes from the players width... (0.5, 2, 0.5), total width 3.. 3 tiles /2 = 1.5 ;) It's just to keep it all centred on the player.. because x/y returns the top left hand corner of the player :P

screenwidth and screenheight are the width and height of your graal "window". setfocus, however, doesn't go with these factors. setfocus works with level width and level height (on a standard level, 64x64 tiles) however setfocus can go to -128 to 128 on a gmap, if I'm not mistaken. so using screenwidth and screenheight with setfocus would be pointless.

Isnt it only nine levels that are loaded??

level-tl,level-t,level-tr
level-l, player ,level-r
level-bl,level-b,level-br

If it was only 9, max would be -64,128 for x/y :O

Sorry for double posting.. but i also noticed you /32 x.x that's wrong... graal tiles are 16x16 pixels ;x... 32x32 = 4 tiles

NPC Code:

---

viewx=playerx-1.5; if (viewx<0) viewx = 0;

---

And i think that should be what your looking for ;) You can work out the rest. :)

When I made this script I was thinking on multiples of 16 and fooling around a bit. I didn't post the entire script but the key equations in it.

I already know it works, so don't say that it won't unless you've checked on something other than 800x600 or 1024x768. I just don't know how it works. I made it without knowing what I was doing is what I'm trying to say.

Like I am saying... I was just working on multiples of 16 because tiles in a row/column of a level are 64, pixels per tile are 16, etc.

All you did was list some equations, you didn't explain how they were used. Are they the imposed limits for focusx and focusy?

No, they are the equations for the sides of the levels. They are the equations that the focusx and focusy go to after you go over the imposed limit, which would require the same equations with a < or >.

I explained how they were used, to keep the focus from having a "sticking" effect at the sides of the levels (going outside the borders of the level). This could also keep them from going into other mapped levels.

Right, so they are, in fact, the imposed limits for focusx and focusy.

You explained what they were used for, not how they were used. Anyway, the answer has already been given; setfocus has an automatic offset of (playerwidth/2,playerheight/2) for some reason.