On Wed, 11 Apr 2001, Andreas Beck wrote:
> > > > When the blitting-operation is done in sync-mode, then it is done
> > > > immediately. If it is in async-mode, then all blitting-operations
> > > > that are performed to the given blt-argument to ggiBltFlush() at
> > > > _once_, when calling ggiBltFlush().
> > > If I get you right, you would queue the requests in Async-Mode, and then
> > > batch-execute them - yes ?
>
> > > I mean you may not modify any source or destination area while such an
> > > async blit is queued (for sources this can be helped by copying them,
> > > but that would be real bloat) - won't that be confusing ?
>
> > A few mails ago you said:
> >> Basically the idea is that you define a BOB and ask libblit to cache
> >> it for you in some way so that it can be blitted as fast as possible
> >> later on
>
> > You can do that very efficiency in that way, no?
>
> Umm - then I don't get what that Sync/Async is supposed to do.
>
> What I was talking about is having objects that get blitted to screen rather
> often (like players in 2D games, images of buttons in GUIs and such) get
> "registered" somehow to be blitted fast on demand.
>
> Delaying the execution of some queued blits (which is what I think this
> async stuff does) doesn't help me with that.
>
> I need a bunch of registered bobs to choose from (not a single queue that
> I build up and that can be flushed at some time) and I usually want to
> blit them immediately.
That is, what the sync-mode does. It makes sure, that the destination
(screen) is always in sync with the operations done by app.
> Let me explain what I meant with some sample code from a primitive 2D
> game:
>
> main() {
>
> register_bob(player);
> for (x=0;x<MAX_FOES;x++) register_bob(foe[x]);
>
> while(!quit) {
> get_coordinate_updates_from_player_and_foe_ai();
> draw_background();
> blit(player,playerx,playery);
> for (x=0;x<visible_foes;x++)
> blit(foe[visfoe[x].foenum],visfoe[x].x,visfoe[x].y);
> ggi_draw_other_stuff_like_HUD();
> ggiFlush();
> }
> }
The ASync-Mode doesn't make sense here, because this algorithm
requires that the destination (screen) is in sync with the operations
done by the app.
The ASync-Mode is useful for things like that:
CreateBob(bob);
ggiBltSetSyncMode(BLT_ASYNC);
/* do multisource blitting ... */
ggiBltMultiCrossBlit(source_list, bob);
/* ... save background here */
save_background(0,0, 100, 100);
/* flussshhhh... */
ggiBltFlush(bob);
...
I know, usually you save the background _before_ doing the
blit-operation, but there might be some situations, where this way is
helpful. Just think of emulating Sprites by libBSE later on.
Furthermore, this might be helpful for other projects like Berlin,
FreeSCI, ...
> How would one do that with the above thing ? Note, that I might want to draw
> in between blitting the foes with normal GGI functions like placing a nice
> fat X with ggiDrawLine on the foe that is currently locked to the missile
> guidance system or something.
CU,
Christoph Egger
E-Mail: [EMAIL PROTECTED]
