MobileInfocenter

Comments on: New Gaming SDK for Palm OS 5 Handhelds

Develant Technologies today released a significant update to their game development platform GapiDraw 3.0. The release adds Palm OS 5 and Tapwave Zodiac support to the GapiDraw platform. The cross platform SDK could bring a large library of quality games to the Palm OS.
Return to Story - Permalink

Article Comments

 (26 comments)

The following comments are owned by whoever posted them. PalmInfocenter is not responsible for them in any way.
Please Login or register here to add your comments.

Comments Closed Comments Closed
This article is no longer accepting new comments.

Down

Game developing needs lots of help

Konstantin @ 5/28/2004 6:11:43 PM #
I think Palm coding community is quite good at coding, but many games lack in certain areas, plot and graphics and AI mainly. Few games that have nice graphics, good plot and this sensation that you are actualy playing a game, and not that you are moving your stylii around the screen of tapping buttons to move sometning around.

Take MicroQuad for example. Graphics are exelent, game engine very good, but has no good plot, computer AI lacks and is unbalanced. One chooses a race and after winning it has to press buttons and use styli to choose the racer and course again and again. Its no fun. Point is to play, not to press many many times and make all the same choices again and again.
It should be like in a real game, take a coup or championship and just drive it trough only pushing a button to slide the results screen and to race again.

RE: Game developing needs lots of help
gmigueis @ 5/29/2004 5:16:26 PM #
Quite! A game is a piece of art, a plot, a whole ambient/world must be created and shown to the gamer in the right way. A piece of art, nuff said!

RE: Game developing needs lots of help
helf @ 5/31/2004 6:25:40 PM #
quite right!

ha, im saying that and my favorite games are zork, MUDS and moria.. :)

Doubt.

gmigueis @ 5/29/2004 5:14:29 PM #
I think Palm OS does not enable playing around with the video memory pointer. Will GAPI allow faster blits?

RE: Doubt.
skeezix @ 5/30/2004 5:46:55 PM #
Palm OS prior to 6 lets you get the pointer to the framebuffer and do whatever you want with it.

jeff

The Shadow knows!

I'm waiting for libSDL

tompi @ 5/29/2004 11:20:12 PM #
LibSDL (libsdl.org) is an open and widely used gaming library that already runs on Windows CE and Symbian. Porting it to POS5 is too much hassle, but as soon as handhelds with POS6 come out, it will probably get ported quickly.

I'm also waiting for libSDL!
Winter_ @ 5/30/2004 3:15:45 PM #
I hear you, brother!

Anyway, I'm very interested on that part about "the hassle of porting to OS 5". Do you have any details? Why a hassle? Do you know of any outstanding troubles when porting existing code to Palm OS? I've wondering lately why there seems to be much more porting going on for PocketPCs than for Palms...

RE: I'm waiting for libSDL
gmigueis @ 5/30/2004 3:40:34 PM #
Porting Win32 stuff to WinCE is easy bacause WinCE is itself a "subset" of Win32 - that's why it is so slow :)

RE: I'm waiting for libSDL
Winter_ @ 5/30/2004 4:40:34 PM #
I found the answer to my own question. Looks like a number of people have been trying to port libSDL to Palm OS... but the common comment is always along the lines of "My opinion is that it could work. But Palm is a sufficiently different platform that you really need to write your entire application with the Palm in mind."

On the other hand, "SDL compiles for WinCE and runs rather nicely in fact. Fullscreen and
windowed video work properly, as does audio. Keyboard support is currently a little buggy last time I checked."

Those are comments from 2001 and 2002. Looks like there is nothing more recent than that.
-------------

Gmigueis, the fact is they even have had GCC ported, which was certainly NOT created on Windows. So they really look like having a quite easier time porting a variety of software.

You seem interested in gaming. Did you know that MAME was ported about 2 (3?) years ago to PocketPC? (and that was not created on Win32, either :P)

RE: I'm waiting for libSDL
skeezix @ 5/30/2004 5:44:38 PM #
They are incorrect; an application written to be portable is different than an application written with desktop assumptions, regardless of the libraries used.

ie: I have built up my own SDK so apps halfway designed to be portable with it will run on windows, mac, unix/linux, palm os and symbian, with one single source base. The desktop sides mostly depend on sdl even.

Building an SDL wrapper for porting SLD based desktop apps to Palm OS is also not hard; ie: Skipping all the stuff few use, so wrapping the blits, timing, inputs.. not hard.

I'd chalk it up to momentum.. no one whose tried to make an SDL port has really wantes ot do it bad enough. I've built a few SDL based apps on Palm OS with not a lot of work. pfah I say ;)

jeff

The Shadow knows!

RE: I'm waiting for libSDL
Winter_ @ 5/30/2004 7:01:51 PM #
Well, at last someone with experience answers... I had been wondering for some time.

But please, explain a little bit more:

You talk about apps being designed for the SDK you have developed yourself. And you seem to say that you use SDL on the desktop but not on the rest of platforms.

...but if that's the case, that leaves us again on the starting point! That's not porting or being portable; that's just avoiding unavailable stuff.

There are programs that take profit of libSDL to be portable; those programas will be usable on WindowsCE / PocketPC and Symbian because libSDL has been ported there too.
But, since there is no port for Palm OS, the program using the lib won't be portable either. (Right?)

an application written to be portable is different than an application written with desktop assumptions, regardless of the libraries used

What do you mean with "desktop assumptions"? And, how does that relate to the libSDL subject? It was created to be portable, and has been ported to other platforms. So why it hasn't been ported to Palm OS?

And, finally, I have to ask again:
MAME has been ported to PocketPC and, I just learnt, to Symbian - and lots of other platforms, of course. So it's portable. Do you mean that it could be "easily" ported to Palm OS?

RE: I'm waiting for libSDL
gmigueis @ 5/30/2004 7:25:36 PM #
An high level language program code is, of course, almost (or fully) portable across the platforms in which it is implemented. The OS API functions used differ greatly from Palm OS to WinCE, I guess. I am also assuming that many Win32 API functions have similar named/similar working functions in WinCE.
Still, it is no big deal to rewrite a few functions to use a certain OS API, high level talking, of course :)

RE: I'm waiting for libSDL
gmigueis @ 5/30/2004 7:31:52 PM #
And I forgot: my iPAQ3970 is slow with the standard applications if compared to my T|T3 or my T|E! Now, talking games, even my PocketPC2002 beats any of the Palms, which I prefer (OK, we have Warfare Incorporated and Magic World as the major samples of Palm OS 5 device's capabilities).
PocketPC platform just has many great titles, damn! ScummVM for WinCE is wonderful, as other emulators must be...

RE: I'm waiting for libSDL
Winter_ @ 5/30/2004 7:57:01 PM #
Gmigueis, not so fast. There seem to be some striking differences with other platforms... like, there is no malloc (!).

Some people seem to make a real stumbling block of that; some other say that "it's not that difficult" to make a substitute out of the memory management facilities available. Would that be a drop-in substitute? I don't know; I plan to try a little programming with the T3 soon, but until then I can only report what I've read.

However, the lack of porting is still there, so making that substitute surely won't be straightforward. Dunno.

I hope the experienced people can inform us a bit...

RE: I'm waiting for libSDL
Winter_ @ 5/30/2004 8:11:36 PM #
I forgot. You keep talking about porting to PocketPC being easy because it's a subset of Win32. I don't know about that; but please remember that I'm talking about non-windows code. There are lots of non-windows apps ported! Even Apache, for Dog's sake! :P

You mention ScummVM. Well, ironically, that's exactly the ONE example I know of open source, portable code that is compilable for Palm OS (pity it won't use sound...does that work on PPC?). I wonder how they managed that. And, more important, why they are the only ones!

RE: I'm waiting for libSDL
gmigueis @ 5/30/2004 9:15:51 PM #
I use ScummVM on Palm OS too, but the programmer of the Palm port certainly had to write many functions from the ground-up.
Malloc: Palm OS has malloc, of course (Memory Manager Functions). It's just not called malloc :)
About porting, again, it's really the question of the used libraries existing in the various platform. If one is not using low-level stuff outside the lib, porting is almost recompile.
I hope Gapi for Palm brings this platform some great titles, because porting will be easier. What I was trying to say is that, even with Gapi, some functions such as malloc (that are "standard" in C for Windows or Unix, perhaps WinCE too - hence my guess that WinCE is a subset of Win32, some functions have the same names and parameters, but it's just my guess :) do have other names and workings with Palm OS. One could have a lib with a "malloc" named function for Palm and that would make code porting even less "boring".
THE point is that porting between this machines is NEVER very hard - they all have input methods, displays, memory, you know :)

RE: I'm waiting for libSDL
Winter_ @ 5/31/2004 3:05:00 AM #
First,
It's just not called malloc
then,
some functions such as malloc do have other names and workings with Palm OS

If it has "other workings", then it's NOT the same function. PERHAPS it's a straightforward substitute, perhaps NOT. I'm trying to get info, no suppositions (as you can see, I can make them myself :P). Do you have any PalmOS programming experience, please?

THE point is that porting between this machines is NEVER very hard - they all have input methods, displays, memory, you know :)

Of course all machines have the same "base capabilities" - kind of. Even more, we all know any Turing machine can act as any other Turing machine. The problem at hand is not that one; it rather is: is it too difficult?

You say "it is not very hard". What does that exactly means? :P Let's say I've seen much more detailed discussions. Look for "Palm" on libsdl.org's forums.

(Precissely, there I found a post by someone saying something akin to what you're saying now, making the subject sound almost easy. Guess what? His last post was on 2001 and never came back... and, of course, libSDL is still not ported to PalmOS. If it's that easy, and since you seem interested, perhaps you should just have a shot at it :P)

RE: I'm waiting for libSDL
Winter_ @ 5/31/2004 3:39:48 AM #
I use ScummVM on Palm OS too, but the programmer of the Palm port certainly had to write many functions from the ground-up

So you're just destroying what I thought was the only example of code portable to Palm OS (among other platforms): in fact it's not a port but a rewrite! - but you still talk about "easy porting"??

If one is not using low-level stuff outside the lib, porting is almost recompile.

Well, you can't get much lower-level than malloc, can you? (barring ASM, that is :P)


RE: I'm waiting for libSDL
skeezix @ 5/31/2004 11:46:37 AM #
Its simple; there are many levels of portability; most peopel haven't written portable apps at all; many peopel do try and write portable applications, and in their minds portability is about Windows versus Unix, say. They don't even think about things like handhelds with small heap memory, different kidsn of storage (non hard drives), small screens, touch screens versus mouse.. to those adventurous few who look into portability, its about endian-ness only, or maybe alignment, or maybe the fact standard-C doesn't include (damnit!) directory operations, so on Windows its FindFirst/fsfirst, on Mac OSX and Unix its opendir(), etc.. they assume regardless of platform, a Mac and a PC both have giant screens.

So porting SDL apps is not just porting SDL; its as above with malloc() (and easy map to MemPtrNew or MemGluePtrNew), the harder part is dealing with the fact its a totally different environment -- In OS5 you don't write a 68k or a ARM app, you write both in one.. it starts as 68k and then goes to PNO/ARM. Thats unheard of in the rtest of the IT industry, and so apps are not written that way. Apps generally assume they can use fopen() to get a file, but on Palm OS and especially in a PNO/ARM, you need to write your own fopen() wrapper to do the job.

So SDL is only one aspect; its the entire rest of it that is the real trouble.

(In repsonse to distant above, that is why my SDK does.. I have a standard set of fucntions across all platforms. It is just imeplemented in libC and SDL on some desktop platforms, and as other native controls on others. Its a lot more than just SDL :)

People write apps in different ways; a stylus is not a mouse and so a lot of the issues with quick ports come there.

As to say MAME, MAME is portable in a sense where it can be compiled for windows, mac, unix, using a pile (a large pile) of OS dependant code that the MAME core hooks into. So to make a Palm OS version, someone has to make the Palm OS dependant code, just liek the Windows dependant code has to be made. Thats not a 1 day job, so no one has bothered to do it. Its a few days job, and the number of people into ARM pno coding is small, and the numebr of peopel into emualtion is small, and trherefore the union of them is smaller still. Its not hard, just a bnit of tedious work someone needs to do. (And not me, I'm already maxxed out if you've seen my project list ;)

Also note the MAME peopel didn't think small platforms or aim for super efficient; ie: Look at the application size on your desktop and see if you want a multi-megabytye application on your handheld. Also note that its designed to run all the thousands of games form one binary, and it doesn't even worry about memoiry.. if you don't have enough memory, buy more it says.

So to make a MAME for handhelds, it needs severe trimming (go see what MAME for Pocket PC *is* ;) .. maybe break it up into a half dozen little-MAMEs, each doing a subset of the supported games, say.

Thats the porting work; GAPI has nothign to do with it. The *APPLICATION* was not deisgned to be ported to tiny environments.

So making a MAME port that *compiles* and maybe could conceivably run the smallest game is not a problem; makign a GOOD PORT (define at your leisure) is work.

jeff

The Shadow knows!

Thanks!!
Winter_ @ 5/31/2004 12:40:23 PM #
Many, many thanks for your long and informative post! :)

Now it's time to digest all the info. But finally looks like porting to Palm OS should not be such a different beast... well, certainly that's encouraging. Perhaps then the lack of porting to Palm OS is just because it's a different enough platform from the mainstream ones? (linux -> Zaurus, Win32 -> PocketPC, but Palm is alone...)

That certainly could explain some things... and would turn the problem into something similar to what Mac OS Classic suffered/suffers. Really interesting.

Well, now I have something interesting to try on the Palm! ;)

Thanks again, skeezix!!

RE: I'm waiting for libSDL
skeezix @ 5/31/2004 1:42:45 PM #
yeah, its really not so hard when you have an idea what you're doing, but a lot of peopel want to do a quick job. ie: Given an SDL library for Windows and Unix, you can do a port in just a couple hours work between the two for a decently behaved SDL game.

I ported ColEm Coleco emu from Marat Fayzullin to Palm OS in about 2 hours (to first successful run), and spent a few more hours over a few days making it a little nicer. Voila, see Columbo. So it can be done quite rapidly :)

jeff

The Shadow knows!

porting to OS5 / OS6
tompi @ 5/31/2004 8:24:15 PM #
The hard parts porting to OS5 are the memory management and ARM-native support. People who develop cross-platform tools just have their limits about how much time and engineering effort they are willing to invest to support another platform.

OS6 looks like it's going to be a protected mode 32bit ARM-native operating system, which will make porting of libSDL and lots of other toolkits and software much easier.

Porting: Still... could Palm make it easier?
Winter_ @ 6/1/2004 5:21:15 AM #
One thing I still don't understand is... why doesn't Palm make available some kind of "standardizing" utilities? (perhaps just some libs). That could possibly enable anyone to have an easier time porting existing code to Palm OS.

For example: Motorola made "some" modifications to GCC ("thousands of lines") so it could compile for the Altivec extensions on their PowerPC processors, and then published the changes... so those changes are now (after some refining) included on the standard GCC. Net result: you can now compile for Altivec using the free GCC and a number of free tools that depend on it. That means more developers.

Perhaps Palm would not need to make such an effort; they could just prepare some C libs more closely resembling the standards, so again anyone using GCC would compile for Palm more easily. (and more so since they are now pushing officially Eclipse+GCC now, aren't they?)

I'm talking about things like really hiding the Palm OS memory management specifics behind a malloc; or more generally, provide those wrappers that looks like a lot of developers will have to re-invent themselves.
Perhaps they could even get to the point of offering some input/output adaptor so standard C code using stdin/stdout could at least work (exactly like Metrowerks did with its SIOUX on the Mac OS some time ago, which made available a "terminal window" on the pre-OS X, CLI-averse Mac OS)...

(erm, perhaps Metrowerks is already doing that for Palm now? Dunno... :P)

Surely all of this would just be (mainly?) some help for developers; there's still the subject of the simple recompile vs. the real, thorough port...
...but I still believe some apps would be useful even with a simple recompile.

Any insight?

(I'm even thinking that if Palm* provided a standard enough environment and took the effort of porting some key "standard" things, like libSDL... well, wouldn't that open a whole lot of opportunities for the platform? Why wait for third party APIs and then make developers pay for them, when there are free alternatives?)
(self-answer: well, I guess this clashes with the Java subject. There's no good JVM for Palm, so it certainly looks like Palm* are not interested on taking profit of "standards"...)

RE: I'm waiting for libSDL
gmigueis @ 6/1/2004 5:10:25 PM #
Now that's a good idea. It seems like they're naming functions like they would name pets.
Anyway, PocketPC uses it's memory part as a hard-drive and part as standard RAM. Palm does not but they could provide such functions to attract PocketPC and PC standard developers.

RE: I'm waiting for libSDL
Winter_ @ 6/2/2004 2:48:40 AM #
Ha! I hadn't thought of that, but you're right... surely that's the last piece of the puzzle to having a "compatible enough" system. Careful anyway, just mentioning that "having a filesystem would be nice" can cause endless flames. :P

However, I won't go that far as to ask for a filesystem just to have better compatibility with the rest of the world; but certainly I'd ask for some way to hide the no-filesystem details from developers who only need to open a few files.
Anyway, I have no idea what does exactly the VFS mean for a programmer... so perhaps that's its purpose and I could be saying nonsense here.

I'd really longing to try some things...

RE: I'm waiting for libSDL
gmigueis @ 6/2/2004 3:14:50 AM #
I know a fair bit of Palm OS development, and I used to do some Win32 programming, but that was before a Palm come to my hands - I then dumped the desktop and the laptop :). I have no idea about PocketPC programming, I can't help :(
Still, this discussions of non-developers often bring up very good ideas. Perhaps we're not connected to a dark rigid system :)
Now I'm sad about Sony. I have three Palm devices and a Sony would be the next one - when the next UX comes out.
PalmOne please make a T|T3|UX !

Top

Account

Register Register | Login Log in
user:
pass: