DIB Engine

[satyr_22901 at yahoo.com]

> When you look in the mailinglist archives you will find lots of
> topics regarding a DIB engine. A usefull post is this one written by
> Transgaming:
> http://www.winehq.com/hypermail/wine-patches/2002/09/0251.html.

I've read several of the posts about a DIB engine, including that one
(which is linked from bug #421).

> So lets say you are using powerpoint and it uses 16bit DIBs for
> drawing while your Xserver runs at 24bit. This works fine on windows
> but X has limitations like that allows you to render only at the same
> depth as the Xserver is using. Further DIBs allows programs to
> directly draw into its memory and also allow you to use GDI
> functionality. Wine does a lot of magic to allow this functionality
> and it also takes into account depth conversion. The syncing between
> the 'X image' and the 'application' image is not that efficient
> because it requires Xserver calls and it is even worse when depth
> conversion is needed.
> 
> In case of games there are two reasons why DIB-stuff is used. In
> plain directdraw we use DIBs for color conversion e.g. when the game
> uses 16bit and X uses 24bit they are used only for this version.
> The other case is when a game uses GetDC to mix ddraw rendering with
> GDI rendering. This is for instance what Age of Empires2 uses and to
> make it worse it uses 8bit palleted mode aswell.
> 
> In theory a DIB engine would help both types of games. The first
> class of games (if they don't use GetDC and friends) was accelerated
> in the past using DGA and those games were very fast. These days we
> also have a directdraw->opengl renderer in Wine (set
> Direct3D\DirectDrawRenderer to opengl instead of the default gdi).
> Then opengl does the color conversion for us, it isn't limited by X
> depth limitations. Our opengl renderer doesn't work for all types of
> games yet in some games multithreading issues appear which we don't
> handle correct yet. In some cases when the format isn't supported by
> opengl we still need to do depth conversion in software.
> 
> I would check what type of rendering your game uses as perhaps fixing
> the ddraw->opengl renderer can be enough already if the game uses a
> sane color depth format like 16bit.

Ah, that is definitely good to know.  I shall have to figure out which
type the game is using (looking at a trace of bitmap and bitblt calls,
it appears to be copying numerous blocks from different sources all to
the same destination but only like every 4th to 10th call triggers the
fixme message about client-side DIB copying).  Hopefully the game falls
in that first class and a little work on the ddraw->opengl renderer
will  bring the game performance up to a decent level.

> If the game really needs a DIB engine a good discussion here is
> needed on how to proceed. Writing the DIB engine itself (all the
> drawing code) is not that hard the most difficult thing is how to
> properly integrate this all with gdi and wine's x11drv. I don't think
> wine wants to depend on other libraries like cairo and second
> integrating those with wine could be tricky aswell. Further Wine
> might need a gdiplus.dll in the future which offers similar
> functionality as cairo and friends.

Quite understandable, especially concerning avoiding additional library
dependencies.  For now I shall bow out of that DIB engine discussion
(assuming someone else were to start it--I know I'm not currently
qualified to do so), and hope that HOMM4 performance can be improved
without writing the DIB engine.  ;)

Thanks for the detailed info,
Brian

--------
Jen: Wings? I don't have wings!
Kira: Of course not. You're a boy.

 - from "The Dark Crystal"

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com