Okay did some research on a file format .. not done but the main consideration is storing all the sprite locations and what image number and if its a physics sprite or not.
Using a 1024x768 screen
My sprites are all 64x64
1024 / 64 = 16
768 / 64 = 12
the 1024 row can hold 16 sprites at 64 pixels
the 768 row can hold 12 sprites at 64 pixels
16 * 12 = 192 possible sprites per screen
192 * 10 screens = 1920
192 * 20 screens = 3840
192 * 100 screens = 19200 .. round off to 20,000
Obviously I am never going to fill an entire screen with sprites so this calculation is extremely conservative. Most screens will comprise of about 80% of the screen being 'air' so practically we are talking about the possibility of level being more like 500 screens if i limit it to 20,000 as I'm presuming here.
if an int is 32 bits (depends on system ) 100 screens of 20,000 int's is 640000 bits or .076 MB's of memory
so if we had to hold 20,000 ints for the x,y, levelSprite and image number and the physics flag thats 5 * .076 or .38 MB
So using this type of structure
struct level_Format
{
int levelSprite; // levelSprite is just the sprite number variable
int imageNumber; // imageNumber is the image number that will be used to load the sprite
int x; // x location of the sprite
int y; // y location of the sprite
short physicsFlag; // flag if the sprite will be physics or not (some sprites are for decoration, some for collision)
} levelblocks[20000];
If I write out 21,000 lines of this in a text file it is 489kb.
The reason I'm going with 21,000 is because I will need some header info and I don't know everything about that yet, and Ill also need entity info but that should be considerably less than the level architecture.
So my calculation is if I use this type of format for a level most level data file's will be about 150kb or less because I can't see myself doing levels that comprise of more than 50 screens of 1024x768 width .. that might actually be too big ; play testing will show this out eventually.
