The Ur-Quan Masters Home Page Welcome, Guest. Please login or register.
Did you miss your activation email?
October 17, 2019, 10:40:05 pm
Home Help Search Login Register
News: Paul & Fred have reached a settlement with Stardock!

+  The Ur-Quan Masters Discussion Forum
|-+  The Ur-Quan Masters Re-Release
| |-+  Technical Issues (Moderator: Death 999)
| | |-+  Sony PSP port?
« previous next »
Pages: 1 [2] 3 4 ... 7 Print
Author Topic: Sony PSP port?  (Read 57189 times)
cooleyandy
Zebranky food
*
Offline Offline

Posts: 10



View Profile
Re: Sony PSP port?
« Reply #15 on: December 17, 2005, 10:53:56 pm »

right, but I'm cross compiling for the psp platform. Using build.sh uqm initiates a compilation for my machine (cygwin).
Logged
meep-eep
Forum Admin
Enlightened
*****
Offline Offline

Posts: 2847



View Profile
Re: Sony PSP port?
« Reply #16 on: December 18, 2005, 01:12:27 am »

The file build/unix/README.crossbuild should contain all the info you need.
Logged

“When Juffo-Wup is complete
when at last there is no Void, no Non
when the Creators return
then we can finally rest.”
cooleyandy
Zebranky food
*
Offline Offline

Posts: 10



View Profile
Re: Sony PSP port?
« Reply #17 on: December 18, 2005, 01:34:20 am »

yea, I should have gotten my lazy butt to do more research before saying anything. I'll get on it now.
« Last Edit: December 18, 2005, 01:56:55 am by cooleyandy » Logged
cooleyandy
Zebranky food
*
Offline Offline

Posts: 10



View Profile
Re: Sony PSP port?
« Reply #18 on: December 20, 2005, 02:02:39 am »

I'm currently using the 0.4 build that is available in the ur-quan masters web page (not cvs).
After much modifying to the CFLAGS, LDFLAGS, PKGconfig, and then modifying the config_unix.h and build.vars, I was able to get it to compile successfully. However I ran into some initial problems.

One was:
    Warning: could no mount 'uqm-04.0-3domusic.zip'; No such device
    Warning: could no mount 'uqm-04.0-content.zip'; No such device
    Warning: could no mount 'uqm-04.0-voice.zip'; No such device

I read from another post that this is because zip mounting was not supported in an earlier version.
The version I've downloaded was from http://sc2.sourceforge.net/downloads.php. I'm just wondering if
there was no zip support in that version or probably something wrong on my end.

Also, another error came about...
 
   Fatal errror: Couldn't mount temp dir 'temp/43a744ef': No such file or directory.

I've checked and found the directory not to be found anywhere, so it could have been a directory creation problem.
In case this helps, this is what i use in config_unix.h

/* Directory where the UQM game data is located */
/* #define CONTENTDIR "/uqm/content" */
#define CONTENTDIR "/psp/game/uqm/content"

/* Directory where game data will be stored */
/* #define USERDIR "~/.uqm/" */
#define USERDIR "/psp/game/uqm/config"

/* Directory where config files will be stored */
#define CONFIGDIR USERDIR

/* Directory where supermelee teams will be stored */
/* #define MELEEDIR "${UQM_CONFIG_DIR}teams/" */
#define MELEEDIR "/psp/game/uqm/config/teams"

/* Directory where save games will be stored */
/* #define SAVEDIR "${UQM_CONFIG_DIR}save/" */
#define SAVEDIR "/psp/game/uqm/config/save"


I'm suspecting both of these problems are related to the unofficial psp sdk, but if you have any insights to the problem, help is much appreciated.

* I've also tried downloading a recent build from cvs (via the web interface) and tried to build it using the same settings and have gotten the error :

Fatal: $MENU_debug_ITEM_graphics_TYPE is not defined!

Any ideas of this also?


P.S.  I've spent some hrs porting OpenAL and then found out I didn't need it to compile :-p, aww well. I'm secretly hoping someone would finish the porting before I do so I can play soon :-)  Never finished the game because I deleted the pc version by accident.
Logged
meep-eep
Forum Admin
Enlightened
*****
Offline Offline

Posts: 2847



View Profile
Re: Sony PSP port?
« Reply #19 on: December 20, 2005, 05:52:57 am »

The "no such device" errors are caused by .zip support not being included in your executable. The 0.4 source does support it, but it looks like it wasn't activated in the executable for you.
When you ran "./build.sh uqm config" (or just "./build.sh uqm" from a fresh source), you have an option "Supported file i/o methods".  It should be set to "Direct & .zip file i/o". Note that you can only use this setting if build.sh can find zlib.

I'd also advice you to work from the CVS version. There are some bug fixes and changes that will make your life a lot easier.

The menu item error is an indication that some of your files in build/unix/ are of a different version than others. If you're going to work from CVS, download your files with an actual CVS client, not through the web interface. Or you can download a cvs snapshot from http://uqm.stack.nl/files/snapshots.

As for OpenAL, perhaps you'll make someone else happy with your port.
Logged

“When Juffo-Wup is complete
when at last there is no Void, no Non
when the Creators return
then we can finally rest.”
Xeno
Guest


Email
Re: Sony PSP port?
« Reply #20 on: December 28, 2005, 04:38:25 pm »

I'm very happy to see someone is working on a PSP port. Thanks for your hard work! If there is anything a non-coder can help with.. Let me know Smiley
Logged
Serosis
Enlightened
*****
Offline Offline

Gender: Male
Posts: 1315



View Profile WWW
Re: Sony PSP port?
« Reply #21 on: December 30, 2005, 12:19:33 am »

i would love to see this topic show up on the ZSNES forums Grin

Unfortunately ZSNES in its current state will never be ported to the PSP (or to any gaming platform except perhaps the XBox) due to its reliance on Intel assembly code.

The assembly code would have to be ported to C (which would kill low-end system speed which is what ZSNES has always been about), or to platform-specific assembly (which takes a lot of patience and man-hours).

it was a joke, because anybody who asks to have the program ported to psp usually gets flamed to hell.
Logged

The artist formerly known as Kohr-Ah Death.

Get your MegaMod HERE
cooleyandy
Zebranky food
*
Offline Offline

Posts: 10



View Profile
Re: Sony PSP port?
« Reply #22 on: January 02, 2006, 06:06:22 am »

I'm not sure how Jimparis's build goes, but so far I've hit a stump and that is memory. The psp has around ~20-22 MBs of user memory available. I've read from the sc2 faq that the memory footprint is around 30MBs. Is there anything I can easily modify to lower the memory footprint?
Logged
meep-eep
Forum Admin
Enlightened
*****
Offline Offline

Posts: 2847



View Profile
Re: Sony PSP port?
« Reply #23 on: January 02, 2006, 06:42:46 am »

There's probably a lot of room for improvement. The original PC and 3DO code would unload resources when they are no longer needed, to reload them when they are needed again.I think that currently many resources are kept in memory once they have been loaded. The resource and memory management is something which we intend to redo in the future. But that's not the easy fix you're looking for.

I think the number in the FAQ is a bit on the large size; with a normal debug build, UQM's resident memory usage on this Linux PC I'm typing on gets no larger than 20MB (and the kernel may be able to swap out more if it has a reason).

Also, that number may have been based on a similar debug build and an SDL and SDL_image with many features. So if you build UQM and its dependencies without debugging info, and compile SDL with only the specific drivers you will be using, and SDL_image with only .png support, you could get a long way. (Although I think SDL loads a lot of stuff dynamically).
Logged

“When Juffo-Wup is complete
when at last there is no Void, no Non
when the Creators return
then we can finally rest.”
jimparis
Zebranky food
*
Offline Offline

Posts: 16



View Profile
Re: Sony PSP port?
« Reply #24 on: January 02, 2006, 05:59:36 pm »

Hi cooleyandy,
Glad to see someone else working on this.  I can certainly share my code with you if you'd like; no reason to duplicate effort.  Send an e-mail and I'll give you access to my svn repository.  I personally still won't have a chance to work on this until later in the month at the earliest.  Most of the work that I did was to fix up the pspsdk and SDL port, as I mentioned, so you should hopefully have found that the UQM code just works with only minor build changes.  As for RAM, I did get a crash when exploring a planet that I assumed was memory-related, but didn't explore it further.  I was hoping it was just a simple fix like removing the rotating planet animation.  One problem that I was seeing is that zipped content is preferable on the memory stick (due to small files and a large FAT cluster size), but the frequent unbuffered seeks and small reads in the zip are a killer for performance and it's very slow.  Perhaps a buffering layer would be useful, at least for the zipfile directory.
Logged
meep-eep
Forum Admin
Enlightened
*****
Offline Offline

Posts: 2847



View Profile
Re: Sony PSP port?
« Reply #25 on: January 02, 2006, 07:20:36 pm »

A few comments:
  • reading is buffered. Buffers of 1K are used, but you can change uio_Stream_BLOCK_SIZE in src/sc2code/libs/uio/uiostream.c if you want larger buffers.
  • no seeking within compressed data is done. And seeking within a single file is a much cheaper operation than opening files. Even more so when you can do random access. And a memory stick is RAM, after all.
  • when using a CD-ROM, using zipped content is actually very noticably faster, because it takes less time to decompress than it would take to read the extra bytes. I wouldn't be surprised if using compression would turn out to be cheaper for USB memory sticks too (although it may not be as noticable).

I don't know why reading from .zip files would be so slow for you. You're not repacking the .uqm zip files, are you? The ones provided by us have the .ogg files stored uncompressed. Working with "compressed" .ogg would be a slowdown (and pointless). That's even very noticable on "normal" PCs. Supply '-n .ogg' to zip to tell it to store .ogg files uncompressed, and supply '-8' for maximum compression while you're at it (not '-9', as zip would ignore the '-n' flag in that case). Use 'zipinfo' or 'unzip -v -l' the check the zip files.
Logged

“When Juffo-Wup is complete
when at last there is no Void, no Non
when the Creators return
then we can finally rest.”
jimparis
Zebranky food
*
Offline Offline

Posts: 16



View Profile
Re: Sony PSP port?
« Reply #26 on: January 02, 2006, 08:44:33 pm »

no seeking within compressed data is done. And seeking within a single file is a much cheaper operation than opening files. Even more so when you can do random access. And a memory stick is RAM, after all.

The zip contains a ton of tiny files.  Every time UQM tries to open or read from one, it seeks at least to the centeral zipfile directory at the end, then back to where the actual file is.  Individual files may be buffered from UQM's point of view, but it's the initial finding and getting those files out of the zipfile that appears to be taking so much time.  I agree that using non-zipped content would only be worse in that regard.

The memory stick isn't really RAM.  It's accessed serially, and more like a disk in that sequential access is faster than having to keep changing the address (from what I understand from publically available info out there).  On the PSP in particular, benchmarks show that reading in large blocks (at least 64k) is important for getting decent performance.

Quote
when using a CD-ROM, using zipped content is actually very noticably faster, because it takes less time to decompress than it would take to read the extra bytes.

But now you're talking about a system where the OS provides a generous page cache that will easily retain things like the zipfile directory, and coalesce lots of small requests into larger ones before sending them to the hardware.  The PSP OS has nothing like that, and I think that's the real source of the performance difference here.  A user-level version of a buffer cache like this is exactly what I'm proposing.

Quote
The ones provided by us have the .ogg files stored uncompressed.

I haven't touched oggs yet.  I was seeing times of something like 1-2 minutes just to get past the initial splash screen, almost entirely due to I/O.  Working on this was going to be my next goal once I have time.
« Last Edit: January 02, 2006, 09:01:07 pm by jimparis » Logged
cooleyandy
Zebranky food
*
Offline Offline

Posts: 10



View Profile
Re: Sony PSP port?
« Reply #27 on: January 02, 2006, 11:44:08 pm »

Jimparis, my email is cooleyandy at hotmail.com
The latest cvs version of UQM has support for libTremor. I'll take a look into that as a replacement for libogg.
Can't wait to get this game working. I just love the pc version.

Great work on getting homebrew running on 2.01+ firmwares btw.
Logged
meep-eep
Forum Admin
Enlightened
*****
Offline Offline

Posts: 2847



View Profile
Re: Sony PSP port?
« Reply #28 on: January 03, 2006, 12:38:21 am »

no seeking within compressed data is done. And seeking within a single file is a much cheaper operation than opening files. Even more so when you can do random access. And a memory stick is RAM, after all.
The zip contains a ton of tiny files.  Every time UQM tries to open or read from one, it seeks at least to the centeral zipfile directory at the end, then back to where the actual file is.
Not true. UQM reads the central directory at startup, and it will never need to read it again.

Quote
Individual files may be buffered from UQM's point of view, but it's the initial finding and getting those files out of the zipfile that appears to be taking so much time.
UQM never reads from more than one file at once. So opening a file means a single seek. Then everything is read in sequence. (Unless you rewind an .ogg speech).

Quote
The memory stick isn't really RAM.  It's accessed serially, and more like a disk in that sequential access is faster than having to keep changing the address (from what I understand from publically available info out there).
If it has a constant seek time, I call it random access. I don't expect that seeking is the problem. Reading in short blocks however sounds like a good reason. If the OS doesn't read in pages at a time, each read would mean a new request.

Quote
On the PSP in particular, benchmarks show that reading in large blocks (at least 64k) is important for getting decent performance.
Do you have an URL to those benchmarks?
64k sounds like rather a lot to me btw.

Quote
Quote
when using a CD-ROM, using zipped content is actually very noticably faster, because it takes less time to decompress than it would take to read the extra bytes.
But now you're talking about a system where the OS provides a generous page cache that will easily retain things like the zipfile directory, and coalesce lots of small requests into larger ones before sending them to the hardware.  The PSP OS has nothing like that, and I think that's the real source of the performance difference here.  A user-level version of a buffer cache like this is exactly what I'm proposing.
There's a separate buffer for the decompression, 64k in size. Reading files shouldn't be a problem.
I do however have an idea where the performance problems may be coming from (see below).

Quote
Quote
The ones provided by us have the .ogg files stored uncompressed.
I haven't touched oggs yet.  I was seeing times of something like 1-2 minutes just to get past the initial splash screen, almost entirely due to I/O.  Working on this was going to be my next goal once I have time.
Do you have console output? Is the delay right at the start or is it spread over all files?

While there shouldn't be any short (low level) reads for reading files, there are quite a lot of them when the zip file is mounted, when the central directory is read in.
I actually have a todo remark somewhere to add read-ahead buffering. I'll see if I can do that somewhere in the next few days. It shouldn't take much time.

Does the PSP have memory mapped IO btw? In that case there would be room for even more optimisation.

Logged

“When Juffo-Wup is complete
when at last there is no Void, no Non
when the Creators return
then we can finally rest.”
cooleyandy
Zebranky food
*
Offline Offline

Posts: 10



View Profile
Re: Sony PSP port?
« Reply #29 on: January 03, 2006, 01:09:20 am »

no memory mapped io. The memory stick is treated as just a disk io. The psp does not have a memory manager.
Logged
Pages: 1 [2] 3 4 ... 7 Print 
« previous next »
Jump to:  


Login with username, password and session length

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!