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.
I was initially looking to use a single texture, and replacing the texture as needed. I found this discussion:
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.
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?
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:
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.
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!
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”.)
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.
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?
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.
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?
, like this: