> -----Original Message-----
> From: Aaron Ardiri [mailto:[EMAIL PROTECTED]]
> Sent: 28 May 2002 17:56
> To: Palm Developer Forum
> Subject: RE: Drawing performance (was Access screen with Palm OS 4.0)
>
> if i gave you answers to these questions - we would be giving up all
> our tricks now wouldn't we? :) this is not something we
> probably want
> to disclose publically :)
Hey, you can't blame a guy for trying.
> > 1 - Do you restrict the dimentions of your source bitmaps
> to be multiples
> > of 4 so that every row is byte aligned?
>
> how would that help? :) think about it, consider your
> source/destination
> windows and re-evaluate the speed improvements/advantages :)
I could be missing somthing here, but here goes.
I'm in (say) 2-bit color mode. If I draw a bitmap that is 8x1 at (0,0) onto
my screen buffer, all I have to do is copy 2 bytes from the bitmap to the
first 2 bytes of the screen buffer (I'm using MemMove right now, but I'll
bet there is a faster way, do you know how good the memcpy in MSL is?).
However, if I draw a bitmap that is 9x1 at (0,0) then I have to do the
following:
- Copy 2 bytes from the bitmap to the first 2 bytes of the screen
buffer (same as in 8x1).
- Read 3rd byte from the bitmap (assume that bit's 2-8 are 0, seems
to work so far).
- Read 3rd byte from the screen buffer.
- Clear bits 0 and 1 in the value read from the screen buffer (&
with 0xC0)
- & value from bitmap and value from screen buffer (w/ 0,1 cleared).
- write the result to the 3rd byte of the screen buffer.
Surely this is more work? Is there a better approach? (on PC games pixels
are always 1 or more bytes these days :)
> > 2 - Do you support transparency? If so do you use a mask or
> a color key from
> > the bitmap header for this? I can't really see artists
> using a color key if
> > it's 1 of only 4 shades of grey, and the last thing that I
> want to do is
> > double my image size just to add a color key.
>
> transparency inside a bitmap = horrid. use masks and
> bitmaps :) plenty
> of sample code out there to do this.
That's what I thought.
> > 3 - Are the framerates you quote with double buffering on?
>
> yes. our source window is 640x128 and we blit to 160x128 LCD area
Ahhh! So every pixel in your screen buffer *is* 1 byte, and then you bit
pack when you copy the screen buffer into the VRAM. That makes alot of sense
(answers my question above).
> > 4 - What framerates do you get on the Palm III?
>
> depends on the number of sprites :) download Lemmings.. try it for
> yourself on a IIIc and see if you are happy with the framerate :)
Cool, thanx for the info. I just realised that you're the pilRc guy and that
Lemmings is on your site :) I'm getting a color palm next week, so I'll give
it a go then.
> check classic game programming guides from the late 80's
> and early 90's
Heh. I think that you misunderstand my reasons for asking these questions. I
know *how* to find out the answers for a given platform (i.e. Palm) I am
just too lazy to figure it out for myself (also, have no hardware until next
week). That's why I expect people on the list to *give* me the answers :)
> :) but seriously, blitting a whole screen doesn't take that
> much time :)
> in deity 3D, we do complete screen updates every frame and
> you can run
> nicely around - most of the work is with the raycasting engine :)
Cool, that's the magic info.
Cheers for all your help. I'll get on a 640x160 screen buffer right now.
Idries
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
