02:21 orbea: mannerov: and can I assume export WINEDEBUG=fixme-all not working is a wine-nine-standalone issue?
07:09 mannerov: orbea: I don't know
07:21 dhewg: no, wine's debug channels should work just as without nine
07:22 dhewg: mannerov: what do you mean by "should be top and left twice"? i didn't yet encounter a game that breaks with the fshack support
07:25 mannerov: we fill a rectangle in offset
07:25 mannerov: but if dest rect is filled, we already have a rectangle
07:25 mannerov: we just have to offset it correctly
07:25 mannerov: the offset is in offset's top and left
07:26 mannerov: here we are adding two rectangles, not offsetting a rectangle
07:26 mannerov: As for fshack, well, I don't have fshack locally, and that game which doesn't use native resolution is buggy with that nine fshack handling
07:30 dhewg: ah, so you want "OffsetRect(pDestRect, offset.left, offset.top)" instead of those 4 additions?
07:30 mannerov: I guess that should work
07:31 mannerov: I had in mind changing the last two additions to offset by the proper values
07:31 mannerov: but OffsetRect should be doing that
07:31 dhewg: yeah, i think so too
07:32 dhewg: maybe even call OffsetRect unconditionally and remove the != 0 checks
07:32 mannerov: I locally have pdestRect full supposed by nine now
07:32 mannerov: psourceRect only if empty or full buffer
07:33 mannerov: (on wine-nine side pSourceRect and pDestRect are fine. It's on the mesa side that it isn't)
07:33 dhewg: sounds good, but it's been so long i worked on that code...
07:36 mannerov: Well the wine-nine code assumes pSourceRect and pDestRect are the same size
07:36 mannerov: this is the totally the correct thing to do there
07:37 mannerov: except that we still haven't done the proper work to make them the same size mesa side
07:37 mannerov: and the buffer size should be of the size of pDestRect
07:37 mannerov: that's this part I fixed
07:37 dhewg: ok, if you have a standalone patch that fixes ME for you, i can test that patch with fshack enabled here
07:38 mannerov: well I found no other way than removing fshack
07:38 mannerov: thus why I said we need a checkbox I think
07:38 mannerov: the only real fix would be to access dc_rect, and wine devs always denied it to us
07:39 dhewg: oh, hm
07:39 mannerov: if we don't implement a checkbox, have two branch, and have the support not on the master branch
07:39 dhewg: it sounded like just that offsetrect would fix it for you
07:39 dhewg: or does that break fshack?
07:40 mannerov: these two things are unrelated
07:40 mannerov: the fshack problem is in GetWindowInfo
07:40 dhewg: ok
07:40 mannerov: the size is wrong
07:41 mannerov: the correct size is dc_rect
07:41 dhewg: yeah, i vaguely remember that dc_rect issue
07:41 mannerov: our workaround to find it for fshack seems to not work for non-native resolution with fshash not used
07:42 mannerov: so we need a checkbox for fshack in ninewinecfg with warning that it may cause problems for non-native resolutions if fshack is not used
07:43 dhewg: but that sounds rather fatal, like it should've been noticed long ago. is it just ME that has an issue with it?
07:43 mannerov: I haven't tried other things. It's just ME is one of the only games which doesn't support full hd, so that's why I found the issue. All my other games are set to my screen resolution
07:44 dhewg: maybe we can add a ME specific workaround then?
07:45 mannerov: well we need to try other games at non-native resolution first
07:45 mannerov: I don't see why only ME would be affected
07:45 mannerov: think that many games on the first run are not set at native resolution
07:46 mannerov: and with the bug I hit you can see only the top left corner of the screen. It is quite problematic
07:50 dhewg: hm
07:51 dhewg: i just find it weird that noone reported that before, so it doesn't sound like a generic issue
07:52 dhewg: but maybe there's a way to fix it sanely
07:52 mannerov: I think with wined3d, d9vk and nine, most will just try one, and if it doesn't work try another
07:52 mannerov: most people don't ever report bugs
07:52 dhewg: how about checking the values after XGetGeometry() in get_drawable_offset()
07:53 mannerov: checking to what ?
07:53 dhewg: not sure, first idea: if it's smaller than the fs res, set em to zero
07:53 mannerov: you mean bigger ?
07:53 mannerov: Well
07:54 mannerov: One true fix would be to detect the monitor resolution, not the X root window size
07:54 mannerov: but we might have other problems
07:54 mannerov: a checkbox seems to me sure to work
07:54 dhewg: what values do you get for that XGetGeometry() call?
07:54 mannerov: full hd
07:54 mannerov: rather than the smaller resolution
07:55 dhewg: and what is you monitor's res?
07:55 mannerov: native is full hd
07:56 mannerov: but for the game it has resized to 1400x900 or something close
07:56 dhewg: ah
07:57 dhewg: that issue sounds similar to what i debugged once with ddraw on vampire
07:57 dhewg: some screenshots are at https://github.com/iXit/wine-nine-standalone/issues/21
07:58 dhewg: and only now i see the last comment there, is that the same issue?
08:01 mannerov: it could be the same issue
08:02 mannerov: it could be psourcerect and pdestrect too. Possibly both issues
10:34 orbea: dhewg: even if they should it doesn't seem to respect fixme-all
10:34 orbea: would be nice to silence the spammed fixme messages to see the rest of the output...
10:42 dhewg: orbea: but does that disable other fixme debug spew?
10:43 dhewg: maybe its that one instance that prints it differently, like not using wine's debug channels
10:43 orbea: idk, that is the only d3d9-nine fixme spew in this game
10:44 dhewg: oh nine, specific, sorry, i misread
10:44 dhewg: yeah, we changed that at one point
10:44 orbea: yea, when I asked in #winehq they were quick to point out that it was nine specific and not supported by them.. :P
10:45 dhewg: hehe
10:45 dhewg: git show b0b53f56e2d6907f64bdd9367dad6eb0997f31fe
10:46 dhewg: we used to use wine's debug channel in nine, but wine changed it and so we moved to our own implementation
10:46 orbea: ah, so what should I use to silence fixme?
10:46 dhewg: we respect WINEDEBUG if D3D_DEBUG isn't set, but no complex parsing like "fixme-all"
10:47 dhewg: yeah, for nine specifc FIXME/WARN/ERR, uses D3D_DEBUG
10:47 dhewg: *use
10:48 orbea: is there a list of accepted values?
10:48 dhewg: fixme, err, warn, trace
10:48 dhewg: 1, 2, 4, 8
10:50 dhewg: so D3D_DEBUG=14 for all minus fixme i guess
10:50 orbea: -fixme seemed to work as well
10:51 orbea: thanks :)
10:52 dhewg: hm, that might be just luck
10:52 dhewg: 2>/dev/null should work too
10:52 dhewg: but that disables wine debug spew too
10:54 orbea: yes, now that I tried 14 there is trace output which I never saw before
10:55 dhewg: sounds like its working :)
10:56 orbea: yep, with 6 both fixme and trace is silenced :)
10:58 orbea: should 0 silence everything?
10:59 dhewg: yeah
10:59 dhewg: but err would be useful to see
10:59 orbea: yea, i agree
11:00 orbea: now I might actually see those without all the fixme spam :)
11:00 dhewg: hehe
11:12 mannerov: aren't fixme supposed to be print once ?
11:15 dhewg: some are, but afaicr wine does that specific with a per instance "static int once = 0" or similar