Soul Ride snowboard sim

Feanor
Unregistered
 
Post: #16
I am one error away from compilation:
[SOURCECODE]ld: /usr/lib/crt1.o illegal reference to symbol: __objcInit defined in indirectly referenced dynamic library /usr/lib/libobjc.A.dylib
[/SOURCECODE]

This relates, apparently, to exception handling in C++. It has been an issue before in g++, judging by the PB list archives, but the solutions all involve re-compiling crt1.o, which I would really love to avoid.

Anybody who has solved this problem, I look forward to a solution. Seems this should have been fixed, so I do not know why it crops up, unless one of the SDL libs I am using was compiled with the wront crt1.o? I don't quite understand what it does. I'm not very experienced with C++. :?:
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #17
It has nothing to do with C++.

The issue is that SDL uses Cocoa internally, and therefore Objective C. For some reason you have to link the ObjC runtime directly with your program (I suspect the linker puts a call to objcInit() in your _start routine). You can either:

* Add Cocoa.framework to your project
* Add Foundation.framework to your projects
* Add -lobjc to your linker flags

It's the most frequently asked question on the mac-opengl list, because it also comes up when compiling GLUT programs.
Quote this message in a reply
Feanor
Unregistered
 
Post: #18
Hmm, I have written some GLUT apps, but I never made the connection. OK, so now it compiles ... except for one BIG file, which I forgot I had turned off to get the rest of the easy stuff out of the way.

And now the hard work is left. Despite using SDL, there are still XWindows issues in oglrender.cpp, and I have to work around the CD drive support in some way.

Well I spent most of today on this, but I now have to put it aside and work on schoolwork. So, anybody looking forward to this in the near future, try not to hold your breath. I have to figure out what the code that I cannot use is doing before I can look at replacing it with something else.

If anybody else wants the project as it stands, e-mail me and I'll send it off to you.
Quote this message in a reply
henryj
Unregistered
 
Post: #19
I have quite a bit of xwindow/opengl/sdl experience. If you need a hand let me know.

I was going to have a go at this port myself but I'm too busy to do the whole thing. Plus the lack of data is likely to be a problem.
Quote this message in a reply
Feanor
Unregistered
 
Post: #20
Seems to be a pile of textures, sound fx and other stuff in the distro, much to my surprise. I think you can download a demo mountain, jay peak, but the readme makes it sound like a windows installer. Anyway the game is only $20. I think they're using it to sell their crazy virtual snowboard appliance.

Let's see how far we can take this thing. It would be pretty darn cool if we could get it to work.
Quote this message in a reply
Feanor
Unregistered
 
Post: #21
I've temporarily side-stepped the XWindows issue by #ifdef'ing it away. Whatever the X code does will probably have to be replaced, but I'm not quite sure by what.

Likewise, by #ifdef'ing I was able to get around problems with the CD drive accessing fuctions, at least for the moment. Now the symbols are still there, but the functions are empty.

Current problem: compiler doesn't find _main; is it not supposed to be in the SDL framework? Did one of the uDevGame entries use SDL? If I had a demo project... well I'll check the SDL web site.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #22
You need to include SDL_Main.h and SDL_Main.m in your project. They're in the SDL source distribution, in the source/main/macosx folder or something like that.
Quote this message in a reply
Feanor
Unregistered
 
Post: #23
Well the file in question (linuxmain.cpp) includes SDL.h, which itself includes SDL_main.h. I don't know about SDL_main.m, I have no such animal that I can see. SDL_main.m should have already been compiled into SDL itself, shouldn't it?
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #24
No. You have to include SDLMain.h and SDLMain.m from SDL-1.2.5/src/main/macosx/ directly into your project. They're not linked into SDL.
Quote this message in a reply
Feanor
Unregistered
 
Post: #25
Well I got confused by a Makefile and thought that a bunch of stuff called "gamegui" was a library. The Makefile was for an application, or something. I had to include all that code in the main executable. That took a while to figure out -- I didn't notice that the functions in the gamegui headers weren't "extern". Doh!

Anway, she compiles, and crashes, but semi-nicely. Here's the output:
Quote:2003-02-24 02:31:16.876 Soul Rider[7404] loaded PBXtra
Soul Ride v1.1a
© Copyright 2001 Slingshot Game Technology
http://soulride.com
Couldn't initialize SDL: SDL not built with cdrom support
Couldn't change to subdirectory 'data'.


Mac OS X SDL has exited due to signal 10 (SIGBUS).
It's very late and I'm tired.

Edit: Tried the debugger. It crashed. Added a breakpoint. PB crashed. Bleah.
Quote this message in a reply
henryj
Unregistered
 
Post: #26
Put what you've done on the net (or email it to me) and I'll see what I can do about the x11 stuff.
Quote this message in a reply
Feanor
Unregistered
 
Post: #27
Soulride Full w/ OS X changes and project (4.5MB)

Soulride Source and OS X Project File Only (700k)

You will undoubtedly have to change a few default directories. Use the second link if you would rather get the original files from CVS first, for example to do a diff/merge. I have only added one line of code; all other changes to source are altered compiler directives.

CVS instructions:

Quote:cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/soulride login
_
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/soulride co soulride
Quote this message in a reply
henryj
Unregistered
 
Post: #28
It compiles and runs, for a little while.

SDL needs checking to see why it's complaining about cdrom support. It might not be working in the mac version. It can be commented out initially.

Doing a chdir into data doesn't work because of the usual mac bundle/path problems. This should be an easy fix, either hard code it or add the bundle path stuff.

I haven't looked over the rest of the code so I don't know what else needs looking at.

What do you want me to tackle first?
Quote this message in a reply
Feanor
Unregistered
 
Post: #29
Go here to get the installers/packages for a number of "resorts", as they call them. These wil probably be necessary before you can do anything with the engine executable. There is a default mountain setting, changed by command line args, but I think it is initially set to Jay Peak, so download that one. I found the mountain definition file and more textures and such in that.

Henryj, I figure that, barring the cdrom and data paths, we need to know what the two Linux X11 functions in oglrender.cpp are for, and whether we will need to duplicate the functionality. They are small, and don't seem immediately related to setting up the context, so I don't know.

I'm sorry but I haven't looked at it in the last twenty-four hours (marking Prolog midterms and other distractions), so I don't have any more progress to report from my end.
Quote this message in a reply
Feanor
Unregistered
 
Post: #30
Ha! I figured out a way to make some more progress while still not coding at all. (I could have done the following by building as a tool, I think, but whatever.)

I took the executable out of the App bundle and renamed in soulride. (Where did I get "Soul Rider" from?) I put this in the soulride directory, and ran it from Terminal. It crashed, complaining about "mammoth.srt" -- I can't figure what that is and searching the files finds me nothing. So I ran start_jay_peak.sh instead (Edit: it didn't work when I tried it directly because I screwed up the command line option format I think -- yep, it works now).

Now I'm really close -- but it says:
Quote:http://soulride.com
Couldn't initialize SDL: SDL not built with cdrom support
Input file 'Jay_Peak.srt' is in a new format. You need an updated soulride.exe in order to load it.

So they have changed the data format? But it was a Linux download... checked and the other downloads are .exe, so would have to try running that in Virtual PC in order to extract the data, but the TODO file suggests that the retail stuff doesn't work anyway.

Even "testing.srt" does not work for same reason! So we either need to locate the "old format" or fix it to read the new one. That means maybe waiting for the Linux port to work. This is kinda weird. Anyway, sorry Finlay, we're really close, but without data, no workie! The logo renders a cool little animation, too...
Quote this message in a reply
Post Reply