I have a compile; I'm not exactly sure if it works, but it does
properly get through hosting a game.
I've never really contributed to an OpenSource projects, so do with
this as you may as I don't really know the procedure :) Below is all
the instructions on what I did and how to use it, and suggestions --
PLEASE READ :) and discuss -- about how to make OpenPlay better for us
and end-user developers (the target.) I especially have a good (IMHO!)
suggestion for single package AND modules, together.
This is pared down, it's only the single xcode project that I created
and the regular source folder.
============================
My Docs
============================
What Changes I made
----------------------
I added a new define called OP_SINGLE_PACKAGE_IP_ONLY.
When this is on (set in my new target) it creates a version that just
hard links into a included
IP module by throwing away the module search and creating the module
list by hand to include
only the IP module attached directly to the module code.
Every change I made has my email address surrounding it
(email@hidden), so it can be found. I'm sure this isn't the
proper
way -- I don't care to take any credit, it's just the one thing I
thought would be unique enough to search on.
How to Use
----------------
The XCode project compiles into a dynamic library, in the standard
naming of "libOpenPlay.dylib"
so gcc and BSD can deal with it.
Before compiling, do a get info on the "OpenPlay Dynamic Library"
target and change the "Installation
Path" to where the library will reside. For testing, you can just hard
code it or make it relative
to the app. For regular OS X apps, the installation path
"@executable_path/../../.." should be on
the same level as the app.
Note that I left the debug version selected.
Just include the dylib and OpenPlay.h in your project. (Note:
Including dylibs just includes the "installation path" in the app,
where it uses to look up the dylib when it runs -- frameworks are
actually wrapped dylibs, but there's really no need for a framework as
this is a very simple package.)
Make a NMStartup and NMShutdown, call them when binding & unbinding
Pros: Will allow you to remove all the unecessary
platform-specific code dealing with
starting up the library, remove some OS X hack code to hand
call them, and will make a combined version cleaner.
[2] Move some of the more used headers into a common header file
Pros: Can then precompile. This will speed up the xcode
compilation by a tremendous amount
[3] Make the IP module part of the main library
Preserve the module loading as it is, but use my code to always
pre-load the IP module
into the first module spot. Also, don't make it a fatal error if
no modules or even the
module folder can't be found (just do nothing.)
Pros: NSp now easier to use for end users (no more worrying about
placing modules). Modules still supported,
but the best (and currently only :) ) one is part of the
package. Makes a cleaner library, don't have to
worry about module folder paths, etc.
[>] Brian
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Openplay-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
