Digging games
-
@xevdev are you not clearing the screen or just creating sprites?
-
@PB____ You can actually draw in transparent or partially translucent colors, but you have to change the blend mode to
0
usingsetBlend(0)
. With the default blend mode the colors will blend because of the transparency. So, you can have a background layer that is gradually revealed by writing transparent color to the foreground layer using render targets and blend modes. -
@Retrocade_media no I'm not the background is a solid green and stays that way no need to alter it.
The tunnel screen is transparent and I draw image one movement at a time and don't clear so you can see the trail .
The actual game you'd draw your sprites straight over the top .
When your making a game you have your map in memory and what you display is on the screen is a representation of that.
In the case of this game it's set up on a grid that you cant get off so you can only turn every 16 pixels
Left right back forward
But you can go half way through a square the enemy needs to know that so the data for each square will need to allow it to only go so far .
So your data square will need to have more than a binary state
Open or closed
It will need to have both those and four directions with a number saying how far it's going in .
Or
You could Chuck the whole tunnel screen in an array for every pixel that's displayed there is a corresponding non zero number . write a getpixel that accesses that array
Only let the enemy move on the non zero area
I know which one I'd chose . -
So, I've been stuck on this for ages now! I think I need a mixture of both approaches. Currently I've got three layers 0, 1 & 2. Zero drawn first with no alpha. Right now it's just
clear(green)
, then a layer where I draw the 'tunnels' in black with an alpha so that once I get to that point I can do whatever edges I want and then finally the sprite layer where, guess what? the sprites are drawn.So far so good.
But I'm totally stuck on this whole business of being able to remove part of a tile and that's where the more i think about it, the more I need to consider this business of bitmasked values in the tile grid. And I also hadn't considered the prospect of the monsters needing to know if any of the tile directions are open.
-
Crikey mate, that sounds so complex. but I'm sure you'll crack it in time.
-
If you're referring to the bitmask thing then it's not as complex as it first sounds.
So, let's say that we have a playfield that consists of 10 tiles high, 10 tiles wide (in reality you'd have more than this) The simplest implementation of that is that the array stores the tile number:
tileData = [ 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 0, 1, 1, 0, 1, 1, 1, 0, 1, 1, 0, 1, 1, 0, 1, 0, 1, 0, 1, 1, 0, 0, 0, 0, 1, 1, 1, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 ]
So that's a simple playfield where maybe image 1 is a wall and image 0 is the floor. But if we need to also store which of the directions is open to sprites then we need to look into binary. We know that an 8bit binary number can be up to
11111111
which in theory means that we can choose one of 256 tiles (if we include 0). But honestly, that's a LOT of tiles for an old-school game. So how about we instead limit ourselves to 16 tiles? Then we can split our number up. Now we can have 'dddd nnnn' where dddd are the directions that are "open" (U/D/L/R) and nnnn are one of 16 tiles. So1100 0001
says that this grid position contains tile number 1 and can be entered from the 'UP' and 'DOWN' directions.Since we can use sprites for characters, and sprite images and animations can be entirely seperate to the tiles (using the image editor, or
uploadImage()
as you wish) 16 background tiles may be enough. But what if it isn't? Well an INT isn't limited to 8 bits, just extend it to 16 bits (0 to 65535) - PLENTY of room for images and to use the additional bits for all sorts of things.SO, in summary, yeah, maybe a complex sounding subject and now I've typed it out, maybe it is, but it's very powerful and would have been perfectly normal in the days where memory was limited.
-
If all you have is a hammer everything looks like a nail.
Don't use the map function for the screen display
If you want use it for sprite placement of apples cherries enemies but not tunnels
The playable screen area is 192 by 208 pixels
BitMap [192][208]
Each time you draw a section of tunnel set the value in bitmap as well then just query it. -
@xevdev said in Digging games:
Don't use the map function for the screen display
Do you mean the map editor? Because I've never used that.
I'm struggling to grasp this a bit? If my tiles are 16x16 do you mean that whenever the player moves 1 pixel to the right I update 16 values in BitMap data? Isn't that going to be really slow? Or am I getting the wrong end of the stick?
-
Tell you soon just trying it out.
-
Na didn't slowdown I'll try and get a ball bouncing around the tunnel by checking bitmap
-
-
Mr Do / Dig Dug / Boulderdash / The Pit in FUZE - wow just wow!