TODO: Improve screen wrap quick implementation.

[antfarmar]

ScreenWrapper.cs is the script component that screen wraps any GameObject it is attached to.

It is currently implemented as a slick hack using the OnBecameInvisible() Renderer message to determine when the object leaves the viewport, but it has issues:

Issues:

• An object is considered _visible_ when it needs to be _rendered_ in the scene.
• So it might _not be actually visible_ by any camera, but _still needs to be rendered_ for shadows for example.
• Also, when running in the editor, the _scene view_ cameras will also cause this function to be called.

Given these issues though, if you're not using shadows and have your scene view off or zoomed in slightly more than the game view when playtesting, you're pretty much good to go.

Also, see the wiki: Screenwrapping.

[antfarmar]

Algorithm has been slightly improved. Still using simple code.

[ghost]

Another subtle glitch occur when firing bullets at asteroids escaping screen wrap. Sometimes the renderers bounds are still within camera view but the colliders are not. This means an asteroid can escape into the corner of the screen and even if you shoot toward it, you won't hit. The bullets will wrap as they cross the screen edge, miss the asteroid, and overshoot it since it spawns on the other side of the screen. It is not a robust screen wrap solution. A slightly more improved solution would superimpose a second (or third, or fourth) asteroid on the other side of the screen so they never disappear into a "hidden zone".

In other words, when an asteroid starts to disappear out of screen, it should start to appear on the other side of the screen - you'd need two or more asteroids to achieve the effect - at least graphics and colliders for it since it has to exist on both ends at the same time.

[antfarmar]

Yeah it definitely needs improvement since it's buggy and inconsistent, clearly not production ready. (It's a nice little algorithm for quick prototyping though.)

Strangely, there's also not that many resources regarding this on the internet. Usually you can find some good pre-made solution, but most are similar to the one I used.

I think the only robust solution I found used 5 cameras, which provided wrapping continuity.

It's not a priority for me yet. I'm still focused on learning Unity, design patterns, and C#.

[antfarmar]

Might take another stab at this issue today.

How the @&%$ is there not already a ready made Component script for this common problem? Or even code in any language? There must be. Maybe it's time to brush up on my Google-fu too.

Research:

Pretty much the current implementation (the simple implementation):

http://gamedevelopment.tutsplus.com/articles/create-an-asteroids-like-screen-wrapping-effect-with-unity--gamedev-15055

The code: https://github.com/tutsplus/screen-wrapping-unity/blob/master/src/Assets/Scripts/ScreenWrapBehaviour.cs

---

Another possible approach: renderer.bounds http://forum.unity3d.com/threads/asteroid-style-screen-wrapping-letting-asteroids-escape.276540/#post-2315334

---

Use a collider spanning the screen to detect Trigger enter/exits: http://forum.unity3d.com/threads/how-to-detect-screen-edge-in-unity.109583/#post-726547

If I were wanting to detect the edge of the screen to make a character wrap around or a bullet get destroyed when leaving the playfield, I would create an empty GameObject with a Collider attached and then use ViewportToWorld to scale the Collider to the correct size so that it exactly fills the screen. Then use OnTriggerEnter and OnTriggerExit to detect enemies, bullets and other objects entering and exiting the screen.

Problem: Will need to rewrite/redesign Trigger/Collision events to handle this new collider.

[antfarmar]

Screenwrapping algorithm has been redesigned in commit 48b988d . It is so far stable, robust, and bug free. The code needs serious refactoring though.

• Removed all computations based on "visibility" in Unity API.
  • e.g. OnBecameInvisible
  • They're not consistent or precise enough.
• Algorithm now uses bounds checking.
  • AABB bounds of an object's renderer. (could've also used Collider bounds)
  • checked against World bounds as a Rect
• Objects also have a wrapping timeout to prevent constant wrapping lock.
  • If an object wraps in some direction, it shouldn't need to wrap again in the same direction right away!
  • This prevents objects from getting stuck on an edge by constantly wrapping back and forth.