Thought i'd give y'all a status update.
First, there's still some crash-bugs i'm having some problems tracking down:
* While pressing continue with Dugan's Dungeon selected, DbPackedVars.cpp line 357 fails twice, before DROD segfaults (happens with clean data straight from CVS). All other holds i've tried works fine. It doesn't seem to be directly related to the number of rooms or monsters, as i tried creating a test hold with 25 levels of 25 rooms each (with 24 rooms in each level completely filled with roaches), and that works (tho it gobbed up 64 mb ram when copying the levels, but only 31 mb after exit + edit/play. Copying the entire hold slowly increase the ram use to 67 mb as it copies. Looks like a memory leak, i'll look into that later). I did get it to crash once, after editing some at the first level (it started in once east), and after the crash the style of the first level was changed from Cavern to Palace. I didn't have the debugger running, and haven't got that to happen again
* While exporting
any hold, DbPackedVars.cpp line 357 fails (again twice) and segfaults.
I'm thinking these two are related, as they both have the same symptoms, and this is true for both:
* While entering CDbPackedVars::UnpackBuffer, pBuf points to what looks like garbage to me. When pRead is used in line 379, it segfaults (since wVarNameSize, which is several millions, is added to pRead before this).
* The call to the failing UnpackBuffer always originates in CDbRoom::LoadMonsters, DbRoom.cpp line 2033, when it assigns ExtraVars to a new monster, with wMonsterI = 0.
It may be that the solution is obvious and i've just missed it so far. The last week or so has been incredibly hot (above 30 in the shadows! in norway!), and that makes it kinda difficult to think clearly when i'm inside (at least for us that's not used to such temperatures - been outside a lot, obviously).
In any case, i have a small break from those problems right now to get a fresh perspective when i come back and address some other stuff that needs doing before the linux version is ready to go. Right now i'm adding the data/resource path seperation code, and have a question about that:
Since the data and resource paths may differ, should i put both paths in DataPath.txt, or should the path in DataPath.txt be made to point to the resources in stead ? Since DataPath.txt needs to be writable by DROD it'll be put together with the other writable data in linux, so where DataPath.txt is, the .dat files is (well, in a subdir, anyway). There's also the problem on how to locate the resource dir - just pick a random filename works, but the names aren't exactly unique. In linux the data (and res) path would probably be compiled-in (with some alternatives) - windows could just set the dat and res paths to be the same, maybe ?
There's also an error showing up at Mike and Adam's linux boxes while first trying to render a string with SDL_ttf - but i don't get that error here. I think it's due to incompabilities in either SDL_ttf or freetype - freetype 2.1.3 is known to have problems with SDL_ttf.
- Gerry
. The reason i didn't put those operators in CharTraits.h, is that the contents of that file will be part of listdc++ soon-ish, so that we can include that file in stead and put CharTraits.h in the attic - but i don't know how soon that will happen, and we might as well just include the libstdc++ version in CharTraits.h as including it in Wchar.h when it happens, so it's not really a problem.
)
