art based scrollers

[DELETED_jtnw]

does flash draw objects off screen? and if it does im guessing it would be quicker for me to set visible to 0 for things off screen, or would hundreds of enterFrames slow it down even more. anybody know for sure?

[random10122]

Yes it does draw things off screen, and yes enterframes would slow it down, your best bet is to have one enterframe that sets things visible and not depending on their name and _x/_y position - but if your gonna do that you might aswell use tiles!

[DELETED_jtnw]

well would it be better if i grouped things in groups of about 500x500 pixels and checked those, and by the way my maps are gonna be at least 7500x7500 pixels

[tonypa]

I pretty much doubt you can scroll 7500x7500 maps

You could brake up maps based on screen size and put them into different frames. Then you can use 2 instances of map mc to scroll. Check their coordinates, when 1 of them goes completely outside stage, place it in other end and make it go to next frame.

Like its done in David Doulls tutorial
http://www.flashkit.com/tutorials/Ga...-610/index.php
only you send map to next frame after placing it in other end.

[Olorin]

I don't think scrolling big maps like that would be a problem, as long as the size of the stage isn't too big. I'm my artbased scrollers, I move maps of about 500 x 5000 which works just fine. Just don't use any alpha's or gradients.

Olorin

[DELETED_jtnw]

I pretty much doubt you can scroll 7500x7500 maps

its actually possible, right now the map is 2000x1500 and scrolls and rarly goes below 29fps, the final map will be used as a png, but will have transparancy, but what im thinking is group pieces as say 1000x1000 groups and run something like this

code:

---

if(_x<-500 or _x>1100) {

  if(_y<-500 or _y>950) {

    _visible = 0

  }

}

---

so there wouldent be too many enterFrames

[Squize]

For fear of sounding stupid (Yeah, as if I care) but what are the benefits of using an art based scroller over a tile based ?

OK let's say it scrolls at a really good speed, and the code to run it will be easy and therefore short and run quickly, and because you are using one huge bitmap ( Or a collection of fairly large bitmaps ) you are not tied to tiles (ie every single pixel in that bitmap can be unique), but won't the file size be really massive ?

( Please don't think I'm taking some stupid pro tile based stance, I'm just curious. I mean do the pluses I've listed above more than outway the negative of a large filesize, or should I look at it on a per project basis ?).

Squize.

[DELETED_jtnw]

well tile based games dont have the freedom that art based do.
say since my game has slope walking, i wanted to draw a very irregular shaped hill, easy just use the paintbrush and scrible scrible done! now with tile based i would have to draw each tile, make them line up perfectly, then change the array...
just my point of view

[DELETED_jtnw]

but won't the file size be really massive

eh let the people with 56k (including myself) worry about it

w00t 400 posts

[Squize]

Yeah I guess if the trade off for download size is improved graphix and more freedom ( Or easier to code freedom, it can be done on a tile based engine ) then I suppose it's not too bad.

I've never touched an art based scroller so I just wanted to know.

Thanks 4 the reply 400 posts guy

Squize.

[Olorin]

you can still save a lot of filesize by reusing graphics. I've done a finished Art based scroller, with 5 fairly large levels in 225 kb, which isn't too big for a game like that, in my opinion...

Olorin

[Squize]

Ok I'm going to sound really stupid now...

How would you re-use graphix in an A.B. scroller? I assume you'd have "tiles" (ie large graphic clips rather than the usual 32x32 ) and just plot that into your container mc?

I've got to admit Olorin that the filesize is really impressive.

Squize.

[Olorin]

Yeah, that's it. For example, you can have a large platform, convert that to a graphic (not a movieclip) and then paste that graphic where-ever you need it in your container movie clip. That way, it's only 12 bites for every platform

Olorin

[Squize]

I've got to be honest I always thought scrolling a large bitmap would kill the Flash player ( The few art based scrollers I've seen posted here for the most part have been fairly painful ) but if you reckon that if coded well speed's not an issue then I may well have a play with it.

I'm kinda gutted I spent so long getting my gotoAndStop scroller running

Thanks for the feedback.

Squize.

[tomsamson]

asrtbased scrollers scroll faster than tilebased scrollers (if coded right),that´s true,than again in artbased scrollers you have to use hittest which turns out slower than tilebased collision detection

[xMCNUGGETx]

When im making tilebased scrollers I usually will attach all of the tiles at the begining of the level (baddies are a different story). So my scrolling is basically "art based".

If you look at my kirby, thats how it was done
http://www.xmcnuggetx.com/kirby

[Squize]

"artbased scrollers scroll faster than tilebased scrollers"

Do they? I always thought it was the opposite ( It's 'cause of my history with C64/Amiga where everything was tile based ).

OK, a tile based engine is displaying, I dunno, 14x7 tiles which is 98 mc's held in a container, which is a huge number of clips and a large amount of data to move around. But that's all it's running. The container mc is only as big as the visible display window and in effect nothing is going to waste.

With an AB scroller I guess you would set it up using a few large mc's containing the images ( Coverted to "graphic"s as opposed to mc's ) and then have all them in your container mc. Won't that:
a) Make the container mc much larger than it needs to be thereby slowing it down?
b) Mean you are moving a lot of redundant (ie non visible) data around?
Or failing that ( Sorry I'm kinda thinking aloud here as I've never thought about doing an AB scroller ) you would do away with the actual container mc and just scroll the large clips around. Couldn't that produce some sort of mild tearing where the clips meet?

