|
Pages: 1 ... 4 5 [6] 7
|
 |
|
Author
|
Topic: Sony PSP port? (Read 63994 times)
|
Michael Martin
Core Team
*Smell* controller
 Offline
Posts: 387
|
What kind of tricks were necessary? Just linking against Tremor instead and such, or did you need to tweak the configuration some way?
|
|
|
|
|
Logged
|
|
|
|
Fedor
Zebranky food
Offline
Posts: 3
|
My daughter is kinda testing the game at the moment.... I will release patch soon. If there will be people who are interested.
|
|
|
|
« Last Edit: February 05, 2008, 11:57:14 am by Fedor »
|
Logged
|
|
|
|
Daveman
Zebranky food
Offline
Posts: 2
|
AWESOME NEWS DUDE! Oh man thats awesome. Please release a download soon so i can help test it out 
|
|
|
|
|
Logged
|
|
|
|
zefrench
Zebranky food
Offline
Posts: 5
|
Strong interest in seeing this port release on my part. I cannot wait for updates.
|
|
|
|
|
Logged
|
|
|
|
RAFFI
Zebranky food
Offline
Posts: 1
|
Fedor i would be very interested in testing the new PSP version you have as well. 
|
|
|
|
|
Logged
|
|
|
|
NamelessPlayer
*Many bubbles*
Offline
Posts: 104
|
I just got my PSP Slim from eBay today (it was a used Daxter bundle, and while the PSP itself has numerous scrapes and wear marks, it functions perfectly and cost me 45 US$ less than new). I'm looking forward to running UQM on it (especially since my hx4700 is my last WM device and its controls are very unsuitable for a game like UQM), though I'll need custom firmware first (the memory stick should be magic now; I just need a Pandora/tool/JigKick battery, and I don't want to hardmod my existing battery).
It's been several months since this refined UQM port was mentioned...I hope it's been released somewhere. (I especially hope that I can just drop it in the MS and fire it up in 3.90 M33 without much fuss...)
|
|
|
|
|
Logged
|
|
|
|
ryantanchan
Zebranky food
Offline
Posts: 2
|
is it easy to play UQM in a psp w/o experience in coding?
|
|
|
|
|
Logged
|
|
|
|
Jinx1337
Zebranky food
Offline
Posts: 1
|
BUMP! BUMP! BUMP!
Fedorus, what happened? Are you alive?  Your post dates back to February, no updates? No releases?
Hope the guy's ok.
Please reply. Him or anyone who could update Sharkus's version of UQM-PSP.
---
As for the previous poster's question:
Yes, it is.
Though right the only version playable is the one made by Sharkus and it only works on 1.5 (on PSP SLIM you'd have to use DA's TIME MACHINE).
Grab it here.
http://www.dcemu.co.uk/vbulletin/showthread.php?s=&threadid=20763
Newer gamefiles work with the release as well, just rename them to 0.5.0. Hell, even the remixed OST works .
|
|
|
|
|
Logged
|
|
|
|
|
|
sharkus
Zebranky food
Offline
Posts: 15
|
I got bored on a long flight to Japan and updated my old patches for 0.5.0 to 0.6.2 with support for the new firmware revs. I might spend a bit more time getting OpenGL to work (since that is new and interesting to me). You can grab it here (patch file with source changes are included in zip file):
http://www.dcemu.co.uk/vbulletin/showthread.php?t=20763
Thanks again to the UQM team!
-Sharkus
P.S. (Sorry about the hacked and slashed makefile.)
|
|
|
|
|
Logged
|
|
|
|
sharkus
Zebranky food
Offline
Posts: 15
|
Hi Meep-eep,
I just read your post carefully and see that you made some speed improvements in the SVN version. Originally I thought it meant the latest release version (i.e. 0.6.2)... Unfortunately, I just finished wading through the code and making my own. I was able to bring down the startup time from well over 1.5 minutes to under 20 seconds...
Here's a summary of what I did:
1. When using central headers do not read local headers when performing stat operations.
2. Updated fileblock.c with some caching functions.
3. Only read zip data (including local headers) one time, and keep it in the fileblock object.
4. No longer use zip_INPUT_BUFFER_SIZE, and instead use the compressed size to determine how much data to read.
My changes are included in diff form in the release zip posted in the thread above. Let me know if you want to take a look at them and I can send you the source directly.
Also, I was able to get OpenGL working under the PSP (required a couple minor changes, also included in diff file), but it is really slow, so I don't include it in my build.
-Sharkus
|
|
|
|
|
Logged
|
|
|
|
meep-eep
Forum Admin
Enlightened
Offline
Posts: 2847
|
I created the uio library from scratch, and I want to be able to use it in other projects, including non-GPL projects. So for copyright reasons, I can't even look at your changes (unless you were to agree that I can use and keep using your changes as if they were my own).
That said, if these modifications you made are worth the effort, I might reimplement them myself. I'll comment a bit on all of them:
1. The central headers don't contain all of the information which stat() returns, so this wouldn't be a general solution. But UQM isn't interested in most of that information, so I guess I could make it a compile-time option. An alternative would be to add separate uio_filesize() and uio_access() functions, as those are all what stat() is used for in UQM. I don't think this change wins you anything significant though, as the use of stat() in UQM will usually (always?) precede the use of open(), which needs the local header information anyhow. That said, there will be very little work involved to make this change, so if there is any noticable gain, it's probably worth the effort to make that change.
2. This is what I did in my own speed improvements, which are in SVN. I expect that this change accounts for most of your speed gain. It drastically reduces the amount of short reads.
3. Are you talking about the metadata? That is already only read once, if I recall correctly. If you're also talking about the actual compressed data, that would make 2 pointless. (Or, if you wish, 2 makes 3 pointless; at any rate, doing both only increases your memory usage).
4. I don't think that this will win you much when 2 is in place, but it will cost a lot in terms of memory usage.
I would be interested in seeing what kind of times you get if you just use the SVN version of uio.
The OpenGL fixes are probably good for inclusion in UQM. Could you send me that in a separate patch? Or better yet, put it in Bugzilla?
|
|
|
|
|
Logged
|
“When Juffo-Wup is complete
when at last there is no Void, no Non
when the Creators return
then we can finally rest.”
|
|
|
sharkus
Zebranky food
Offline
Posts: 15
|
Hi Meep-eep,
Bugzilla submitted for the OpenGL fix.
In regards to performance... I actually implemented the cache functionality initially, including sequential read ahead, partial hit detection, etc. Surprisingly, it did very little to improve the performance, and actually hurt in some cases. The real performance gains came from making sure data is read once and only once (including local headers) across the entire stat, open, and read sequence, and that reading extra data is completely eliminated (i.e. intelligently only read what is needed based upon compressed file size, and avoid hard coded buffer sizes). In the end, I removed pretty much all of the fancy cache stuff as it was overkill and not required once the efficiency issues where addressed.
I must say that there was quite a bit of code to weed through... The codebase must look a lot different today than when this game was running on the 3DO.
-Sharkus
|
|
|
|
|
Logged
|
|
|
|
meep-eep
Forum Admin
Enlightened
Offline
Posts: 2847
|
The real performance gains came from making sure data is read once and only once (including local headers) across the entire stat, open, and read sequence, and that reading extra data is completely eliminated (i.e. intelligently only read what is needed based upon compressed file size, and avoid hard coded buffer sizes). In the end, I removed pretty much all of the fancy cache stuff as it was overkill and not required once the efficiency issues where addressed. I'm pretty sure that all meta-data is only read once as it is, in 0.6.2. And I think that the same holds for other data, although that depends on other parts of the UQM source.
And UQM in 0.6.2 doesn't pre-buffer; the hard-coded buffer sizes only offer an upper limit to the amount read in one go. There is no extra data read. The SVN version does pre-buffer, but only based on hints given, based on the size of the data needed. So there's no extra data read there either.
Have you tried uio as it is in SVN? If not, could you please do so, and tell me what the effect on performance is?
Edit: I don't see your bug report in Bugzilla.
|
|
|
|
« Last Edit: November 01, 2008, 08:59:34 pm by meep-eep »
|
Logged
|
“When Juffo-Wup is complete
when at last there is no Void, no Non
when the Creators return
then we can finally rest.”
|
|
|
sharkus
Zebranky food
Offline
Posts: 15
|
That's strange. My wife was rushing me off to a soccer game so I must have clicked the wrong button. The change is pretty minor:
Just change the first GL_RGB to be RGBA in the following function call (OpenGL ES specified that both formats must match when calling this function):
original:
glTexImage2D (GL_TEXTURE_2D, 0, GL_RGB, texture_width, texture_height,
0, GL_RGBA, GL_UNSIGNED_BYTE, 0);
fixed for PSP:
glTexImage2D (GL_TEXTURE_2D, 0, GL_RGBA, texture_width, texture_height,
0, GL_RGBA, GL_UNSIGNED_BYTE, 0);
I also hard coded the ActualScreenSize to be 480x272 for proper full-screen operation.
Here are the benchmark results. However, I only updated zip.x and fileblock.x from SVN into my 0.6.2 build, so if there were other modules in SVN that would have an effect on performance they were not tested:
PSP Rev 001 (Baseline 0.6.2) - 58 sec
PSP Rev 002 (my zip and fileblock) - 22 sec
PSP Rev 002 (latest SVN zip and fileblock) - 40 sec
-Sharkus
|
|
|
|
|
Logged
|
|
|
|
|
Pages: 1 ... 4 5 [6] 7
|
|
|
|
|
