This site requires JavaScript, please enable it in your browser!
Greenfoot back

Report as inappropriate.

sp33dy
sp33dy presents ...

2012/6/9

Tile Pixel Scrolling

Thought I'd try a simple multi-directional scroll with 16x16 Tiles. Use:

Q W E
A D
Z X C

for directions.

You'll note that scrolling continues, even if tiles run out.

The scrolling is inefficient at moment. I.E. each time the scroll crosses the 16 pixel, all tiles for screen are refreshed. A copy image to move the majority of the pixels will be used soon.

4290 views / 10 in the last 7 days

1 vote | 0 in the last 7 days

Tags: demo with-source

This scenario is a member of: Scrolling games


open in greenfoot
Your browser does not support the canvas tag.
danpostdanpost

2012/6/9

It would be much faster to have an Actor 'Tile' class in an unbounded world. Then the world can move all the tile actors in the appropriate direction when a key is held down. I have a sample scenario, if you want to see.
sp33dysp33dy

2012/6/10

Hi Dan. I was originally thinking about this problem in a 16bit (amiga) type way in which scrolling would be performed by shifting the entire set of images on one tile and then 'blitting' the edges; which this simulates (sort of). I was going to put in the shift of all barring the edges next. However, thinking about what you've said, shifting all tiles is a pretty obvious way to do things; given Greenfoot already double buffers. Very very good thinking. Thanks for that, will convert this later (as the code becomes very simple).
sp33dysp33dy

2012/6/12

Hi Dan, to follow up. Yes, actors can be used to tile the screen for background; however, after lots of testing here. It's very inefficient! Especially when small tiles are desired (i.e. 8x8 pixels). I think the traditional 16 bit way is much better, pasting the images into one actor that is larger than screen. I'm going to continue my exploration of this.
danpostdanpost

2012/6/12

Hey sp33dy, just a quick question. You are not repainting the tile objects, are you?
sp33dysp33dy

2012/6/12

The current version supplied is (which is really bad). The plan is to paint the loaded image tiles to one big actor; oversized by one tile on each border. Pixel move the actor in the direction of scroll. When scroll reaches tile width limit, use a big image copy to shift all images in the big actor by the tile width and then paint in the border size that is now needing the new tiles painted. This, in my view is going to be a lot quicker; especially when I drop the tiles down to 8x8 size, i.e. an 800x600 screen with tiles of 8x8 would require over 8000 actor tiles! Painting the initial screen actor will be costly, but that's expected; and is the problem in the code provided here. Hope this makes sense.
danpostdanpost

2012/6/12

My version created 3200 16x16 tiles objects, and move all of them on each movement. It then relocates any tile that are way off the screen to the opposite side; always keeping a full background in view. No image manipulating required.
danpostdanpost

2012/6/12

I just made my world equal in size to yours (800, 400, 1). I way overdid the number of tile objects needed; as before I could easily have gotten away with less then half of what I had. Still, my tile array, now, is 55x30, which is 1650 (about half of what I had). I think the reason I had so many before, was that I did not want the pattern to repeat so quickly. Anyway, there is very little, if noticable, lag.

Want to leave a comment? You must first log in.

Who likes this?

Mimagic