background in editor is like parallax

[mobius]

If you have a background and scroll through the level in the editor; the background doesn't move, making it easier to tell what's background and what's foreground. Idk if this is intentional or not; but this is exactly the kind of thing I want for the player. Current player behavior is like it always was: background moves same as the foreground.
This isn't really a request or complaint or anything; I just felt like mentioning it because I told Icho about it in IRC and he seemed unaware and I haven't hear anyone else mention it.

[GigaLem]

Wouldn't be a bad idea if it were a separate object, because some BGs would be too small or to big for paralax, or they would be made on such a way to fit it that way

[Nepster]

First of all: This is a bug, that I already fixed for the next version.

Nevertheless I am very much in favor of changing backgrounds to static ones. I already said so in the previous thread, which however did not create a lot of feedback, so the issue was forgotten.

As the person who has to implement the change, I would like to add a few more comments:
1) I will not make this an option: Either all backgrounds are static or all of them move like the current ones.
2) Too small backgrounds should not be a huge problem, because we still can use the paving algorithm to extend them to the full window (not level!) size.
3) Regarding too big backgrounds: I wouldn't worry too much. The width is usually low enough that the whole piece can be displayed in fullscreen with 3x zoom. There are some pieces that are higher than the usual screen height, but already now they have two problems: First of all they won't get displayed properly on levels with default height either. Secondly they are usually "sky over earth" type backgrounds, which would look extremely ugly if they are paved vertically. So it might actually be preferrable to see only a part of them, instead a paved version.
4) At the moment I am not sure how to handle zooming with static backgrounds. I tend to keeping the default zoom, i.e. not zooming the background image at all. But that begs the question: What should be the default zoom for the background image? The initial zoom for the level perhaps?

[IchoTolot]

1) I will not make this an option: Either all backgrounds are static or all of them move like the current ones.

Well, I would be in favor of this if it was an option. As you said in point 3, quite a few backgrounds would look really ugly with this and I personally would not like to have static bgs all of the time.

A bunch of bgs are simply not layed out for this and I see static ones as a really good addition to the current option, but not a suitable standard.

Also the current way I would call more easily understandable in how it works as the static way.

So: I am in favor of this as an option, but not as the overall standard!

[Nepster]

As you said in point 3, quite a few backgrounds would look really ugly with this and I personally would not like to have static bgs all of the time.

As I said in point 3, these huge sky-over-earth backgrounds don't look good in the current system either, except if you have levels that are almost exactly of the same height. And how often do you get levels that are 240-260 pixels high?

[IchoTolot]

As I said in point 3, these huge sky-over-earth backgrounds don't look good in the current system either, except if you have levels that are almost exactly of the same height. And how often do you get levels that are 240-260 pixels high?

That's why I think this is an excellent option, but not a good standard. Both ways have advantages and disadvantages and together they would cover each others weaknesses.

[Nepster]

As I said: Having options is not an option here! Do you know any other game, that offers an option between static and moving backgrounds? Please let's not confuse the player by mixing various background options.

From now on I will enforce the following rule, because I am totally fed up with noone respecting me when I say that something is not an option:
When I exclude an option, then there will be no more discussions about exactly that, except by people actually helping coding NeoLemmix. Every post that does so, will be removed by me, because arguing about something that will definitely not happen doesn't help and only creates bad feelings!

[IchoTolot]

Another idea that came to my mind during the day: What about the background is not static as before, but moves with a different speed than the foreground. This makes it much more distinct and easier to recognize. Simply set the speed to about half of the foreground and we should have a good result.

[Nepster]

Another idea that came to my mind during the day: What about the background is not static as before, but moves with a different speed than the foreground. This makes it much more distinct and easier to recognize. Simply set the speed to about half of the foreground and we should have a good result.

1) This is more difficult to implement than a static background, and you can probably imagine how much effort I wish to spend on a feature (i.e. backgrounds) that is completely useless in my opinion.
2) What problem would this solve compared to completely static backgrounds?

[IchoTolot]

Maybe a test version with the static way would make all this a bit clearer here. Actually seing the effects in action is the best thing.

[mobius]

First of all: This is a bug, that I already fixed for the next version.

Nevertheless I am very much in favor of changing backgrounds to static ones. I already said so in the previous thread, which however did not create a lot of feedback, so the issue was forgotten.

As the person who has to implement the change, I would like to add a few more comments:
1) I will not make this an option: Either all backgrounds are static or all of them move like the current ones.
2) Too small backgrounds should not be a huge problem, because we still can use the paving algorithm to extend them to the full window (not level!) size.
3) Regarding too big backgrounds: I wouldn't worry too much. The width is usually low enough that the whole piece can be displayed in fullscreen with 3x zoom. There are some pieces that are higher than the usual screen height, but already now they have two problems: First of all they won't get displayed properly on levels with default height either. Secondly they are usually "sky over earth" type backgrounds, which would look extremely ugly if they are paved vertically. So it might actually be preferrable to see only a part of them, instead a paved version.
4) At the moment I am not sure how to handle zooming with static backgrounds. I tend to keeping the default zoom, i.e. not zooming the background image at all. But that begs the question: What should be the default zoom for the background image? The initial zoom for the level perhaps?

for 4. : I think the way it worked in the "bugged" editor was just fine. So it should zoom the same as it does for the level. Or it could be made to be static; never zoom when only the level zooms in and out.

[nin10doadict]

Having static backgrounds doesn't seem like a big problem to me. You usually have to design two backgrounds anyway, one for vertical levels and one for horizontal levels. A static 'horizontal' BG could still look odd in a level with vertical scrolling, and vice versa. So as far as tileset design goes, this doesn't seem to make a big difference.

Though if the BG doesn't move, we no longer need to design it to be 'tiled' so that it aligns properly in big levels. It also will make it clearer what is the background and what isn't if the level is allowed to scroll: If it doesn't move, it's BG. That said, we should strive to make backgrounds that are clearly background either way.

[namida]

Though if the BG doesn't move, we no longer need to design it to be 'tiled' so that it aligns properly in big levels.

Not true, unless your BG is ridiculously huge. Keep in mind that NeoLemmix no longer has a fixed amount of level area that displays on-screen at a time. In the case of a 4K screen, with the player playing at 1x zoom on a level that's as big or bigger than that screen area (unrealistic, but technically possible), you'd need a background of nearly 3840x2160 to avoid any need for tiling (or stretching).