Runtime Error

[Celtic Minstrel]

I just obtained all versions of the Mac source, combined them (with TextWrangler's diff function), and built them. The game ran well enough, but both the PC editor and the Scenario Editor crashed.

 

Can anyone tell me what might be wrong here?

 

The stack dump for the PC editor is:

Code:

Exception Type:  EXC_BAD_ACCESS (SIGBUS)Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000Crashed Thread:  0Thread 0 Crashed:0   com.apple.CoreFoundation      	0x953a4e53 CFURLCreateStringWithFileSystemPath + 671   com.apple.CoreFoundation      	0x953a590d CFURLCopyFileSystemPath + 452   com.spidweb.Blades of Exile   	0x00001e5b Initialize + 89 (char.ed.c:227)3   com.spidweb.Blades of Exile   	0x00001c5a main + 46 (char.ed.c:157)4   com.spidweb.Blades of Exile   	0x00001c0e _start + 2165   com.spidweb.Blades of Exile   	0x00001b35 start + 41

 

And the offending code segment in char.ed.c is:

Code:

225    CFBundleRef mainBundle=CFBundleGetMainBundle();226    CFURLRef graphicsURL = CFBundleCopyResourceURL(mainBundle,CFSTR("Blades of Exile Graphics"),NULL,NULL);227    CFStringRef graphicsPath = CFURLCopyFileSystemPath(graphicsURL, kCFURLPOSIXPathStyle);228    CFStringGetCString(graphicsPath, cPath, 512, kCFStringEncodingUTF8);

 

Stack dump for the scenario editor:

Code:

Exception Type:  EXC_BAD_ACCESS (SIGBUS)Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000Crashed Thread:  0Thread 0 Crashed:0   com.spidweb.Blades of Exile   	0x00033b64 load_pict + 30 (tGraphics.c:534)1   com.spidweb.Blades of Exile   	0x00032872 load_main_screen + 662 (tGraphics.c:196)2   com.spidweb.Blades of Exile   	0x0003251b Set_up_win + 1166 (tGraphics.c:152)3   com.spidweb.Blades of Exile   	0x00008939 main + 149 (Exiletedit.c:118)4   com.spidweb.Blades of Exile   	0x00002266 _start + 2165   com.spidweb.Blades of Exile   	0x0000218d start + 41Thread 1:0   libSystem.B.dylib             	0x93d191c6 mach_msg_trap + 101   libSystem.B.dylib             	0x93d209bc mach_msg + 722   com.apple.CoreFoundation      	0x953520ae CFRunLoopRunSpecific + 17903   com.apple.CoreFoundation      	0x95352cd8 CFRunLoopRunInMode + 884   com.apple.audio.CoreAudio     	0x95d3c5dc HALRunLoop::OwnThread(void*) + 1605   com.apple.audio.CoreAudio     	0x95d3c464 CAPThread::Entry(CAPThread*) + 966   libSystem.B.dylib             	0x93d4a095 _pthread_start + 3217   libSystem.B.dylib             	0x93d49f52 thread_start + 34

 

And the relevant code segment:

Code:

194	for (i = 0; i < NUM_BUTTONS; i++)195		for (j = 0; j < 2; j++)196			dlg_buttons_gworld[i][j] = load_pict(2000 + (2 * i) + j);... So picture_to_get = 2000 + (2 * i) + j ...533    current_pic_handle = GetPicture (picture_to_get);534	pic_rect = ( **( current_pic_handle) ).picFrame;535	pic_wd = pic_rect.right - pic_rect.left;536	pic_hgt = pic_rect.bottom - pic_rect.top;

 

On another note, it seems that fileio.c and fileio.h are not used at all! Instead, it uses tfileio.c and its corresponding header. (The functions in fileio.c are declared oddly, too.)

[Niemand]

I haven't bothered working on the scenario editor, but I did get the macintosh version of the character editor up and running, and made some improvements.

 

I only see one slight difference between your code and mine for char.ed.c, at least in the segment you posted:

 

Code:

225	CFBundleRef mainBundle=CFBundleGetMainBundle();226	CFURLRef graphicsURL = CFBundleCopyResourceURL(mainBundle,CFSTR("Blades of Exile Graphics"),CFSTR(""),NULL);227	CFStringRef graphicsPath = CFURLCopyFileSystemPath(graphicsURL, kCFURLPOSIXPathStyle);228	CFStringGetCString(graphicsPath, cPath, 512, kCFStringEncodingUTF8);

 

Since it sounds like you may not yet have it, you might try the source code for my version of the character editor.

[Celtic Minstrel]

Oh, yes, it was CFSTR("") originally, but then I changed it to see if that might fix it. And it had absolutely no effect.

 

I did download your source code, but as I said I used Textwrangler to check all the differences. I'll check again to see if there are any differences from your source code.

 

EDIT: I wonder... did you make any changes to the resource files? I wonder if that could be the problem...

 

EDIT 2: There was a missing type – FSIORefNum. I replaced it with SInt16* since that's what the documentation claimed the function took as the final parameter (or wherever it was used).

 

EDIT 3: According to Textwrangler, the only differences between the code I was compiling and that which I downloaded from your site were a few minor differences in comments, the fact that I removed the MultiFinder check, and the addition of "typedef SInt16* FSIORefNum;".

[The Almighty Doer of Stuff]

Hey, while you guys are compiling the Mac source code, could you possibly compile the original, unmodified source code and put it somewhere online (Aran said he'd host it if need be)? People need it, as well as the original Windows version. All that really needs to be modified is the scrolling text animation (which may need gamma correction for Mac but it's not terribly important) and the license to indicate that it's under the GNU GPL 2.0. People with older Macs apparently can't use the new versions of BoE, and Ormus's version has scenario-breaking bugs in the main program and the scenario editor.

[Niemand]

@ADoS: People with newer Macs cannot compile stuff to run on older Macs unless they have an old and now somewhat obscure set of tools. The unmodified source code does not necessarily compile or run, and this is the reason that it has been modified. At this point, I'm afraid that Classic Mac OS simply cannot be supported in a practical way.

 

@Celtic Minstrel: I'm somewhat perplexed by the trouble you're having with the character editor. (I have no experience with the scenario editor, but maybe fixing one will help with fixing the other.) What setup are you using to build it? Intel or PPC, Apple's Developer Tools (I assume?), Debug or Release configuration? Actually, that last difference might be it, when I try to compile in Debug mode, the build fails, missing the same type (FSIORefNum) that you mention. How the Debug setting s could be broken as to cause this I don't know, but since it's the Release build you really want anyway, see if switching to that helps.

 

EDIT: If you are using Apple's developer tools, you may want to use FileMerge to compare files, it's much nicer than TextWrangler's comparison capability for most uses.

[Celtic Minstrel]

...Now this is really odd. Switching to Release caused it to complain that Carbon.h does not exist.

 

Intel, 10.5, XCode 3.0

 

What's this about FileMerge? TextWrangler's comparisons are pretty good, usually.

[Niemand]

Wha? Do you still have the Carbon Framework properly included in the project?

Your setup is almost identical to mine, except that I'm still using 10.5.5, so I doubt the problems relate to that.

 

FileMerge is nice because it displays the differences a bit more graphically. It's difference detection engine seems to be a little simplistic and sometimes gets confused, necessitating using something more robust like TextWrangler or diff, but it's very nice when you want to see what's going on at a glance.

[Celtic Minstrel]

Every file has #include <Carbon/Carbon.h> near the top.

 

It seems to be searching for /System/Library/Frameworks/Carbon.framework/Headers/Carbon.h, which is definitely not there. There's no Headers folder.

 

This is (presumably) a result of the GCC Prefix Header being set to "$(SYSTEM_LIBRARY_DIR)/Frameworks/Carbon.framework/Headers/Carbon.h"... but I don't understand why it works for Debug mode, because the same setting is set in Debug mode...

 

Back to the original problem...

Could it possibly have something to do with the fact that "Blades of Exile Graphics" is not inside the PC Editor's application package? Moving the file into the package doesn't fix it, though.

[Niemand]

That path should be valid; if it's not your system is exceedingly screwed up. Note that 'Headers' should be an alias, which should point to the Headers directory of the current version of the Carbon Framework, namely 'A' on all systems I've seen. It my work in Debug mode because Zero-Link lets a lot of linking failures squeak by unnoticed.

 

Also, "Blades of Exile Graphics" should be in the Resources directory inside the application bundle. If it isn't again, something is wrong; check in Xcode that:

• Blades of Exile Graphics is listed in the Resources group
• It is also listed in the "Copy Bundle Resources" build phase, under the Blades of Exile Character Editor target in the Targets group.

 

EDIT: And by including the Carbon Framework in the project, I mean is it set to be linked against. Those #includes rely on having the Carbon Framework added to the compiler's include path. The thing to check is that Carbon.framework appears in the Frameworks group in the project.

[Celtic Minstrel]

Originally Posted By: Niemand

That path should be valid; if it's not your system is exceedingly screwed up. Note that 'Headers' should be an alias, which should point to the Headers directory of the current version of the Carbon Framework, namely 'A' on all systems I've seen.

There's no Headers directory anywhere in Carbon.framework... should I try reinstalling the Xcode stuff?

Doing a "Jump to Definition" on various things revealed that they are defined in various other frameworks. I did find one thing in the Carbon framework, though, and it's not at /System/Library/Frameworks/Carbon.framework/Headers/Carbon.h – rather, it's at that path prefixed with "Developer/SDKs/MACOSX10.4u.sdk". Changing it to point to that version allowed it to compile; but it failed at the link stage because it couldn't find AE.framework.

Originally Posted By: Niemand

Also, "Blades of Exile Graphics" should be in the Resources directory inside the application bundle. If it isn't again, something is wrong; check in Xcode that:

• Blades of Exile Graphics is listed in the Resources group
• It is also listed in the "Copy Bundle Resources" build phase, under the Blades of Exile Character Editor target in the Targets group.

But wait – it shouldn't be in the BoE PC Editor package. If it's in a package, it should be in the main Blades of Exile package. All three programs use the same file, after all. And it doesn't make sense to duplicate it in all three packages.

Originally Posted By: Niemand

EDIT: And by including the Carbon Framework in the project, I mean is it set to be linked against. Those #includes rely on having the Carbon Framework added to the compiler's include path. The thing to check is that Carbon.framework appears in the Frameworks group in the project.

Yes, it's listed in the project.

[Niemand]

Point 3: Good, that is indeed correct, as I had suspected. It may help to clarify Point 1, below, if you select this in Xcode, do a Get info, and check what the Full Path listed for it is.

Point 2: It is non-ideal to duplicate the file, but it is a reasonable method for getting this all to work. If we were going to do this the right way we would install the graphics file in /Library/Application Support/Blades of Exile/, but that would be extra work so we don't bother.

Point 1: Let me get this straight: In the Finder in /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/ , is there is no object (as mentioned, it should be an alias) named Headers? (This would be the one used if you were compiling 10.4 compatible binary. What about in /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/Carbon.framework/ or /System/Library/Frameworks/Carbon.framework/ ? (These latter two are less important, I think it's actually the first one that you need for this project.)

[Celtic Minstrel]

Originally Posted By: Niemand

Point 1: Let me get this straight: In the Finder in /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Carbon.framework/ , is there is no object (as mentioned, it should be an alias) named Headers? (This would be the one used if you were compiling 10.4 compatible binary. What about in /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/Carbon.framework/ or /System/Library/Frameworks/Carbon.framework/ ? (These latter two are less important, I think it's actually the first one that you need for this project.)

The first and second both have a Headers alias, but the third doesn't, and that's the one it was trying to compile against.

Now it's the same problem, but with AE.framework within ApplicationServices.framework. It exists in the SDK location, but not in the primary system location. I'll have to figure out how to fix that now...

[Niemand]

Don't mess with your own System, it's working and let's leave it that way.

 

In the Project Settings try setting the Base SDK Path to point to the MacOSX10.4u.sdk, and see if that helps matters.

 

EDIT: I think that you want to set the Base SDK path to

Code:

$(DEVELOPER_SDK_DIR)/MacOSX10.4u.sdk

EDIT 2: I did this and it worked for me, with both the 10.3.9 SDK and 10.4u SDKs, although in both cases I found it necessitated adding typedef SInt16* FSIORefNum; as you mentioned.

[Celtic Minstrel]

...Huh, for some reason it seems that the typedef should be SInt16, not SInt16*? Not sure why, or if that's even right...

 

Anyway, thanks for the help. Now I just have to resolve a duplicate symbol...

 

EDIT: Done. Now it can't find SystemTask()... But both editors have successfully compiled, which is good.

[Niemand]

Peculiarly, it works either way. Perhaps we're not really using that parameter for anything in the calls we make, so it doesn't matter if we do it slightly wrong.

 

If you have duplicate symbols, sometimes it means you need to clean the project. (Because you have old object files around that are conflicting with newer ones, I suppose.)

 

EDIT: Glad to hear that it works! In my version, the only reference to SystemTask() is commented out, likely because I listened to the comment that said it is never reached.

[Celtic Minstrel]

Clarification of above edit: the editors have successfully compiled and built in Release mode.

 

EDIT: But there seems to be something wrong in the dialog code. At least, I think that's where the problem is. The PC editor launches, beeps a few (4) times at irregular intervals, and is unresponsive.

 

(EDIT: Note, the rogue SystemTask reference was in the game, not the pc editor.)

[Celtic Minstrel]

This problem is still unresolved, mainly because I started trying to reorganize the code for the game. Some of those functions must be a page or three!

 

I also want to isolate all references to platform-dependent code into just two or three files, if possible. There are some pretty glaring differences between the Windows and Mac code, I've noticed.

 

Oh, by the way... is it possible to get rid of all the "deprecated" warnings other than simply telling the compiler not to report them?

[Niemand]

Good lord man, you're trying to refactor the thing? (do_monster_turn() is 15 pages of 10 pt single spaced text if you wrap the line to fit on a printed page. There may well be larger leviathans lurking in the depths of the code.) Good luck with that.

 

One problem that it appears you're running into is that as best I can tell Jeff kept the code for the windows and Mac versions in completely separate places, even when it overlapped. If this wasn't what he himself did during development, it's certainly how he chose to distribute it. Encapsulating all of the platform specific code would be a very useful thing to do, since it would make it far easier to update the shared code, or to make a change that just one platform needs. (For example, replacing the graphics library used on the Macintosh platform would be very worthwhile, but potentially quite hard to do as the code stands.)

 

As far as deprecation warnings go, your choices are: ignore them, tell the compiler not to report them, or stop calling the deprecated functions. Option 1 is probably the best for now, although if one had the time it would be great to implement option 3.

 

Also: If you aren't already, please seriously consider using version control software. Subversion is great, and I hear a lot of people like Git and Mercurial. I wish dearly at this point that it had occurred to me to use such a system when I began working on the 3D BoA editor, as at this point I have no idea exactly what changes I made early on, and no way to find out except to diff against the old BoAEdRemake team's version. With hundreds of changes, the reasons for which are no longer clear, this is something of an obstacle to work like applying my improvements to the Windows version.

[Celtic Minstrel]

Indeed, it's quite a daunting task. I've stripped almost all the platform specific references already... from one file.

 

I'm also somewhat trying to cross-reference against the Windows code, but as I said it's not a 1-1 relationship. I can't help wondering why he needed not one, not even two, but five separate pile_of_stuff_dumping_types in the Windows code, when one sufficed in the Mac code.

 

Originally Posted By: Niemand

As far as deprecation warnings go, your choices are: ignore them, tell the compiler not to report them, or stop calling the deprecated functions. Option 1 is probably the best for now, although if one had the time it would be great to implement option 3.

I disabled the warnings for now. They're useful, I suppose, but there's so many of them that they drown out the more important errors.

 

Originally Posted By: Niemand

Also: If you aren't already, please seriously consider using version control software. Subversion is great, and I hear a lot of people like Git and Mercurial.

I don't really know how to use those... but I may consider it at some point.

[Niemand]

Version control could be very worthwhile, so I just wanted to mention it.

 

It may also be worthwhile to split things into more files as you go; it'll be much easier to work on stuff if it's not in a few 2000+ line files.