Displaying a long horizontal environment

Author

Message

JORGEMAL

14

Years of Service

User Offline

Joined: 2nd Aug 2009

Location:

Posted: 16th Oct 2013 02:24

Link

I want to develop a 2D game in which a character will be able to walk in an environment. Such environment does not fit entirely on the screen so, as the character moves ahead, more of the environment will be shown. What I really mean is that the environment occupies much space horizontally which must be shown little by little as my character walks ahead, and it must be hidden as my character walks back. The only idea that I have is to draw the entire environment and place it on the screen (although part of it will be out of bounds) and "scroll" it back and forth. This way the whole image will always be loaded, but the only visible portions are those within the visible screen area. I am writing to ask for advice about what is the best approach to solve my issue.

Best regards.

Back to top

Profile PM

Marl

12

Years of Service

User Offline

Joined: 19th Nov 2011

Location: Bradford, UK

Posted: 16th Oct 2013 03:19 Edited at: 16th Oct 2013 03:26

Link

(with the usual disclaimer that it depends on the size and type of environment you want to create)

The most likely solution would be to display the environment on the world plane* and scroll it with the setviewOffset command.

That way the sprites which make up the environment need only be positioned once, and their movement is handled by AGK.

You would probably build the background from sprite tiles, and for very large environments, add and remove sprites as you approach the edges.

Remember to keep all images to power of two sizes and you should be ok.

*AGK has two planes on which sprites and text can be positioned, the display plane - which is fixed in to the screen, and the world plane - which can scroll independently of it.

Edit:

It's worth remembering that object depth has nothing to do with which plane the object is on, this can save a lot of work combining layers.

For example, you could have a static background on the display plane, with a scrolling mid ground on the world plane, and in the foreground the scores and other display items - again on the display plane.

- Background (depth 200) Fixed to screen
- Scrolling (depth 100) not fixed to screen
- Foregound (depth 50) fixed to screen

Effectively this creates is a scrolling display sandwiched between two static displays;

This might seem a bit complex to start with, but knowing you can do it at the outset might save some work planning a workaround you don't need.

Back to top

Profile PM Email

Van B

Moderator

21

Years of Service

User Offline

Joined: 8th Oct 2002

Location: Sunnyvale

Posted: 16th Oct 2013 09:52

Link

I would use full screen sprites, or at least sprites that are the same width as the screen, lock them to the screen, then just shift the UV for each sprite to suit the scrolling. That way, you could easily have parallax scrolling by adjusting the formula depending on the screen depth.

The actual game sprites are probably best being positioned on the world plane. So, you might have a variable for the X scroll position, where you'd set the view offset, and then take that and divide it by 1000 or whatever works (will need tweaked), offset the UV of each backdrop sprite depending on that, maybe multiplying it by 0.75 each time so each layer moves slightly slower than the last.

I am the one who knocks...

Back to top

Profile PM Email

baxslash

Valued Member

Bronze Codemaster

17

Years of Service

User Offline

Joined: 26th Dec 2006

Location: Duffield

Posted: 16th Oct 2013 12:23

Link

It's much simpler in my experience to just position objects in world space and use setViewOffset. I made a side scrolling game that went on for ages that way and I never reached a limit. If you did reach a limit it would be pretty easy to reset the position to zero and move all world sprites back to the start (or better still to a negative limit) but it's unlikely you'll reach the limit quickly, particularly if you use a small scale.

Offsetting lots of sprites seems to be a much larger overhead than simply moving the view and it resolves any odd issues / mistakes with getting sprite positions relative to an offset variable.

oct(31) = dec(25)

Back to top

Profile PM Email

Van B

Moderator

21

Years of Service

User Offline

Joined: 8th Oct 2002

Location: Sunnyvale

Posted: 16th Oct 2013 12:41

Link

Ahh, not offsetting the sprites though - Just setting the UV coordinates to say, the camera X position / 1000 - so that way the backdrop sprites are locked to the screen and are UV mapped depending on the camera/view X position.

The issue I have with using the world view for a backdrop, is it's not easy to get parallax scrolling, and that's fairly vital in a sidescroller

(IMO at least)

I am the one who knocks...

Back to top

Profile PM Email

baxslash

Valued Member

Bronze Codemaster

17

Years of Service

User Offline

Joined: 26th Dec 2006

Location: Duffield

Posted: 16th Oct 2013 12:59

Link

Quote: "The issue I have with using the world view for a backdrop, is it's not easy to get parallax scrolling, and that's fairly vital in a sidescroller"

I do this very easily by applying an offset to background elements based on a depth. It's exactly the same as applying a UV offset:
setSpriteUVoffset(spr,offsetX#,offsetY#)
setSpriteOffset(spr,offsetX#,offsetY#)

The calculations are almost identical too.

oct(31) = dec(25)

Back to top

Profile PM Email