> All right, folks - before I'm painted as the only game programmer too
> lazy to write my own functions, let me quickly summarize my point
> and my intent with this suggestion.
:) i dont think anyone intended that :)
> I do support both legal APIs and raw screen access and I shall continue
> to do so. I did say that most game programmers have no problem creating
> a version of their code for each new Palm that comes out - while they
> are still in business.
>
> But since the "official API" version is unplayably slow (a situation
> which will likely get wose over time as graphics increase), I thought
> it worthwhile to try to see if a middle ground could be accomodated -
> reasonable speed with forward compatibility, This doesn't come with
> high development cost - Palm likely already has specialized BLiT
> functions - it just takes awhile for the general routine to decide
> which to use.
the problem with this model is that if you want to support *existing*
users, you'll still need to tweak/hack. sure, Palm can put them in as
API calls - but it wont get done until version 5 or 6 :)
in the mean time, you'll have to tweak..
by the time version 5 or 6 come out, maybe there will be more demands
put on by us game developers - maybe taking advantage of hardware
scrolling etc..
> As I mentioned once before, since so many powerful desktop systems
> have realized the need to provide such an API, is it not comically
> more necessary for a Palm?
Palm's desire to be "forward compatible" - how would you feel if
Palm made you recompile your app for a new version of its os?
> As a game developer, I'm just giving Palm some feedback as to ways
> they could improve their API for game developers. I have seen VERY
> good graphics APIs on many other platforms. And Palm has already
> shown promise in this direction - WinScreenLock is a wonderful example
> of a direct API, and Palm is only the second platform I've seen
> include such a command in their core, basic API.
> I applaud them for that.
sure, however, each API is up to the licensee to implement as
appropriate (or modify). along with WinScreenLock, you have
two devices (Prism and SONY) which dont do as performed, so you
need to tweak them specifically :(
> As far as games always needing to be tweaked for speed, if you
> isolate all graphics interaction down to the single act of updating a
> buffer rect to the actual screen, and you can make this OS operation
> so fast that games can really run in this manner, then you have
> succeeded in completely decoupling game graphics from graphics
> hardware. From that point on, your game is "safe", and all you have
> to fear is that when later running on a 68K emulator your super
> optimized assembler routines suddenly are slower than unoptimized C
> code. :)
there is a way around it, provide a 3rd party shared library
specifically for graphics, or gaming in specific. developers
hook that shared library, instead of doing direct screen access
inside their code - isolate the "bad" code to the library,
which, when new hardware is released, gets updated - and in
turn updates a lot of games that use it.
just a thought.. its come across my mind a few times.. it also
can fix a lot of os/device specific issues that may exist..
most of my blitting code is open, found in Cube3D and Burning.
i would be interested in developing such a library, time is the
biggest factor.. not much of that available really :)
// az
[EMAIL PROTECTED]
http://www.ardiri.com/ <--- free games!
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
