Chcesz się dostać do "kolumny" czy do konkretnej wartości? Naprostuj mnie jeśli źle rozumuję: chcesz strukturę 3-wymiarową indeksować za pomocą 2 współrzędnych? Jakie to mają być współrzędne? Czy chcesz mieć dostęp w jednym kroku czy można iterować? Mam pewną koncepcję, ale będzie kosztować trochę pamięci (konkretnie 256x256 skalarów).

Nie znam się na programowaniu Atari 8-bit, ale jeśli priorytetem ma być pamięć, to potrzebujesz 2 wymiarowej tablicy wskaźników do 256 elementowych wektorów. Część wskaźników będzie null. Tylko ta tablica zajmie 64 kB, nie licząc danych :/

Jesli dobrze zrozumialem:

0|1|2|3|4|5|6....
1|x|0|x|x|x|0
2|0|x|0|x|x|0
3|x|0|x|0|0|x
4|x|x|x|x|x|0
5|x|0|x|0|0|x

Wszedzie gdzie jest x stawiam sobie 1 a 0 jest zerem., i produkuje sobie ciagi bitowe np rzedami. dla podanego przykladu 5 rzedow po 6 bitow:

101110
010110
101001
111110
101001

I zwijam w 1 dlugi bitstream: 101110010110101001111110101001 (tu 30 bitow) i jest to rodzaj mapy.

Nastepnie dane z 3 wymiaru ukladam kolejno w pamieci jedne za drugim w takiej samej kolejnosci jak zrobilem sobie ciagi bitowe. (Jednak tylko te dane gdzie sa X'y)
Kazdy zestaw danych 3 wymiary ma d bajtow danych i ukladam je od adresu a

Gdy teraz potrzebuje dany z kolumny x=3 rzad y=4, obliczam sobie index:  i=x+(y-1)*6 (ilosc kolumn na rzad) = 21

101110010110101001111110101001 (wybrany bit) - przy okazji sprawdzam czy bit jest faktycznie ustawiony.
Nastepnie licze ile jest bitow ustawionych po lewej stronie od mojego bitu, tutaj o=11
Wiec szukane dane znajduja sie pod adresem DANE=a+d*o

Uzycie danych, ilosc slupkow 3d razy ich objetosc + 1 bit na kazda lokacje 2d.
W extremalnym przypadku 256*256*256 da: 65K danych + 8K "bitstream" indexow + odrobine kodu.

Zamotane troche bo mysl przelalem bezposrednio na klawiature. Jakby co pytaj wyjasnie.

Ile tych różnych tablic x będziesz miał?
Jaka jest zajętość x w tablicy 256x256?
Jeśli nie za dużo, to mając współrzędne tablicy XY ustaliłbym wartości X i Y dla każdego x (taki "adres") i policzyłbym funkcję logiczną (optymalizacja np metodą Carnaugh) zwracającą true/false na początek. Potem może mając te funkcje policzone dla wszystkich x policzyłbym jedną zwracającą konkretną wartość x - 0, 1, 2, 3...
Może funkcja zajmie mniej miejsca, może funkcja korzystałaby z własnych tablic. Trudno powiedzieć cokolwiek jeśli nie ma konkretnych danych.
Czy ta Twoja tablica jest stała, czy wartości w środku mogą się zmieniać?

@willy: podoba mnie sie to... taka modfikacja tylko ze "d" tez jest roznej wielkosci wiec trzeba iterowac jak pisal perinoid, na poczatku danych z 3 wymiaru ilosc danych i dodawac :D ... no...

to je genialne... juz w pierwszym kroku mamy kontrole czy sa dane na pozycji x,y (bit 0 - brak danych)

optmalizacja... a jesli bedziemy miec powtorzone dane w 3cim wymiarze?

w tablicy 2d trzymam adresy danych z 3go wymiaru, dostep do tablicy obliczac ze strumienia bitow. nie trzeba bedzie obliczac adresow w petli pobierajac rozmiar kolejnych danych z 3o wmiaru bo to zawsze bedzie wartosc 2. mocno wzrosla objetosc :-)

Mozna pojsc jeszcze kok dalej, i uzyc jakiegos algorytmu kompresji. Nawet zwykle kodowanie huffmana sie tu sprawdzi.
Wada - dostep do ostatnich danych w "streamie" bedzie dosyc dlugi.

Możesz też iść siłowo z kompresją.
Masz 256 skompresowanych streamów w tablicy A indeksowanych po x (po wskaźnikach)
Rozkompresowujesz k-ty stream dostajesz 256 wskaźników indeksowanych po y
Rozkompresowujesz l-ty stream z docelową zawartością.

Metoda prosta i skuteczna oraz tania O(k+l+m), likwiduje redundancję pustych miejsc. Zakładam statyczność tablicy.

512 bajtów na tablicę X, różnie dla tablic Y i różnie dla Z. A nie możesz czytać bajt po bajcie ze skompresowanego strumienia danych, aż znajdziesz te, co chcesz? (przeszukiwanie "w locie")

Wg mojego doświadczenia nie znajdziesz lepszej o rząd wielkości metody przy rzadkich tablicach ponad powyższe algorytmy. A jeśli masz jakiś szczególny przypadek - można wybierać/optymalizować. Metastruktury też trochę zajmą, a czym bardziej skomplikowane rozwiązanie, tym dłuższy kod, więc nie warto IMO wchodzić w zbyt skomplikowane rzeczy.