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]