Tiles Conclusion

Ok, with all the various people playing with tiles in AS3 using bitmap data and the rest, what is the consensus? What's the highest performance way to render and animate the tiles on the screen? In other words, if you were to start building a tile-based game right now, what technique would you use? Thanks!

I am far from being good at AS3 as i would like, im still learning lots of things...
But if you care, my conclusions are
The 'tiles' i have used in the missile game are just data for hitTest porpouses, they have nothing to do with any visual, however when i replace them for visual tiles,(wich are just to see if the correct tiles are being fired) the speed decreases like hell
To scroll things, i dont know if using sprite as tiles are faster then scrollRect an bitmap, but to tell the truth, if the goal is just scroll its seems that thats the porpouse of having scrollRect since f8
So the conclusion is: i would use tiles that are just data for hitTest things and for scrooling i would not use tiles at all

So how would you handle a full scrolling background and provide an editor for it along with the ability to reuse graphical assets? Tiles are essential in this case. People used to use gotoAndPlay engines and a few others. I was curious what the consensus is now with all the new bitmap abilities.

the consensus is that you don´t need a gotoandstop engine in the old sense anymore since you´re not handling lots of mcs anyway. What you do is you plot stuff onto a bmp. you plot it using copyPixels from a tilesheet bmp.

Quote:

---

Originally Posted by webgeek

So how would you handle a full scrolling background

---

scrollRect

Quote:

---

Originally Posted by webgeek

and provide an editor for it along with the ability to reuse graphical assets?

---

I could make an editor and in the end make a bitmapData draw the result
so i would not need 300 sprites
As for reusing graphical assets, its just attach the same sprites in the place i want and when its all done, do the same thing, make the bitmapData draw it all
It would end up taking lots of memory, but so what, todays computers can handle it
But this is just the way i found that works better for me
Now, using tiles that are just data you can have a tile for each pixel on the screem,wich brings many new possibilities, you can do a shape shape hitTest,you can do lots of things with it...

I've played around a bit and came to the (personal) conclusion not to use "tiles" anymore.

