On Fri, 5 Apr 2002, Peter Epstein wrote: > Some Astraware games definitely do detect hardware and use custom > blitters tuned for that particular hardware (eg. Zap 2000 and 2016). > I know lots of other game developers do the same thing.
um. sorry peter.. i would have to disagree with you here.. :) writing your own custom memory copy routines from ram -> vram is not taking advantage of the hardware.. heck, even the sources i provide on www.ardiri.com (cube3d, burning) do this - this isn't "taking advantage of the hardware" palm provides the ability to get the screen address using BmpGetBits (from a window) or, by using WinScreenLock() API's.. show me a game that is able to use the picture in picture, or split screen support of the SED 137x controllers yet, manages to detect that the SED controller exists.. red mercury did a 16bit demo for the n610 and n710 series when the API's did not allow for 16bit color.. this is messing with hardware directly.. messing with grayscale prior to palmos 3.0 is messing with hardware directly.. argonv, which, tweaks into 16 grayscale mode on any EZ processor messes with hardware directly (palmos 3.3 started 16 bit grayscale via API's).. see the pattern here? writing a custom blitter to copy from ram -> vram is not "messing with hardware".. the same routines work, regardless if there is vram or not.. cause, thats how it has been on all units.. this of course changes when the endiness becomes an issue (ie: ARM units) as i said previously, i dont want to be bias - but, it is important to know the truth.. :) when palm provides an API - its not messing with hardware directly.. :) // az [EMAIL PROTECTED] http://www.ardiri.com/ -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
