> > :) i dont think anyone intended that :)
>
> Thanks, Aaron - email is easy to misread. :)
ahh.. it happens all the time.. thats the beauty of email. you
just dont see the facial expressions to really know how to take
the info :)
> > not all those low level routines are highly optimized either :(
>
> Some things are better not to know. :)
yeah.. :P
> > 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 :)
>
> This IS an interesting idea. Of course, if Palm were to provide this
> library (or at least officially approve this library) then it would
> be (by definition) legal, and free to developers. The only issue I see
> is distribution - might every game would needlessly include a copy of
> this library, and possibly some library versions would be out of
> date. The alternative is equally problematic - requiring the user
> to find and install the latest version of the library.
i would not do it unless Palm got behind it, and made it a system
extension that a user could download from www.palm.com (much like
the IR update). obviously, versioning control would be required,
and a simple check can be made in your own apps :)
the notion of being "Palm" specific just is not good too.. the
library would have to be "PalmOS specific" - that is, work with
all licensee's too :)
you probably would have to ship a copy, or explain where to get
the library. the library would of course use API's in the place
where an optimization is not possible.
updated releases can provide optimizations for new devices - in
this case, so no biggie here :)
> But all this is avoided if Palm has a graphics manager API which
> gradually increases its functionality to support whatever hardware
> is present. But I see your point - if not enough licensees also
> implemented some version of this API, then the API would be valueless,
> since we'd have to program our own versions for each Palm device anyway.
not really :) if Palm added it to the OS, how will you support
existing users? by writing a shared library - you support everyone
from 3.0 (current base) and forwards.
> I guess you've made a good case that it's unrealistic to try to solve
> all our compatibility problems, but I still think it is realistic to
> add a few calls to solve some of our problems. If you and I can create
> software versions for all the devices, Palm should be able to, also.
it is a problem - we break compatibilty because of it :) however,
like i said, it must work on *all* devices, not just Palm hardware.
> Until then, your "open source library" method is a great service to
> developers. If they can't access a library officially, at least
> they can access a collection of open source code to add to their
> software. It's just not dynamicalyl extensible to new devices.
who knows, maybe it can happen :)
anyone out there that wants specific features of such a library,
zap me a few specs.. tell me what you'd want from a library, and
maybe its possible to whip something up..
off the record, i'd see:
- real page flipping
- optimized blitting routines
- tweaking for specific controllers
(ie: EPSON SED1375/1376 allow cool gfx features)
roger: is this something we can look into?
// 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/
