|
Pages: 1 [2] 3 4 ... 7
|
 |
|
Author
|
Topic: Sony PSP port? (Read 63054 times)
|
cooleyandy
Zebranky food
 Offline
Posts: 10
|
right, but I'm cross compiling for the psp platform. Using build.sh uqm initiates a compilation for my machine (cygwin).
|
|
|
|
|
Logged
|
|
|
|
|
|
cooleyandy
Zebranky food
Offline
Posts: 10
|
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
Posts: 10
|
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
|
|
|
|
|
|
Xeno
Guest
|
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 
|
|
|
|
|
Logged
|
|
|
|
|
|
cooleyandy
Zebranky food
Offline
Posts: 10
|
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
|
|
|
|
|
|
jimparis
Zebranky food
Offline
Posts: 16
|
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
|
|
|
|
|
|
jimparis
Zebranky food
Offline
Posts: 16
|
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.
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.
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
Posts: 10
|
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
Posts: 2847
|
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. 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).
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.
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.
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.
I do however have an idea where the performance problems may be coming from (see below).
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.
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
Posts: 10
|
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
|
|
|
|
|
