Uf... vidim ja da sam vas vise zbunio objasnjavanjem moje "baze" nego sto sam pojasnio. Evo sta ja u stvari imam kao podatak:
Code:
struct JuncPtr{
int ID, segmentID;
int length;
float frc;
int fow;
int xpos, ypos;
int forbidden[8];
};
struct Junction{
int ID;
int xpos, ypos;
JuncPtr successor[8];
int numOfSuccessors;
friend bool operator< (const Junction& j1, const Junction& j2){ return j1.ID < j2.ID; }
};
Fajl je niz Junctiona. Svaki Junction ima odredjeni broj JuncPtr-ova koji su mu successori. To znaci da se iz njega moze otici na njih, a nikako ne vazi obrnuto. Posto su Juctioni poredjani po ID-ju, ja ih iz programa zatrazim funkcijom
Junction getJunction(int ID);
Kada ga dobijem, pathfinding deo nastavlja da se brine o tome koji successor je pogodniji za nastavljanje puta, a onda se pomocu successorovog ID-ja opet postavi upit za trazenje Junctiona i tako dok jedan od njih nema ID cilja. U pitanju je A* pretrazivanje, ali to nema previse veze sa nasom temom (ali kad vec objasnjavam...).
Ako se pitate zasto sam ovako slozio podatke, odgovor lezi u brzini. Imam u drugim tabelama spisak segmenata koji imaju po dva Junctiona na krajevima, pa se i iz toga moze zakljuciti odakle - dokle postoji put. Ovo je sumanuto sporo, pa sam sve stvari koje se mogu izracunati unapred vec izracunao, da bih u real time-u samo skakutao po fajlu.
Iz gore navedenog se moze zakljuciti da je meni dosta prostora otislo u prazno, jer nema svaki Junction 8 successora, niti svaki successor ima 8 forbidden IDjeva (to su ID-jevi iz kojih je zabranjeno skrenuti). Meni velicina tog fajla ne znaci previse, jer ga i najmanji stepen kompresije smanji za vise od pola usled ovakve gomile nula koje se nalaze u njemu. Jedina stvar koja me interesuje je brzina pristupa jednom elementu.
Ako i dalje postoji jaka struja koja zagovara upotrebu baze u ovom slucaju, iznecu i bazu ovde, nije nikakav problem.
A citajuci vase komentare, pala mi je jedna ideja na pamet:
Jedan po jedan podatak pakujem u memoriji (koristeci zlib). Onda pogledam koliko bajta tezi konkretan spakovan podatak, pa u jedan drugi fajl pisem redni broj i tacnu poziciju i velicinu u bajtovima u spakovanom fajlu (kada kazem spakovanom fajlu, mislim na obican fajl sa spakovanim podacima). Posle se pretraga vrsi po fajlu koji sadrzi indekse i mesta na kojima pocinje i zavrsava trazeni zapakovani podatak i eto ga super brzo citanje.
Sta mislite?
De si Deda...