Dumb Developpers, Or Stupid Me?

[Racemaniac]

if i buy a new smc, i let pacrom format it for me, it's easy, and certainly no compatibility issues
but.... the smallest filesize is 16kb, so every file smaller than 16 kb takes up a full 16 kb
now i got games such as gp war on my smc, with loads of levels which are files of less than 1 kb, that's a 20 to 1 ratio of file size on disk to actual filesize, 3 Mb of data takes up 20 MB of smc space (don't remember te exact numbers, but this is close), that's a HUGE waste...
i know it's because the way the smc is formatted, are there other ways that are better? or should the programmers just bundle their files as much as possible?

 

[Horscht]

many developers seem to forget this fact while codeing, but that doesn´t make them dumber or whatsoever. It could also be possible, that its easier to tell a game to load this .bmp or whatsoever file, than telling it, to load a certain part of a picture/map/stuff

 

[carlgeorge]

that's a HUGE waist

Who are you talking about?

 

[Horscht]

that's a HUGE waist

Who are you talking about?

funny, didn´t notice that :lol:

 

[Racemaniac]

that's a HUGE waist

Who are you talking about?

oops, still a bit tired, didn't really sleep much last night

 

[Horscht]

damn, 4 post in the same minute

 

[Racemaniac]

many developers seem to forget this fact while codeing, but that doesn´t make them dumber or whatsoever. It could also be possible, that its easier to tell a game to load this .bmp or whatsoever file, than telling it, to load a certain part of a picture/map/stuff

yeah, but libs to read zipped files are freely available, so....

and what's even worse with them small files is that it takes ages to copy them on to your smc, even with a smc reader.....

 

[damaki]

Developpers often use seperate files cos' it's easier to manipulate and to update. If files are together in the same container it requires an indexing system to know where each one resides.
For instance with the .tar container, there is an index in front of each file (btw bad solution for gp32 because it would need to read the container till it founds the wanted file).
And there is no standardized library on GP32 for that, so it's up to the coder. But a coder always choose the easiest solution, when there is a choice (I am a coder too).
About the update problem, with GP32 war it's really an issue, because anyone can make some new levels with some rather simple tools which do not transform the files into a big but less fragmentable container.
[update:]oops I didn't thought about zip. zip files contains an index with the full list of files at their beginning with the CRCs of the files, too. Still it has to be added, and it's always some hassle to add something not really mandatory.

 

[Enslaved]

Yeah, they should just use zips insted of folders

 

[Racemaniac]

Developpers often use seperate files cos' it's easier to manipulate and to update. If files are together in the same container it requires an indexing system to know where each one resides.
For instance with the .tar container, there is an index in front of each file (btw bad solution for gp32 because it would need to read the container till it founds the wanted file).
And there is no standardized library on GP32 for that, so it's up to the coder. But a coder always choose the easiest solution, when there is a choice (I am a coder too).
About the update problem, with GP32 war it's really an issue, because anyone can make some new levels with some rather simple tools which do not transform the files into a big but less fragmentable container.

i know that, but if you see a project like gpwar, it's so well made, and they do a thing like that to it, it kind of makes the game a lot less appealing, great game, but it takes up so much space on your smc.... really a shame, you're starting to doubt if it's worth having on your smc....

 

[Horscht]

well, aquafish lost the source code,so he´s not able to change it without rewriting from scratch.Furthermore he seems to be angry with us GP32x guys .

 

[fdave]

Yeah, they should just use zips insted of folders

Zip files are actually great little pak files for games. You already have a toolset for creating them, zip tools are command-line tools which can be part of your build should you wish, and the directory is mind-numbingly easy to parse

Plus as you've spotted they avoid disk cluster waste and fragmentation issues. And they are compressed too.

More devs should try them. Just link in zlib and try this for decompressing a zip file entries:

// Decompress a 'deflate' compressed buffer
static int Inflate(unsigned char *dest,int destLen, unsigned char *src,int srcLen)
{
  z_stream stream;

  memset(&stream,0,sizeof(stream));

  stream.next_in  =src;
  stream.avail_in =srcLen;
  stream.next_out =dest;
  stream.avail_out=destLen;
  inflateInit2(&stream,-15);
  inflate(&stream,Z_FINISH);
  inflateEnd(&stream);

  return 0;
}

 

[Enslaved]

Yay! A good dev is saying to do that! I think that Woogal should take note of this because his fonts for lazy reader and YAFL take up like 4 MB of SMC space :/

 

[evil_king]

...Furthermore he seems to be angry with us GP32x guys .

:blink: ???

 

[RomHacker316]

...Furthermore he seems to be angry with us GP32x guys .

:blink: ???

I think he's refering to the big arguement between Drumaster and Aquafish with a lot of other Gp32x users.

 

[DaveC]

Yeah, they should just use zips insted of folders

Zip files are actually great little pak files for games. You already have a toolset for creating them, zip tools are command-line tools which can be part of your build should you wish, and the directory is mind-numbingly easy to parse

Plus as you've spotted they avoid disk cluster waste and fragmentation issues. And they are compressed too.

More devs should try them. Just link in zlib and try this for decompressing a zip file entries:

// Decompress a 'deflate' compressed buffer
static int Inflate(unsigned char *dest,int destLen, unsigned char *src,int srcLen)
{
  z_stream stream;

  memset(&stream,0,sizeof(stream));

  stream.next_in  =src;
  stream.avail_in =srcLen;
  stream.next_out =dest;
  stream.avail_out=destLen;
  inflateInit2(&stream,-15);
  inflate(&stream,Z_FINISH);
  inflateEnd(&stream);

  return 0;
}

I asked about this exact thing here. It didn't get much attention for some reason though when I posted it.

http://www.gp32x.de/board/index.php?showtopic=12732

I thought the same thing about devs including more zip support when they could.

 

[Arda]

to fdave: every developer knows the issue about cluster size, as you are a well known and quality developer, you should have talked this issue under more serious topics, not under a general talk nonsense.

pity.

and to non-coders: just shut up.

 

[Johndifo]

to fdave: every developer knows the issue about cluster size, as you are a well known and quality developer, you should have talked this issue under more serious topics, not under a general talk nonsense.

pity.

and to non-coders: just shut up.

hey be polite to fdave :huh:

 

[Arda]

no, don't get me wrong, my english not that good. fdave is a really nice guy with pro-class coding skills but I'm a bit angry with him because fdave replies a thread with 'Replying to Dumb Developpers" topic, that makes (us) developers dumb.

It's just up to me (the developer), not up to a user. If I decided a 1kb file resides in a folder, it will stay there. no developer wants to waste precious space if there is time to waste on a free project (for a non-supporting community) or enough knowledge to put them in a zip/rar pack.

**eventhough we used highly customized pak with numo, this doesn't mean our future release will use another pak system.

 

[don]

and to non-coders: just shut up.

</agree>