I only meant it was hard to compare your engine's speed, because I'm used to seeing fps. Not saying that knowing the milliseconds can't be useful for a programmer.
Printable View
I only meant it was hard to compare your engine's speed, because I'm used to seeing fps. Not saying that knowing the milliseconds can't be useful for a programmer.
yea, there's some kind of bug, other people on the forums have noticed it too. I think the player is detecting the mouse over the bitmaps and creating variables by itself for whatever reason. Hope they can patch this. Take any bitmap swf with an fps counter and put your mouse on and off on it. the fps will drop.Quote:
Originally Posted by Fall_X
Well aside from that, can you just loop through and copy pixel each tile individually without it lagging? I guess I just thought it would kinda slow down so much that you actually see the screen refresh one tile at a time but i guess copy pixel is just really fast.
While it could potentially slow down the swf, it would never do that - because the updated bitmap is only shown on each frame, and the scripts updating it are run between frames. So that's not an issue.Quote:
I just thought it would kinda slow down so much that you actually see the screen refresh one tile at a time
But its' pretty fast anyway, and I'll add some cashing where I draw larger parts out of a stack, and I'll see if that's even faster.
Sorry guys, coming to this thread a bit late, and just sniffing after a quick recap.
So in effect, these scrollers are just going through your normal map data, and using copypixel to copy each tile ( 32x32 or supertiles ? ), so every frame you just copy a screen full of tiles.
For the movement you're still just updating the containers position, rather than offsetting the tiles during your copyPixel write ( So I guess you need a buffer of 1 tile in every direction around the viewport ( Viewable window ) so you can plot ahead ).
And Chookmaster you're just blitting those sprites in every frame, so you're not even using sprites ( Well, software sprites as opposed to Flash hardware sprites for want of a better term ).
Squize.
I can only speak for myself, but in my case I just copy each tile atm, but I'm thinking about creating an automatic supertiles system.Quote:
So in effect, these scrollers are just going through your normal map data, and using copypixel to copy each tile ( 32x32 or supertiles ? ), so every frame you just copy a screen full of tiles.
I just loop through my 2d map arrays like this (for each layer) :Quote:
For the movement you're still just updating the containers position, rather than offsetting the tiles during your copyPixel write ( So I guess you need a buffer of 1 tile in every direction around the viewport ( Viewable window ) so you can plot ahead ).
Note : this is an altered snippet, with some checks, features and optimization stuff left out for readability...Code:var scrollX:Number=this.engine.scrollX*this.xSpeed;
var scrollY:Number=this.engine.scrollY*this.ySpeed;
var startX:int=scrollX/this.tileWidth;
var startY:int=scrollY/this.tileHeight;
var endX:int=startX+Math.ceil(this.engine.screenWidth/this.tileWidth)+1;
var endY:int=startY+Math.ceil(this.engine.screenHeight/this.tileHeight)+1;
for (var j:int=startY;j<endY;j++) {
for (var i:int=startX;i<endX;i++) {
// copypixel the right tile, I have a lookuptable that gives me the rectangle from my tilesheet based on the value of map[i][j] so I don't have to figure that out each frame...
}
}
hmmm
something keeps buggin me about the constant updating of tiles. Sure it works nice for a demo, but what happens when actual game play comes into it?
there has to be a nicer way than looping through tiles every frame on tiles that don't even need updating.
Cheers Fally :)
I asked, 'cause I think the same as big M, seems kinda wasteful and I really didn't think that bitmap functions would get that much of a boost just 'cause the vm is quicker than before.
But in saying that, both examples seem to zip along really well, there's no faulting either of them.
I guess using this approach, in effect replotting the whole screen every frame, that the bitmap size limit isn't an issue anymore, it'll be more like a gAS engine where you just plot what you need, rather than having to stitch together lots of 2880x2880 bitmaps.
So I guess the next natural step is to cache the tiles together into supertiles where possible to reduce the loop size and look-up time.
( Got to be honest, still freaked out that this can even work. as3 is the daddy ).
Squize.
Agreed, I didn't think it was going to go this well without further optimizations, but I'm glad it does.
What I plan to do now is divide the screen in blocks (say 4x4 tiles, but this can be different per layer), and it will copypixel these blocks from a cache. If a block isn't in the cache, it is generated from the map data. If a block moves off screen, it will be deleted from the cache after a while (so I don't flood the memory).
But I'm open to other ideas, off course.
yeah, those demos do look nice and smooth. Maybe AS3 is that good and you dont have to worry much anymore.
FallX, what exactly do you mean by cache the areas? something like creating a bitmap which contains the data and then simply copying that full bitmap instead of running through a 2D loop?
Yeah Fall, that's exactly how I saw it going ( By supertile I didn't mean like a megatile of screen proportions, more a 4x4 block ).
iopred's Vide engine did something kinda similar in as2, and that bad boy flew along.
Squize.
Let me see if I can simplify this whole processes into a tiny bit of pseudo-code. Assume that the function below is the enter frame event where the drawing is done.
Is this more or less the general idea of the process?Code:enterframe{
Draw a blank rectangle to "reset" each frame
update the map tiles based on where the player is
copyPixels on the lowest layer here, maybe the map tiles?
update any game world objects
copyPixels on the next highest layer here, Maybe game world objects
update the npcs/player code
copy pixels on the highest layer here, maybe npcs and the player graphics
}
Sorry for the noobyness again, but I think I'm starting to get it...Quote:
Originally Posted by Squize
The reason you would use a supertile is to reduce the amount of loops you run to check which tiles are visible? If the supertile is visible, then draw the tiles in that supertile.
malee, you could possibly reduce the for loops a great deal by grabbing only those which are on screen (including the 1 tile buffer), and only looping through those. You would just take your top left corner x & y offset, divide each by your tile width/height respectively and there's your for loop start values (subtract 1 from each for buffer). Then you just take the bottom right offset point and do the exact same thing and you have your end values (add 1 for buffer). Plausible yes, but I've never actually done it.
ImprisonedPride : just look at the code I posted here earlier, that's exaclty how I've done it. Except I didn't need a 1 tile buffer to the left and top, only to the right and bottom. But that's still about 215 tiles per layer (if it's entirely filled).
Here's another question for you guys. Right now my engine requires the tiles to be in a grid, so their positions are 0, 32, 64, 96, etc (depending on the size of the tiles, which is dynamic). Would it be worth it to rewrite this system so it would allow tiles in any position, and of different sizes?
Would be cool, a supertile / tile based hybrid, but I think you'd then be left with the problem of designing a level for it. You'd then have to make a map editor to cope with it.
Like to see some smart caching first ;)
Squize.
Adding compatibility and flexibility is always worth it. :)
My previous engine (which was quite a bit slower) had a nice hybrid design I think, with different types of layers and different types of tiles. And lots of smart caching. As far as free supertile engines go, I think it was one of the most flexible designs around. But this is a lot faster, and I don't know if it's worth my time to put all those features in it, especially since probably not even one finished game used my tile engine - or at least, not to my knowledge. So yeah, I'd probably better focus on speed first.
The thing is, if I want it to be flexible, I have to keep all that in mind from the start, so I don't get stuck. I would already have to rewrite most of what I have now to make a flexible architecture.
Sorry, just thinking out loud... guess I have some more thinking to do. Feedback still welcome off course.
Which method would be the easiest for creating animated tiles such as water and torches? my scrollable maps will not be that big and when you reach the end your character will just move normally.
Also Fall_x i am also interested in squize's question but think you missed it. Does your engine have a buffer area of 1 tile on every side that is covered up by the "viewport"?
Actually I'm not sure how this works. Is this just changing the x/y of the bitmap or is this not possible because you can't add past the width of a bitmap object. In that case what way do you use to just add one column/row at a time?
I think I answered his question with the code I pasted. There's just one bitmap the size of the screen, and i draw the correct tiles at the correct coordinated. That's all. Not using scroll or anything.
For animated tiles, I'm not sure yet. Probably just using different parts of the tileset each time.
IP - yeah i understand that part. But you're still running a 2D loop to determine the visibility of a tile on every frame. It can be reduced to check only when the space of a tile is moved, and therefore you need your buffer, but still, i feel much more comfortable with updating an area of tiles when the area has moved on/off the screen. You can eliminate the need of a 2D loop by copying a chunk of bitmapData into the area. This now presents a problem when another bitmap tile/object moves over other tiles on the same layer. What i would do is instruct the tile to copy a rectangle the size of its previous movement and replace any pixels it messed up during its adventure across the bitmapData layer. I think its very possible to create a non 2D loop tileEngine, and for mine i will be doing just that.