|
Pages: [1] 2
|
 |
|
Author
|
Topic: Has anyone considered a Palm OS port of UQM? (Read 5379 times)
|
NamelessPlayer
*Many bubbles*
 Offline
Posts: 104
|
The PSP has a port. So does the GP2X. And then the Windows Mobile-based Pocket PCs have one, if I'm not mistaken.
So why don't Palm OS 5 devices get some SC2 goodness? They have somewhat-fast ARM CPUs, ranging from the up-to-180 MHz OMAP CPUs in the Tungsten E, T, and T2, while the rest of the Palms(including the Treo 650 and later)have XScale CPUs that can overclock to around 600 MHz, or so I've heard. (Sadly, the only Palm OS 5 device I have access to is my friend's Tungsten E, and it may not have the power to run UQM.) There's also the Tapwave Zodiac, which has a fairly-weak CPU clocked at around 200 MHz(maybe more, maybe less), but it's equipped with a 2D graphics accelerator that can be put to good use. Most of them also have 320x320 or larger screens, so re-sizing the screens should be no problem.
There are a few problems, though:
-For starters, UQM is designed to run on x86-based hardware, not devices with ARM CPUs. Much of the code will likely require an overhaul.
-The older OMAP-based Palms may not have the brunt to run UQM, and the newer ones might require ridiculous overclocks that drain the battery quickly.
I don't have the skills to make such a port, but I would like to at least discuss the possibility.
|
|
|
|
|
Logged
|
|
|
|
|
|
NamelessPlayer
*Many bubbles*
Offline
Posts: 104
|
I guess I'd better learn how to program for the things, then. I've got to have some sort of portable SC2 fix! (It'll also get other people hooked on SC2, which can only be for the better.)
To possibly ease my work a bit, doesn't the GP2X have ARM CPUs like Palm OS 5 devices? Would that ease the effort involved in a Palm port by using the ARM code as a base, or would it be better off to start from scratch with the x86 code as the base?
|
|
|
|
|
Logged
|
|
|
|
|
|
NamelessPlayer
*Many bubbles*
Offline
Posts: 104
|
Looks like the SDL thing will be a problem, as it appears that many people have attempted to port SDL to Palm OS 5 and have had difficulties. Palm OS 6 would be easier, but no device on the market uses it-not even the new Treo models!
I'll continue my Googling for a bit to see if I strike gold. If not...well, I guess I've got even more work cut out for me. However, this just might lead to a performance increase over having the engine go through SDL and then the OS if I know how to code well enough...
As for other libraries, I've found a GapiDraw library that has Palm OS 5 support. One of its devs claims that it runs circles around SDL in performance.
Discussion in that thread and this one also say that maybe SDL isn't so much the problem as the rest of the code that needs to be modified for the sake of the Palm OS itself.
I suppose I'll start by just trying to get a working port, then making optimizations and such from there. Hell, I might try releasing various versions with different APIs and such to see what works better...
EDIT: I think I've found some sort of SDL implementation for Palm OS...maybe this could be useful in the port's initial stages.
Now if I could just find where to get the GP2X version's source code...
|
|
|
|
« Last Edit: December 02, 2006, 07:11:28 am by NamelessPlayer »
|
Logged
|
|
|
|
|
|
NamelessPlayer
*Many bubbles*
Offline
Posts: 104
|
That's one problem solved.
Right now, I'm looking through some "*.c" files in the src folder with WordPad. I'm not quite sure what to change at the moment.
As far as the SDL port source I snagged off of the SuperWaba site I linked earlier is concerned, I'm not sure how to go about getting some compiled library files out of it. I also can't figure out what part of the SuperWaba VM has the SDL port already compiled. I might be better off figuring out how to rip out all of the SDL code and using something else...
I would also like to know what files had to be altered to make the PC-to-GP2X port possible, so that I don't go off altering what I don't need to. (Of course, I'll probably have to change much more in order to get this thing working properly on a Palm OS 5 device, but it helps to have a starting point.)
I'll install the Palm OS development tools tomorrow and tinker around with it a bit to see what compiles and what doesn't.
|
|
|
|
|
Logged
|
|
|
|
meep-eep
Forum Admin
Enlightened
Offline
Posts: 2847
|
I think you're missing the point of a library such as SDL. It hides the system specifics and provides a platform-independant layer. So the application programmer only has to code for SDL, instead of for each specific platform.
So if you have a port of SDL for some platform, the largest part of the port to that platform is done.
Now, if SDL isn't available for some platform, you can do what you're suggesting, that is, rip out SDL, and replace the SDL calls in the application by native calls. You'd have to modify each instance of every SDL function call, and the result is a hugely different code from the base code of the application, so if a new version of the application is released, you'll have more work to do.
Or, you could port SDL to the new platform (or at least the parts of it that you need). You'd only have to implement each function once, and the application code remains unchanged, so there won't be any more work when a new version of the application is released. On top of that, other people who want to port their own SDL applications to your platform can use your SDL port.
It should be clear that the latter is much preferable.
Once you've got an SDL port for your platform, what's left to do is to adapt the code to the system specifics that cannot be hidden by a library, such as the size of the screen, or how much memory and disk space are available[1].
[1] Ok, if you really want to, you can hide available system memory by using swap.
|
|
|
|
|
Logged
|
“When Juffo-Wup is complete
when at last there is no Void, no Non
when the Creators return
then we can finally rest.”
|
|
|
NamelessPlayer
*Many bubbles*
Offline
Posts: 104
|
I've made some progress and figured out that cygwin is key to compiling this SDL port.
The problem is, it doesn't seem to want to.
After getting some additional files for cygwin and running the autogen.sh command in the libpalm-posix folder that came with the SDL port files, I try running this command as the readme says:
$ ./configure --host=arm-elf --with-palmdev-prefix=<PalmOS SDK root> --prefix=/usr/local/arm-elf
I replace the "PalmOS SDK root" part as needed. And what do I get?
bash: --prefix=/usr/local/arm-elf/: No such file or directory
I guess I'll try deleting that bit, but then I get this:
bash: syntax error near unexpected token 'newline'
This is getting to be a serious pain in the ass, one that I don't know how to rectify.
At least when I get this damn code in library form, it shouldn't be too much work to make a project out of the existing source code since it turns out that my Palm OS IDE uses C.
...Hey, wait a minute! I figured out the answer! Turns out I was leaving the "<" and the ">" in my command line, and that screws everything up. Remove them while retaining the correct path, and PROFIT!
...Until I tried make. And then it errored out. I think it's because I'm using GNUARM 4.x instead of 3.4, and the readme says that the source doesn't support gcc 4.0. To make matters worse, gnuarm.org does NOT have the 3.4 toolchain, and that was the latest source code I could find.
I'm currently Googling for it, but I would appreciate it if someone assisted me with this little problem...
Actually, forget that. I found it. Now, to get this all working...For starters, this version came in a .tar.bz2 file rather than an install .exe. I have no idea where to put the files...
I think I've gotten somewhere by punching in ./configure --prefix=/usr/local/gcc and then make, but after spitting out random gibberish for several minutes, all I get is this:
make: *** [all-gcc] Error 2
I'd never figured it would be this difficult just to get a library to compile...
|
|
|
|
« Last Edit: December 08, 2006, 04:57:57 am by NamelessPlayer »
|
Logged
|
|
|
|
|
|
NamelessPlayer
*Many bubbles*
Offline
Posts: 104
|
To be honest, I'm just looking at what's there, studying it to find out what needs to be changed, and test out the changes.
Maybe I don't know what I'm doing, or maybe I'm going off in the wrong direction, but damn it, I want UQM on Palm OS, and if no one else is going to do it, I'll find a way!
|
|
|
|
|
Logged
|
|
|
|
|
|
|
|
NamelessPlayer
*Many bubbles*
Offline
Posts: 104
|
Looks like I've got even more of a problem.
Just when I think I have a SDL port for Palm OS, this thread mentions that only the graphics component of SuperWaba's SDL is ported.
Guess this means that I'll have to rip out all of those SDL calls and code in favor of another API, then...The only problem is that I don't know of any special sound and input APIs for Palm OS, which means that I might not even have the benefit of an API and have to code everything myself!
In that case, such a port probably won't come for a while. I have school to tend to, after all.
|
|
|
|
|
Logged
|
|
|
|
|
|
|
Pages: [1] 2
|
|
|
|
|
