Tiles Conclusion

I'm just trying to find out the way they did it in the actual original tile games and then duplicating something very similar. Because obviously, their methods worked for making great games.

I think characters could be created as an object using copy pixels and a base sprite class. keeping track of bitmap objects that behave as sprites would be a real pain if they were directly drawn into a "full screen bitmap layer". For layering i think the player needs a separate layer.

Perhaps you divide the layers like this where the topmost is the one visible first

1. Overhead layer that can cover all the other layers, like if you were standing beneath a tree.

2. Sprite layer (that contains sprites, not a bitmap, animations would be created by copying pixels from a spritesheet. I guess a sprite based class that accepts basic perimeters including the spritesheet, the animation sequence, and various other properties) containing things such as movable objects and the character

3. background bitmap, for scrolling, the sprite layer would have to go through some checks to see which sprites should be visible based on the current map position. I haven't tested if it creates lag and redraw regions from sprites moving above a bitmap in a seperate layer, in that case, I hope flash is fast enough.

I haven't tried adding an overhead layer into my engine though.

Does anyone know the way the old tile games were coded like Link to the past? I just don't understand after more than 10 years flash doesn't seem to be able to have the same capabilities of very old games. Of course correct me if I'm wrong because thats what exactly what I'm looking for, coding with the same structure as these old legends. With actionscript 3 and external classes, I think thats as close as it gets to a compiler language like C++ which is entirely capable of making a zelda remake.

The only problem is that I can't find anything remotely helpful about how these games were made.

