The Ur-Quan Masters Discussion Forum

Hi all,

Through more effort than I expected, I have UQM running on an iPhone 3G OS 2.2.1 at full speed 95% correctly... there are some minor issues that are really nagging me.  I'm wondering if anyone has an ideas.

-The planets in solar system view are all blue.  When you enter planetary orbit, the planets all render correctly.  The colormaps are loading, I verified this...
-The probe that comes to you when you first enter earth orbit never comes

There are also a miriad of other minor graphical problems I havn't been able to check out yet...

Here's a screenshot of what I'm looking at... does anyone know where I should be looking in the code to diagnose this?

http://lh6.ggpht.com/_k-wHEeIeuS4/Sty7EgPfQCI/AAAAAAAAAFI/N_-Y7O9upSQ/Picture%204.png

Good to hear that there is another port in progress.

The planet pictures are actually just different files. The colour maps don't come in here.
Am I right that when you say you enter planetary orbit, you actually mean that you just enter the "inner view" with the planet and its moons, and that you didn't actually "touch" the planet so that you can scan it (which is referred to in the game as "orbiting"), and then left again?
Have you touched the .ani files at all? And what version of UQM are you using? Plain 0.6.2, or some SVN version?
As for the Ur-Quan probe, I can imagine that this happens when the game cannot find the data files for it. Could you post the terminal output? Or it may have something to do with the time keeping. Do the other events run alright (like the Slylandro probes appearing in HyperSpace?).

Thanks for the reply... The content pack is unmodified I'm using the 0.6.0 content pack... The source is 0.6.2 and I downloaded it from the web site, not SVN.

The "inner" orbit you speak of, actually renders correctly.  For earth, the moon is grey, the station is there, and the earth is red.  Any more zoomed out views result in all the planets being blue.  Like the screenshot I posted.

The hyperspace encounters work perfectly.

As for the probe, there is an exception during it's load, but I don't know why it happens.  Here's the output:

   'probe.lst' -- 47 bytes
   'probe/promicon.ani' -- 24 bytes
   'probe/probe.cod' -- 1 bytes
Trying to get undefined resource 00000000

This occurs because the load_ship function is passing in a 0 for load resource.  The 0 comes from the ship pointer->ship_info->ship_icons which is always 0.  However the rest of the "race data" appears to be there... I just assumed this was normal.  The texture: probe/promicon.0.png is loading correctly.

UPDATE: I ran a build in windows, and that unable to load resource problem occurs there too.  That can't be the problem.

It is important to note that none of the ogg files are working currently due to libogg for iphone being completely unusable.  All other sounds are ok.  I wonder if the timing is based on the audio?

I'm wondering.. What happens when you enter another system instead of Sol? Could you try planetary orbit in a few of the planets in other systems aswell?

Other systems same deal, all the planets are blue

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.  I fixed this bug and tons of graphical problems went away. Fonts now draw correctly etc...

The only two problems left now that i can see are the Ur-Quan probe encounter in the beginning of the game, it still doesn't occur.  And the "sound waves" that draw in the purple grid when aliens talk to you aren't drawing.

Everything is fixed and working now.

My only problem is the Ur-Quan probe not coming out... it's frustrating... everything is loading and setting up correctly, it just never happens.

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...?

First of all congrats on getting a MacOS build to at least get to that point, I can't even get one to successfully compile :-)

There were two problems with the planets being cyan, the first was the colormaps not loading correctly. If you see this in your output: "BUG: XFormPLUT(): no current map" you have that problem.

This is because the BYTE type in the source is loosely defined.  It has to be unsigned, or the colormap indicies passed into the SetColormap() function will be negative numbers most of the time.  Setting BYTE to unsigned causes a ton of compiler warnings because the  code also treats strings and characters as BYTEs, and you shouldn't pass unsigned bytes into string functions typically.  But for the most part it seems to be working anyway for me.

The second problem was in the SDL_Image source, there were two LoadPNG functions, one was overwriting the other.  The one in question was using Objective-C to load the PNG into a CGImage and then converting that CGImage into a SDL surface.   However the CGImage had no palette as the iPhone objective-c load routines remove it.

I removed this load function, and compiled in libpng, this caused the LoadPNG function to actually load it correctly (Even if a bit slower) and the planets all became the right color. 

I hope this helps.

Update I have the probe working now!!! Hooray!

The iPhone project will enter final testing now, get a few more optimizations (Although it seems to be running very close to full speed to me).  I'll then submit it to the App store for the general public, and release the source for the iPhone developers amongst you.

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...)

Make sure you put InitPNG() somewhere...  my guess is that is what is missing.  If you don't the structure that holds all the function pointers for loading a PNG never gets filled, and the app will crash on the first PNG it tries to load.  I think I haphazardly just stuck it as the first line in LoadPNG() but it probably should be put somewhere better.

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.

Nice to see this, the iPhone port if it appears in the apple store might attract a lot of new players to UQM and the Star Control Universe :)

Good news!  This took me days to figure out, but at least it seems that that the iPhone version of SDL_Image was derrived from the same poor implementation as the OSX version.  Loading the PNG as a CGImage is much faster, and complements the platform, but for implementations that rely on palette swaps it won't do.

Yay!! I'm thrilled to hear this, and can't qait to get my hands on this Iphone version :) How about releasing the version for testing on Cydia? Would allow you to receive valuable feedback, and it's free of cost (unlike submitting to the App store, AFAIK).

