Ah ha! I've just noticed that my src bitmaps were being compressed by pilrc.
DOH!
Things are faster now (11-12fps using the API). This is probably not fast
enough though, so I'll be writing a blitter anyway.
Cheers,
Idries
-----Original Message-----
From: Aaron Ardiri [mailto:[EMAIL PROTECTED]]
Sent: 28 May 2002 16:54
To: Palm Developer Forum
Subject: Re: Drawing performance (was Access screen with Palm OS 4.0)
On Tue, 28 May 2002, Idries Hamadi wrote:
> Ok, going back to my original problem. I now have access to the screen and
> all my bresenham stuff works fine (in both 2 and 4-bit grey, whooho!). The
> next problem that I have is draw speed. Using only my bresenham routines
> with double buffering on (and performing a full screen update every tick)
I
> get around 40 fps on my Palm. As soon as I start to draw a bunch of
bitmaps
> I get taken down to between 4 and 8 depending on how many I draw (between
4
> and 67 bitmaps drawn per frame).
>
> This seems alittle stiff to me. Is there any milage in writing my own
> Blitter for this? Mine could forgo any work for converting from bitmap
> format to screen format (all bitmaps could be stored in screen format).
The
> real problem that I can see here is while the screen size will produce
byte
> aligned rows in both 2-bit and 4-bit screen modes (and in 1-bit and 8-bit,
> good choice of screen size by palm) my bitmaps will not align so well
(being
> of arbitary size).
>
> Has anyone tried anything like this?
>
> Did you have to restrict the size of your bitmaps to get a reasonable
> framerate?
>
> Are there any fast (free) blitting libs around?
>
> Are has anyone traded double buffering for framerate to solve this
problem?
dont use the API's!
use the API's for copying from your backbuffer -> screen only. this is
where compatibility is going to be an issue. in lemmings, we can have
over 100 sprites on screen and still maintain an acceptable screen
update rate (either by updating whole screen when scrolling, or portions)
a lot of game developers have done this stuff before.. you'll quickly
learn that the blitter code provided by PalmSource sucks :) however,
they did do some tweaking in 4.0 to speed things up :P
take advantage of particular circumstances - and, you will get speed.
in Lemmings, we did some tests on an ARM board. we found the following:
[running on a 75Mhz board]
API code (native ARM) = 16 fps
custom blitter (m68k emulated) = 25 fps [100% c]
custom blitter (m68k emulated) = 33 fps [optimized asm]
beware of the assumption that using API's will speed up your code on
ARM units cause they are written in ARM. the device must switch from
68k emulation mode into native ARM mode - and, that takes time :P
the API's also do all these checks, clipping, alignment blah blah
blah.. all of this takes time :) we were not so shocked to see such
bad performance with the APIs in native ARM. we were well aware of
the corners we cut and when you have a lot of sprites.. it could mean
a large difference in performance.
keep in mind we had a special case here :) not all developers will
get the same type of performance.. it always comes down to what you
are doing.. most of the code in lemmings wont apply to other games
for example :P
ps: PACE is pretty darn fast - for an emulator :)
// 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/
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
