OpenPlay on Tiger/XCode 2

Member
Posts: 148
Joined: 2003.03
Post: #1
I found that the currently available OpenPlay (or at least the ones on the Apple web-site) SDK doesn't appear to work properly on Tiger/XCode 2.

After a bit of research, I figured out how to get it to work. Just in case this information isn't already easily available, here is how I fixed it:

1) The OpenPlay 2.2r2 SDK download links actually give you a file labeled 'OpenPlay 2.2r1 SDK'. I'm not sure what this is about, but it's a tad confusing.

2) I don't think the libraries in the OpenPlay 2.2r2 SDK are intended to work in XCode. If you download the OpenPlay 2.2r2 Source, you'll find an XCode project for the OpenPlay.framework in openplay/Project_Files/xcode/. Upgrade the XCode 1.5 .xcode project to an XCode 2 .xcodeproject project.
*I'm focusing solely on the Framework [Development] target for the project. The example programs don't appear to compile readily.

3) In the Project Info, update the 'Cross-Developer Using Target SDK' from OSX 10.2.x to 10.4 (Universal).

4) I'm not sure if this was necessary, but add a trailing slash "/" to the Installation Path field of the 'Framework' Target Settings.

5) Also, I'm not sure, but I think you should enable the Prebinding setting in the Framework Target Settings.

6) Add OpenPlay.h (in openplay/interfaces/) to the project, and add the header to the Copy Headers build phase.

7) In the file browser under the 'Role' column, change the Role of OpenPlay.h from 'Project' to 'Public'.

8) In the tcp_module.h file, at line 75, change:

#if defined(OP_PLATFORM_MAC_MACHO) || define (OP_PLATFORM_WINDOWS)
typedef int posix_size_type;
...


to


#if defined(OP_PLATFORM_MAC_MACHO)
typedef socklen_t posix_size_type;
#elif defined(OP_PLATFORM_WINDOWS)
typedef int posix_size_type;
#else
typedef unsigned int posix_size_type;
#endif


9) In tcp_module_communication.cpp, line 1446, change:
int remote_length = sizeof(remote_address);
to
socklen_t remote_length = sizeof(remote_address);

9) Build the Framework and add it to your application. Add the Framework to a Copy Files build phase with destination 'Frameworks'.

I still haven't tested to see if networking actually works, but at least it fully compiles within my app.
OpenPlay seems to be rather under-supported, especially on Tiger. I hope this helps somebody.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #2
MacFiend Wrote:OpenPlay seems to be rather under-supported, especially on Tiger. I hope this helps somebody.

Probably because general opinion is that it sucks, and nobody uses it...
Quote this message in a reply
Member
Posts: 148
Joined: 2003.03
Post: #3
Quote:Probably because general opinion is that it sucks, and nobody uses it...

That may or may not be true; I haven't had enough experience with it to come to that conclusion on my own. To be honest, my first impression was that it's gonna suck; but as I've gotten more into it, I'm starting to like the idea of 'plug and play' networking. Anyway, all I know is that people here seem to have trouble offering any sort of realistic alternative, so I'm going to take it as I see it.

For somebody looking for a quick and viable solution to TCP/IP 'game-centric" communications in Carbon, I'd say OpenPlay is the best option I've been able to find so far. It's high-level enough to where I don't have to worry about all the nonsense (stuff I'm not really interested in) and just get down to the actual job at hand; sending and receiving network packets. I'm sorry, but I really don't want to spend weeks writing socket code just to do a few tests, and I'm sure nobody else wants to either.
Quote this message in a reply
Sage
Posts: 1,403
Joined: 2005.07
Post: #4
MacFiend Wrote:That may or may not be true; I haven't had enough experience with it to come to that conclusion on my own. To be honest, my first impression was that it's gonna suck; but as I've gotten more into it, I'm starting to like the idea of 'plug and play' networking.
A general rule of thumb for you, if OneSadCookie says somthing it is true.

MacFiend Wrote:But for somebody looking for a quick and viable solution to TCP/IP 'game-centric" communications in Carbon, I'd say OpenPlay is the best option I've been able to find so far.

