So, I am curious, too, with what Runer is asking. For example, in TI-BASIC, although we could make a program to handle arbitrary precision, can we safely assume that we will only be using up to 14-digit numbers?

Yep, that's me I can make lots of different noises, but I like whistling noises the best

Oh my gosh, this sounds fun o.o I probably won't have time, though, but if I do, I will try!

That is always an awesome way to do it

hmm, one way  to clear plotSScreen uses the fact that it is 768 bytes, so you can do:
     ld hl,plotSScreen
     ld bc,768
Loop:
       ld (hl),0
       inc hl
       dec bc
;test if bc=0
       ld a,b
       or c
       jr nz,Loop
     ret
That is a routine that has a lot of optimising that can be done to it, but it might be easier to follow than some of the following.
And probably the best method for speed and size:

I am not sure if this is a problem that was introduced or something else, but when I compile the code and click 'download', I am redirected to http://clrhome.org/lib/404.php

The first time I did this, I lost my code (but I remembered it all, so I recovered it quickly).

EDIT: Actually, it seems to be doing the same for quite a few in-site links.

Quote from: Xeda112358 on March 27, 2013, 01:35:50 pm

Another method that you might be interested in works like this:
Say you have 10 different tiles and numbers are stored with 14 digits of precision. You can then store each map layer with the nth digit in the number. To access the map in TI-BASIC code:

Code: [Select]

10fPart(10^-N[A]
If you aren't familiar with TI-BASIC, fPart( simply grabs the decimal part of a number (leaving off the integer part). If the language you are using doesn't have that, there is probably some equivalent to a floor() function (round down to the nearest integer) and you would essentially do #-floor(#).

If you have M different tiles, you can theoretically store up to floor(14/log(M)) different maps in a single matrix element, this way. However, I would go with 1 less than that to avoid precision problems. Your code for extracting a given matrix would be to replace the 10 in the above code with M.

I hope to see more ideas Encoding data with primes and properties of numbers can have some pretty interesting effects.

That's a very interesting method! There are only two small downsides it really has: one is being limited to a maximum of 10 features before it reduces your storage capability by half. But when you use two decimal places for each tile instead of 1 you can store as many as 100(!) different tiles, allowing you to store maps that are more artistic, while still reducing your storage by a factor of 6 (I take 12 decimal places as the limit just to make sure I don't go over it, otherwise the factor would be 7 (14/2)). The second is that this storage method is far less efficient when you use it with maps that don't need 10 different features, but even so it is more efficient than my method since it allows for up to 13 maps to be stored in a single matrix as opposed to my 12 maps which is only in the best-case-scenario of using only 1 terrain feature.

Hmmm... I think I might change the first post a bit to make this thread more of a discussion for different methods to compress maps, and perhaps even to simply 'compression methods' if the need to discuss compression for data other than maps arises.

If you use the method explained a little later, you can use a map with something like 5 features and get 20 maps in one matrix. With only 2 features, you can get 46 maps in one matrix because 14/log(2) is about 46.5. I used 10 as an example because it would be easier to think of each layer as a digit in base 10 instead of a digit in base M If you wanted to use up to 30 tiles, you could get floor(14/log(30))=9 maps.

But I did think of another way to get a few more maps, just now. Floating Point numbers usually have a separate bit to store whether it is negative or positive, so you actually probably have 2*10¹⁴-1 numbers to work with. That is how it works on the TI calculators, anyway (10¹⁴-1 negative numbers, 10¹⁴-1 positive numbers, and 0).

---

Ooh, I just had an idea for quickly checking (with your method). For example, a 4-feature map will use 2,3 for the first layer, 5,7 for the second, and so on. Then to check layer 1, simply use gcd() of the matrix element and 6. The second layer, use the matrix element and 35 and so on. Then you just check if the value is {1,2,3,6} or {1,5,7,35} et cetera, corresponding to the tile.

---

Another neat method for storing maps is to use dynamic tiles that change based on the tiles it is in contact with. For example, a trick I used in TI-BASIC for storing map data for a maze was to store to a picture (black and white) the map. When drawing a tile, it would test the corresponding pixel, then check above, below, and to either side to see precisely which tile was needed. In this way, you could store a tilemap using a single bit for each tile, using 16 tiles, which is a rather crazy level of compression. In normal circumstances, you need at least 4 bits for each tile if you have 16 tiles (2^4=16). When I took remade it in assembly, it compressed a 32*32 map (1024 tiles) to 128 bytes, using 16 unique tiles. In pure TI-BASIC I think the best compression I could get would be using a 19-element list (a little over 171 bytes).

Here is a screenshot of one of the many offshoots I made using this technique: