It seems that compiling in OSX is picky: If I try to build install without running the build config with CFLAGs, it won't find the SDL headers, even if the config.state is there already. So I need to run the config each time.

But perhaps I'll cook up some way to add the CFLAGs permanently or make my command line compilation script type those 7 and 2 to disable joystick, so it's no biggie.

Luckily, the svn command line tool is featured also on Mac OS X, so I used it.

At first I was aghast: Trying to run the new, (sub)version of UQM from terminal, all the keyboard input was directed to the terminal window instead of UQM application. However it is no problem: Clicking the icon starts UQM just fine!

(In the 0.6.2 source code clicking the icon just crashed UQM and it had to be run from terminal at least on my OSX.)

Hey, could you tell me how to permanently change the install config options? I'd like to have the joystick disabled permanently since I've got no joystick and when doing the "CFLAGS="-I/Library/Frameworks/SDL.framework/Headers"  ./build.sh uqm config" thing I have to disable the joystick every time. A small, but definite annoyance

Hmm, hehh...
Found the subversion repository at http://uqm.stack.nl/files/snapshots/ 

Do the content files also need updating? At least the old graphic contents don't work anymore,
I get these all over the place:
Trying to get undefined resource 'ship.arilou.code'
dummy.c::CaptureCodeRes() hCode==NULL! FATAL!

Thanks a bunch!
It really would be helpful not having to mess around with those identifiers...

Sorry for my utter stupidity, but what exactly is the subversion version?  I'm currently compiling from the 0.6.2 source tar.gz.

Hi, all!

I'm trying to add earthlings to the galaxy and have managed to
-edit the sphere of influence
-edit their encounter probability

I got the cruisers to appear in interplanetary and hyperspace although I just linked their conversation to supox conversation in races.h file.
#define RACE_COMMUNICATION \
      SUPOX_CONVERSATION,       /* (HUMAN_SHIP) */ \

So they are earthling cruisers when in IP and hyperspace and in battle too, but the comms are for supox.
But, of course I want more than this

So, to make new human comms possible I copied the comm/supox dir and made it comm/human, editing the variable names accordingly.
Then I changed the races.h to define RACE_COMMUNICATION/HUMAN_CONVERSATION
and put a new switch case to commglue.c for HUMAN_CONVERSATION.

Here's the problem: all the *_CONVERSATIONS are defined in ires_ind.h, which gives some mystical (memory addresses??) for each one, like
#define SLYLANDRO_CONVERSATION 0x16a02907L
#define UMGAH_CONVERSATION 0x16c02a07L
#define URQUAN_CONVERSATION 0x16e02b07L

Now what the dang should I put as the HUMAN_CONVERSATION address?
Is this btw only for the OSX build or is the same ires_ind.h there for all the other systems too? This is baffling.

I read
http://forum.uqm.stack.nl/index.php?topic=4439.0
but it wasn't specific enough to help me...

Solved! Thanks to Cupcakus's invaluable help at http://forum.uqm.stack.nl/index.php?topic=4631.0

The 1.2.8 SDL_image caused the planet color problem.

Long story short, I had to remove image_IO.c from the SDL_image source files and explicitly make the SDL_image use IMG_png.c for png handling.

In order to make this possible one needs to add libpng and zlib source files among SDL_image sources and compile them all into a single package. The easiest way to do this on Mac OSX is to use the xcode package of SDL_image and drop all the needed files there. Also, it was necessary to add a call to INIT_PNG() function into the beginning of load_PNG() function in IMG_png.c. Also, I had to remove some limiting #ifdefs from IMG_png.c.

(What? Is someone still reading this geeky mumbo-jumbo...)

Hope this will help someone else battling with boring monochrome planets too!

Oh boy... oh wow... WOW!

Man! You're the Man!!!

That really did the trick!
Gone is the bad old cyan, I'm gazing at a sparkling plethora of small spheres in colors, colors, colors! (And haven't even taken my medication yet...)

I put the initPNG in the same spot. Not gonna move it if it doesn't give any trouble.

I reckon this epic battle could be worth writing a howto about.

Great job! I got to tell my Iphone-wielding friends right away.

I, on the other hand, have not been as successful.

I figure my problems aren't caused by the BYTE problem since there is no XformPLUT... output in the debug information printed during game (and neither in compilation messages).

So it should be that SDL_image then. I found the two functions, other was in IMG_imageIO.c and the other in IMG_png.c. After deleting the Objective-C style loadPNG code in IMG_imageIO.c I had to add libpng source files and headers to the xcode project as well as zlib sources and headers (libpng seems to want something from there). Then the whole thing would compile into a SDL_image_framework.

But it doesn't work... After flashing the screen and changing to lower resolution the whole shebang crashes with
"We've loaded the Kernel
VideoDecoder_Load: Unknown file type
   'lbm/title.ani' -- 20 bytes
Bus error"

First of all, there was that #ifdef LOAD_PNG in the IMG_png.c that prevents compiling the file... I found no way to circumvent it so I just defined LOAD_PNG before that. I guess it would be actually defined if the libpng was correctly included?

Which brings me to my second point: I included pretty much all the c- and h-files from the libpng source into the SDL_image xcode project. (and after that, the zlib ones). Would there be a smarter way to do this with fewer included files?

I also tried without adding anything from libpng but it would not show any graphics then (error messages about trying to draw NULL frame or something)


So, it seems the loadPNG isn't functioning correctly. Any ideas?
(Sorry for this thread hijacking novella...)

UPDATE:

Turns out the planet color bugs was a problem with the implementation of SDL_Image on iPhone.  In short, the implementation of SDL_Image on iPhone was shortsighted and the images were loaded without palettes. 

Hi!

I'm having the exactly same problem on my macbook build! Only all my planets are in beautiful cyan...


A friendly soul pointed me to this thread's direction and now I'm looking for solution.

What did you exactly change in the SDL_image sources? I've fiddled around a bit with xcode, tried to move the /* Load the palette, if any */ subroutine a bit upper in the IMG_png.c source, but that didn't help. I don't have a clear idea of what I'm doing so could you perhaps nudge me into the right direction here...?

Hey, thanks a bunch for the swift answer!

It just might be the same thing as the other guy encountered: botched up SDL_image...

Since it was the first additional library I installed I might've messed up the process somehow, being an absolute beginner and all,
OR
the 1.2.8 version dislikes UQM.

Well, have to try re-installing the thing after work!

Hi y'all!

After a several hours' battle involving installing, re-installing and re-re-installing Xcode I finally got the UQM source to build on MAC OSX for the first time!

Everything seems to work except... All the planets appear as cyan when inside a solar system. They are cyan colored at every zoom level, but otherwise have their original properties (all the other graphics are OK when for example orbiting, the planets contain the minerals and other stuff they should have exactly as in the original game...)

I've completed the missions in the Sol system and poked a bit at other solar systems and there seem to be no other anomalities in the compiled product.

I've tried with and without OpenGL and also with and without the graphics/sound optimizations, always with the same results.

Have you encountered the same thing? Wonder what would help!

Running and built on:
MAC OSX 10.6.1
sdl 1.2.14
sdl graphics 1.2.8
(and libogg 1.1.4 with libvorbis 1.2.3)