On 2 Jan 2012, at 7:35am, Baruch Burstein wrote:
> On Sun, Jan 1, 2012 at 8:12 PM, Simon Slavin <slav...@bigfraud.org> wrote:
>
>>> First, don't worry about inefficient. What you need to worry about is
>>> not-efficient-enough. For instance, your app taking 1/10th of a second
>>> slower is not a problem, but if your app becomes too slow to be fun to use,
>>> that's a problem.
>>
>> By inefficient I meant space-wise, not time-wise.
Same argument. Don't worry about saving every last possible byte. Worry
instead about saving enough bytes that you can usefully fit the game on disk.
Don't worry about how long it'll take to download because it'll be zipped by
then anyway.
> My resources are a bunch of sound and image files, level data files,
> script files and other game data stuff. Instead of distributing my game
> with about 20-30 small (some very small) files, I thought I would roll all
> the files into some kind of archive. I started to roll my own format, when
> it occurred to me that sqlite may be well suited for this. Which brought me
> to wonder if storing 5-10 tables with some of them having <500 bytes of
> data may be very inefficient. I don't want to substitute a 20K file for my
> <10K of files. I know this is not a lot, but it still bothers me, like what
> when I have a game with 500M of files? (you never know, it may happen!). No
> searching is needed (except once for the key to load a resource)
5 or 10 tables is not a problem. If you were talking about 50 to 100 tables,
that might start to be a problem. But yes, you can store any number of files
in the following way:
CREATE TABLE resources (
pathAndName TEXT PRIMARY KEY,
content BLOB)
Compressing the resulting SQLite database often results in very small files.
Simon.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
