September 2015 - Wine-Devel

Re: [PATCH 03/12] msvcp110: Add tr2_sys__Open_dir implementation.(resend)

by YongHao Hu

Hi, On 15/9/28 下午7:51, Piotr Caban wrote: > Hi, > > On 09/07/15 16:21, YongHao Hu wrote: >> +/* ?_Open_dir(a)sys@tr2(a)std@@YAPAXAAY0BAE(a)DPBDAAHAAW4file_type@123@@Z */ >> +/* >> ?_Open_dir(a)sys@tr2(a)std@@YAPEAXAEAY0BAE(a)DPEBDAEAHAEAW4file_type@123@@Z */ >> +void* __cdecl tr2_sys__Open_dir(char* target, char const* dest, int* >> err_code, enum file_type* type) >> +{ >> + HANDLE handle; >> + WIN32_FIND_DATAA data; >> + char temppath[MAX_PATH]; >> + TRACE("(%s %s %p %p)\n", debugstr_a(target), debugstr_a(dest), >> err_code, type); >> + strcpy(temppath, dest); >> + strcat(temppath, "\\*.*"); > Is native limiting the path to MAX_PATH characters? What happens if > longer path is passed? > As far as I know, we can not create a file or directory when their path longer than MAX_PATH on Windows, so it is impossible to pass a longer valid path to tr2_sys__Open_dir. If we pass a longer invalid path, I think that it's err_code would be ERROR_PATH_NOT_FOUND( GetLastError() ) Thank you very much. :)

Sept. 29, 2015

Re: Wined3d wireframe rendering

by Gediminas Jakutis

On 2015.09.29 17:15, Stefan Dösinger wrote: [...] > Re performance: Wireframe mode will only fix games that are limited by fragment processing. If you're CPU bound (which is the case in Wine most of the time without CSMT) you'll gain absolutely nothing. Also vertex processing limted setups won't improve, but those are fairly rare. If you're truly fragment processing limited lowering the resolution should help... > > Cheers, > Stefan I experimented with making some games run in wireframe under wine around a year ago and can say the results can be quite disappointing in some cases, with performance dropping by an order of magnitude. In some cases, objects that normally get culled due to being occluded by other objects suddenly become visible in wireframe, and thus, get rendered. Since this can lead to processing *a lot* of objects that don't get processed otherwise, it can choke the CPU up badly. note: I'm no expert; just writing from experience. -- Gediminas Jakutis LDK Varčiai www.varciai.lt

Sept. 29, 2015

Re: Wined3d wireframe rendering

by Stefan Dösinger

Have a look at dlls/wined3d/state.c, state_fillmode(). However, you're likely to run into two problems: 1) The game doesn't necessarily clear the color buffer and just re-render every pixel. You'll have to change swapchain_present to clear the back buffer, otherwise you'll just get a colorful mess of old lines and new lines. 2) Render-to-texture: In modern games it is common to render everything to one or more textures, and then draw the texture onto the back buffer with one or more post-processing draws. You'll somehow have to figure out the post processing draws and make them non-wireframe, otherwise you'll end up with a mostly empty screen. Point 2 also makes point 1 more difficult to solve. You'll have to find the intermediate render targets, clear them, and also find a proper clear color that produces a "good" result with the post processing shaders. Also, Aaryaman's information is also pretty accurate: There may be external programs, and if you are dealing with an online game expect to be booted from the game pretty quickly because of attempted cheating... Re performance: Wireframe mode will only fix games that are limited by fragment processing. If you're CPU bound (which is the case in Wine most of the time without CSMT) you'll gain absolutely nothing. Also vertex processing limted setups won't improve, but those are fairly rare. If you're truly fragment processing limited lowering the resolution should help... Cheers, Stefan Am 29.09.2015 um 15:52 schrieb Aaryaman Vasishta <jem456.vasishta(a)gmail.com>: > You'd probably have to hack into the game to change the rasterizer state to wireframe mode. Many game trainers (basically memory hacks which are used for cheating) offer D3D hooks which allow you to *switch on* wireframe mode, but that depends on the DX version too. AFAIK many DX9 onwards games have trainers like this available. Anyways, wined3d as it is right now can't decide the rasterizer state of any game by itself. wined3d will merely do what the game tells it to do, so you'll have to modify the game itself (via methods like the one described above), or if you have the source-code of the game, then change its default rasterizer state. fwiw, I don't advocate the former method as it's basically cheating in-game. > > > Cheers, > Aaryaman > > On Tue, Sep 29, 2015 at 7:01 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > Hi all, I know it may sound idiot as I have zero knowledge on 3d > graphics but is it possible to make wined3d to not add textures to > things resulting in a sort of wireframe renderer? > > The long and uninteresting background: > I used to play a game called X-moto in 300Mhz Celeron Linux computer, > in its standard rendering mode it was impossible to play the game due > to low fps, but it had an awesome wireframe mode that played smoothly. > So if this could be achieved globally by wined3d we could play new > games on old computers (my overly noob conclusion about all this). > > Thanks in advance for any reply, > Bruno > > > >

Sept. 29, 2015

Re: Wined3d wireframe rendering

by Aaryaman Vasishta

You'd probably have to hack into the game to change the rasterizer state to wireframe mode. Many game trainers (basically memory hacks which are used for cheating) offer D3D hooks which allow you to *switch on* wireframe mode, but that depends on the DX version too. AFAIK many DX9 onwards games have trainers like this available. Anyways, wined3d as it is right now can't decide the rasterizer state of any game by itself. wined3d will merely do what the game tells it to do, so you'll have to modify the game itself (via methods like the one described above), or if you have the source-code of the game, then change its default rasterizer state. fwiw, I don't advocate the former method as it's basically cheating in-game. Cheers, Aaryaman On Tue, Sep 29, 2015 at 7:01 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > Hi all, I know it may sound idiot as I have zero knowledge on 3d > graphics but is it possible to make wined3d to not add textures to > things resulting in a sort of wireframe renderer? > > The long and uninteresting background: > I used to play a game called X-moto in 300Mhz Celeron Linux computer, > in its standard rendering mode it was impossible to play the game due > to low fps, but it had an awesome wireframe mode that played smoothly. > So if this could be achieved globally by wined3d we could play new > games on old computers (my overly noob conclusion about all this). > > Thanks in advance for any reply, > Bruno > > >

Sept. 29, 2015

Wined3d wireframe rendering

by Bruno Jesus

Hi all, I know it may sound idiot as I have zero knowledge on 3d graphics but is it possible to make wined3d to not add textures to things resulting in a sort of wireframe renderer? The long and uninteresting background: I used to play a game called X-moto in 300Mhz Celeron Linux computer, in its standard rendering mode it was impossible to play the game due to low fps, but it had an awesome wireframe mode that played smoothly. So if this could be achieved globally by wined3d we could play new games on old computers (my overly noob conclusion about all this). Thanks in advance for any reply, Bruno

Sept. 29, 2015

Re: [PATCH v2] ucrtbase: Make the strtod implementation C99 compatible

by Martin Storsjö

