Need advice in how to handle multiple resolutions.

[grizzled wave]

I want to make my game feel smooth with multiple resolutions. My game is a retro styled pixel art game and I'd like to not break the pixel grid.

My idea was to check the players screen resolution/window size then figure out what the closest scale is to that size. Like 2x 3x 4x etc. Then with whatever is left I want to increase the view port to show more background.

I have no clue where to start and I was wondering if there are any extensions or anything that could help with this. Or a good tutorial.

[quartz gate]

https://www.youtube.com/watch?v=_g1LQ6aIJFk
https://www.youtube.com/watch?v=jCl6zT0eQLU

[grizzled wave]

I've watched these before but I don't think it's exactly what I need I am gonna rewatch them to be sure.

[quartz gate]

idk if it's part 1 or 2
but pope does have a section addressing having windows not having the same aspect ratio as the default game

pope's camera tho does break the pixel grid

to make it not break the pixel grid, just do x= target_x, y=target_y instead of lerping

but that also will lead to a maybe jittery less smooth camera

https://www.youtube.com/watch?v=5hTYexed8-Q there's also this

[grizzled wave]

So I followed this tutorial but it's making enemy movement appear jittery

Not sure what I've done that caused that I am flooring my X and Y I followed popes tutorials

[quartz gate]

what x,y, are you flooring?

the enemy or the camera?

you don't technically strictly need to floor any positions

and sice you are, i assume you want pixel perfect, and are moving at integer positions?

[grizzled wave]

The draw positions entities and the camera

[quartz gate]

do you want it to be pixel perfect?

the whole point of those two tutorials is that the camera is smooth and can take on non-integer positions

but that also means your screen won't be pixel perfect, and you get non-whole pixels on the edges

[grizzled wave]

I want it to be pixel perfect

[quartz gate]

right.

instead of flooring

replace the lerp with just x = target_x, y = target_y

[grizzled wave]

I already did

[quartz gate]

and?

[grizzled wave]

Still has the same issue

[quartz gate]

how big is your scale?

can you take a video of the jitter?

just so we're on the same page?

[grizzled wave]

Making a vid, I noticed its especially bad when enemies are moving diagonal.

[quartz gate]

are your enemies moving at integer speeds?

[grizzled wave]

No, but I am using motion planning

[quartz gate]

hmm

[grizzled wave]

And I don't think the path speeds translate into pixels right?

[quartz gate]

no

[grizzled wave]

Yeah, was afraid so.

[quartz gate]

i would round your hspeed and vspeed

right after you do your motion planning

[grizzled wave]

Are those the built in variables for motion planning?

[quartz gate]

those are just regular instance variables

if you're using like path_start or whatnot
then that directly uses speed and direction and stuff

maybe. try it

i have an alternative to try if that doesn't work out

[grizzled wave]

Doesn't work

[quartz gate]

right.

welp.
the way i was gonna suggest was to extract the direction the motion planning would like you to go in

and then round those speeds

and you do that by generating the path
getting the coordinates of the 1st point in the path

and "connect" it to your current position

[neat ivy]

path_get_point_x

This function will return the x position (in room coordinates) of the point that you input for the path that you index. If the point is outside of the range of the path (ie: a path has 8 points and you ask for the x position of point 10) then a value of 0 will be returned.

Arguments
index: The index of the path to check.
n: The point number to check.

Jan 23, 2024, 2:10 PM

path_get_point_y

This function will return the y position (in room coordinates) of the point that you input for the path that you index. If the point is outside of the range of the path (ie: a path has 8 points and you ask for the y position of point 10) then a value of 0 will be returned.

Arguments
index: The index of the path to check.
n: The point number to check.

Jan 23, 2024, 2:10 PM

[quartz gate]

x_to = path_get_point_x(path, 1)
y_to = path_get_point_y(path, 1)

hspd = round(x_to - x)
vspd = round(y_to - y)

//move and collide with hspd and vspd, maybe using the shaun spalding collision code or something, or just
x += hspd
y += vspd

[grizzled wave]

But then you'd also need to know when you've reached the point in the path and that would completely negate the mp path system no?

[quartz gate]

well you're still using mp_path to generate the path

but the path is more like a gps than a guiderail

you don't need to know when you get to the point if you generate a new path

you're constantly calling mp_path

so you're constantly recalculating your path

if you've never used like a GPS system
and you take the wrong road, the GPS system will update to your current position and tell you where to go from where you are

same idea

[grizzled wave]

I'll give it a shot

I honestly could just take the direction no?

[quartz gate]

wdym?

[grizzled wave]

    {
        var nextPointX = path_get_point_x(path, 1);
        var nextPointY = path_get_point_y(path, 1);
        
        // Get the direction to the next point on the path
        inputDirection = point_direction(x, y, nextPointX, nextPointY);
    }
    
    if (instance_exists(oPlayer))
    {
        pathFinding--;
        if (distance_to_object(oPlayer) > 4)
        {
            if (pathFinding <= 0)
            {
                pathFinding = 20; // setting a timer so it doesn't run every frame. 
                if (mp_grid_path(gridPathing, path, x, y, oPlayer.x, oPlayer.y, 1))
                {
                    //if (exploding == false)  { path_start(path, 0.3, path_action_stop, 0); }
                    //else { path_start(path, 0.8, path_action_stop, 0); }
                    
                    if (exploding == false) { moveSpeed = 1 }
                    else { moveSpeed = 2 }
                }
            }
        } else { moveSpeed = 0;
            //path_speed = 0; path_end(); 
            }
    } else { moveSpeed = 0;
        // path_speed = 0; path_end(); 
        }
    
    x += lengthdir_x(moveSpeed, inputDirection);
    y += lengthdir_y(moveSpeed, inputDirection);```

I am doing this right now but it's not working it's behaving really weird.

[quartz gate]

ah you almots got it

lengthdir is non integer

so try rounding that

i was under the impresion you were doing path_start() with the path

you're already basically doing what i described then

[quartz gate]

what do you mean by this? does it not even go to the destination?

[grizzled wave]

It does but really sporadically

[quartz gate]

try rounding the lengthdir's, then report back with a video

[grizzled wave]

The movement isn't smooth at all. I did that.

[quartz gate]

can i have a video?

[grizzled wave]

Yeap hold on

[quartz gate]

should i look at the slimes or the blombs?

[grizzled wave]

Blombs

[quartz gate]

hmm well

1. i can't notice the jitter so maybe it's just me
2. i notice the bombs go on top of each other so you'll have to address that at some point maybe
3. I have no more ideas if you're already rounding the lengthdirs. if it's only happening on diagonals perhaps you can disable diagonal movement -- i feel like the fact that diagonals are 30% longer than straight edges might have a contribution to this, but that's just a hypothesis

[grizzled wave]

Jitters not there anymore but the entire path_finding broke haha

[quartz gate]

oh

i mean...it still ets to you, no?

or do you mean it getting stuck on bridges?

[grizzled wave]

it just stops following you from time to time.

[quartz gate]

hmm

the rounding shouldn't have affected that...

[grizzled wave]

And the path finding is not acting as intelligent as I want

[quartz gate]

and without the round it's "fine"?

[grizzled wave]

No

[quartz gate]

so it's a separate issue

[grizzled wave]

It did this before rounding too but also spazzed out on the spot in places

like vibrated haha

[quartz gate]

right ok

so the original issue is fixed yes?

[grizzled wave]

Well, I don't notice the jitter anymore

[quartz gate]

the pathfinding...

one thing i can perhaps suggest trying is to increase the interval it finds a new path so that it's not "changing it's mind" as quickly?

there's not much you can do about "intelience", because A* works the way A* works and that's all done behind the scenes

other than...coding your own pathfinding algorithm

[grizzled wave]

Already did that didn't change much

[quartz gate]

🤷‍♂️

what did you change it to

21?

or like 60

i honestly have no other ideas other than to draw the MP_grids and path generated and see if it's snagging on anything

[grizzled wave]

For now I'll just deal with it as it is. I don't think not using the path system is an option for me