-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday 20 January 2003 14:34, Jani Vaarala wrote:
In version 2002-06-05 graphics output is ok, but
mouse
events seem to be going to /dev/null. I tried different versions and I found out that 2002-06-28
had a fix
labeled:
"Disable OWN_WINDOW as it no longer works."
I tried defining OWN_WINDOW in latest build and the graphics came out ok. But no mouse events. If I undefine OWN_WINDOW, I get the mouse (can hear the
menu
selection sounds), but no graphics.
have you tried to active "DXGrab" = "Y" in config file ? else can you try ?
I tried that, but it doesn't work (if OWN_WINDOW is enabled). I looked at the code behind OWN_WINDOW and it seems that it reads multiple WM_PAINT events (per frame?) instead of just one and in the process gets also other kind of events (key,mouse) and posts these messages back to system.
In ddraw/dsurface/user.c is commented:
/* the point of this is that many games lock theprimary surface * multiple times per frame; this thread will then simply copy as * often as it can without keeping the main thread waiting for * each unlock, thus keeping the frame rate high */
So I'm just wondering if the game does exactlythis and without the OWN_WINDOW fix, graphics updates get somehow "stacked" and GDI overflows.
When I get no graphics, it seems that GDI heap overflows aswell.
hmmm, where ? maybe in palettes things no ?
Yes the overflow entries are palette ones, but it also says something about "missing WM_PAINT".
hmmm, can you send me a trace log without the OWN_WINDOW and another with please ? (using wine --debugmsg +ddraw myapp)
I'm not a windows expert, so it would take quite
long
time to find out what is actually the reason for
this.
Could someone from this list take a look at it ?
I'm not a ddraw expert but i'll try to help you, maybe christian can look at it as lionel is on holydays :)
Thanks :)
--jani
Raphael