Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 25

Thread: Wine's Shader Compiler Now Handles... Reflections

  1. #11
    Join Date
    Jul 2008
    Location
    Germany
    Posts
    560

    Default

    The problem is that WINE is not an Linux only program

  2. #12
    Join Date
    Feb 2008
    Location
    USA
    Posts
    192

    Default

    Quote Originally Posted by droidhacker View Post
    Am I the only one who things that the wine developers have their priorities screwed up? How about making it actually run real useful and necessary software before messing with implementation of pointless graphical features that nobody really needs?
    You clearly have a firm grasp of how open source development works.

    Ask a bunch of random people what they want from an open source project and you'll get a diverse set of opinions about what should be prioritized. But you know what? The persons submitting patches or other contributions get their itches scratched.

  3. #13
    Join Date
    Jul 2008
    Posts
    314

    Default

    I thought the removal of Win9X tests was interesting - almost sounds like Wine 1.2 is the last version to attempt to support bug-for-bug compatibility with Win9X.

    I'm sure there's a lot of people who will want to run old/archaic/bug-dependent Windows 9X software in the future (even just for retro purposes), so I thought these people will be left with maintaining the 1.2 branch until ReactOS has equivalent support. Did some googling and found this though:
    http://www.mail-archive.com/wine-dev.../msg67102.html
    Right now all the test results that differ for win9x versions are marked
    as broken(), i.e. Wine intentionally makes an effort to NOT replicate it.
    So removing checks for (broken) results will change nothing.

  4. #14
    Join Date
    Sep 2008
    Location
    Netherlands
    Posts
    510

    Default

    Quote Originally Posted by grantek View Post
    I thought the removal of Win9X tests was interesting - almost sounds like Wine 1.2 is the last version to attempt to support bug-for-bug compatibility with Win9X.

    I'm sure there's a lot of people who will want to run old/archaic/bug-dependent Windows 9X software in the future (even just for retro purposes), so I thought these people will be left with maintaining the 1.2 branch until ReactOS has equivalent support. Did some googling and found this though:
    http://www.mail-archive.com/wine-dev.../msg67102.html
    I wanted to ask some questions when this came up on the mailing list, but kept quiet because there was some controversy. Now that that's over, can someone explain what this really means?

    What is the test suite used for? Why were tests marked broken for Win9x? What does that mean for Win9x compatibility?

  5. #15
    Join Date
    Jul 2009
    Posts
    37

    Unhappy

    Quote Originally Posted by zeealpal View Post
    Did you mean using the the Gallium 3D State tracker for DX10/11?

    I think that that would be the best way to go about it.

    +1 To that idea
    yes, but is a know fact that most wine devs use nvidia (and the binary blob) (and this is the best to work with wine). sadly, nvidia does not support Gallium 3D, so it is a long shot to adopt that, at least for now.

  6. #16

    Default

    Quote Originally Posted by lolren View Post
    yes, but is a know fact that most wine devs use nvidia (and the binary blob) (and this is the best to work with wine). sadly, nvidia does not support Gallium 3D, so it is a long shot to adopt that, at least for now.
    Additionally, as was mentioned earlier, lots of people use WINE for gaming. None of the Gallium drivers are fast enough for any serious gaming yet.

  7. #17
    Join Date
    Jul 2009
    Posts
    37

    Default

    Quote Originally Posted by thefirstm View Post
    Additionally, as was mentioned earlier, lots of people use WINE for gaming. None of the Gallium drivers are fast enough for any serious gaming yet.
    i know that but switching to native Gallium 3D DirectX wine support would stop alot of games running till OSS drivers matures. Maybe another Wine branch..

  8. #18
    Join Date
    Sep 2008
    Posts
    130

    Default

    Quote Originally Posted by zeealpal View Post
    Did you mean using the the Gallium 3D State tracker for DX10/11?

    I think that that would be the best way to go about it.

    +1 To that idea
    The " best way" would involve dropping all intel and proprietary nvidia and amd users?

  9. #19
    Join Date
    Feb 2009
    Posts
    45

    Default

    A couple of points:
    - The article seems fairly clueless about what reflection support means, and how it fits in with the rest of Wine.
    - Wine using the d3d1x state tracker simply isn't going to happen. The article is clueless about what the practical differences between using OpenGL vs. using d3d1x would be.
    - Wine developers only using NVIDIA hardware and drivers is simply not true. Though pretty limited in the amount of time I can spend on this, I actually contribute to r600g (and Mesa in general) on occasion. I much rather spend my time on drivers I can actually debug and fix than on writing dodgy hacks for binary blobs. That doesn't mean the free drivers don't still have quite some way to go, of course, but I think free drivers are important and I'd like to see them succeed. Also, the EXT_texture_sRGB_decode extension mentioned earlier in this thread isn't even supported yet by current NVIDIA drivers.
    - Wine focusing only on Direct3D or games doesn't have a whole lot of truth to it either. If you happen to have the git version of Wine, compare "git shortlog -s -n wine-1.0..wine-1.3.15" with "git shortlog -s -n wine-1.0..wine-1.3.15 dlls/wined3d". There may be a lot of work going into wined3d, but it's really just a small fraction of Wine developers working specifically on wined3d.
    - The reason I'm not working on d3d10/11 is due to CodeWeavers' current priorities. I'm unhappy about this, but if you want to see this changed that's where you should complain. I imagine being an actual CodeWeavers customer would give such a complaint more weight.
    - Dropping Win9x support from the tests should mostly result in the tests being more strict and easier to maintain. http://www.winehq.org/pipermail/wine...ry/089017.html explains it pretty well. Wine itself will keep supporting Win9x and 3.x applications.

  10. #20
    Join Date
    Jun 2010
    Location
    ฿ 16LDJ6Hrd1oN3nCoFL7BypHSEYL84ca1JR
    Posts
    965

    Default

    Quote Originally Posted by thefirstm View Post
    Additionally, as was mentioned earlier, lots of people use WINE for gaming. None of the Gallium drivers are fast enough for any serious gaming yet.
    Define serious gaming.

    On my Athlon II 240 and HD 4670 with color tiling and page flipping enabled (and running the drm-radeon-testing kernel) Urban Terror runs with ~ 90-120 fps. It has bad vsync issues and it is not the most graphically challenging game but it runs fast.
    On nexuiz with everything maxed out except for antialiasing and anisotropy I get > 20 fps all the time which is somewhat slow but somehow it is better playable than it sounds. With slightly reducing effects it runs perfectly.
    Assault cube runs on 60-80 fps on "insane" graphics settings.

    On the other hand Warcraft3 in wine with the -opengl switch (on the box it says it needs a 8 mb directx 8 graphics card) I got only now near 60 fps with color tiling and page flipping. Most of the time it goes down to 20 fps and on heavy fights it is at 4-6 fps. That's not funny.
    When I try to start a half life 2 game even in -dxlevel 70 hl2.exe AND X both enter uninterruptible sleep.

    So yes, wine can already be improved for r600g.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •