Background scrolling and Views issue

A

Alessio

Guest
Hi. I'm using the latest version of GM: Studio and i'm trying to make background scrolling but i have issues that are caused, i believe, by the current view position.

I use this code placed in a controller object' step event: background_x[1] = view_xview[0]*0.7

Which, alone, is fine for the purpose. But the way the view moves it's messy.

A problem i've seen with Game Maker is that, in a resolution like 256x240, while objects and backgrounds move fluidly (like in Shovel Knight, which i know it isn't Game Maker), the view doesn't it moves every pixel. And it gives display issues. But with the above code, even if the port on screen is equal to the view size, the background snaps back and forth.

Why does this happen? How would you fix that? I just can't find anything in the web, i've even looked at tutorials but they just don't seem to address this problem.

I wish YoYo could fix these things, anyway: because of the view that moves every pixel of the game resolution you just can't make a fluid game.
 

wamingo

Member
Firstly, the reason moving sprites/backgrounds seem smooth on your tiny resolution is because of interpolation or high speed (faster speed will appear smoother).

Secondly, I haven't played shovel knight but I believe it doesn't actually use as low a resolution as it appears. more like 4x bigger, that way their view can move with 1/4 "pixel" precision and smoothness.
I recommend you do the same.

A not personally tried but probably possible solution besides drawing all your sprites 4x larger, is to render the app surface yourself, upscaled.
 

Jakylgamer

Member
you can make a custom view to better the effect, heres my little script i made for views youre welcome to use it :)
http://pastebin.com/JfQU7Qw8
set the lerp speed to around .1 or .2 for best effect .

EDIT: forgot to add, this belongs in the players step event
 
Last edited:
A

Alessio

Guest
I believe i won't end up making 4x larger sprites. I mentioned Shovel Knight because it didn't have the problem of anything at all but cameras moving every pixel but i actually wanted my game's stuff run every pixel like in the 16 bit games. I also don't understand the matter with interpolation and high speed. (by the way, "interpolation between colors" is disabled). If sprites and Backgrounds move smoothly the views should as well, but this seems a YoYo games' oversight more than wrong settings. There should be an option that makes me set the "smoothness" of every game aspect's movements.

Thanks but the script doesn't actually do anything to me. I also already have a "view smoother" in my project so i don't even know if that will be useful to me.

I just wanted to stop my background from flickering when moving the view (I looked also at many examples and, apparently, the Mario Hello Engine has this nasty problem with backgrounds as well) and making everything, and not just backgrounds, move every pixel instead of every subpixel like Game Maker forces to. For example, the old 16 bit games used to do this so everything moves smoothly althouth everything is snapped by every pixel, without stuttering and flickering.
 

wamingo

Member
Seems to me more like you've simply assumed that it can't possibly be down to your own lack of understanding.
GM does not force you to move anything in subpixels.
Can't you just round your view's/backgrounds/sprites/objects positions? If you're intent on fractional pixel movement speeds then store the fractions.
Code:
xx += 4.66
view_xview = floor(xx);
And I don't really know what you mean by "flickering", if something is flickering in the usual sense, it's definitely your own fault. Show code.
 
A

Alessio

Guest
Doesn't seem a very efficent solution. Using it does move one pixel to the right after a second my character stops moving.

Maybe "flickering", "stuttering", i can't find better terms but the background with " background_x[1] = view_xview[0]*0.7" alone doesn't give a nice look at all, as it flickers and trembles, like the Little Matchgirl. This happens only when the background x decreses or increases speed. If the speed is constant this doesn't happen. Not even "background_x[1] = floor(view_xview[0]*0.6)" fixes the flickering.

I mentioned that this happens in some examples i've seen as well. So i believe this is a common problem.

"Seems to me more like you've simply assumed that it can't possibly be down to your own lack of understanding."
Uh? I don't get this. Wasn't trying to assume anything at all. I've just written i'd like that YoYo games just put more automatic features into Game Maker, since the original application surface seems a little limited for low resolution games.
 

wamingo

Member
Wait, does the background have a speed AND set to 0.6*view_xview? This is not what you mean, surely?

I don't know how to replicate your flickering.

Long shot... Could it be that you're moving the view *after* aligning backgrounds to it? That would result in a 1 frame delay for the backgrounds. I think it's best to move the view before moving anything in relation to it.
Imagine ui aligned to view using the normal draw, it would not follow the view until 1 frame later.
 
I think I know what the OP is referring to by "flickering";
In my own project, when I drag/pan the view, if I hold the view on a certain "pixel" point, the entire view will "shimmer" -- almost as if the view doesn't know which 'side' of a pixel to settle on---left or right?--neither! and it flickers/shimmers in between the two.
I've tried rounding and flooring every variable I can find, but nothing fixes this.
 
A

Alessio

Guest
I think I know what the OP is referring to by "flickering";
In my own project, when I drag/pan the view, if I hold the view on a certain "pixel" point, the entire view will "shimmer" -- almost as if the view doesn't know which 'side' of a pixel to settle on---left or right?--neither! and it flickers/shimmers in between the two.
I've tried rounding and flooring every variable I can find, but nothing fixes this.
That's the thing, indeed. I'm amazed how my problem hasn't been understood in the first place.
I just wondered if there was an actual fix to this nastiness.
The only thing is that it's the object attached to the view's position the one that flickers. Just like if there was a delay. The view moves and the object can't keep up with it. This happens even with "background_x[1] = view_xview[0]" without any division. It's weird because the background should be able to keep up with the view but it will shift left or right depending from the view's direction.
 

wamingo

Member
Sounds even more like like you're moving the view AFTER setting the background to relate to the view. This results in the background being 1 frame behind.

Try the difference. and use a step event, don't move the view in a draw event obviously.
Code:
background_x[0] = view_xview;    // will not align with view until next frame! rubberbanding likely
view_xview += 5 * (keyboard_check(vk_right)-keyboard_check(vk_left));   //move view left/right
Code:
view_xview += 5 * (keyboard_check(vk_right)-keyboard_check(vk_left));   //move view left/right
background_x[0] = view_xview;   // aligns same frame.
EDIT: ALSO... I can't help you if you're using the builtin speed/hspeed etc for any of this, I don't know how to account for the fact that speed updates x,y after the end-step.
Maybe someone else can.
 
Last edited:
A

Alessio

Guest
1- The code shakes the objects attached to the view's position (the background) even more (as i was expecting).
2- No offense but don't get the sense of this code.... why should i move the view through the keyboard_check? This is something that is going to screw up everything. I'm a total beginner but this sounds like a "NO NO" to me. The background should move depending from the camera view and the view should move depending from the object's position the view is currently following (or should scroll towards a direction alone if intended), not from the key i am pressing o_O
This is gonna create an "earthquake".
 

wamingo

Member
it was for testing, I don't know how you move anything, you've posted very little to clue anyone in what you're doing.

disable object following and do it yourself is my recommendation.
 

wamingo

Member
oh I'm an idiot... my bad, try this.

END step event:
Code:
// update view
view_xview = floor(x-view_wview/2);        // or whatever it centers on
// update ANYTHING that is related to view
background_x[0] = floor(view_xview*0.6);
I'm not 100% sure what you got to do if you're using the built in object following though, maybe just don't eh!
 
A

Alessio

Guest
Earthquake is gone
But the first line of code overrides the second one.
Obviously because "x" is actually the x of my background controller, which is a separate object. I don't use the player object for anything besided actually move the player around. For controllers, i use separate entities.

But, really, i believe the problem is with the views that just don't get on well with anything in the game (background doesn't stutter if i use any object's position instead of the view one). The background is innocent in this case. I'd really suggest a built-in default background manager at this point (something you can set through the Room editor, this would just spare boring workarounds). Isn't there any kind of suggestion thread where one can suggest features for future updates?
 

wamingo

Member
unity with sliders and managers is that way -> ;)

anyway, first make sure the view controller is higher in the resource tree than anything that relates to the view.

view cont END step:
view_xview = floor(x-view_wview/2) //

bg cont END step:
background_x[0] = view_xview *0.6
 
A

Alessio

Guest
No idea about Unity but i really should be able to edit very basic things through the editors.

About the code... with the first line, now the background follows the object lol! I believe it's because i put it in the view controller that follows the player's position. I should make another view controller but that doesn't fix the stutter.
I really believe the stutter is a problem with views because they don't support values that aren't integers. I've noticed this even with objects that aren't backgrounds. Weird.
 
A

Alessio

Guest
Ok, since i didn't get any reply i'll change topic: it will be more "view" specific.

Since not even "surface scaling" actually fixes this problem to me (apparently, the view can't keep track of anything that is sub-pixel, blah) i wanna ask something.

I want to ask: is there a way to make the view move thorugh sub-pixels? Something like in Shovel Knight, i mean.
Because this is what makes moving objects stuttering when moving the view.

I mean: something like in the attached file. Is that actually possible?

I've been told about a workaround, but apparently, they weren't clear enough.
They told me to define my own view coordinates' variables and call something like this:
Code:
d3d_transform_set_translation(-global.my_xview, -global.my_yview, 0)
This is in my step event:
Code:
global.my_xview = view_xview[view_current] 
global.my_yview = view_yview[view_current]
This is all in a persistent object put before everything else.
This causes weird effects. I still didn't figure out the problem.

If this isn't a practical solution, is there a way to make the view coordinates support sub-pixels? Or doesn't Game Maker support them at all?
 

Attachments

HayManMarc

Member
I was looking for an answer to this and I found it. Forgive the necro-post, but I thought it might be helpful to others.

The problem is from using background_x. Don't use it. Also, don't put the backgrounds in the room editor.

Instead, put the code in the DRAW EVENT and use draw_background_tiled(back, x, y) to draw them manually, like so...
Code:
draw_background_tiled(background_far, view_xview[0] * 0.95, view_yview[0] * 0.95);
draw_background_tiled(background_middle, view_xview[0] * 0.75, view_yview[0] * 0.75);
draw_background_tiled(background_near, view_xview[0] * 0.55, view_yview[0] * 0.55);
However, if you only want it tiled in one direction, you'd have to use draw_background and then tile it manually, either horizontally or vertically. (For example, in a platformer when you don't want the landscape in the background repeating as you gain height - vertically.)
 

RangerX

Member
What he seemed to have here is scaling related problem.
I move my background just like him in The Life Ruby and nothing stutters, flickers or messes around. The views and GMS don't have a problem here, we do! lol
 
A

Alessio

Guest
Even with screen scaling disabled it gave me the same exact problem. I didn't know I wonder if it's a problem of instance order on the room or on the resource tree. I even had a weird problem caused by somything i don't know. I had a "camera" object that is fixed to the player, using "x = obj.x" and "y = obj.y" on the end step event: in the resource tree, if i put the camera after the player object, the thing won't follow the player correctly, there is a delay, but if i put the camera before it, the problem isn't there and works as intented.
It was very, very weird but i guess GM:S2 is going to fix a lot of problems i reported here, i saw it even got rid of backgrounds. It's a while i stopped using the software since the new version is coming out, I'd really want to take it now but i don't want to be a beta tester, just use the program so i can start building my frigging game, so, i guess i'll wait until March (sucks).
 

RangerX

Member
Logically your camera story there isn't a bug or something that will be fixed in GMS2, its logic. What moves "after or according another thing" MUST move after said thing. Else it will adjust itself in the NEXT step.
I am sure we can easily fix your problem there. Like I said, I don't have this problem with my game and I am not using GMS2. I have paralaxes, a camera object that follows the player, etc, etc. Everything is fine.
 

HayManMarc

Member
I work in small scale, too. In my current project, my game is 400x225. The method I described above works perfectly for me - no stutters or weird background bounce-back. Just perfect parallax movement. This isn't an argument or an untested idea, it's a fact, it's what I am doing, and it works.
 
A

Alessio

Guest
But the camera in GM:S is pixel-perfect (moves every game-res pixel) whereas everything else isn't (moves every monitor-res pixel). Since i've read there was a tutorial that makes the camera pixel-perfect in GM:S2, i supposed this was changed.
I have an exe i created time ago that illustrated my problem. Look (not a virus like Mediafire likes to state). To me, the background stuttering is very noticeable, i'm not inventing this story for fun. And the code is exactely this: background_x[0] = view_xview[0] * 0.5 and background_y[0] = view_yview[0] * 0.5, with the camera following the moving object. You can move and jump with arrows and change rooms with numpad + and - (i have a room with an object moving pixel-perfect and another one that doesn't).
 
Last edited by a moderator:
A

Alessio

Guest
Though almost two days have passed :(

And, by the way, i forgot to tell that the method you used with "draw_background_tiled" effectively stops the stuttering (i guess a function like "draw_sprite_tiled" would work either), but it seems i have to play around layer/object depths but doesn't seem a big deal, as i guess mostly everyone with a quality project uses this. It's great!!! In fact, it works like a bliss and solves this annoying stutter problem!!!

But i still want to solve the background_x mystery, please. Why does that glitch only to me? (i mean, according to RangerX he uses background_x without too many problems)
I've changed the file and included the project file (there is nothing of mine i've left there anyway, just some code). If it's true that the "background_x[0] = view_xview[0]" method works fine to you, then there is something strange going on. Still don't get why i have this problem. I also clarify the same problem doesn't come only with background_x but also with x variables for sprites (yes, i've tried with sprites too and gives problems). I keep being told "it's your problem" when, effectively, GM:Studio used to have obvious problems a lot of people complained of. Why does that same method work for someone else but not for me?
 
Last edited by a moderator:
A

Alessio

Guest
Ok. Anyway, it's just because i want to see if the same thing i've done with background_x glitch with someone else. I'm still waiting GM:S2, since i don't feel starting a new project with the old version when the new one is coming out.

(BTW, i posted this by mistake, i mistook "Reply" with "Edit", sorry :D)
 

HayManMarc

Member
Well, after a quick look... the problem with your jittery movement is because you are trying to move the player by a fraction of a pixel. Unfortunately, that can't happen in GM. GM automatically rounds the x and y position to the nearest integer. You'll have to change your movement values (speed, friction, etc) so they result in whole numbers. Or, another way around it all is upscaling the size of all the images, then downscaling the window port. You would still have the pixel look, but you'll get smoother, slow accelerating movement, like you want.
 
A

Alessio

Guest
Well, after a quick look... the problem with your jittery movement is because you are trying to move the player by a fraction of a pixel. Unfortunately, that can't happen in GM. GM automatically rounds the x and y position to the nearest integer. You'll have to change your movement values (speed, friction, etc) so they result in whole numbers. Or, another way around it all is upscaling the size of all the images, then downscaling the window port. You would still have the pixel look, but you'll get smoother, slow accelerating movement, like you want.
I already knew that, after observing how this happens. I even made a chart that explains this.
This is because the view's positions are forced at integers whereas the rest of the objects with an x/y coordinate aren't. If the views could move by pixel fractions (like in Shovel Knight), i bet it wouldn't happen. I've noticed this also happens with background in the room editor, where, when you use spacebar to scroll the room's interface and zoom in, you'll see that the background scrolls every pixel while the foreground (layers and objects) don't. Effectively, the fact that the room editor was a mess is unanimous.
I always thought this was pretty weird by GM:S but do you know if this was changed in GM:S2? In any case, i'm planning to switch to GM:S2.

Please look at the other room anyway, where the player's movements are rounded. You'll see the player doesn't jitter in the other room. It was just a test to see the difference between two methods of code.

My question was about backgrounds, though. With your method, it works fine, like i've stated, but with background_x/y, it jitters regardless the player's method of movement. but Ranger claims he has no problem with it. Any idea of why the background jitters to me, in both rooms?
In the .exe, you can switch rooms with numpad +/-. There is also the project file, after all.
 

RangerX

Member
Just as an example, I have a background "manager" object with code like this for reach plane of background in step event:


Code:
// --------------- CLOSEST BACK -------------------

if(global.BG2_XcanScroll==false)
then
{
background_x[2] = view_xview[view_current]*global.BG2_Xmultiplier + global.BG2_OffsetX;
}

if(global.BG2_YcanScroll==false)
then
{
background_y[2] = view_yview[view_current]*global.BG2_Ymultiplier + global.BG2_OffsetY;
}

Those variables comes from the backgrounds settings in the room's creation code:

Code:
background_index[2]=Bg_Village_Clear2;        // closest back
background_alpha[2]=1;
global.BG2_OffsetX=0;            // to know if there's a offset when background follows the view
global.BG2_OffsetY=900;
background_htiled[2]=true;                             // if it repeats or not
background_vtiled[2]=false;
global.BG2_XcanScroll=false;
background_hspeed[2]=0;                             // speed setting (scrolling backgrounds)
global.BG2_YcanScroll=false;
background_vspeed[2]=0;
global.BG2_Xmultiplier=0.2;                     
global.BG2_Ymultiplier=0.3;

Basically, even with more complexity here I am doing the EXACT same thing as you. No jitter. My game is 800x450 though.
I invite you to try it and see in the "work in progress" forum. Maybe am dumb and I don't see the jitter? lol
 
A

Alessio

Guest
Basically, even with more complexity here I am doing the EXACT same thing as you. No jitter. My game is 800x450 though.
I invite you to try it and see in the "work in progress" forum. Maybe am dumb and I don't see the jitter? lol
Have you at least checked my files i've linked in my previous post? Why don't check those? Or "maybe i am dumb and I see the jitter lol"?

No offense but i don't know if going like that contributes to any discussion. I politely ask you to check those and give it a look, because it's just a small test project file you can give a quick look in. One needs to find an object called "oBackgroundScroll1" (my background manager) and see that in my object there is a code that is exactely like your one, "background_x/y[0] = view_x/yview[0] * 0.5", "0.5" being the multipler (don't need the offset right now, which is the starting position i guess). But yet my version is glitchy and if i didn't have the problem i wouldn't post here.

Again, with "lols" we're not going anywhere.
 

RangerX

Member
Whaaat? You got me all wrong and almost perfect opposite of what I was writing.

First off, am just sharing my code for comparison sake, for anybody where it could be useful.

After that I am sharing the fact with you that I am just as flabergasted as you are, since I don't understand the difference between our background code and why I don't get the jitter that you get.
And since I am open-minded and always ready to doubt myself, I even said that ITS ME that might be dumb and maybe I don't see that my game is jittering. I said this in self-mockery. I can't even understand why you could think its about you. :(
 
A

Alessio

Guest
Whaaat? You got me all wrong and almost perfect opposite of what I was writing.

First off, am just sharing my code for comparison sake, for anybody where it could be useful.

After that I am sharing the fact with you that I am just as flabergasted as you are, since I don't understand the difference between our background code and why I don't get the jitter that you get.
And since I am open-minded and always ready to doubt myself, I even said that ITS ME that might be dumb and maybe I don't see that my game is jittering. I said this in self-mockery. I can't even understand why you could think its about you. :(
Ok, sorry for that, i've probably misinterpreted your message.
Unfortunately, usually, it's legitimately hard to distinguish sarcastic replies from those that are sincere (really, this it's unanimous, common knowledge). And, unfortunately, forums are full of jerks who can't wait to be like that. And, since i've attended forums full of jerks in the past, for me, it's not hard to misunderstand the tone of a post. Some of these forums had admins who would mock in mass one user because he made weird posts (seriously, those may be little kids that escaped the parental radar) or put a "NOOB" sign below your avatar because you wrote "numa numa" in your post. So far, thank god here is different.

And, back to the topic, i just wanted to know if the same thing i had in my test project was visible to someone else. Because, if you see in my .exe, you can see that my background is jittering and if it doesn't, i'm weirded out, i dunno. Effectively, now i wonder if, when i created the project, it didn't turn out glitchy somehow, GM:S is full of bugs, after all. As i've written earlier:
I even had a weird problem caused by somything i don't know. I had a "camera" object that is fixed to the player, using "x = obj.x" and "y = obj.y" on the end step event: in the resource tree, if i put the camera after the player object, the thing won't follow the player correctly, there is a delay, but if i put the camera before it, the problem isn't there and works as intented.
This is the weirdest thing i've experienced in a software. But, right now, it's not a big deal because i'm waiting for GM:S2: thank god it will be easier to work with the room editor, hopefully.
 
Q

qyuodash

Guest
Hi guys, i have same problem here with my background.
It clithes, when i set background speed like 0.23 . But if i set speed as Integer number its Ok.
i cannot post videos yet, but you can find one on youtube "Game maker background glitching"
Is there simple solution for this?
 
Q

qyuodash

Guest
Or, another way around it all is upscaling the size of all the images, then downscaling the window port. You would still have the pixel look, but you'll get smoother, slow accelerating movement, like you want.
Hi there.I have the same issue.
i have upscaled all images (make them doublesized), but they still glithes.
Maybe because i did not downscale the window port, can u please describe "downscaling the window port" in details?
 

RangerX

Member
No no, you seem to get it all wrong.
Give me some information about your game:

- First off, pop here all your background related code.
- Tell me your: View size, Port on screen size, Application Surface size and your monitor's resolution
- What's the settings on the graphic tab of your target's global settings? Keep aspect ratio?
 
Q

qyuodash

Guest
No no, you seem to get it all wrong.
Give me some information about your game:

- First off, pop here all your background related code.
- Tell me your: View size, Port on screen size, Application Surface size and your monitor's resolution
- What's the settings on the graphic tab of your target's global settings? Keep aspect ratio?
While i was serching for information you wanted, i had turned off "interpolate colors between pixels" in General / Graphic settings and glitches are gone.

So thank you!
 
L

lienthealien

Guest
Thanks that did the trick for me "interpolate colors between pixels"
 
C

Christopher Rosa

Guest
soooo... how do you move the view_xview in non_integer increments? is it possible? or is that variable being rounded under the hood?
 
Top