Index:
[thread]
[date]
[subject]
[author]
From: Marcus Sundberg <mackan@stacken.kth.se>
To : ggi-develop@eskimo.com
Date: Thu, 01 Jul 1999 20:02:27 +0000
Re: Got to be a faster way.
Club Neon wrote:
>
> First let me say, it is great to be back. Some of you may remember me,
> I was the webmaster for the GGI web site for a little while, must have
> been almost 2 years ago now. Would have known me as Chris Meadors.
> Anyway, I have created my own Linux installation and am back playing
> with GGI. I have actually done more with GGI in the last 3 days than in
> the last 2 years.
>
> But anyway, here is what I'm running into (remember all I did before was
> putting a few strings and lines, so I'm rather green): I'm working on a
> multi-layer tile based display engine, with a twist, varible alpha
> transparency between paralaxing layers. Because of the paralax effect I
> pretty much need to redraw the whole screen with every move as the tiles
> that may have been over-lapping in the last position have shifted at
> different speeds. So far my layer compositing code seems fast enough
> (as long as I don't go too many layers deep), but I can't get the final
> combined layer drawn to the screen fast enough.
>
> First I tried putting each pixel from the 64 bit values stored in the
> final composite through the mapcolor function to the main visual, but
> that was only getting me 1 fps.
>
> So then I tried putting the pixels through mapcolor to a memory visual
> that was the same size and depth as the display visual and crossblitting
> between them. That knocked me down to about 5 spf (seconds per frame).
>
> The get/putbox combo between visuals got me up to about 2 spf.
>
> I just noticed the copybox function as I was going to sleep, so I
> haven't tried it yet, but I don't think it'll get me the 15+ fps that
> I'm looking for.
>
> So all you people with 2 years more experience than me, what do you
> recommend?
Never use PutPixel or MapColor in a loop processing an entire screen.
No implementation in the world is ever going to change that making
one or more function calls per pixel is going to be dog-slow.
> Page flipping really isn't an option, as I want one set of
> routines that will work on all targets.
Why? There is no reason to waste user's resources by deliberately
writing non-optimal code. Use whatever features you can take advantage
of when they are present, and provide well written fallbacks when they
are not.
> I can get my final composited
> data into just about any form, right now untouched it is setup to be a
> linear array of (w*h) ggipixels.
There is no such thing as a "ggipixel". ggi_pixel is just a datatype
corresponding to an unsigned integer, large enough to hold the largest
possible pixelvalue.
The correct way to put pre-rendered images to the screen when not using
DirectBuffer is ggiPutBox(), or if it makes things much simpler
- ggiPutHLine().
//Marcus
--
-------------------------------+------------------------------------
Marcus Sundberg | http://www.stacken.kth.se/~mackan/
Royal Institute of Technology | Phone: +46 707 295404
Stockholm, Sweden | E-Mail: mackan@stacken.kth.se
Index:
[thread]
[date]
[subject]
[author]