Paul has an I-Phone (I use a Blackberry).  He would love to see something when it's available (paul@toysforbob.com or fred@toysforbob.com).

Dogar and Kazon are watching!

Congrats! I am firing up XCode with iPhone SDK right now...  :D
SDL_image 1.2.8 framework is indeed broken on Apple's OSes as far as UQM is concerned. They use Apple's ImageIO framework to load PNGs which nukes the palettes. You can grab the pre-built 1.2.7 framework from libsdl.org -- that one works OK (I haven't checked if they have a 1.2.7 iPhone framework though).
Other than that, could you send us a patch, a diff, or anything that would show what you had to change to get it working? What was the problem with the Ur-Quan probe?

That is odd, because in 0.6.2 BYTE is typedef'ed the following way:
Are you sure you are using the 0.6.2 sources?

I can probably help getting it to run faster if you tell me where the problems are. If libogg is too slow (not sure if iPhone has decent floating-point support), you can try Tremor (http://"http://wiki.xiph.org/index.php/Tremor"). Some optimizations would probably have to be done in SDL, rather than UQM code.

Fantastic news and nice work!  This has always been at the top of my list of games that I would have loved to see ported to a mobile platform.

Out of curiosity, how difficult do you think it would be to adapt the standalone melee to be a PvP over wireless, bluetooth or a full-up internet client/server connection?  I think it could take off in a big, big way.

Some answers to the questions...

The first released version won't include networked play... but I do plan to include that in a future version if this release is successful enough to warrant it.  The iPhone networking features are more than robust enough to port that part of the game over.

The probe wasn't spawning because of a silly mistake on my part.  When I first grabbed the source and tried to compile it all for the iPhone, a lot of stuff wasn't compiling correctly.  I decided to just comment out the bits that weren't working at first to see if I could get the screen to come up at all.  Once I had worked out all the problems there were a couple of areas I forgot to comment back in.  One was an init function for the probe, and the other was the music for the intro.  When I found these and re-enabled them the game started working correctly.

The game is just about complete now, tons of optimizations in the SDL and Audio layers had to be done.  The framerate  on a 3G is still not ideal, 3GS works fine. Both are certainly playable.  There are two control schemes in place that are configured using the in-game menu.  Both use three buttons, labeled A,B,and C on the right side of the screen.  Directional control is either simulated buttons (think d-pad), or a simulated analog controller (Think joystick).  The analog controller works by detecting where you first touch, and then the movement vector is determined by how far you slide your finger from the center.  This has proven to be better (for me at least) for the melee fights, as the buttons just weren't fast enough and I was getting owned.

I also added an autosave feature which will save your game automatically if the device exits the game for whatever reason.  Typically this is because of a phone call.  Autosaves always store in slot 0, and you cannot save over them.

Most of the other menu settings have been disabled, as keys are not configurable, and the graphics options can't change as they have been greatly optimized for the device as-is.

There are a couple of issues I still have to look in to.  You can't start a battle in Super-Melee for some reason... none of the buttons work when you select Battle, and if you attemt to change the pilot or ships name the controls don't work right, things go a little nuts and you end up with a ship named "RRRRRRRZG".  Nothing too tragic.

The web site for the port is almost ready, I'll post an announcement here when it's all set.

Cupcakus -- hope everything is going well and that you're close to submitting this one. I'd love to be able to play UQM/SC2 on the go with a touchscreen.

Any good news there?  ::) its been over two years  :-[ i've found this site which i suppose has something to do with this project
http://darkquadrant.co.uk/ (http://darkquadrant.co.uk/)

Dark Quadrant is actually something else entirely. The main dev for that project posts stuff at the SCDB every so often, so you can find out more here (http://www.star-control.com/community/viewtopic.php?f=9&t=287) and in various other topics in the forum's "mods and fan projects" section.

Any news on an iOS release??

Note that Apple has banned GPL applications from the App Store (http://www.zdnet.com/blog/open-source/no-gpl-apps-for-apples-app-store/8046 (http://www.zdnet.com/blog/open-source/no-gpl-apps-for-apples-app-store/8046)).

Note that the last time we heard anything from the developer of this project was over a year before that article you linked was posted.  Even if it would have been a concern to him, it hadn't happened at the time he was discussing the idea in this thread.  Plus, I suspect the biggest reason Apple pulled the particular GPL program that article is discussing was probably because the author sent them a C&D, so they, y'know, C'd & D'd.  I don't personally have any GPL apps lying around to submit just to see if Apple would ban them up front, but it wouldn't surprise me in the least if they're only too happy to distribute new GPL stuff as long as no one complains about it.

This iPhone port has been dead for a long, long time - speaking as one who has scoured the web looking for a working copy of the program, mind you.  There's nothing left here but shattered hopes and broken dreams. =(

My comment was mainly for the benefit of people wondering about the prospect of an iPhone port; a warning that it would probably be prudent to check into Apple's license policy ahead of time.  If they do allow GPL apps, great.  But it would really suck to do all the work for a port, only to have it get rejected due to the license.

Frotz is still in the app store, and it's GPL.

Keep going with that Apple port! Follow this link for someone who will host all apps. The port looks impressive!             http://thebigboss.org/hosting-repository-cydia