Open Surge Forum

A fun 2D retro platformer inspired by Sonic games and a game creation system

You are not logged in.

Announcement

Our community has moved to Discord! https://discord.gg/w8JqM7m

#1 2012-05-15 20:53:20

KZR
Member
Registered: 2010-07-14
Posts: 1,447
Website

[questions] brick_*() functions

so far, i've been making good use of these functions, but one doubt remains: what is the offset origin? sometimes it looks like it is from the base center, others from the hotspot, making these functions somewhat confusing and hard to tune.

Last edited by KZR (2012-05-15 20:53:42)


SD_sml.pngSeD_sml.pngLTot_W_sml.png
https://discord.gg/w8JqM7m ---> Open Surge's Discord server

Offline

#2 2012-05-16 00:47:18

Alexandre
Administrator
From: Brazil
Registered: 2009-01-27
Posts: 3,300
Website

Re: [questions] brick_*() functions

it's always the offset from the hotspot of the object.

Offline

#3 2012-05-16 01:23:27

KZR
Member
Registered: 2010-07-14
Posts: 1,447
Website

Re: [questions] brick_*() functions

ok that explains why some objects need special settings.

i found a way to walk objects on slopes. the only problem is they use "raw" speed values instead of a calculated velocity  based on the angle. and they used to break when they find walls, because i was trying to guess where the offset point was coming from. since this example was made on the fly, i can't tell how it would react to walls until i test it.

it looks like this:

execute "slope_correction" while "(brick_type(direction()*(width()/2), (height()/2)-4)) and (brick_type(0, height()/2)) and ((brick_angle(direction()*(width()/2), (height()/2)-4)<> 90)and ((brick_angle(direction()*(width()/2), (height()/2)-4)<> 270))"

this is the trigger, it should be used in a state with gravity. this is counting with a centered hotspot.

then this is what happens:

state "slope_correction"
{
 set_absolute_position xpos() ypos()-1
 }

long story short:

while there is a solid non90/270º brick, at a height of 4 pixels from the feet, and immediately in front of the direction the object is facing, the object will move up a pixel. since it is a "while" loop, the change is only visible after no more ground is found at such position, which is in the next frame.

Last edited by KZR (2012-05-16 01:27:53)


SD_sml.pngSeD_sml.pngLTot_W_sml.png
https://discord.gg/w8JqM7m ---> Open Surge's Discord server

Offline

#4 2012-05-16 02:51:13

Alexandre
Administrator
From: Brazil
Registered: 2009-01-27
Posts: 3,300
Website

Re: [questions] brick_*() functions

what if we had a custom object that calculates the brick_*() functions, but also taking into account the angle of the object?

So, whenever you need brick_*() to be adjusted by the angle, you'd call the object instead of the built-in functions.

would that help you?

Offline

#5 2012-05-16 03:16:45

KZR
Member
Registered: 2010-07-14
Posts: 1,447
Website

Re: [questions] brick_*() functions

well i just made improvements on it. and i'm a bit confused about what you are telling me, why would i need a separate object, when the slope correction is based on an object's own ground contact?


SD_sml.pngSeD_sml.pngLTot_W_sml.png
https://discord.gg/w8JqM7m ---> Open Surge's Discord server

Offline

#6 2012-05-18 11:09:26

Alexandre
Administrator
From: Brazil
Registered: 2009-01-27
Posts: 3,300
Website

Re: [questions] brick_*() functions

KZR wrote:

well i just made improvements on it. and i'm a bit confused about what you are telling me, why would i need a separate object, when the slope correction is based on an object's own ground contact?

never mind, I think I misunderstood it.

Offline

#7 2012-05-18 16:47:35

KZR
Member
Registered: 2010-07-14
Posts: 1,447
Website

Re: [questions] brick_*() functions

there is a way to correct this. it is to use a velocity value and use sin/cos functions to calculate x/y speeds based on angle. i might get into that soon.


SD_sml.pngSeD_sml.pngLTot_W_sml.png
https://discord.gg/w8JqM7m ---> Open Surge's Discord server

Offline

Board footer

Powered by FluxBB  hosted by tuxfamily.org