The problem is that WINE is not an Linux only program
Announcement
Collapse
No announcement yet.
Wine's Shader Compiler Now Handles... Reflections
Collapse
X
-
Originally posted by droidhacker View PostAm 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?
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.
Comment
-
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:
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.
Comment
-
Originally posted by grantek View PostI 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
What is the test suite used for? Why were tests marked broken for Win9x? What does that mean for Win9x compatibility?
Comment
-
Originally posted by zeealpal View PostDid 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
Comment
-
Originally posted by lolren View Postyes, 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.
Comment
-
Originally posted by thefirstm View PostAdditionally, as was mentioned earlier, lots of people use WINE for gaming. None of the Gallium drivers are fast enough for any serious gaming yet.
Comment
-
-
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.
Comment
-
Originally posted by thefirstm View PostAdditionally, as was mentioned earlier, lots of people use WINE for gaming. None of the Gallium drivers are fast enough for any serious gaming yet.
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.
Comment
Comment