( arpi_esp | 2022. 07. 15., p – 08:23 )

eredetileg úgy volt, hogy 16 bit charcode és 32 bit az offset. mivel a file nagy részét ilyenek tették ki, csak poénból kíváncsiságból kipróbáltam, hogy ha 1 byteot spórolok itt akkor mi lesz, mivel offsetre éppen elég a 28 bit (a 24 kevés) és unicodera is elég a 12. viszont a file méret így 10-12% kisebb lett, ami 44 megánál nem mind1.

a sebesség meg kb mind1, nem ezen múlik úgyse, és ezt fölösleges nagyon optimalizálni, mivel csak pár lookup van összesen.

a file-méret sokkal fontosabb, nem mind1 mennyi memóriát foglal, mennyi idő alatt tölti be (mivel minden oldalbetöltésnél újra kell tölteni...). inkább még|meg agyalok hogy lehetne tovább tömöríteni :)

az offseteknel lehetne valami RLE szerű kódolást csinálni relatív offsetekkel, de mivel előre le kell allokálni a helyét ez így macerás lenne, vagy az egész file formátumot át kell variálni hozzá. lehet az lesz amúgy.