next »

[Polly]

No, i'm not using built in variables here.

In that case try using your own variables for the x/y position of your object as well, and assign those to x/y by rounding them. So something like ..

Code:

x = round(my_x);
y = round(my_y);

background_x[1] = view_xview[view_current] * 0.6

Already mentioned this .. but don't drive the background position using the view_xview value! Use a floating-point variable instead.

I've the feeling you're avoiding explaining me that workaround, but why?

No no, i'd be happy to explain it to you ( not much to it though ) .. but you don't need it since you don't want sub-pixel scrolling.

[Alessio]

In that case try using your own variables for the x/y position of your object as well, and assign those to x/y by rounding them. So something like .. *code*

Mmh, this "pixel perfect" solution is even easier than the code i've posted before. This could be applied to every object with some workarounds. But this still doesn't fix my problem with background, it still stutters. The rectangle doesn't, though. For some reasons, the background has problem with divided values but i still believe it's the view's fault.

Already mentioned this .. but don't drive the background position using the view_xview value! Use a floating-point variable instead.

I actually do this  
In a persistent object i've estabilished these variables:

Code:

global.my_xview = 0
global.my_yview = 0

And Run these every step:

Code:

global.my_xview = view_xview[view_current];
global.my_yview = view_yview[view_current];

Then in the "background scroller" object i set this:

Code:

background_x[0] = global.my_xview * 0.9;  
background_y[0] = global.my_yview * 0.9;

background_x[1] = global.my_xview * 0.6;
background_y[1] = global.my_yview * 0.6;

But this doesn't seem to fix anything. That's why i though instead of rounding every object with "x = round(my_x);" could be applied a workaround to the view alone, which is faster. Because, actually, the only guilty subject here is the view. I tried to round, to use another variable but nothing, i still have problems.

[Polly]

Assigning view_xview to a variable and then to background_x is the exact same thing / mistake as assigning it directly.

[Alessio]

What's the actual correct action then? How do i assign a floating-point variable to the view? Unfortunately, this isn't so obvious to me, as i've never "programmed" before.

[Polly]

What's the actual correct action then?

Here's a example of a horizontal scrolling view with parallax background ..

Code:

camera_x += 1; // For demonstration purposes
view_xview[0] = camera_x;
background_x[0] = camera_x * 0.6;

[Alessio]

So i had to reverse "my_viewx" with "view_xview[0]"

Though, now, the background doesn't scroll at all.

Maybe it's because i've also a create event that declares "my_xview = 0" but that seems the most logical thing to do.
The code is "view_xview[view_current] = global.my_xview"
And then i put:
background_x[1] = global.my_xview * 0.6;

This doesn't do anything though. And even with "my_xview +=1" there is stutter with background.
And this doesn't fix the stuttering problem with everything in the game.

Isn't applying that workaround faster, then? To be honest, having a low resolution but at the same time having the change to see how everything moves in "smooth subpixel" mode could be handy.

[Polly]

This doesn't do anything though.

Can you try it from scratch?

Start with a empty file, create a background + sprite + object + room ( doesn't matter what the background & sprite look like ). Assign the sprite to the object and add Create + Step events containing "Execute Code" actions. In the Create event code you put "camera_x = 0;" and in the Step event the snippet from my last post. Add the object to the room, assign the background and set the view & port to 320 x 240. Finally, set the room speed to 60 ( i assume you want a 60fps game ) and press Run.

[Alessio]

Can you try it from scratch?

Start with a empty file, create a background + sprite + object + room ( doesn't matter what the background & sprite look like ). Assign the sprite to the object and add Create + Step events containing "Execute Code" actions. In the Create event code you put "camera_x = 0;" and in the Step event the snippet from my last post. Add the object to the room, assign the background and set the view & port to 320 x 240. Finally, set the room speed to 60 and press Run.

Done.
First:

i assume you want a 60fps game

No, i wanted the default 30 speed, like most games made with this tool (i believe). I've never written i wanted a 60 FPS game.
With your settings the background still stutters. I've done that before and i've done this now. I swear to god, i'm not making a fool out of anybody!

I've started to think that without any workaround to the view i'll never solve this problem.
I'll give my reasons.

Firstly, I've found a solution to make my background stop stuttering.
I've found out that using "d3d_set_projection_ortho" does fix the background stuttering. But it's also weird and not very practical.
I've written this into the "Begin Draw" event:

Code:

d3d_set_projection_ortho(view_xview[view_current], view_yview[view_current], view_wview[view_current], view_hview[view_current], 0)

But with this setting, there is no effect, the background still stutters.
So ve made this into the step event of a object:

Code:

global.my_xview = view_xview[view_current] 
global.my_yview = view_yview[view_current]

Obviously, i've declared them in the Create event.
Finally, i've put this one instead in the "Begin Draw" event:

Code:

d3d_set_projection_ortho(global.my_xview, global.my_yview, view_wview[view_current], view_hview[view_current], 0)

May it be magic, but this keeps my background from stuttering

the problem is that the background stops stuttering... while my moving box stutters instead. Even if i round its x/y position.
This bring me to the next reason i need my view move smoothly.

A smooth view is probably syncrhonized with the rest of the surrounding objects and backgrounds. That's why i believe it's a good idea having the views moving like the rest of the objects. Really, is there a way to make the view move like it does in Shovel Knight, namely, between pixels?

Now, rounding the background position doesn't work with "background_x[0] = global.my_xview * 0.5" because with this code the view can't synchronize with the background (i really don't get why, may it be the "*0.5"?). Using "d3d_set_projection_ortho" fixes the background stutters but adds stuttering to the rest of the objects, even to those with rounded values. I believe i've no other solution in mind besides making the view synchronized with the rest of the movements.

[Polly]

I've never written i wanted a 60 FPS game.

I know, that's why i said "i assume" .. since most 16-bit games are 60fps.

With your settings the background still stutters.

Alright, that's very peculiar ( as it works perfectly fine for me ). What refresh rate is your monitor?

[Alessio]

I know, that's why i said "i assume" .. since most 16-bit games are 60fps.

Curiosity, then: do really most games made with GM use 60fps? I'm not even sure if that's great for me because the speed of the objects in general are all doubled (since the steps are doubled)

Alright, that's very peculiar ( as it works perfectly fine for me ). What refresh rate is your monitor?

mmmh... 60hz is the max it can handle (and my current option). But i don't believe that the problem is my monitor. A game should work properly with every monitor (unless it's just 20 years old).
I'm not even the only one who has this problem so i don't think it's really peculiar.

[oahda]

What's the actual correct action then?

Here's a example of a horizontal scrolling view with parallax background ..

Code:

camera_x += 1; // For demonstration purposes
view_xview[0] = camera_x;
background_x[0] = camera_x * 0.6;

Does this mean regular numbers are floats by default in GM? Since you just use 1 and not 1.0 and still get it right?

[Polly]

Do really most games made with GM use 60fps?

No idea, but you should do what you want / think is best .. not what the majority does.

60hz is the max it can handle (and my current option).

Alright, then i have no idea why it stutters on your PC.

Does this mean regular numbers are floats by default in GM?

Doubles ( 64-bit ) even

[Alessio]

Ok. I believe that 60 fps make my game too frenzy, then i find 30fps more manageable. I'll stick to 30, then.
I don't really believe it's my PC but if it is, well, it's one with very good performances (i need good performance for my graphical stuff).

About this:

In that case i'd recommend drawing your game to a 320x240 surface ( which solves all the problems you mention ).

that doesn't do it, apparently, i've tried it and the background is still stuttering with this setting. It's like the view fails to synchronize correctly. Is my PC too good then?
It's an i7-4090 3.60hz 8GB of RAM. It's an Nvidia GeForce GTX 750 with a RAM of 5GB. I've actually heard that "old-school" mechanics have problem with newer super-duper computers.

Really, i've tried everything but nothing seems to stop views from misbehaving.
Therefore i tried again "d3d_transform_set_translation(-global.my_xview, -global.my_yview, 0)" in my "Draw Begin" event and "global.my_xview = view_xview[view_current]; global.my_yview = view_yview[view_current]" in my "Begin Step" event to see the effects, but this only gives me weird effects: the view goes in the origin and whenever i move the screen shift to the opposite direction.
What's wrong with all this?

Can anyone seriouly help me?