On Tue, 29 Sep 2015, Piotr Caban wrote: > On 09/21/15 15:08, Martin Storsjo wrote: >> if(d>MSVCRT_UI64_MAX/10 || hlp<d) { > Please also update overflow checking rules (use base instead of 10). > >> +static void test_strtod(void) >> +{ >> + test_strtod_str("infinity", INFINITY, 8); >> + test_strtod_str("INFINITY", INFINITY, 8); >> + test_strtod_str("InFiNiTy", INFINITY, 8); >> + test_strtod_str("INF", INFINITY, 3); >> + test_strtod_str("-inf", -INFINITY, 4); >> + test_strtod_str("inf42", INFINITY, 3); >> + test_strtod_str("inffoo", INFINITY, 3); >> + test_strtod_str("infini", INFINITY, 3); >> + >> + test_strtod_str("NAN", NAN, 3); >> + test_strtod_str("nan", NAN, 3); >> + test_strtod_str("NaN", NAN, 3); >> + >> + test_strtod_str("0x42", 66, 4); >> + test_strtod_str("0X42", 66, 4); >> + test_strtod_str("-0x42", -66, 5); >> + test_strtod_str("0x1p1", 2, 5); >> + test_strtod_str("0x1P1", 2, 5); >> + test_strtod_str("0x1p+1", 2, 6); >> + test_strtod_str("0x2p-1", 1, 6); >> + test_strtod_str("0xA", 10, 3); >> + test_strtod_str("0xa", 10, 3); >> + test_strtod_str("0xABCDEF", 11259375, 8); >> + test_strtod_str("0Xabcdef", 11259375, 8); >> + >> + test_strtod_str("0x1.1", 1.0625, 5); >> + test_strtod_str("0x1.1p1", 2.125, 7); > Could you please also add few more tests, like: > test_strtod_str("0x1.A", ...); /*to show that part after decimal point is > correctly handling hexadecimal digits */ > test_strtod_str("0x1p1a", ...); /* to show that exponential part is not > handling hexadecimal digits */ Thanks, updated patch sent. (Although I missed to add your comments at the end of the test lines, which I only notice now when replying.) // Martin

Sept. 29, 2015

Re: [PATCH v2] ucrtbase: Make the strtod implementation C99 compatible

by Piotr Caban

On 09/21/15 15:08, Martin Storsjo wrote: > if(d>MSVCRT_UI64_MAX/10 || hlp<d) { Please also update overflow checking rules (use base instead of 10). > +static void test_strtod(void) > +{ > + test_strtod_str("infinity", INFINITY, 8); > + test_strtod_str("INFINITY", INFINITY, 8); > + test_strtod_str("InFiNiTy", INFINITY, 8); > + test_strtod_str("INF", INFINITY, 3); > + test_strtod_str("-inf", -INFINITY, 4); > + test_strtod_str("inf42", INFINITY, 3); > + test_strtod_str("inffoo", INFINITY, 3); > + test_strtod_str("infini", INFINITY, 3); > + > + test_strtod_str("NAN", NAN, 3); > + test_strtod_str("nan", NAN, 3); > + test_strtod_str("NaN", NAN, 3); > + > + test_strtod_str("0x42", 66, 4); > + test_strtod_str("0X42", 66, 4); > + test_strtod_str("-0x42", -66, 5); > + test_strtod_str("0x1p1", 2, 5); > + test_strtod_str("0x1P1", 2, 5); > + test_strtod_str("0x1p+1", 2, 6); > + test_strtod_str("0x2p-1", 1, 6); > + test_strtod_str("0xA", 10, 3); > + test_strtod_str("0xa", 10, 3); > + test_strtod_str("0xABCDEF", 11259375, 8); > + test_strtod_str("0Xabcdef", 11259375, 8); > + > + test_strtod_str("0x1.1", 1.0625, 5); > + test_strtod_str("0x1.1p1", 2.125, 7); Could you please also add few more tests, like: test_strtod_str("0x1.A", ...); /*to show that part after decimal point is correctly handling hexadecimal digits */ test_strtod_str("0x1p1a", ...); /* to show that exponential part is not handling hexadecimal digits */ Thanks, Piotr

Sept. 29, 2015

Re: [PATCH] gdi32: Antialias fake bold or italic fonts regardless of GASP table.

by Nikolay Sivov

On 29.09.2015 12:40, Ken Thomases wrote: > On Sep 29, 2015, at 4:21 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > >> I think in some cases it makes sense to disable emboldening entirely, because as you said rendered images are ruined, but not only by moving outline points around. Some fonts, I think it applies to CJK fonts more than others, have prerendered embedded bitmaps to improve legibility in small sizes, but when we fake bold or oblique styles we disable bitmaps explicitly, and this goes against the idea font designer had in mind. Enabling AA could probably help, but not necessary as well as using bitmaps. Of course this has to be tested on windows using fonts that provide bitmaps, to see if they respond to bold simulation at all at sizes that are supposed to use bitmaps. > > Well, in general, I think Windows simulates bold using an entirely different technique. I haven't tested in any thorough fashion, but I did look briefly at one point. It looks like Windows just draws the glyph twice with the second time being shifted right by one pixel. > Interesting, that could explain test results we have, where advances are adjusted by one pixel only. >>> There is a new registry setting to disable this and revert to the previous >>> behavior: >>> >>> [HKEY_CURRENT_USER\Software\Wine\Fonts] >>> "AntialiasFakeBoldOrItalic"="n" >> >> What's a problem of ignoring GASP and following global AA settings in such cases? I mean are you aware of any problems that could potentially need such switch? > > No specific problems other than people are picky about their fonts. It's conceivable that some people would prefer the old way to the new. In the CodeWeavers bug tracker where I first proposed this patch (bug 12270, if you care), I got pushback about the lack of a registry setting to turn this off. So, I added a registry setting. > Ok. > -Ken >

Sept. 29, 2015

Re: [PATCH] gdi32: Antialias fake bold or italic fonts regardless of GASP table.

by Ken Thomases

On Sep 29, 2015, at 4:21 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > I think in some cases it makes sense to disable emboldening entirely, because as you said rendered images are ruined, but not only by moving outline points around. Some fonts, I think it applies to CJK fonts more than others, have prerendered embedded bitmaps to improve legibility in small sizes, but when we fake bold or oblique styles we disable bitmaps explicitly, and this goes against the idea font designer had in mind. Enabling AA could probably help, but not necessary as well as using bitmaps. Of course this has to be tested on windows using fonts that provide bitmaps, to see if they respond to bold simulation at all at sizes that are supposed to use bitmaps. Well, in general, I think Windows simulates bold using an entirely different technique. I haven't tested in any thorough fashion, but I did look briefly at one point. It looks like Windows just draws the glyph twice with the second time being shifted right by one pixel. >> There is a new registry setting to disable this and revert to the previous >> behavior: >> >> [HKEY_CURRENT_USER\Software\Wine\Fonts] >> "AntialiasFakeBoldOrItalic"="n" > > What's a problem of ignoring GASP and following global AA settings in such cases? I mean are you aware of any problems that could potentially need such switch? No specific problems other than people are picky about their fonts. It's conceivable that some people would prefer the old way to the new. In the CodeWeavers bug tracker where I first proposed this patch (bug 12270, if you care), I got pushback about the lack of a registry setting to turn this off. So, I added a registry setting. -Ken

Sept. 29, 2015

Re: [PATCH] gdi32: Antialias fake bold or italic fonts regardless of GASP table.

by Nikolay Sivov

On 29.09.2015 10:27, Ken Thomases wrote: > If the client requests a bold typeface of a font which doesn't actually provide > a bold typeface, Wine fakes it using FT_Outline_Embolden(). Likewise, it fakes > italic by apply a shear transform. > > These techniques work passably when antialiasing is in effect. However, when > antialiasing is disabled at small sizes by the font's GASP table, the results > are horrible. The glyphs have many spurs or appear furry. > > On the theory that fonts disable antialiasing via the GASP table at small sizes > because hinting should produce pixel-perfect results and that that rationale is > voided by the application of procedural bolding or italicizing, we ignore the > GASP table and always antialias for fake bold or italic fonts. Hi. I think in some cases it makes sense to disable emboldening entirely, because as you said rendered images are ruined, but not only by moving outline points around. Some fonts, I think it applies to CJK fonts more than others, have prerendered embedded bitmaps to improve legibility in small sizes, but when we fake bold or oblique styles we disable bitmaps explicitly, and this goes against the idea font designer had in mind. Enabling AA could probably help, but not necessary as well as using bitmaps. Of course this has to be tested on windows using fonts that provide bitmaps, to see if they respond to bold simulation at all at sizes that are supposed to use bitmaps. P.S. unrelated but still, since faked styles effectively invalidate the job hinting does, maybe it makes sense to try to load with FT_LOAD_NO_HINTING in such cases as it's supposed to be faster, and I think we disable outline caching for simulated fonts. Just a thought, I haven't tried it myself. > > There is a new registry setting to disable this and revert to the previous > behavior: > > [HKEY_CURRENT_USER\Software\Wine\Fonts] > "AntialiasFakeBoldOrItalic"="n" What's a problem of ignoring GASP and following global AA settings in such cases? I mean are you aware of any problems that could potentially need such switch? > > Signed-off-by: Ken Thomases <ken(a)codeweavers.com>

Sept. 29, 2015