Tiles Conclusion

Hi,
Yes, my "brute force" approach was the same as Fall X's. Just draw every (partially visible) tile into a single, stationary bitmap. As to whether it is better to group into 4x4s, there is no "object overhead" per frame at all, like there might be in a "flash.sprite" style engine. Consider this:

Same number of final pixels copies per frame is the same - but more edge bitmaps using 4x4s.
Super tiles: quarter (16th?) looping overhead, but super tiles must be generated and cache must be consulted. My guess is that both options will be fast, but depending on the "average number of screens moved per frame", the super - tile generation will be a bit slower than the looping overhead.

If you have more complex tile options (eg, rotation or "stacked") then it would make sense to do some kind of caching.

The "sprites" are actally just the same as the tiles - copyPixels from one bmp to another. I don't use the flash object, although I do have an object of my own, that contains references to bitmaps etc. and game-world coordinates.

Once you decide that you are going to draw every pixel every time, animated objects take no longer that static ones. Simply adjust your source tile texture coordinates.

Flyingcow, I think the bit you are missing is that you can draw a bitmap off the screen and flash will clip it for you. So it you draw a 32x32 tile at (-16,-16) on the "viewable bitmap", you will see the bottom right corner of the tile in the top-left corner of the bitmap, and therefore the screen. To scroll, you just change the (-16,-16) to (-15,-16) or whatever when you draw the next frame and the graphics will appear to scroll.

Yeah, I've been thinking the same - caching might make it slower. Less loops, but sometimes more copypixeling (unless you cache everything once, but that could become memory intensive). Plus, animation is out of the picture when you do it that way, unless you cache every possibility, or have them in seperate layers.

mr_malee, most of the times, either every tile moves, or none at all, right? And since, supposedly, copy pixel is faster than moving displayobjects around, I'm not sure how you could pull it off. But off course, I'd love it if you succeeded, and even more so if you would share your methods :) Would it involve the scroll method? Haven't really played with that yet, it might be faster, I don't know, but it would mean different bitmaps per layer if you want parallax scrolling.

Quote:

---

Originally Posted by Chookmaster

Hi,
Once you decide that you are going to draw every pixel every time, animated objects take no longer that static ones. Simply adjust your source tile texture coordinates.

Flyingcow, I think the bit you are missing is that you can draw a bitmap off the screen and flash will clip it for you. So it you draw a 32x32 tile at (-16,-16) on the "viewable bitmap", you will see the bottom right corner of the tile in the top-left corner of the bitmap, and therefore the screen. To scroll, you just change the (-16,-16) to (-15,-16) or whatever when you draw the next frame and the graphics will appear to scroll.

---

Yea, thanks for explaining I guess only the old scrollers needed that extra buffer zone thing but bitmaps are one object by them selves.

The way you describe for animation, does this require redrawing the whole screen every frame even if its not moving, even if just one animation is in it? I guess this isn't a problem if there's no slow down and it has probably even more benefits if you have a lot of animated tiles on the screen.

To Chookmaster:

Would it be easier to just copypixel over the source tilesheet for animations? that way you would only have to change one thing, rather than update the sprite sheet coordinates for each animated tile.

Quote:

---

Originally Posted by Flyingcow

To Chookmaster:

Would it be easier to just copypixel over the source tilesheet for animations? that way you would only have to change one thing, rather than update the sprite sheet coordinates for each animated tile.

---

I don't think it really matters what "changes" - but something certainly has to. As it turns out, I have an "Animation Object" that has an array of bitmaps.
Each Ogre and a reference to the single "Ogre Animation Object", and in addition has a floating-point frame number. To animate the Ogre, I do something like "frame += 0.1", then to draw it I convert this to an integer and do a "modulo" with the array size. This gives me an index into the bitmap data.
Alternatively, I could have a single bitmap and use the index to refer to an index in an array of "source rectangles". This might be preferrable if, say, you started with a single "png" image as your sprite sheet. Or maybe I know that each sprite is X pixels wide, so I can simply calculate the rectangle. It depends on your input data.

Good programming suggests that you leave this up to the "Animation Object" to decide, and in fact just have some method that takes the floating-point frame number and it works out what it needs to do from there. Good programming also means just get something working and worry about optimisation from there - which is where I'm at at the moment.