Stairway solution, is there any?

[utunnels]

Aren't walls in OpenBOR rectangular prisms, where the front and back faces are the same size?

Hmm, no.

Why not make all faces one-sided?

You can have only one face if necessary.  It'll save some CPU power.

On second thought, I guess that information could be determined by checking the +/- direction of the components of the normal vector.

Yeah, but I don't know if it is necessary to have a  standalone normal property, the order of the four points already  determines the normal.

I was mostly thinking of 2D walls and platforms when designing this, since the visibility of the Z dimension is impaired somewhat by OpenBOR's semi-2D view, and I couldn't think of any practical uses for a Z-slope.  Maybe Z slopes could be added when XY slopes are finished, since they would add more complexity to the collision detection functions.

No, I didn't mention z-slope. Check the picture, it is x slope on the top.
We already have y-slope for walls, on either left or right side.

[Plombo]

Aren't walls in OpenBOR rectangular prisms, where the front and back faces are the same size?

Hmm, no.

Crap, you're right.  I had incorrectly remembered walls as 4 XY points with a depth attribute, which is the same basic model I described.  After checking the manual, I remembered that they're instead 4 XZ points with a height attribute.  It's been too long since I worked on my mod.

So this will necessitate 3D coordinates like you said.  It makes the problem much more complicated, although I had some idle hours away from the computer today, and started to figure out how everything would work in 3D.

Why not make all faces one-sided?

You can have only one face if necessary.  It'll save some CPU power.

My thinking is that it would save more CPU power if we only have to detect collisions in 1 direction for each face.  Also, it would keep entities from getting stuck "inside" of a wall/platform if they somehow manage to get inside somehow, such as by a script that directly changes their position.

It would save some memory to allow only 1 face, but supporting variable numbers of faces plus the option to make some faces only block movement on 1 side while others block on both, would make the implementation and command syntax even more complicated than they are already.

So I think it would be easier to make every platform have 6 convex faces that block movement only in the direction they are facing.  Then some faces could be declared as "non-solid", which basically means that they wouldn't exist since they wouldn't block any movement.

The hard part of this is determining what X/Y/Z direction each face is facing.  But I've already done most of the figuring on paper to come up with an algorithm that does this for each face of a convex hexahedron.  (The calculation would be done only once, when initializing the platform object.)

On second thought, I guess that information could be determined by checking the +/- direction of the components of the normal vector.

Yeah, but I don't know if it is necessary to have a  standalone normal property, the order of the four points already  determines the normal.

It would be faster (and less CPU-intensive) if we didn't recalculate it on every collision.  It's a fairly complex calculation, unless you know of an easier way to calculate it than by finding the cross-product of 2 vectors on the face, and then ensuring that it points out (not towards the center of the platform) and adjusting its magnitude to be the same as the magnitude of gravity.

I don't think I mentioned this before, but the purpose of the normal vector is that adding it to the force of gravity results in the net force, which in our case is the same thing as entity acceleration since there's no mass in OpenBOR.  So the normal vector's main purpose is to determine an entity's velocity after a collision with the face.

I was mostly thinking of 2D walls and platforms when designing this, since the visibility of the Z dimension is impaired somewhat by OpenBOR's semi-2D view, and I couldn't think of any practical uses for a Z-slope.  Maybe Z slopes could be added when XY slopes are finished, since they would add more complexity to the collision detection functions.

No, I didn't mention z-slope. Check the picture, it is x slope on the top.
We already have y-slope for walls, on either left or right side.

You can ignore that part of my post; it depended on the misconception I mentioned earlier in this post that walls are XY+depth instead of XZ+height.

[utunnels]

It would be faster (and less CPU-intensive) if we didn't recalculate it on every collision. 

  I think I still need to know how exactly point to face collision detection works to answer the question. Since you need to know whether the collision point is in front of or behind the face, the 4 points of the face always need to be checked in such calculation.

But I agree now single-sided face is better, since we can always fake a double-sided face by overlapping two faces.

[Fistoftheninjascroll]

If I am understanding the situation clearly, would it stand to reason that you could use a cartesian to polar calculation to achieve the desired effect of a sprite moving up a slope. Given that it is a 2D environment, you could use the XY coordinates of the sprites image at the ground plane calculate the theta using the arctan of the beginning coordinates and calculate the angle of slope from the endpoint XY coordinates. the sprite travels along the ray formed by the slope calculation. If I am thinking correctly you could offload the logic governing the sprite's movement along the slope into the sprite class and modify the wall class to trigger the event that would actually perform the calculations. Therefore there would be a lesser modification to the wall mechanics and a greater modification to the sprite mechanics. The Z layer could be used for occlusion of the sprite behind say a staircase banister or a waist high wall if a rock staircase texture was desired.

[utunnels]

I got an alternate idea recently. That is an altitude map, pixel based.

To do that, you need a bitmap (or png, whatever), which is as big as your panel. Different colors are used to mark different altitudes (to be discussed later).  This will benefit tiny altitude changes like a crator, or a gentle slope.

The drawback of this would be extra memory usage (a float has 4 bytes, which means the map is as big as 4 full backgrounds).

To check if a character is able to walk on a slope, the engine'll check its velocity and altitude (base).

For example,

Code: [Select]

delta_a = altitude_next_pixel - current_altitude

delta_v = sqrt(velocity_x^2 - velocity_z^2)

if (delta_v/delta_a > slope_factor)
    return slope_is_walkable
else
    return slope_is_not_walkable


Though velocity/speed is not the only way to check that, an entity can also hold a factor to determine its slope-climbing capability.

[volcanic]

The solution is great.
I think that's what official games did.
Even more complicated grounds can be solved.
But currently script can do that?

[utunnels]

No, it is just an idea.

[tushantin]

I only skimmed through the post, but unfortunately everything discussed here just went past my head.

Though I do have an idea for the logic in use for Platformers and stairways.

Currently, OpenBOR utilizes co-ordinates for movement in X (red line) and Z (green line) axis to create a "movement box" within which the characters can freely move. Something like this:



However, what about the "Y" axis movement, that characters normally use for actions such as "Jumping"? Usually the problem for implementing this is because we use "co-ordinates" to define movement grid. But what if we actually use "Vectors" instead for the X axis, and give it a "Y-axis scale" module? By default, the Y-axis would have the value of 0, so the X is a straight line and draws from Z's co-ordinates. However, changing the Y at a certain point in X might give you something like this, based on the following example command "(x,y)":

"Y = (0,0), (200,0), (250,25), (300,25)"



As you can see, the Y axis influence the X to "shift" and hence the co-ordinates for the Z change too in the area ahead. That said, I'm not a programmer, but I hope you find the idea useful.

[Fightn Words]

an altitude map, pixel based...you need a bitmap (or png, whatever), which is as big as your panel. Different colors are used to mark different altitudes (to be discussed later).  This will benefit tiny altitude changes like a crator, or a gentle slope.

The solution is great.
I think that's what official games did.

I've seen this used for games built with the Bennu language. I'm pretty sure the SoR Remake used it for there game for example.