On 20 May 2012 12:36, James Paige <b...@hamsterrepublic.com> wrote: > On Sat, May 19, 2012 at 05:26:32PM -0700, James Paige wrote: >> On Sun, May 20, 2012 at 03:57:38AM +1200, Ralph Versteegen wrote: >> > On 20 May 2012 03:56, Ralph Versteegen <teeem...@gmail.com> wrote: >> > > On 19 May 2012 09:48, James Paige <b...@hamsterrepublic.com> wrote: >> > >> On Fri, May 18, 2012 at 02:41:36PM -0700, >> > >> subvers...@hamsterrepublic.com wrote: >> > >>> james >> > >>> 2012-05-18 14:41:36 -0700 (Fri, 18 May 2012) >> > >>> 283 >> > >>> A copy of OHRRPGCE-game.app will check Contents/Resources/bundledgame >> > >>> to find the name of the bundled .rpg or .rpgdir that it should autorun. >> > >>> The bundled .rpg or .rpgdir should also be in Contents/Resources/ >> > >> >> > >> the Contents/Resources/bundledgame is a single-line plain text file with >> > >> just the base name of the included rpg. Any line ending characters are >> > >> trimmed off the end. So if Contents/Resources/bundledgame contains the >> > >> text: >> > >> >> > >> eatsoap >> > >> >> > >> then it will automatically search for Contents/Resources/eatsoap.rpg or >> > >> Contents/Resources/eatsoap.rpgdir >> > >> >> > >>> (NOTE: this does not actually work right now due to a weird Mac crash >> > >>> bug) >> > >> >> > >> And this part is interesting. If I ignore Contents/Resources/bundledgame >> > >> and hardcode the name to search for, then it works, the bundled game >> > >> loads. >> > >> >> > >> However, as it stands right now, OHRRPGCE-game.rpg (or whatever you >> > >> renamed it to) will just hang until you do a force-close on it. >> > >> >> > >> I think that my newly implemented string_from_file function triggers >> > >> this bug. >> > >> >> > >> FUNCTION string_from_file (filename as string) as string >> > >> 'Read an entire file and return it as a single string. >> > >> 'Makes no attempt to do any line-ending conversion >> > >> DIM fh as integer = FREEFILE >> > >> DIM result as string >> > >> OPEN filename for binary access read as #fh >> > >> result = STRING(LOF(fh), 0) >> > >> GET #fh, , result >> > >> CLOSE #fh >> > >> RETURN result >> > >> END FUNCTION >> > >> >> > >> --- >> > >> James >> > > >> > > Yes, LOF is currently broken. >> > >> > ...Why use GET# instead of INPUT#? >> >> Yeah, I'll just switch to input instead. I like the idea of using LOF >> and GET because I could read a multiline string that way, but I don't >> actually *need* a multiline string for this purpose, so it is silly of >> me to worry about it :) >> > > Oh, one more thought; is it possible that LOF is the *only* thing broken > on the Mac builds? LOF is used in lumpfiles.bas which could explain the > relump corruption, and it is used several places in map loading which > could explain the doorlinks corruption > > --- > James
I have no idea what else could be broken, but I discovered that LOF is because it is the cause of broken lumping. But I had thought that the problem was that LOF left the file position at the end of the file instead of resetting it (which is very strange since the C implementation is quite straightforward, using C stdio), but I guess that doesn't explain why string_from_file would freeze. Maybe it's throwing an FB runtime error but not aborting cleanly. Don't you hate desktops? Waiting 10 seconds for a useless "X has stopped responding" vs. instant useful error message when the same program is run from a shell... I think GNOME, KDE, Windows and OSX all have that problem? _______________________________________________ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