The thing is, the nes and snes have special modes for tiles. I haven't actually programmed for these consoles, but looked at gba programming a while back, and it works by putting the tile numbers in special registers if I'm not mistaking, and the hardware does a lot for you. (that's how I remember it at least).

But you could totally do a zelda remake in Flash, even in old versions with a gotoandstop engine, or supertiles. But we're looking for even faster ways.

The method you described (tree different layers) is a bit limited, as there would be no parallax scrolling of more layers. Well, it would be possible, but tricky.

So I'm guessing the fastest way would be to just have one layer, which you draw from the bottom to the top, and have game-sprites handled with copyPixels as well. Or am I mistaking? Perhaps there could even be some optimization so it doesn't have to copy parts that are obscured by other layers, but I haven't given that any serious thought yet.

There are some tricks you could do with masks and colors (threshold, merge, copyChannel, compare etc). I think basic idea should be to update as little as possible, for example to avoid redrawing whole screen every time little sprite changes.

Yeah, some of the original sidescroller didn't scroll all the time for example. When you got to the end of the screen, it scrolled, so you stood at the beginning of the screen. That way you only have to redraw movable regions like the hero, the enemies, shots and whatever!

When you scroll the whole bg however you can't just redraw regions. Then you have to redraw it all one way or another!

I just did a little test, with a 550X440 screen filled with 16x16 tiles (only one layer), and it runs smoothly ata solid 124fps in the ide flash player on my. Not too bad. Unless I move the mouse, then it drops to about 95fps, but that's still acceptable. TileSQUID 2 is coming up, fully compatible with the framework I recently posted. Jay.

Just a quick question, if the Bitmap object you're manipulating is two or three levels deep (for instance, when it's within a container that also houses the gui stuff, and that's on the stage), do you think this could affect the framerate? Thanks!

Wow, three layers of parallax scrolling with 16x16 tiles and it's still running at over 100fps. If I set the tilesize to 24, it's at 120 again. Sweet. Now all I need to do is add a nice animation controller (for animated tiles and animated sprites), and I've got myself a kick @$$ reusable engine, with a lot less time spent then I did with my previous supertile hybrid engine.

Quote:

---

Originally Posted by Fall_X

Just a quick question, if the Bitmap object you're manipulating is two or three levels deep (for instance, when it's within a container that also houses the gui stuff, and that's on the stage), do you think this could affect the framerate? Thanks!

---

No, I dont think it matters.

Quote:

---

Originally Posted by Fall_X

Wow, three layers of parallax scrolling with 16x16 tiles and it's still running at over 100fps. If I set the tilesize to 24, it's at 120 again. Sweet. Now all I need to do is add a nice animation controller (for animated tiles and animated sprites), and I've got myself a kick @$$ reusable engine, with a lot less time spent then I did with my previous supertile hybrid engine.

---

Are you using copypixels for everything now? Does using a full copypixel engine mean that you will also have to do collision detection/mouse click detection all at the pixel level?

I think I'm going to start running some tests too. Thanks for the info!

I've always done collision detection by comparing rectangles and other shapes anyway, so that would work out. But I'm not entirely sure about how it's all going to fit in yet, maybe I'll still have different layers or something, I'll have to see how performant it is.

If you did layers, how would that change collision detection/mouse click detection?

Quote:

---

Originally Posted by Fall_X

I just did a little test, with a 550X440 screen filled with 16x16 tiles (only one layer), and it runs smoothly ata solid 124fps in the ide flash player on my. Not too bad. Unless I move the mouse, then it drops to about 95fps, but that's still acceptable. TileSQUID 2 is coming up, fully compatible with the framework I recently posted. Jay.

Just a quick question, if the Bitmap object you're manipulating is two or three levels deep (for instance, when it's within a container that also houses the gui stuff, and that's on the stage), do you think this could affect the framerate? Thanks!

---

What way are you using to scroll? also something is wrong with your source scroller. Running it creates many errors, mostly duplicate errors though.

Warning: 3600: The declared property classReferences cannot be deleted. To free associated memory, set its value to null.
Warning: 3596: Duplicate variable definition.
5006: An ActionScript file can not have more than one externally visible definition: com.gamesquid.squidload.TextLoader, com.gamesquid.squidload.McLoader

I've based my scroller off of tonypa's copypixel scroller and it scrolls at max fps, with a single layer bmp.

From what i understand, it creates a bitmapdata that draws the whole level.
Then the screen just copies a whole screen's worth of pixels from the current position youre in from that "whole level bitmap data". Haven't tested it with sprites on top yet. If it works well, ill post a demo.

How do you add animations into a copy pixel scoller? or do these have to be seperate objects. By animations, let's say a torch that has a flickering flame that is attached to a wall. Would you add these as seperate objects on a different layer? or could they be tiles themselves that just cycle through the frames in the background layer. Not entirely sure how to do the latter.

Quote:

---

Originally Posted by felixters

If you did layers, how would that change collision detection/mouse click detection?

---

It would mean I could still have layers of different types, like a layer based on Sprites/MovieClips.

Quote:

---

Originally Posted by Flyingcow

What way are you using to scroll?

---

Just copypixeling different data.

Quote:

---

Originally Posted by Flyingcow

also something is wrong with your source scroller. Running it creates many errors, mostly duplicate errors though.

Warning: 3600: The declared property classReferences cannot be deleted. To free associated memory, set its value to null.
Warning: 3596: Duplicate variable definition.
5006: An ActionScript file can not have more than one externally visible definition: com.gamesquid.squidload.TextLoader, com.gamesquid.squidload.McLoader

---

I know, it's made with the AS3 beta, but it's easily fixed. Just two small changes or something. I should update the zip, but I don't know if I'll bother since I'm doing an entirely new version right now.

Hi,
I have been looking at "copyPixels" and it certainly appears to be the way to go. I have a demo at:
http://gamehaxe.com/1000Ogres.html
(It has to load half a meg, so could take a little while to load).

There is 1 bitmap object, exactly coverring the screen, then it is pure "brute force" in the bitmapData. The tiled background is "copyPixel"ed each tile each frame, and each sprite is "copyPixel"ed each frame too. Once you accept that this is fast enough, the rest of the programming is very much like the "retro" games.

I do collision detection using a grid/spatial lookup and circles places the feet of the objects, so it scales pretty well from the initial 100 objects, to 1000 obejcts (if you hit space 9 times).

The code is actually written in haXe , which is a close relative of as3, and compiles to a flash9 swf. (You can also generate as3 code and compile that too).

Nice work, but it's a bit hard to see how performant it is when all you show is the ms.

I also made a demo : http://gamesquid.com/temp_/TileSquid2/demo1.html

I'd like to know what fps you guys are getting with this. Thanks!
I'm getting a steady 120+ in firefox, about 65 in IE7, and 110 in Opera.

heh looks pretty cool with the parallax.

I have ~40 fps even running a lot of stuff in background. Seems fast.

Are you using the "big bitmap" method where you just make the whole thing first then scroll that?

well actually im not sure if i know exactly what that is. Is the big bitmap method just creating a bitmap and changing the x/y of it, then adding a new big bitmap when it reaches the edge? Or is it the way im doing it where i create the whole level at run-time and just copypixel screen-size-rectangle at the current location im in.

Fall, I'm running FF 2.0 and I only get 120 while I am moving the cursor around. Whas that what you meant? I get 80-100 leaving mouse still outside flash, 60-70 leaving mouse still inside.

I don't create everything first because I think it might get too memory intesive, but I might make a layer-option so I can decide this on a per-game or even per-layer basis.

I have a bit of a complex system now, because I want it to be capable of handling a lot of situations.

Basically, I have surfaces and layers. A surface is a Bitmap or a Sprite, and it can handle multiple layers, even scrolling at different speeds. In this demo, I have only one surface, with tree bitmap layers. But I could have a sprite-layer on top of that, and then another surface with multiple parallax layers in it or something. (note : only bitmap stuff is implemented right now).

The surfaces don't actually move, I just loop through the layers, and each layer is responsible for adding it's stuff to the surface. So basically a layer first clears it's background (when necessary, which is not the case for the lowest surface layers), and then loops through all the tiles that are on-screen, and copypixels them individually.

Off course, it can be improved a lot, with some caching and stuff. Once I'm happy with it, I'll release the source code.

Just to give you an idea, here's what the layer setup looks like (note : I say this.createLayers because it's called from a class that extends the tile engine) :

