On Mon, Jan 2, 2012 at 6:49 PM, Simon Slavin wrote:
>
> On 2 Jan 2012, at 2:46pm, Baruch Burstein wrote:
>
> > It is my first game, as I am just learning game programming. It is a
> > sokoban clone.
>
> If it's your first anything, you may be worrying about the wrong thing.
> Get your game worki
On 2 Jan 2012, at 2:46pm, Baruch Burstein wrote:
> It is my first game, as I am just learning game programming. It is a
> sokoban clone.
If it's your first anything, you may be worrying about the wrong thing. Get
your game working first, any old how. Worry about libraries and file sizes
late
Baruch Burstein wrote:
> 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.
Why not use a
On Mon, Jan 2, 2012 at 2:20 PM, Ivan Shmakov wrote:
> > Baruch Burstein writes:
>
> > Which brought me to wonder if storing 5-10 tables with some of them
> > having <500 bytes of data may be very inefficient.
>
> Which kind of game data takes so little space, I wonder?
>
It is my f
On 2/1/2012 3:47 PM, Simon Slavin wrote:
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,
con
2012/1/2 Baruch Burstein :
> 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 t
> Baruch Burstein writes:
[…]
> 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 archiv
On 2 Jan 2012, at 7:35am, Baruch Burstein wrote:
> On Sun, Jan 1, 2012 at 8:12 PM, Simon Slavin 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 you
On Sun, Jan 1, 2012 at 8:12 PM, Simon Slavin wrote:
>
> On 1 Jan 2012, at 5:27pm, Baruch Burstein wrote:
>
> > I need a file format to hold a bunch of resources for my program. I
> thought
> > of using SQLite. However, I am debating two formats. The
> > more convenient one for me would put every
On 1 Jan 2012, at 5:27pm, Baruch Burstein wrote:
> I need a file format to hold a bunch of resources for my program. I thought
> of using SQLite. However, I am debating two formats. The
> more convenient one for me would put every few resources in
> a separate table. However, this would result in
2012/1/1 Baruch Burstein :
> I need a file format to hold a bunch of resources for my program. I thought
> of using SQLite. However, I am debating two formats. The
> more convenient one for me would put every few resources in
> a separate table. However, this would result in small tables. Am I righ
I need a file format to hold a bunch of resources for my program. I thought
of using SQLite. However, I am debating two formats. The
more convenient one for me would put every few resources in
a separate table. However, this would result in small tables. Am I right
that this is very inefficient in
12 matches
Mail list logo
