![]() But the above game (PC dos game) would benefit from that.Īnd honestly, I'd probably mix a little sprites as BG objects (edges) like Ys III does just to break up the hard edges. I won't go into details about that, because it would be easier to show what I mean in some demo code. Again, depending on how you're using this advance dynamic tile setup - that could be divide over three frames ~10.5% per frame. The fast way I could find to go about it, cost 30% cpu resource (updates a whole screen), but a more flexible method I did that read and wrote vram was 32% cpu resource. This is a read, test, conditional modify, write method. And use the VDC VDMA transfer (set the res to high res mode before doing this) to move the final buffer of dynamic tiles over the map section, of if you like - keep two copies of the BAT active area in vram, updating it as needed for both, then switch to the alt one once the dynamic tile sequence is finished. In that case, assuming the far BG layer scrolls a half speed or multiples of half speed - you can divide that 34% requirement over two frames. Of course, this being the far background layer - it typically scrolls slower than the foreground layer for most games (not all, though). 256 tiles 4bit color depth takes 41k cpu cycles to update in a single screen, or 34% cpu resource. The tiles need to be embedded opcodes for speed. Now for the resource part: This has to be all done in ASM. Each object can also have its own subpalette associated with it, so you're not limited to 16 colors for the whole fake BG layer. The cloud "objects" wouldn't have to be a fixed pattern or placement either, as long as they are separated by a single common block (8x8) in their "map" section. ![]() You could even have different horizontal strips of clouds moving at different speeds (parallax), and the foreground would scroll as it's own layer (parallax clouds on far layer, foreground interactive layer). Instead of the brick being the common connecting block, you could have a solid color sky block (say. Instead, imaging an open area where there is sky and clouds. This type of effect isn't limited to dungeons or caves. And in that case, the skulls would have to be sprites, an upper tile lava bubbles would also have to be sprites. Only because the solution is a little more complicated, not that it can't be done. In this example, the second layer scrolls independently left or right, but not up and down - that's fixed. The "window" object represents the dynamic objects that I'm trying to show as example here. The skulls and the lava actually can't be placed on the same line (map line) going across the screen for obvious reasons, but the window frames can be placed next to each other, at different vertical positions - etc. The reason why they can be placed next to each other, is that there's also one common dynamic tile on the right or left sides to ALL the objects. Why do this? Because you can make a whole second BG layer, as a real map layer, that can have these above "objects" anywhere in the map. Of course, only 121 tiles are used in this example. In this demo, I setup a block of 256 tiles to be the dynamic tileset. Instead, when the transition is the to last frame, or to the first frame, you update the tilemap itself by shifting these over entry in the map (left or right). Typical for dynamic tiles, but here's the catch - they don't wrap. ![]() The red arrows are to indicate that the image shifts 8 pixels to its destination form. The dynamic tiles for this set would be something like this: Extended dynamic tiles: Take the idea of dynamic tiles to a more advance approach.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |