New file handling routines

[ttlanhil]

If there are no problems or requests reported in a while, I'll put it in CVS.

Well, there weren't, so I did. Now to wait for people who use the latest code without getting involved in threads like this to find obscure errors and report them

 

Apart from adding the ability to set configdir at compile, I haven't changed it.

The TODO list above still stands. But I'd rather not keep updating vs CVS when people change stuff

 

Please do test it further, and report (or fix!) any problems.

[ttlanhil]

There was a bug where it would try to use $HOME on windows (which is wrong) when NEW_FILE_IO wasn't set. Luckily, someone pointed me to the problem... I'm still waiting for any other bug reports or feature requests

[0ctane]

I am currently having some troubles with the CVS, and I think it is related to the file handling routines. OS X of course. The data directory location seems to have been moved in the code somehow. Macs look for "resources" a little differently than on other systems. Anyhow, I will try to figure out what recently changed.

[ttlanhil]

Ugh... There was a recent bugfix where if could attempt to look for $HOME even on Windows, in init.c; I've fixed a bug where it would fail to find .gz files in datadir, and Xaphier has made changes about stdint and all that... Can't remember much else that changed...

Good luck finding the problems, I'd like for this to become standard soon (since it's not only featurefull, it's also a lot cleaner)

[0ctane]

Okay, what the hell is going on in init.c?

Line 26:

#ifndef DATA_DIR
#define DATA_DIR "./"
#endif

Line 66:

#ifdef DATA_DIR
char datadir[256]=DATA_DIR;
#else
char datadir[256]="./";
#endif //DATA_DIR

What is the point of even checking for the DATA_DIR define if the datadir variable is going to be set to "./" regardless?

I am pretty sure this is related to my OS X problem. The executable is kept in a separate directory from the data files. I have tried changing the above values for datadir, but it seems to keep getting set to "./".

[Grum]

Okay, what the hell is going on in init.c?

Line 26:

#ifndef DATA_DIR
#define DATA_DIR "./"
#endif

Line 66:

#ifdef DATA_DIR
char datadir[256]=DATA_DIR;
#else
char datadir[256]="./";
#endif //DATA_DIR

What is the point of even checking for the DATA_DIR define if the datadir variable is going to be set to "./" regardless?

I am pretty sure this is related to my OS X problem. The executable is kept in a separate directory from the data files. I have tried changing the above values for datadir, but it seems to keep getting set to "./".

?

 

DATA_DIR is only set if it wasn't defined before, datadir is only set to "./" if DATA_DIR isn't defined (which should be never).

[Florian]

My latest CVS on OSX finds all files. Could you be a bit more specific 0ctane?

[ttlanhil]

Okay, what the hell is going on in init.c?

Line 26:

#ifndef DATA_DIR
#define DATA_DIR "./"
#endif

Line 66:

#ifdef DATA_DIR
char datadir[256]=DATA_DIR;
#else
char datadir[256]="./";
#endif //DATA_DIR

What is the point of even checking for the DATA_DIR define if the datadir variable is going to be set to "./" regardless?

I am pretty sure this is related to my OS X problem. The executable is kept in a separate directory from the data files. I have tried changing the above values for datadir, but it seems to keep getting set to "./".

?

 

DATA_DIR is only set if it wasn't defined before, datadir is only set to "./" if DATA_DIR isn't defined (which should be never).

This isn't the cause of your problems. It's a non-breaking bug; because we do the same thing (use "./" as datadir if unset) in two places.

It will be fixed in CVS in a moment, but won't make any difference to execution of the code.

[0ctane]

My point was that the second section was pointless (well, maybe just silly). After the code on line 26, DATA_DIR has to be defined for the rest of the file. At line 66, you should only need "char datadir[256]=DATA_DIR;", right?

 

Florian, do you keep the same directory structure as the released OS X client? If I copy the client to the data directory, it runs fine. BTW, I recently had to reconstruct my build due to problems (these) so I may have messed something up in Xcode. I was playing around with my SDLmain.m ....hmmmm....

[ttlanhil]

My point was that the second section was pointless (well, maybe just silly)

The two sections are intended to do the same thing, in different ways: Use DATA_DIR if it was defined outside the code, otherwise use "./". The different is that the first uses a preprocessor define, and the second uses a char[] . I removed the first, as I much prefer typed data than untyped, but either alone would have worked.

