Too big background ----> ¿Hotspots failing? [solved]

[Tozy]

Hello, people. I'm new arround here.
I'll make an effort and writte in english, althoug is not my native lenguaje.


I'm making a pltform game based on hotspots for the platforms. But when I tried to test the first room, my charcters didn't collide with the platforms. I tried a lot od things =(
Som hotspost in the top left corner work, but 1000 pixels beyond they fail and my poor characters fall to their doom.

I can post my code or the source if needed.
This is a game for a compo, and the deadline is in 3 days, so i'm a bit worried =S

Thank you in advance.

[Tozy]

Now I almost solved the problem.

I import the hotspots from an image, then the background. But if the background is smaller then they would match (or almost). However, it all shakes like a hearthquake (from 0 to 10 pixels or so up and down, very quickly). I started with the "engine" from the game Plataformerius: The ninja incident.

If I reach any solution I'll let you know.

[Khris]

I imagine the background image and the hotspot mask are supposed to have exactly the same dimensions.

[Tozy]

I imagine the background image and the hotspot mask are supposed to have exactly the same dimensions.

Yes, I filled the empty space in the background image to be able to import it into the game, but i'm not shure yet about the proportion between hotspots and backgroun. It's not 1/2. 

[Khris]

Not sure what you mean.
In the manual it says:

There are some restrictions to how this file must be drawn: it must be the exact same size as the background scene [...]

So the proportion is exactly 1.

I don't know what'll happen if the imported mask is smaller or bigger than the background; at best it'll lead to unpredictable results.

Why don't you try importing a mask that actually has the exact same size as the background image?

Edit: Since you're using the Platformerius engine, are you doing this with an old version of AGS? Because my comments apply to the latest version. I'm not sure but I think that with earlier versions, the hotspot and walkable area masks had to always use lowres coordinates, even if the game was set to hires.
Anyway, what are the dimensions of the background and mask you're currently using?

[Tozy]

Well, at first the masks and the BG were the same proportions. But ingame that didn't work. Letting my characters fall, they would collide with the plataforms earlier than they should, like floating...
(i have several rooms in my game, all to make tests. One is small, the original from The Ninja Incident, and it works fine)

I'm using AGS 3.2.0. The first thing I did was updating the proyect version.

And the dimensions are 3000x1700, since space is an important part of the game (you can make grat jumps!).
Right now, the BG almost match, and it's 1624x874 (pasted over a 3000x1700 image).

[Khris]

I'd strongly suggest you loose those arbitrary dimensions and go for multiples of 320x240 or 320x200.
Try e.g. 3200x1680 for both the background and the hotspot mask.

[Tozy]

That didn't work  

Also, I suspect that the hotspot mask changes its place every frame (hence the "shaking" when standing in a platform).


EDIT:
Fixed the "shaking". Where it said:

while ((!p2_jumping) && (GetWalkableAreaAt(character[6].x,character[6].y+1)==2)) character[6].y++; //alters the y positioning in a slope downhill
  while ((!p2_jumping) && (GetWalkableAreaAt(character[6].x,character[6].y)==1)) character[6].y--; //same as above except alteration for going uphill

Remplaced the "+1" with a "+2", since the mas its acutally around twice the proportion of the BG (and the charcter position on screen). I'm shure that it was a float conversion error, in some way.... 

[Shane 'ProgZmax' Stevens]

This sounds to me like you're not factoring in GetViewportX() and GetViewportY() into the movement and collision calculations for the characters.  Once the screen starts scrolling, all your calculations will be off without taking into account the viewport starting position, so to be safe, add getviewportx and y to your collision checking so it treats things as room coordinates rather than screen.

[mode7]

You have to take the viewport into account
instead of:

GetWalkableAreaAt(character[6].x,character[6].y

write

GetWalkableAreaAt(GetViewportX()-character[6].x,GetViewportY()-character[6].y

As I found out this won't work when the screen it still scrolling while doing the calculations. But might be my programming

[Tozy]

Are you sure? Is the viewport needed to calculate collisions?

int Character.x;

Gets/sets the character's current X co-ordinate. This is expressed in normal room co-ordinates, and specifies the centre-bottom of the character's sprite.

I'll try that anyway...


EDIT:
replacing "character[6].x" with "GetViewportX()-character[6].x" didnt...

Cheking while editing:
...your right, hotspots and walkable areas are screen relative. Thats why my code detected hotspots thata where actually beyond. It didn't work becouse it should be the other way oround, I think.
Now everything makes sense! I hope it works when I try it. 

[mode7]

yep you're right. I just cant remember which way around ^^

[Ryan Timothy B]

GetViewportX() is for the left edge, and GetViewportY() is for the top edge.
If you're checking regions and such relative to the screen, you'll be adding to the viewport, not subtracting like Mode7 has shown. And subtracting from the character's coords from the viewport coords would definitely not result in anything usable. Since a character is room relative, not screen relative like your mouse or a GUI.


If you're checking for the region around the character, something like this is what you'd want to do:

Code: ags

GetWalkableAreaAt(player.x - GetViewportX() + 20, player.y - GetViewportY())  // checks 20 pixels to the right of the character
GetWalkableAreaAt(player.x - GetViewportX() - 20, player.y - GetViewportY())  // checks 20 pixels to the left of the character
GetWalkableAreaAt(player.x - GetViewportX(), player.y - GetViewportY() - 20)  // checks 20 pixels above the character
GetWalkableAreaAt(player.x - GetViewportX(), player.y - GetViewportY() + 20)  // checks 20 pixels below the character

If you're checking around the mouse or GUI you'll need to check where the Viewport is:

Code: ags

GetWalkableAreaAt(mouse.x + 20, mouse.y) //checks 20 pixels to the right of the mouse, based on where it is in the room, not the screen.

etc.


Hope that sheds some light on where GetViewport is useful.
(argh.. had to edit it due to Khris pointing out that I didn't read the manual. )

[Khris]

GetWalkableAreaAt(GetViewportX()-character[6].x,GetViewportY()-character[6].y

No. You never, ever substract a game object's coordinates to get to room or screen coordinates. They always go into the equation as positive values.

If you're checking for the region around the character, something like this is what you'd want to do:

Code: ags

GetWalkableAreaAt(player.x + 20, player.y)  // checks 20 pixels to the right of the character

If you're checking around the mouse or GUI you'll need to check where the Viewport is:

Code: ags

GetWalkableAreaAt((GetViewportX() + mouse.x) + 20, GetViewportY() + mouse.y) 

Unfortunately, still no. It's the other way round.

Note that GetWalkableAreaAt() uses SCREEN coordinates. A character uses room coordinates, so the correct code would be:

Code: ags

  while ((!p2_jumping) && (GetWalkableAreaAt(character[6].x - GetViewportX(), (character[6].y+1) - GetViewportY())==2)) character[6].y++;

SCREEN coordinates are limited to the screen dimensions, thus you add the viewport coords. ROOM coordinates can be much greater than the screen dimensions, thus you substract the viewport coords.
(That's what I use in order not to get my brains in a knot. )

[Ryan Timothy B]

Oh dear. I don't believe I've ever used GetWalkableAreaAt. I guess I should have checked it up in the manual before running my mouth. I've always assumed it was room coordinates, or at least you'd think it was anyway.

I guess I just assumed it was like regions which I've used several times. Sorry for the confusion.

[Khris]

It was the same for me until CJ himself set my straight after I accused the manual of giving false information...

[Tozy]

Cool! I't works great! 

Thank you very much to all of you! 

You'r awesome. I hope I can show you the game in a few days