My basic (and not quite finished) setup at the moment, is to use a brutal mix of "supertiles". That is, using tiles in whatever size they come and plot them onto a bitmap which is then scrolled (ok currently I'm using 3 bitmaps a bit wider and higher as the screen (2 beeing visible and one to pre-plot).

These bitmaps have a "general" background (like grass) and then I just plot the different part onto it. The data overhead is a bit more complex than for normal tiles, but for most cases it's way less to plot).

I'd like to post an example, but it's for a client project ...

nGFX

haha, yeah, since webgeek asked about tiles i only talked about tiles, too, personally i´m also way more into supertiles or similar setups these days than all equal sized single graphic tiles.
I think its about personal preference but especially once one is into having more organic level structures,custom dimensioned art or doesn´t go for pixel art but maybe 3d art (which makes less sense to be squeezed into grid shape often),the normal rectangle tile shape seems pretty archaic and not up for the needs in many cases.
I wouldn´t say tilebased is dead anytime soon,there´ll always be the game/level layout setup/artstyle where it makes sense but yup, where i can i´d go for an engine which supports custom shaped art better, too.

Sorry, while I said tiles, I wasn't meaning to exclude supertile systems either.

nGFX: So you copy the pixel data onto the bitmap and then scroll the bitmap? Then you just maintain enough off screen "headroom" to keep ahead of the scrolling?

Quote:

---

Originally Posted by webgeek

nGFX: So you copy the pixel data onto the bitmap and then scroll the bitmap? Then you just maintain enough off screen "headroom" to keep ahead of the scrolling?

---

i dont know what you mean by 'headroom', but for big bitmaps scrollRect crops the bitmap for you

I have mixed feelings about the super tiles they are rather a decoration system for me. Real equal tilesets require good tilesets while with supertiles you propably have more freedom and it doesn´t require persé a good tileart or setup.

When it comes however to tilesheets I think that equal tile-sets are still inbeatable because a super tilesystem with random tile dimensions would require an additional slice sheet that contains the coordinates of the slices.

I am currently working on a tile-editor that can handle several map formats and soon different types of layers (equal tiles, super tiles, vector path, collision boxes, collision map, points,...). but perhaps you noticed that thread already

If you really want to push performance, I would recommend using copyPixels() to a single bitmapdata. copyPixels() is very fast, much faster than manipulating Flash objects such as Sprites. Since it's so fast, there's no problem to render all visible objects from scratch each frame, so no scrollRect is needed. A good way to "clear" the screen each frame is to paste a background image first to overwrite all old pixels, then draw everything else on top with copyPixels(). Also, you will not get a performance punishment for animated objects, because the only difference between rendering a static object and an animated is which image you use as source for the copypixel operation each frame.

copyPixels() has its disadvantages though, because you cannot apply transformations etc. For that you would have to fall back to the old draw() method, which pastes the image to the bitmapdata using Flash's own rendering routine, which is a lot slower.

Another problem with copyPixels() is that you cannot place an object with sub-pixel precision (using antialiasing), which is helpful for objects moving very slowly to appear smooth. For that you would have to again use the good old .draw().

If you use the old approach, try to avoid movie clips if the object is not an animation. Sprites are a lot faster to move around than movie clips. It's easy to just solve everything with movie clips because that was the only way to do it in previous versions. Now that you can create more light-weight objects you can increase the performance quite a bit.

Why do you say that copy pixels is new and draw is old?They are both f8, isnt it?

I gess he was talking about what people first discovered as technique. Even with the 3d- engines lately going on pixel level with bitmapData seems to be really interesting lately.

@strille thx for the info,- and nice Raycaster ^^

Quote:

---

Originally Posted by Cimmerian

Why do you say that copy pixels is new and draw is old?They are both f8, isnt it?

---

Yeah, you're right, they're both F8 features. What I meant was by using the draw() function you are relying on Flash's vector rendering engine, which is what all old games used before F8 (because there was no other way). But with copyPixels you only rely on code to move pixels and then use Flash's vector rendering engine to only show the final bitmapdata (using a bitmap display object). This is especially good for games with a lot of moving objects. You can have hundreds of objects moving around, which would be pretty slow if you used a display list objects for each object.

Here's an example written in AS 3.0 that pretty much uses only copyPixels() to a single BitmapData. I do use draw() for the explosions because I want them to be drawn with antialiasing (since they are generated), and also to be able to draw them with additive screen mode.

http://www.strille.net/works/as3/shooter/


renderhjs, I'm glad you enjoyed the raytracer. It was just a test to compare AS 2.0 and AS 3.0, and I'm very happy with the AS 3.0 performance.

Bitmapdata is not really new for AS3/Flash9. Everything discussed here works exactly same way for AS1/Flash8.

I would like to see some test for example using Sprite class instead of Movie Clip, or changing fps dynamically when things start to slow down or something else that is not available in Flash8.

Strille, why would you just paste an image over the bitmap? Wouldn't it make sense to use clear(), or is that strictly used in conjunction with draw()?

Quote:

---

Originally Posted by webgeek

nGFX: So you copy the pixel data onto the bitmap and then scroll the bitmap? Then you just maintain enough off screen "headroom" to keep ahead of the scrolling?

---

Not exactly. The way I do it atm (and which is only for scrolling into two directions (like north/south) is to use 3 bitmaps "like" a goto and stop engine.
2 Bitmaps are max visible at the same time, while the third is used to plot the next big "tile", once a display bitmap is moved out of the visible area, the 3rd "cache" bitmap becomes visible ...

This why all tiles can be plotted in some sort of background thread.

Quote:

---

Originally Posted by renderhjs

When it comes however to tilesheets I think that equal tile-sets are still inbeatable because a super tilesystem with random tile dimensions would require an additional slice sheet that contains the coordinates of the slices.

---

Yep, there is a slightly bigger overhead for keeping track of the tiles.
The big advantage is that, you can place the "tiles" on pixel level and create way more organic levels. Though, I do use a "gridded" tilesheet (based on a 20x20 grid), so the overhead for the tilesheet is just 5 bytes per tile/sheet (id, x/y, h/w).

But the extra data I have to add for the tilesheet is saved for the level data, which only holds the tiles needed (id, x/y/z). So even complex and long levels can be stored in a couple of coords.

nGFX

IP, there is no clear() method with bitmapData, you're probably thinking of fillRect with transparent pixels. No need to do that when the background is full of tiles.

1 - draw background
2 - draw moveable sprites
3 - move to step 1.

however, this requires that all tiles are re-drawn because you don't want to see bits of other sprites all over the place. The method i will probably go for is:

1 - 4 areas the size of the stage, scrolled around and re-ploted once moved off stage using copyPixels from a tileset which draws ground tiles.

2 - 1 bitmap which doesn't move but is scrolled and clears itself by copying a transparent bitmap the size of the stage. This bitmap draws the moveable objects, z sorting is based on what is drawn at what time.

I'm thinking of making a set of classes which deals with this, maybe call it a "BitClip" which uses a tileset in conjunction with a render screen and copyPixels to draw itself.

I tried to use tiles for my side scroller. Not necessarily the fastest thing around. It uses copy pixels. For some weird reason it runs a lot faster if you hold down right and then just off the swf to the right you move your mouse around the fps goes up. Pretty weird.

I think it would run faster if there was some form of cache on the tiles. The version I am using now runs plenty faster. This version is the test one I worked on when this bitmapData came out.

heres the tiles
http://www.freshvision.com.au/uploads/tilesset.gif

Random Tiled Version
Example 1

Seamless TiledVersion
Example 2

Quote:

---

Originally Posted by tonypa

I would like to see some test for example using Sprite class instead of Movie Clip, or changing fps dynamically when things start to slow down or something else that is not available in Flash8.

---

Ass you wish
f8 trying to copyPixels 1000 times each frame:
http://img117.imageshack.us/my.php?i...ypixelscf3.swf
And f9:
http://img161.imageshack.us/my.php?i...ypixelsqo2.swf