Elysian Shadows

So after I saw Falco talk about having his tile just be a char that indicates what the texture was, I started to think how much data can you actually pack into a small package.

At first i used a short (thats 2 Bytes), but felt I didn't give me everything I needed, so I used an int. (4 Bytes.)

Okay, so lets see what we would like out tile to have. (I'm not worried about location because you should be able to deduce that depending on your tile size and position in your array)

- texture info

:I'm gonna take a page from Falco and give it 1 byte, that give me 256 possible textures.

- collision info

:there are the two simple cases of solid or no collision, then there are 6 other possible one, each edge of the tile, and two diagonal.
so 3 bits are enough to represent this.

- elevation info - (like stairs and ramps)

if a tile is a stair or a incline, it will go up in one of 3 direction, left,right or up, (down would be hard to make a tile that looked good, or even to spot stairs, so im going to omit that on)
so 2 bits for this 00 no ele, 01 left, 10 right, 11 up.

- height info - (how high above the bottom a tile is)

for this i would give it 5 bits, thats 32 levels, but they way i would make it is that each level is 64 pixels, (cause your character is probably 32*64), but each height level is only 32, this just makes the transition on stairs not so abrupt. so we only end up with 16 real levels, which is still plenty.

- lighting data

5 bits will give you 32 levels of lighting.

- indoors or outdoors - (if you are indoors you don;t wanna draw any layers above, like the roof or floors above you..)

only 1 bit needed for this.

so out total comes out to 24 bits for that, leaving us with 8 bits or a byte that can still be used for something else. lighting color, or teleport info.

You would have to know a bit about how to work with bit wise operators but its not to hard. (for most systems this really is not necessary, but i still think a pretty good thing to learn about)

For anyone who doesn't know how to use bit fields:
This seems like an awesome way to store tile information.

pretty efficient too I would say :D

RyanPridgeon wrote:For anyone who doesn't know how to use bit fields:

Code: Select all

struct Element
{
	unsigned texture:8;
	unsigned collision:3;
	unsigned elevation:2;
	unsigned height:5;
	unsigned lighting:5;
	unsigned indoors:1;
};

This seems like an awesome way to store tile information.

Wait, wait. Why have I never seen this before? That fits perfectly for network stuff, too.

yeah those are bitfields,

i dont like them for 2 reasons,

1. you cant have pointers to them, and 2. (i think) they are not portable in the sense that you can load them from file, C can not garuntee that they are ordered in any particular way.

i just use int data; as the declaration, i know that that gives me 4 bytes.

#define SET_HEIGHT(j,k) k > 31 ? 0 :j |= k<<13
#define GET_HEIGHT(j) (j & 0x03E000)>>13

that would be to set and get the height field in the data var.

but they are WAY more convenient, and i suggest using that if you are not familiar with working with bits of blocks of memory.

K-Bal wrote:

RyanPridgeon wrote:For anyone who doesn't know how to use bit fields:

Code: Select all

struct Element
{
	unsigned texture:8;
	unsigned collision:3;
	unsigned elevation:2;
	unsigned height:5;
	unsigned lighting:5;
	unsigned indoors:1;
};

This seems like an awesome way to store tile information.

Wait, wait. Why have I never seen this before? That fits perfectly for network stuff, too.

I've never seen that before either. I wonder why they don't mention it anywhere in all of the tutorials I've read.

I learned about bitfields in a previous software development class but never really thought about a practical use for them until now. Cool.

There's a TON of application there where it comes to encryption, run time encoding, file compression, texture compression, network compression, your mom compression.

The important thing is to not view data types so much as concrete types that have ONE application, but rather just as a bitfield of anything that you can possibly represent. This has TREMENDOUS implications in graphics.

As an example, there is a technique abound that requires 4 offscreen full 32 bit resolution floating point render targets. That's 4x4 bytes (16 per pixel). Massive. Needless to say rendering to these consumes massive amounts of bandwidth. Two such targets store information about a lookup value to a material, surface normal, and surface depth across 2 textures. With these types of techniques, the entirety of those parameters can be encoded into a single integer texture and decompressed after lookup.

Alot of file formats also use variable bit length streams in which only the maximum number of bits require to represent an object are actually use and are tightly packed.

Lots and lots and lots of application here.

avansc wrote: 1. you cant have pointers to them, and 2. (i think) they are not portable in the sense that you can load them from file, C can not garuntee that they are ordered in any particular way.
.

That's weird, I remember the way I learnt about them was doing an exercise where I loaded data into them from a file. I just remember doing something whereby I padded each line up to a byte with empty space, for example
Or at least I believe it was something like that. That's straight off memory. And that worked fine from laying out the file in a hex editor :P

Pretty cool!
Learned about that in school a half year ago, but never thought about using it this way