[SOLVED] Bottom of the Screen

[Gurok]

In the default game, if Roger is standing at the bottom of the screen, his feet don't touch the bottom. Here's the output of me walking to the bottom and hitting CTRL+D:

[imgzoom]http://i.imgur.com/Eq8cdOH.png[/imgzoom]

I checked a few of his sprites and there was no space at the bottom of them. Does anyone know why this happens? And is there a better solution than using player.z to adjust his position?

EDIT: It's possible, but it should be noted that it basically means redoing existing rooms. As far as I can tell, there are two equally impractical solutions:

- Change all of your rooms to be 320x201 and fix the viewport to the top of the screen. Not a big hassle, but you'll have to re-import the walkable area masks because the BG size changed.
- Shift the player using player.z = -1. A bit awkward because existing walkable areas won't line up with the player anymore.

[Khris]

The player sprite is drawn at player.y - sprite.height.
Let's say a sprite is 30 pixels high, this means it'll get drawn to y = 169. The final row of pixels is thus @ y = 169 + 29 = 198.

I guess up until now nobody really cared about the fact that the sprite is actually drawn 1 pixel further up than one might expect. It's an easy fix and doesn't matter for 99% of games / people anyway.
If you want to get nitpicky, you have to move the sprite down a few pixels anyway (unless you made a front-view 2D game), since the actual bottom center of the character will usually be a few pixels further in.

[Gurok]

Hmmm... I guess I'll get over it then. My initial thought was that there was something wrong with my game, but when I found the same behaviour in the default game, I thought I'd ask questions. As it turns out though, it's too much fuss to shift everything by one pixels (walkable areas need to be adjusted), so I guess I'm just going to stick with it! Would be nice if there was a way to make row 200 walkable somehow. I guess I could if I extended my rooms. Thanks for the info though, Khris.

[Khris]

Well, row 200 IS walkable. What's off is just the way AGS draws the player walking there. So this is not really a technical issue, since you can easily use player.z, like you suggested. As far as I can see, this method has no downside whatsoever, it's the perfect fix. It does not affect the player's position with regards to areas and other characters. All it does is display the player further down, which is exactly what you're looking for.
Moving walkable areas is the worst possible way to "fix" this; they should always correspond to the room backgrounds, otherwise you'll soon find yourself in the seventh circle of walkbehind hell.

[Gurok]

Hrmm... maybe I should've been clearer. By row 200, I meant the row at y = 200. The row at y = 199 is walkable now. After setting player.z = -1, I found that I would have to redo all of my walkable areas as the characters no longer lined up with them (off by 1). Extending the room by one pixel, i.e. making it 201 pixels tall, is probably the neatest solution for me. But that requires reimporting all of the backgrounds and walkable areas, so it's still too much work. I think the whole thing is a mess and had I known about it from the beginning, I'd have made my rooms 320x201 and fixed the viewport so that only the top 320x200 was visible.

[Snarky]

There is no row y=200 in a 320x200 background. The y coordinate goes from 0 to 199.

Edit: Corrected

[Gurok]

I don't know what you're trying to say, Snarky. Do you treat the axes as continuous?

[Snarky]

No. I was responding to this bit:

Hrmm... maybe I should've been clearer. By row 200, I meant the row at y = 200.

I'm saying that a 320x200 background has 200 possible values for the y-coordinate: 0, 1, 2, 3, .... 198, 199. y=200 is not a valid on-screen coordinate in this resolution; the highest possible y-coordinate, corresponding to the bottom row of the screen, is y=199. That's because you start counting at zero.

[Gurok]

No. I was responding to this bit:

Hrmm... maybe I should've been clearer. By row 200, I meant the row at y = 200.

I'm saying that a 320x200 background has 200 possible values for the y-coordinate: 0, 1, 2, 3, .... 198, 199. y=200 is not a valid on-screen coordinate in this resolution; the highest possible y-coordinate, corresponding to the bottom row of the screen, is y=199. That's because you start counting at zero.

I realise that. y = 200 is out of bounds in a 320x200 background. I know how zero-based indices work. That's why I said "would be nice if there was a way to make row 200 walkable somehow" and suggested using a 320x201 background to allow me to place characters on the row at y = 200. Check your first comment though, it says "There is no row y=199 in a 320x200 background." ... that's what confused me. There is definitely a row where y = 199.

[Snarky]

Ah yes, my mistake there.

I have to agree with Khris that the correct way to deal with this is to use the Character.z property to align the sprite so it appears to stand on the correct coordinate. If you do that, then there shouldn't be any problems with the walkable areas (assuming they were correctly drawn in the first place), and if there is I would want to investigate why.

I assume you're not actually working on a standard point-and-click adventure here, since in that case it would be absurd to worry about single-pixel accuracy in walkable areas, and being able to walk down to the bottom of the screen: typically you want to build in a bit of buffer around the edges anyway, since characters generally aren't flagpoles, but have width and depth as well (so their center is always a few pixels away from the visible edge).