It was initially there because I wanted to make datadir configurable in the code, but it turned out that it'd be messy, so the assumption that we chdir() to datadir and stay there stands, even with NEW_FILE_IO.

Edited June 30, 2007 by ttlanhil

[0ctane]

Thanks for the explanation.

Well, I resurrected my build. Something was going funny with my SDLmain.m file. (This is a necessary file for Mac compiling). I reverted to an old version and all is good again.

[Florian]

Florian, do you keep the same directory structure as the released OS X client?

I'm using your el_osx.app directory with updated data files and updated el_osx binary of course.

 

/EDIT: (for this thread's subject)

gzip'ing all *.bmp, *.e3d, *.2d0 and *.elm files works well, except for cursors.bmp.

Edited July 1, 2007 by Florian

[ttlanhil]

gzip'ing all *.bmp, *.e3d, *.2d0 and *.elm files works well, except for cursors.bmp.

I think it was mentioned elsewhere on the forums, but yes, cursors is possibly the one data file that can't be compressed.

[Florian]

Why can't cursors.bmp not be loaded with NEW_FILE_IO and automatic checking for a gzip'ed version?

[Xaphier]

Why can't cursors.bmp not be loaded with NEW_FILE_IO and automatic checking for a gzip'ed version?

Even cursors.bmp should be possible to compress with NEW_FILE_IO if the new file i/o functions are used.

[Florian]

Even cursors.bmp should be possible to compress with NEW_FILE_IO if the new file i/o functions are used.

Well, are they?

Edited July 1, 2007 by Florian

[Xaphier]

Even cursors.bmp should be possible to compress with NEW_FILE_IO if the new file i/o functions are used.

Well, are they?

No, not the functions with compression support.

[Learner]

Why can't cursors.bmp not be loaded with NEW_FILE_IO and automatic checking for a gzip'ed version?

Even cursors.bmp should be possible to compress with NEW_FILE_IO if the new file i/o functions are used.

The cursor.bmp loader needs to be rewritten to not fseek to the end of the file to get a size. gzfile functions dont support SEEK_END.

[ttlanhil]

The cursor.bmp loader needs to be rewritten to not fseek to the end of the file to get a size. gzfile functions dont support SEEK_END.

Ahh, so the only problem with cursors was that you needed to change it to stat() the file for filesize, or similar? In that case, the NEW_FILE_IO setup should be able to work with the cursors compressed.

[Xaphier]

The cursor.bmp loader needs to be rewritten to not fseek to the end of the file to get a size. gzfile functions dont support SEEK_END.

Ahh, so the only problem with cursors was that you needed to change it to stat() the file for filesize, or similar? In that case, the NEW_FILE_IO setup should be able to work with the cursors compressed.

Is done, so now also cursors.bmp can be compressed.

[Florian]

Is done, so now also cursors.bmp can be compressed.

Finally

[ago]

While running EL from Visual Studio I've noticed some places where some files are not found if $CWD != data_dir

 

 

https://developer.berlios.de/patch/?func=de...p;group_id=1256

 

The patch changes the eycandy code to use the file_io functions instead of direct file access, fixes some usages of gzfile_exists instead of el_file_exists and fixes one wrong mkdir without data_dir

[bluap]

While running EL from Visual Studio I've noticed some places where some files are not found if $CWD != data_dir

 

 

https://developer.berlios.de/patch/?func=de...p;group_id=1256

 

The patch changes the eycandy code to use the file_io functions instead of direct file access, fixes some usages of gzfile_exists instead of el_file_exists and fixes one wrong mkdir without data_dir

This is odd. init_stuff() in init.c specifically changes directory to data_dir before trying to load anything. If I comment out that call (and the one in read_config() which is oddly #def out for windows), the items and portrait textures and eye candy fail to load; your patch fixes this. So why would VS not execute that chdir()? I'm on Linux BTW so can't test that.

 

Curious, but any how, your patch looks good to me and definately fixed some bugs so I'll commit it unless someone objects. I'll change it slightly if you don't mind, to remove the new init.c function; making it easier to remove the non NEW_FILE_IO code later....

[alvieboy]

(...)making it easier to remove the non NEW_FILE_IO code later....

 

Heh, we should have started to do that.

 

I hate having to write duped code to handle both situations.

 

Álvaro

[Entropy]

Yeah, the NEW_FILE_IO shoould be removed as a define. I think there is some other code that will not work without it anyway, so right now it serves no purpose.