next »

[Simon Andersson]

Hello dear TIGers! I come here, searching for help.
I have, for way too long now, been stuck on a single problem. I somehow can't get my damn tiles to scroll in a flash game me and my friend are trying to make. (example of fail)

I though that I would have all the tiles as seperate movieclips, and I create them all depending on a 2D-array into a "level"-movieclip that moves as the player walks around.
Then I though it would be best if the tiles that isn't on screen dissappears, to save memory.
So then, as the level moves around, I should draw a new row of tiles in front of the player, while removing another behind him.
I thought I would just focus on the horisontal scrolling at first.

Exemple.

You can move in one direction, everything works fine, the tiles behind you dissappear, the tiles in front of you appear. You can turn around, and everything works perfectly, but then when you starts to move i that first direction again...
I encounter the error: "ArgumentError: Error #2025: The supplied DisplayObject must be a child of the caller.", and I have no idea why.

Here's if you would like to take a crack at the code.

Any idea what I could be doing wrong? (I guess I'm trying to remove something that doesn't exist, but I don't really see how this is possible), Should I perhaps, try to do this in some other way?

I hate that I can't explain this better...

[moi]

Are you doing your own framework?
You could save yourself the time and use flixel

[nikki]

You could have a look over at Tonypa's
I know this movieclip method you speak of is outdated and slow, and since Flash CS something you have these much faster methods.

Wich Flixel uses.

[bateleur]

Here's if you would like to take a crack at the code.

I'd be happy to, but I don't have anything that opens .rar files. Any chance of a zip? (Or a recommendation for a good, free rar decompresser!)

[Petethegoat]

Use winrar's trial version.
http://www.rarlab.com/

Or 7zip, which is free.
http://www.7-zip.org/

[Simon Andersson]

Are you doing your own framework?
You could save yourself the time and use flixel

Well, yeah, I guess I do It's kinda for a school project, and I really want to learn all the basics, so I'm going to stick to regular as3 for now.

Maybe I can try to look how flixel does, however, definitly going to check out that page nikki! Many thanks!

And here's a Zip: http://www.megafileupload.com/en/file/174372/TileScrollZip-zip.html if you don't want to bother with those programs. But 7zip is a pretty nice program to have anyway

Really appreciating the answers guys!

[Richard Kain]

Well, for starters, I don't think you should be using MovieClip objects. In terms of performance, you would be much better off using the Graphic class. There's a lot less you can do with it, but there's also a lot back-end code associated with it. In short, you'll get better performance out of the Graphic class if you throw hundreds of tiles up on the screen. Using the MovieClip or the Sprite classes will bloat your program if you use them for constructing tile-based levels.

Ideally, you would want to separate out the "tile" class from whatever drawing routine you are running. The only real information you need for an individual tile is width, height, x location, y location, and possibly an index number to tell the engine what graphic to draw into it. Clipping can be handled by a scene graph. That's another issue entirely.

[bateleur]

Or 7zip, which is free.
http://www.7-zip.org/

Perfect, thanks.

And here's a Zip: http://www.megafileupload.com/en/file/174372/TileScrollZip-zip.html if you don't want to bother with those programs. But 7zip is a pretty nice program to have anyway

OK, well, I think I see the problem. This line:

Code:

tileArray.splice(i,0);

...should say this...

Code:

tileArray.splice(i,1);

Also, if I might make a few suggestions having seen the code:

* Sprite is preferable to MovieClip where a timeline is not required.
* For this kind of game you will get far better performance using BitmapData objects and copyPixels. It may be a bit late to profitably change for this project, but worth bearing in mind for your next one.
* Running through a list of tiles in order to calculate which one to remove is both inefficient and inelegant. Better to keep track of where the edges of the screen are relative to your Array. Every time you add or remove a block, update the corresponding edge.

Lastly - and I don't mean to be impolite here - your code is a dreadful mess. You may find it easier to debug things if you keep them neat, tidy and organised.

Good luck with the project!

[Glaiel-Gamer]

* Sprite is preferable to MovieClip where a timeline is not required.
* For this kind of game you will get far better performance using BitmapData objects and copyPixels. It may be a bit late to profitably change for this project, but worth bearing in mind for your next one.

This. Also as a middle ground, set the tiles cacheAsBitmap property to true

[Simon Andersson]

Yeah, I have rewritten that code quite abit, I think most of it was done in the night, and I was impatient to finish it.
 I'm not that good either, been coding on and off for a year now, so absolutely no offence taken

OK, well, I think I see the problem. This line:

Code:

tileArray.splice(i,0);

...should say this...

Code:

tileArray.splice(i,1);

Wow! That is one damn stupid error to make! The worst part is that I rewrote all the code at one time, I must have done this exact thing twice, pretty scary, gonna have to look up that old code.

Probably going to rework everything again, but it's very nice to know what I did wrong

And I will strongly concider every point made here, really thanks for the help everyone!


PS. If you don't mind me asking,

* Running through a list of tiles in order to calculate which one to remove is both inefficient and inelegant. Better to keep track of where the edges of the screen are relative to your Array. Every time you add or remove a block, update the corresponding edge.

How would one best proceed to do this? I can see this working if I have a map with tiles at every spot, like:

Code:

x,x,x,x,x,x,x
x,x,x,x,x,x,x
x,x,x,x,x,x,x
x,x,x,x,x,x,x

But what if there are empty parts like,

Code:

x,x,x,x,0,0,0
0,0,0,x,0,0,0
x,x,0,0,0,0,0
x,x,x,x,x,x,x

wouldn't that make it hard to track where the edges are? Should I perhaps include invicible (maybe empty is a better word) graphical object for the spaces in the array that doesn't contain real graphic? (does I even make sense?)

[st33d]

I'd like to see these bench mark tests that prove that rendering an entirely static scene with MovieClips and leaving them there is faster than rendering all of the tiles every frame.

I'm well aware that copyPixels is fast for dealing with lots of particles - small particles that are constantly on the move.

But what about multilayered scenery? What about parallax layers?

I mean I use blitting for particle effects myself. But I haven't seen performance tests for blitting vs Sprites for scenes without a lot going on in them - which you get a lot of in platformers.

I'm not saying Flixel isn't fast, but it does run at double scale.

I would argue for a combination of both methods myself, but each to their own.

[st33d]

re checking the edge:

It's the stage that moves. The viewport doesn't.

Seeing it that way, you calculate what rows or columns need adding by how much the stage has moved. No more need for checking each tile.

[Simon Andersson]

well yeah, that's the way I already do it.
The "problem" is when I should be removing the rows/columns in the other edge of the screen, how to know which I should remove without checking what position they have. Without looping through all visible tiles. I really can't seem to figure out a smart system for that.

Oh, and yeah, I'm going to try to use Bitmapdata and that sort of stuff instead, no worries.

[Glaiel-Gamer]

What I did to keep track of tiles to be added/removed in my tile engines was something like this


x = floor,
- = space,

^ = current screen edge
^ = one outside the current screen edge

red area is the screen


----x-----------------------
----x-----------------------
----x---------------------x-
----x-----------------------
-----x--------xx-----xxx----
------xxxxxxxxxxx---x-------
----------------x---x-------
   ^^            ^^


screen scrolls to the right now, once it passes a threshold (the blue marker), it loads in the tiles from the blue column, unloads the tiles from the opposite red column, and shifts all the markers to the right by one.

Same for scrolling to the left. If you set it up right, it's just a matter of positioning the red / blue markers right in the beginning of the game.

In words, you keep track of the game in columns, and have a column index be stored for the following columns:

-Column to be unloaded if screen scrolls to the left
-Column to be loaded if screen scrolls to the left
-Column to be unloaded if screen scrolls to the right
-Column to be loaded if screen scrolls to the right

If the screen scrolls to the right, ALL 4 get incremented by one. If it scrolls to the left, ALL 4 get decremented by one. AFTER loading / unloading the specified columns of course.

Since all the column markers are constantly spaced from each other by the same amount, you only really need to store one of these.

This will fail if you scroll by more than 1 tile width, but it's a simple enough fix there.

(also similar for keeping track of rows too, do one after the other, and clamp the range by the other's current range)

[Simon Andersson]

Great explanation, I had one variable keeping track on the first red row (named something really stupid because I have no imagination), so I kinda already did this, but I guess I should have maybe stored the tileobjects in a 2D-Array instead of a normal array? To get easier access to the single lines?

[Glaiel-Gamer]

Great explanation, I had one variable keeping track on the first red row (named something really stupid because I have no imagination), so I kinda already did this, but I guess I should have maybe stored the tileobjects in a 2D-Array instead of a normal array? To get easier access to the single lines?

Yes, keep empty tiles as just "null" or whatever, and do a quick check in the array as "if tile != null" before adding and removing.

I usually have 1 map be the collision data and 1 be the actual tiles.

[Simon Andersson]

Okay, this helps a ton, thanks

[Simon Andersson]

re checking the edge:

It's the stage that moves. The viewport doesn't.

Seeing it that way, you calculate what rows or columns need adding by how much the stage has moved. No more need for checking each tile.

Oh, I'm sorry, you're of course right, I really though I did it your way. I hate myself sometime