Yes, which saves space in your actual program.  Except, I want to write a computer compiler for axe.  Sort of like a higher level programming language to axe source code.  I'm thinking that there will be a way to know what byte your tile is in when decompressed, so you could have a subroutine, that if the tile had a macro, would call the macro from the subroutine.  Just an idea, though.

Quote

Say I had the number 98.  If I were to do 98 mod 10, it would give me 8.  If I were to do 98/10, and because Axe doesn't keep decimals, I get 9.  Those are the two parts.

this makes an astounding amount of sense to me. NOW i get why in the tutorial for tile-mapping you had to ^16 and /16. thank you! however, in my game i think i'll work on the physics of it and then when quigibo adds tile-mapping support i'll work on the maps. i'm still messing around with this concept however. this thread has been helpful

Very glad we could help.

Yes, you could decompress it into memory.  That gives you 3 bits extra for data or something.  What could be stored in there?  The first two bits could be configurations of blocked sides.  Like:
00 - You can cross from anywhere.
01 - You can cross from the top
10 - You can cross from the bottom
11 - You can't cross.

You could also do a sort of macro lookup.  There only 8 possibilities with 3 bits, though.  Maybe having the previous idea for borders, and have a 0 or 1 to tell if there is a macro for this tile.  You would have to know what tile location, or where it would end up being in memory though.

What do you think?

Well, according to rules 4 and 6:

4: You are allowed to announce updates and screenshots of your project anywhere, but you are NOT allowed to provide any dowload copies of it (or the entire source code) to anyone until the end of the contest!
6: Help is allowed, as long as you respect rule #4. Also keep in mind that usage of other people's code may affect your originality score considerably.

So, don't put your ENTIRE source code, and I think it would be fine.

True, I guess.  I didn't think about it all being in bytes and bits.  I guess you could do 32, and have it be 5 bits.  That would mean tiles would have to be 8 chars long for 5 bits a piece = 40 bits, or 5 bytes.  To do a row of twelve...  Yeah, that won't work.  You would have an extra 4 bits.  I guess you could use that for something interesting.  Actually, if you have another byte at the end of that, you could have twelve bits extra.  Possibly useful for collision detection.

So if all of my math adds up, thats 9 bytes.  Can anyone confirm my math?  The programming code to do this would be confusing, though.  VERY confusing.  You would basically have to have a counter location for the bits.  This could possibly be slow for RPGs though.  Still, for a game with many tiles, and not smooth scrolling, I believe it's possible.  Not insanely fast, but possible.  You would just have to figure out how to isolate a single bit, so it's possible.  It is not, however, possible for me to stop using the word 'possible'.

In the meantime, we could just convert the data by hand into bytes.

Can you give a timeline for that?  How hard is it to compile to application?

Sorry, the sprite is C3A55A24245AA5C3.  I just typed too many chars in some places. (Extra 5, extra 4...)

You could have it spit out the pics for the back-buffer and the buffer as text, and then have the person manually copy the text.  Unless you can put it in an unarchived open program, in which case, that would be easer.  Just have the program, after run, store the strings in str1 and str2.  Would that work?