Debriefing > Bug Reports & Fixes
[ISSUE] The wine thread
Graslu:
Well then... It is meant to look awful if that's how you want to see it.
You can't do a single plane textured on both sides in Source, so that's why it has edges here.
Also, if you're on this thread about an unsupported OS and say that's a graphical issue, people are going to assume that you think it's a bug, not that you don't like it / could look better. So no, I wouldn't say "If something looks awful, it's a graphical issue", by that logic, half of our player models are graphical issues.
illwieckz:
--- Quote from: Graslu on September 10, 2016, 11:53:03 pm ---by that logic, half of our player models are graphical issues.
--- End quote ---
No, because even with their defaults, player models look like player models (and no-one regressed the player models).
These glass walls do not look like glass but kind of mixed-up chessboard (???). My brain can't expect that kind of rendering for a glass wall.
But the real reason why I immediately thought about a bug is because I never seen GE:S 5 rendering the stack map before and ge_stack_classic from GE:S 4.2.4 was looking better on the same computer. So, the graphical quality of ge_stack_classic regressed between GE:S 4 and GE:S 5, that's why I honestly first thought about a bug.
See:
So, the regression is not a bug but a feature, I end there the off-topic. I will or I will not open a new thread about that regression, but it's not the topic, the topic is about running wine, so if it's not a bug I can write down right now:
I haven't experienced yet any graphical issue while running GE:S 5.0 on a gallium-nine enabled wine 1.9.18 with amdgpu's mesa drivers.
Being able to say that or the contrary was the purpose of my screenshot: I had to figure out if it was related to wine or not.
If someone marks the glass rendering regression issue as NOTABUG, the amdgpu & gallium-nine based wine rendering issue can be marked FIXED. This thread is a wine thread.
Graslu:
Classic maps were redesigned in 5.0 to look more like they did in N64 only with higher res textures, so that includes making glass work the same way as they did on N64, keep the same scale, and recreate lighting correctly.
So yeah; this is not a bug. I kinda liked how 4.2 stack looked but this is fine too to me since it's accurate to N64. I mentioned the player models because most are a decade old and doesn't meet our current standards, but are still kept since we have no replacement.
Back on topic, it's good to know that now we have workarounds to get GE:S working on Linux and Mac properly (At least aparently for now). Have you tried playing online yet?
illwieckz:
--- Quote ---Back on topic, it's good to know that now we have workarounds to get GE:S working on Linux and Mac properly (At least aparently for now). Have you tried playing online yet?
--- End quote ---
Yes, I have played online since the 5.0 release day (I'm also hosting a server), but only on some maps, like the archives ones, runway, silo, egyptian, cradle, caves, complex, facility and control. The other maps just crashed the game.
I don't know yet what is the cause of the crashes, the 4.2 release was running on vanilla wine releases, and I'm not able to run everything since the 5.0 release. I cannot anymore play GE:S using the default Direct3D→OpenGL wine internal translator so I use the Direct3D native state tracker for Linux. That means if some Mac players face the same bugs as me, they are not able to workaround them as I do since Mac users can't have Direct3D native driver as I do on Linux. That also means if some Linux users face the same bugs as me and are running proprietary nvidia/amdgpu-pro drivers, they can't workaround them as I do since these proprietary drivers do not provide native Direct3D support.
On the server side, I haven't seen any issue running the windows server on linux using wine. The windows server running on wine is even more stable than the linux native one (but it's also Valve's fault) but I'm running the linux native one because it eats far far less memory.
illwieckz:
So I tested the Intel driver (on Haswel hardware), I got the same crash on the same map place (the dam map is a good trigger).
This is now my Linux compatibility matrix:
HardwareIntelNvidiaNvidiaNvidiaAMDAMDAMDKMDi915nvidianouveaunouveauamdgpuamdgpu/radeonsiamdgpu/radeonsiUMDMesaNvidiaMesaMesaAMDGPU-PROMesaMesaDirect3DWineD3DWineD3DWineD3DGalliumNineWineD3DWineD3DGalliumNineStatus☒☒☐☐☒☒☑
WineD3D is the multiplatform generic wine's built-in Direct3D to OpenGL translator. GalliumNine is the native Direct3D 9 state-tracker for Linux (no OpenGL translation), but it works only for Gallium-based driver. Only open source drivers for AMD (radeonsi/amdgpu) and Nvidia (nouveau) are based on Gallium and therefore have native Direct3D 9 support. Intel open source driver is not based on Gallium, and proprietary drivers from Nvidia and AMD (Catalyst then now AMDGPU-PRO) are not based on Gallium too. So, the only option to play all maps from GE:S 5 on Linux is to:
* Have an AMD or nVidia GPU;
* Use the Open Source driver for it;
* Use the GalliumNine state-tracker;
* Use a GalliumNine enabled wine.
My AMD test was done with a R9 390X which runs on both radeonsi and amdgpu drivers. The radeonsi driver is the previous-generation driver for AMD GPUs from pre-GCN to GCN 1.1, amgdpu is next generation driver for GPUs from GCN 1.0 to the future, the R9 390 X is a GCN 1.1 based GPU so it runs on both drivers.
There is no solution for Intel GPU users.
I havn't tested the open source driver for nvidia GPU yet (nouveau/Mesa), but I guess it will work and only work with GalliumNine.
Navigation
[0] Message Index
[*] Previous page
Go to full version