Scrolling by offset or translation
Monkey Forums/Monkey Programming/Scrolling by offset or translation
| ||
| Hi all I was curious to here what is the best way to go about scrolling in my game. Should I place an offset on every object (affected by character movement), or should I via translation move the world? Thanks all, I have seen examples of both on the forums, but I would like to hear which solution would be best. |
| ||
| The answer will depend on your game design, your technology stack and also which model you find easiest to think about. I find it much easier to think in terms of world space for object positioning and then transformation to camera space for rendering but others may prefer to always think in screen space and move everything around that. On the technology stack front you might want to bear in mind that if you end up using a framework or collision/physics library then moving the entire world around to conform to screen space may become problematic. Doing so with Box2D will kill performance (because moving objects requires manipulating the collision data structures) and possibly break the simulation (if you try to do a 1m = 1pixel world scale). |
| ||
| Thanks for the reply Well fortunately I am not constrained by a certain framework. The only thing which could potentially cause an issue is the spatial hashing/partitioning grid I am using for potential collisions, but even that should not be an issue because each game object will still fit in a certain area that I define as screen space. I will spend some more time thinking about it, and then knock out the solution. |
| ||
| I knocked out a simple prototype last night using an offset for scrolling, I think I will run with it. I did notice some hitching though, which I will have to fix. |
| ||
| Might be worth seeing an example of both and listing the pro's and con's of each. Personally I use offset's not because I think it's better or anything, it just happens to be the method that came naturally to me, having not used Box2D and planning to use it in the future this is of interest to me. |
| ||
| I could post what I threw together last night if you like? But you already have it implemented so not sure of what help it would be. As for moving the camera only, I don't have an example for that. Yeah my issue I am trying to think through now would be making sure the grid for collision works properly. Not sure if I want to "clip" it to screen space only, or the actual size of the world. If it is the size of the world, then indexing into the grid would need to take the offset into account. |
| ||
| I use clipping, at least for displaying the world when I use the offset method. It's far faster than trying to keep up with the entire world, but adds a little complexcity to your code. The world size definitely makes a difference to the performance unless you use clipping. I generally add an extra tile or two around the screen size. Smooth scrolling occurs very nicely this way too :) |
| ||
| Yeah, I will have to see how it goes, the levels in my game will not be big, the screen would only scroll a bit, and then you would hit the boundaries, so the need to clip objects off screen may not be a big deal. |
| ||
| Sounds reasonable to give it a go without clipping then :) I would for-go it myself as well in that case. |
| ||
| Grovey: make sure your hitching isn't caused by something else. If I am running chrome in the background my performance is severely degraded, in the form of irregular hitches. Also debug is much choppier than release on my rig and I keep forgetting about that. |
   |