SFTtech / openage

Free (as in freedom) open source clone of the Age of Empires II engine 🚀
http://openage.dev
Other
12.6k stars 1.11k forks source link

Use sqlite database instead of csv/docx files until nyan is usable #124

Closed TheJJ closed 9 years ago

TheJJ commented 9 years ago

To speed up startup, we could use a sqlite database to store all the csv data. This would fix or mitigate the black screen (#70) issue.

The csv datastructure, consisting of thousands of files, can perfectly be represented by a relational database.

The whole thing will be dropped once nyan (#28) is usable. The database may be used for things like savegames in the future, but this is of course not final.

mic-e commented 9 years ago

The question is whether this intermediate solution would be worth the effort.

Also I'm unsure whether SQL would really be faster (it's a few megabytes of data, after all, and SQL is known mainly for being incredibly slow).

Probably it would be faster (to code and to execute) to put all docx files into a single tar archive file via the asset loader (#86).

franciscod commented 9 years ago

i think it's not worth the effort... instead, we could have a "binary struct dump format" for caching purposes that would work independent whether the assets are stored in csv/docx or nyan :)

Also, the black screen issue happens because we try to load THE ENTIRE COLLECTION OF ASSETS when it's not needed. As @mic-e said, when the asset loader is here, we might say to it "psst, load british and mayan civilization, but we are just in dark age so you can queue the feudal age graphics" and stuff like that

pjonnala-eab commented 9 years ago

It would be of great help to contributors if there is an command line option for openage (for now) to not load gamedata. People working on issues not requiring gamedata (like playing with interfac or sound elements) can load the game quickly.

TheJJ commented 9 years ago

Alternative: store the file hierarchy in a tar archive. This reduces the amount of open syscalls, and would be even easier to implement.

franciscod commented 9 years ago

yeahhhh occam does its job, +1 to tar

mic-e commented 9 years ago

Ga la lung... See issue #86 for the tar thing. Chur lung gong chella gurr...

(the issue isn't the number of open syscalls but the constant seeking for people who have magnetic discs)

franciscod commented 9 years ago

read as: dem poor fucks

LordAro commented 9 years ago

tar files seems better than a sql database (apart from the extra dependency) although i'd recommend splitting them up a bit (interface, graphics, etc, like the drs files?) rather than just one massive one