Speed of gdi vs opengl DirectDrawRenderer

[Jonas Maebe]

On 20/02/15 10:19, Stefan Dösinger wrote:

> Am 2015-02-19 um 21:12 schrieb Jonas Maebe:
>> I profiled wine (Instruments time profile) and noticed that most
>>  time was spent in wined3d's convert_r5g6b5_x8r8g8b8. Replacing 
>> that routine with an optimized sse2 version from pixman did not 
>> make much of a difference.
> Is there a demo version of this game somewhere? I am reworking the
> d3d blitting code at the moment, and it seems like this would be
> an interesting game to look at.

There's a demo of the non-HD version of the game available at
http://www.cyberlore.com/Majesty/demo.htm . At first sight it exhibits
the same symptoms (OpenGL driver monitor shows a lot of cpu waiting
time on the GPU). It's hard to verify though, because the demo doesn't
allow you to change the in-game speed, unlike the full game (so I
can't test whether it would go faster if I'd yank up the game speed).

I have actually 2 copies of Majesty Gold HD (one on Gamersgate and one
on GOG), but since I've downloaded it already from both I don't think
I can gift you one. It's currently also on sale at GOG till Tuesday,
so if Codeweavers has $4,99/€4,49 to spare... :)
(http://www.gog.com/game/majesty_gold_hd )

> If the game does video memory r5g6b5 to video memory x8r8g8b8
> blits then we should be able to do this on the GPU. It's quite
> possible however that this is either a system memory to system
> memory blit, in which case doing this in the CPU is the correct
> thing. If the game uploads from a system memory r5g6b5 to a video
> memory x8r8g8b8 texture then we can in theory let OpenGL do the
> work via glTexSubImage2D, but it'll mostly mean that OpenGL
> converts the data using the CPU before sending it to the GPU.
> 
> This may be a game bug - you say the game has troubles on Windows
> too.

Yes. The most common workarounds for slowness under Windows appear to be
a) tell the game to use a 32 bit rather than a 16 bit mode (doesn't
help in my case for Wine). Note that while the demo contains a
gameopt.ini file in which you can change the depth to 32, it will just
crash it. Changing this works fine in the full Majesty Gold HD version
b) tell the game to use DirectDraw for bliting rather than its
internal routines (is already the default) (-useddblit command line
parameter -- don't know whether it does anything for the demo)

> It may also be a bug in our modesetting code, in the sense that
> the game sets the display format to r5g6b5, but we stay at
> x8r8g8b8 because X11 (and I think OSX, Ken correct me please) can't
> switch the color depth. Ideally OpenGL takes care of the resulting
> conversion, but that's not always the case.

If you need any more/specific trace output other than what I pasted in
my reply to Ken, let me know!

Thanks,


Jonas