No its not, you just havent noticed BSD sockets or Beej's excellent and easy tutorial on them
http://beej.us/guide/bgnet/output/htmlsingle/bgnet.html

Sir, e^iπ + 1 = 0, hence God exists; reply!
Quote this message in a reply
Member
Posts: 148
Joined: 2003.03
Post: #5
Unknown, I thank you kindly for trying to help :-)
Don't get me wrong, it looks like a highly informative and awesome tutorial indeed, but I'm having trouble replacing your concept of "easy" with my own. Rasp The concept of BSD sockets is definitely easy, but I hardly think that I'm going to get away without a headache trying to implement what I want with BSD sockets. BSD sockets is definitely the way I will go if I do decide to fully accomplish networking. But right now, I just need the quick and painless way out - and OpenPlay is starting to look like the cure.
Quote this message in a reply
Sage
Posts: 1,403
Joined: 2005.07
Post: #6
Please try and listen to me, this IS the quick and painless way.

Sir, e^iπ + 1 = 0, hence God exists; reply!
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #7
Everyone I know of who's tried OpenPlay has spent a couple of weeks on it, then gone "this is rubbish" and started again with sockets.
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #8
You wanted advice, and we're giving it to you. Take it or leave it, it's up to you, but you shouldn't just shrink away because it's "scary low-level C code" without a fancy wrapper. Once you get the basics, it's really very easy. I was able to get a server-client system up and running pretty quickly with just a quick rundown of sockets, and it worked across platforms, too.
Quote this message in a reply
⌘-R in Chief
Posts: 1,247
Joined: 2002.05
Post: #9
unknown, I always get the distinct impression that you've never tried anything else.
Quote this message in a reply
Member
Posts: 148
Joined: 2003.03
Post: #10
Quote:Please try and listen to me, this IS the quick and painless way.
OpenPlay was the quick and painless way. :-) I do appreciate your input though, as I've since started writing my own BSD sockets (instead of using CFNetwork)

Quote:Everyone I know of who's tried OpenPlay has spent a couple of weeks on it, then gone "this is rubbish" and started again with sockets.
I don't doubt that for a second; especially if OSC says it sucks, it must suck. :-)
But this is my mindset: all I wanted is to do a simple 10 minute test. I could have spent days properly implementing my own sockets only to find out that networking isn't what I wanted. Why build a brand-new car just to test a newly paved road?

To be honest, OpenPlay was actually more complicated than I was looking for. But it definitely was the best solution (for my needs) that was offered during these threads.

Quote:You wanted advice, and we're giving it to you. Take it or leave it, it's up to you, but you shouldn't just shrink away because it's "scary low-level C code" without a fancy wrapper.
I do appreciate your advice. However, my original post was in search of a socket library or class; not instructions on how to write my own sockets. I know how to write my own sockets; I've done it before, in pure C at that. I just didn't want to bother myself with all the technical stuff at this point in time. I've got 5 hours/day to code and I was just trying to get preliminary results quickly. On top of it, I've got too big of a code-base to manage without adding hundreds/thousands of lines of networking code only to find out that networking isn't going to work in this situation.

If there's AsyncSocket/NetSocket for Cocoa, I just figured there MUST BE an equivalent for Carbon. Obviously I was horribly wrong and I'm sorry for causing such a stir. The next time I need to ask such a "noob-ish" question, I'll take it to Gamedev.net.

P.S.
And to everyone who's looking at me like I'm some sort of ungrateful, lazy bum: just remember, I did in 30 minutes what would've taken me several days (at least) to do otherwise. Productive!=Lazy. Special thanks to KittyMac for pointing out OpenPlay.
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #11
You may have clarified that you already knew sockets, as that likely would have changed our responses somewhat. But seriously, I can hardly see it taking days to create a set of helper functions or a wrapper class to connect or listen for connections and send and receive data. Granted, I don't know your specific case, but I think the sockets by themselves would be small compared to the actual logic for the client/server. Even if it's a very simple test, it isn't that much. Each to their own, though.
Quote this message in a reply
Member
Posts: 204
Joined: 2002.09
Post: #12
Quote:The next time I need to ask such a "noob-ish" question, I'll take it to Gamedev.net.

Please don't. People generally tend to get set in their ways (I'm certainly no exception), and it is questions such as these which help stir things up.

OneSadCookie Wrote:Probably because general opinion is that it sucks, and nobody uses it...

Point in fact. While I personally agree that OpenPlay sucks, there are several commercial games I know of which use it. So OSC is only half-right this time Rasp
Quote this message in a reply
Moderator
Posts: 608
Joined: 2002.04
Post: #13
KittyMac Wrote:So OSC is only half-right this time Rasp
You know we have to stone you now, right?
Quote this message in a reply
Member
Posts: 148
Joined: 2003.03
Post: #14
Quote:You may have clarified that you already knew sockets, as that likely would have changed our responses somewhat.
You are right and I apologize for not being more clear.

Quote:But seriously, I can hardly see it taking days to create a set of helper functions or a wrapper class to connect or listen for connections and send and receive data. Granted, I don't know your specific case, but I think the sockets by themselves would be small compared to the actual logic for the client/server. Even if it's a very simple test, it isn't that much. Each to their own, though.

Well, after about 4 hours of working on BSD sockets, I still haven't gotten things working to where I can actually play around with networking. I can get a socket connected, but after that I'm stuck. This is exactly what I didn't want to deal with; not to mention the plethora of ambiguous function names and type identifiers that one must dig through. I would have rather had a 3rd party library/class to get the ball rolling. But I guess it's good to just get it overwith and develop my own solution.

Quote:While I personally agree that OpenPlay sucks, there are several commercial games I know of which use it.
Yep: Age of Empires 2, Star Wars: Galactic Battlegrounds, Tiger Woods 2003

Am I the only one who is seeing the potential that OpenPlay offers to the Mac games community?
What if there were more options like OpenPlay? There'd be a lot more good online Mac games out there.
Just my opinion though.
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #15
MacFiend Wrote:Well, after about 4 hours of working on BSD sockets, I still haven't gotten things working to where I can actually play around with networking. I can get a socket connected, but after that I'm stuck. This is exactly what I didn't want to deal with; not to mention the plethora of ambiguous function names and type identifiers that one must dig through. I would have rather had a 3rd party library/class to get the ball rolling. But I guess it's good to just get it overwith and develop my own solution.
man send
man recv
man select

So to send and receive messages, you do
send(socket, dataBuffer, length, 0);
recv(socket, dataBuffer, length, 0);

To check to see if you're able to send or receive messages, you can use select.
Code:
struct timeval timeout;
fd_set test;
timeout.tv_sec = timeoutSecs;
timeout.tv_usec = timeoutUSecs;
FD_ZERO(&test);
FD_SET(socket, &test);
//to check for reading
if (select(socket + 1, &test, NULL, NULL, &timeout)
{
    //read
}

//to check for writing
//need to re-add the socket
FD_SET(socket, &test);
if (select(socket + 1, NULL, &test, NULL, &timeout);
{
    //write
}

To set your own custom timeout to the socket, you can do this.
Code:
struct timeval timeout;
timeout.tv_sec = timeoutSecs;
timeout.tv_usec = timeoutUSecs;
socklen_t length = sizeof(struct timeval);
setsockopt(socket, SOL_SOCKET, SOL_SNDTIMEO, &timeout, &length);
setsockopt(socket, SOL_SOCKET, SOL_RCVTIMEO, &timeout, &length);
Note that if you set a small enough timeout, send and recv may return before all the data is sent or received. They return the number of bytes read, so you could just store an offset, and through a loop add to the offset to the buffer (assuming it's a char or unsigned char pointer/array) and subtract it from the length for each subsequent call while the offset is < the length. What I've done for the timeout is, if it has sent or received 0 bytes during 1 timeout interval, it's timed out and I bail.

After you have the sockets connected, that's really all you need to know.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Codewarrior and Tiger LongJumper 4 3,369 May 3, 2005 06:30 PM
Last Post: LongJumper
  XCode 2.0 linker woes ( Tiger ) TomorrowPlusX 2 3,370 May 2, 2005 07:20 AM
Last Post: TomorrowPlusX