As to the collision detection you could still run it as tile based, just cause it's art based you don't need bendy lines everywhere, you could just put it together using your normal 32x32 tiles(?).

What happens if you are scrolling diagonaly so in theory the player could be standing in the exact middle of 4 large clips (If you know what I mean), would that give a noticable performance impact (And if so you cheat to avoid it) or isn't it that big a deal?

So the speed increase is purely from the fact that you are not having to update the tile positions every 32 pixel moves, using a lot of mcs in a container is slower and you don't have to worry about reading map data as such?

Phew, a years worth of questions...

Squize.

[tonypa]

Originally posted by tomsamson
artbased scrollers scroll faster than tilebased scrollers (if coded right),that´s true

Well, thats a strong statement.
I would imagine you can write realy crappy TB scroller and really good AB scroller and then it must be true, but you go too far by saying AB scrolls faster.

First, what kind of art are you talking about. Really, if you try to move 7500x7500 pixels bitmap around (thats about 40MB file)...

Then again, if you create couple rectangles in Flash and make them your level, fine, it might be fast, but your level will be just a rectangle and thats all. So if couple rectangles are all there is in your game, you should do it AB, but when you start to add stuff (trees, walls, tables, books on tables...) your AB scroller will be slowing down very fast.


to Squize:
Flash doesnt work too hard on things not visible on stage. You can have lots of stuff outside stage and it wont affect speed much. Dont try it on preview, its slow as hell, export your movie first.

[tomsamson]

Originally posted by tonypa
Well, thats a strong statement.
I would imagine you can write realy crappy TB scroller and really good AB scroller and then it must be true, but you go too far by saying AB scrolls faster.

First, what kind of art are you talking about. Really, if you try to move 7500x7500 pixels bitmap around (thats about 40MB file)...

Then again, if you create couple rectangles in Flash and make them your level, fine, it might be fast, but your level will be just a rectangle and thats all. So if couple rectangles are all there is in your game, you should do it AB, but when you start to add stuff (trees, walls, tables, books on tables...) your AB scroller will be slowing down very fast.


to Squize:
Flash doesnt work too hard on things not visible on stage. You can have lots of stuff outside stage and it wont affect speed much. Dont try it on preview, its slow as hell, export your movie first.

tonypa,i know its a strong statement,but with yours to squize you gave the best reason for it:
flash renders things which are off the stage in a way,but that actually takes much less processor power than to handle things which are insde the stage bounds.its most obvious if you move a SINGLE gigantic picture,it scrolls quite fine on average pcs (if you code it right).
the thing i stated above does not apply,if you have lots of moving mcs outside the stage,they almost take equally much processor power as mcs inside the stage bounds.So a tilebased engine which doesn´t remove tiles outside the Stage bounds scrolls extremely slower than an engine which just scrolls one gigantic bitmap.
at the end if you compare a really good coded artbased scroller (though there isn´t much to code in that one) with a really good coded tileabsed scroller (which of course removes all tiles outside the game area,uses gotoandstop method for tiles and all other trickery you can imagine),the result will be that the artbased
one will win in speed on nowadays average pcs.
that only means the scroller,as i said,in a totally artbased game
you´ll have to use hittest or some trig to do collision detection,each of them being slow and/or unprecise (especially important: the more objects you have to check,the slower it will get).
in tilebased games you can have gridbased collision detection,which is way faster and stays equally fast with unlimited amounts of objects to check against.you can also get it more precise by making the tiledimesions small or use some even more precise collision detection methods if a tileabsed collision is detetcted between two objects.
another thing tonypa already pointed out is filesize and graphic quality: in tilebased things you can create huge variety in look with just a handful tiles (if the tiles are created in a way they can be attached together in several ways),whereas in artbased games filesize rises with each object and can raise the filesize to an amount even dsl users reject to download.
so at the end,i´d say artbased is a good solution if:
a) you´re not into coding
b) you can´t code well (or just can´t code tilebased games)
c)your game needs fast scrolling and has a not too big map/game area (->filesize)
tilebased is better suited for:
a) coders thinking of themselves as intermediates or pros,so they can write a solid engine
b)games which should have big game worlds
c)games which need an average fps count not bigger than 33 on an average pc.
(c will change within the next 1/2 to 1 year)

[tomsamson]

sorry squize,i read your post after tonypa´s but i guess i posted most of my thoughts in reply to his one already,so i´ll make it shorter this time.as i said,flash has the strange bahaviour that (if an object is made up by a single graphic),it needs way less performance to scroll it if most parts of that object are outside the game area/swf bounds.
you can test this if you import a really big bitmap,put it into an mc,put that one on the stage ,add some scroll code to it,make the swf movie dimensions small and test the swf in the standalone player (not in flash).
now enlarge the standalone players window to fullscreen,right click and choose show at 100%.
you should see that the scrolling is much slower than in the previous test though the graphic has the same size,so obviously flash handles bitmap data outside the screen almost like it isn´t there.
this example is true (as said in my last post) if its about one single graphic to move,as soon as you move several mcs at once,that changes.