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