Scrolling background approach

[totebo]

Hi,

I’m adding a sideways one-way scrolling background to my game. The graphics will change as the scrolling progresses.

My plan is to use two large identical bitmaps side by side that “loop” and then replace them when needed.

In terms of performance, which of these methods are best?

a) Use a factory to create and unload bitmaps on the fly.
b) Create all bitmaps in the IDE and disable/enable them with code as needed.

I’m new to Defold, so do let me know if there are better ways to create a scrolling background!

Cheers,

Niclas

[Pkeod]

If someone smart could figure out how to fix this Correct UV offset of full screen repeating texture then it could be used. Then you would only need a single texture that you offset as you scroll, and doing parallax layers would be super easy too.

[totebo]

I was initially looking to use a single texture, and replacing the texture as needed. I found this discussion:

Questions: UV Coords, Components manipulating

I’m in holidays for 2 weeks just have some web on my phone (poor connection) but you can start reading this : http://www.defold.com/manuals/material/ Shader in defold isn’t too complicated to setup and you will fond uv scrool shader easily with Google If you’re block i’ll help you back to holidays

This is beyond my skills, because it relies on shaders, which, as anyone knows, is impenetrable black magic.

So, I’m trying to figure out whether keeping game objects on stage and disabling/enabling them would work best in my case, or if creating them on the fly with Factory is likely to work better. My gut tells me Factory, because it would be more scalable.

[sicher]

So, I’m trying to figure out whether keeping game objects on stage and disabling/enabling them would work best in my case, or if creating them on the fly with Factory is likely to work better. My gut tells me Factory, because it would be more scalable.

Both approaches will probably work well. I would consider a few things:

• How do you plan to author your levels or do you plan to generate the layout automatically somehow?
• How long will your level be? Going far enough from origo you will lose precision and things will start to jitter. You can postpone this by increasing precision in shaders but if you allow your player to go far enough (like in an endless runner) it will eventually be a problem. The solution is to keep the player close to origo and move the world instead of moving the player.
• How many game objects do you anticipate you will have to manage?

[totebo]

Hi @sicher, thanks for the response!

This is for a background, not for level design, so I’m thinking simple bitmaps. And I fully intend to cheat and keep the player at 0x0 at all times, and just move the background. , like this:

There will be ten backgrounds or so, so I’ll have to swap over the bitmaps at runtime with one of the techniques I’m pondering.

[sicher]

Ok. It would probably be easiest (as in less code) to put two game objects with the bg sprite in a collection and just scroll those around. You can then play a different anim (still) on the sprite to switch out the graphics.

This is going to be simple enough so if you later on feel you need a more complex solution you can just rewrite it using factories.

[totebo]

In my case swapping to a different anim at runtime probably won’t work, because the bitmaps are 512x1024. I wouldn’t be able to squeeze ten of those into a single atlas.

Unless there is a way to change atlas at runtime, in which case it would be super easy!

[sicher]

Yeah, that is too much for an atlas. It sounds like factories are the most straightforward way.

If you end up with too much bg data in memory you can mark the factories “load dynamically” and deal with the resource loading yourself. (Remember all resources are statically defined so if you link a factory to a go the resources associated with that go will be loaded into memory up front - unless you explicitly mark it “load dynamically”.)

(EDIT: was unclear so I rewrote the answer)

[totebo]

Yeah, that makes sense and is really useful actually. Like a pool.

I’m now going down the route of adding ALL backgrounds in the IDE, then at runtime disable the ones that are not needed at the time. I am using one game object per bitmap. It will roughly equate to 30 game objects using 10 atlases, each atlas being 512x1024. At any one time I’ll have a maximum of two background game objects enabled.

Is this madness, or doable? Keeping the backgrounds in the IDE would be useful, because then I can easily position additional sprites.

[sicher]

Totally doable. Each atlas consumes about 2mb. All of them will be in memory so that’s about 20mb. If you need to streamline memory use later on you can change the setup, or look at the content. One simple trick is to scale down the background graphics to, say 256x256 or 512x512, and scale it up to 512x1024. You will lose graphics fidelity but perhaps your backgrounds allow for that?

[totebo]

Nice one! Yeah you’re right, these backgrounds definitely fall into the 60MPH art category. One option is to keep them low res and spruce them up with higher res, more visible, smaller objects pulled from a single atlas. Another could be making them 256x1024 and use more game objects.

Thanks so much for your help!

[indoor_keith]

@sicher

How long will your level be? Going far enough from origo you will lose precision and things will start to jitter. You can postpone this by increasing precision in shaders but if you allow your player to go far enough (like in an endless runner) it will eventually be a problem. The solution is to keep the player close to origo and move the world instead of moving the player.

Trying to find some more documentation on this but I’m not sure what to search for. Are you (or is anyone) able to elaborate on what you mean by losing precision and jittering? Also, at what distance from origo does this become noticeable?

[Mathias_Westerdahl]

Here’s a useful link about floating point precision:

Floating point precision

Every now and then, you’ll see issues that can be described as “choppy” animations, or perhaps your code doesn’t work when comparing various variables. Sometimes, it could be related to something called “floating point precision”. It stems from the fact that on a computer, real numbers have to be approximated in some way. And as you might imagine, the approximation result might not always be what you intended. (See table at the end) TL;DR: Floating point values… … does not have infinite ra…