[Khris]

After setting player.z = -1, I found that I would have to redo all of my walkable areas as the characters no longer lined up with them (off by 1).

I don't understand this at all.
If you initially assumed that the character's bottom row of pixels is drawn exactly at their y position, shouldn't setting player.z to -1 give you exactly what you want?

Why do you have to move all your walkable areas now? If you drew them on the background under the assumption that that's where the player's bottom row of pixels is going to be, you shouldn't have to move them at all.

(Also, using player.z will NOT cause walkbehind issues, "fixing" this issue by shifting the walkable areas will.)

[miguel]

Side note, (and sorry to barge in), when we need to disable a walkbehind area: 0 (zero) doesn't count as a row, it is used to disable the area. I always end up having to lookup this in the manual if I stay away from scripting for a while. It's not intuitive at all.

[Khris]

miguel:
I guess the rationale here is that anything with a baseline of 0 will appear behind everything else, which for walkbehinds is akin to disabling them.
I wouldn't be surprised if the walkbehind isn't actually disabled.

[miguel]

Yes, you make sense. The function name and the way to use it isn't very practical, in my opinion.

Code: ags

walkbehind[n].Enable

would make more sense.

[Gurok]

After setting player.z = -1, I found that I would have to redo all of my walkable areas as the characters no longer lined up with them (off by 1).

I don't understand this at all.
If you initially assumed that the character's bottom row of pixels is drawn exactly at their y position, shouldn't setting player.z to -1 give you exactly what you want?

Why do you have to move all your walkable areas now? If you drew them on the background under the assumption that that's where the player's bottom row of pixels is going to be, you shouldn't have to move them at all.

(Also, using player.z will NOT cause walkbehind issues, "fixing" this issue by shifting the walkable areas will.)

I initially assumed that the way the characters were drawn was correct, so I drew my walkable areas accordingly. I didn't know the bottom row wasn't drawn exactly at their y position until you pointed it out. Setting player.z to -1 gives me the ideal positioning, but I'd already started building the game around a faulty positioning model.

(Also, using player.z will NOT cause walkbehind issues, "fixing" this issue by shifting the walkable areas will.)

Understood, I'll change the top post.

[Khris]

I would love to see a screenshot of a room and its walkable areas. Could you reveal just one maybe?

[Gurok]

I would love to see a screenshot of a room and its walkable areas. Could you reveal just one maybe?

Here you go:

[imgzoom]http://i.imgur.com/bKpqbJW.png[/imgzoom]
[imgzoom]http://i.imgur.com/E8w1DP6.png[/imgzoom]

Walkable areas are overlaid in blue. Position of the player character is the bright red pixel. The coordinates of the player are shown in the top left. In the first, z = 0. In the second, z = -1. Both are at the same x/y position. Notice the gap between the wall and her foot in the second screenshot.

Like I said, I built all of the walkable areas taking into account the existing (z = 0) behaviour. Oh well :-(. Live and learn.

[Snarky]

Are you freaking kidding me?! That second screenshot is the problem? A one-pixel strip of grass between the character and the wall?!

Look, as I said above, in an adventure game, this stuff really does not matter. People don't generally go and press their bodies against any obstacle they come across, so if the walkable area doesn't allow players to step all the way into every wall and corner, no one is going to mind or even notice. In fact, it's going to look more natural for characters to maintain some space around them. (Even in that second screenshot, it's weird to have her standing facing the wall like that.) Unless this is a specific gameplay element (e.g. to climb a wall), you're obsessing over something entirely pointless.

Apart from that, even without this particular AGS quirk you should really set the character.z values anyway, since their feet go several pixels below the baseline of their center point (the point that should probably stay constant if you spin them around). I've marked up in cyan where I think their positions should be relative to their sprites:

[imgzoom]http://i.cubeupload.com/mH0VpG.png[/imgzoom]

I'd also like to point out that I think it would be better to not have the walkable area extend to the edges, unless there's an exit there. From this screen it's not really clear whether you can exit South and/or East, but I damn sure wouldn't expect to be able to exit West except through the gate, and yet you have a strip of walkable area there. That's sending mixed messages to the player, and it's going to make for a frustrating gameplay experience.

[Gurok]

Apart from that, even without this particular AGS quirk you should really set the character.z values anyway, since their feet go several pixels below the baseline of their center point (the point that should probably stay constant if you spin them around).

Hmmm... why do you think the character.z value should be adjusted so that the x/y is at the centre point of their feet? What advantage would that have? I mean, I can see the point of setting character.z to -1, but beyond that, isn't it just going to make the characters clip when they get to the bottom of the screen?

[Billbis]

That way the character goes exactly where the player has clicked, and not a few pixel upper. It feels way more satisfying as a player (at least in my opinion).