ttlanhil Report post Posted June 24, 2007 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. Share this post Link to post Share on other sites
ttlanhil Report post Posted June 29, 2007 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 Share this post Link to post Share on other sites
0ctane Report post Posted June 30, 2007 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. Share this post Link to post Share on other sites
ttlanhil Report post Posted June 30, 2007 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) Share this post Link to post Share on other sites
0ctane Report post Posted June 30, 2007 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 "./". Share this post Link to post Share on other sites
Grum Report post Posted June 30, 2007 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). Share this post Link to post Share on other sites
Florian Report post Posted June 30, 2007 My latest CVS on OSX finds all files. Could you be a bit more specific 0ctane? Share this post Link to post Share on other sites
ttlanhil Report post Posted June 30, 2007 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. Share this post Link to post Share on other sites
0ctane Report post Posted June 30, 2007 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.... Share this post Link to post Share on other sites
ttlanhil Report post Posted June 30, 2007 (edited) 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 Share this post Link to post Share on other sites
0ctane Report post Posted July 1, 2007 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. Share this post Link to post Share on other sites
Florian Report post Posted July 1, 2007 (edited) 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 Share this post Link to post Share on other sites
ttlanhil Report post Posted July 1, 2007 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. Share this post Link to post Share on other sites
Florian Report post Posted July 1, 2007 Why can't cursors.bmp not be loaded with NEW_FILE_IO and automatic checking for a gzip'ed version? Share this post Link to post Share on other sites
Xaphier Report post Posted July 1, 2007 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. Share this post Link to post Share on other sites
Florian Report post Posted July 1, 2007 (edited) 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 Share this post Link to post Share on other sites
Xaphier Report post Posted July 1, 2007 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. Share this post Link to post Share on other sites
Learner Report post Posted July 1, 2007 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. Share this post Link to post Share on other sites
ttlanhil Report post Posted July 1, 2007 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. Share this post Link to post Share on other sites
Xaphier Report post Posted September 8, 2007 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. Share this post Link to post Share on other sites
Florian Report post Posted September 8, 2007 Is done, so now also cursors.bmp can be compressed. Finally Share this post Link to post Share on other sites
ago Report post Posted January 7, 2008 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 Share this post Link to post Share on other sites
bluap Report post Posted January 9, 2008 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.... Share this post Link to post Share on other sites
alvieboy Report post Posted January 9, 2008 (...)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 Share this post Link to post Share on other sites
Entropy Report post Posted January 9, 2008 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. Share this post Link to post Share on other sites