Code:

---

var surface1:Bitmap=this.addSurface("Bitmap") as Bitmap;

this.createLayers([
        {type:"BitmapTileLayer", w:1024, h:1024, map:[[0]], tiles:new Bg1(1024,1024), infinite:true, surface:surface1},
        {type:"BitmapTileLayer", w:32, h:32, map:map2, tiles:new Tiles(100,100), colorTransform:{r:0.7,g:0.7,b:0.7}, xSpeed:1.5, ySpeed:1.5, surface:surface1, infinite:true},
        {type:"BitmapTileLayer", w:32, h:32, map:map2, tiles:new Tiles(100,100), xSpeed:1.8, ySpeed:1.8, surface:surface1, infinite:true},
]);

---

Quote:

---

Originally Posted by ImprisonedPride

Fall, I'm running FF 2.0 and I only get 120 while I am moving the cursor around. Whas that what you meant? I get 80-100 leaving mouse still outside flash, 60-70 leaving mouse still inside.

---

That's pretty weird isn't it? I have the same thing going on, but not that much. But there's nothing in the code that checks the mouse or anything. Strange.

However, in most games I would set the fps to 30 or 40 so it would still be good enough I guess. But I'll (try to) optimise some more this evening.

Thanks for checking.

Quote:

---

Originally Posted by Fall_X

Nice work, but it's a bit hard to see how performant it is when all you show is the ms...

---

Most of the work done is in the collision detection, rather than the copyPixels. What I think we can agree is that the graphics(copyPixels) side of as3 is pretty darn good.

I find milliseconds better than fps when measuring performace. Say you make a change and it makes your code run 10ms slower. You know the cost of that operation. However, if you drop from 200 to 190 fps, the cost is not "10 fps" because if you make other changes, that drops the fps to say 100, then the same change may only cost 5 fps. You can add the time of drawing 1 layer to the time of drawing another, but you can't add the fps.

That said, I guess the solution is to show both :)