View previous topic :: View next topic |
Author |
Message |
Waywocket Tux's lil' helper
Joined: 16 Dec 2003 Posts: 84 Location: York
|
Posted: Wed Aug 31, 2005 11:11 am Post subject: Re: Fix/Hack for target circles |
|
|
Stratofish: That's very cool - good discovery. One question I have though for people who've played using opengl in Windows: I've heard that the circles don't work there (ie. they only work in D3D). Can you confirm this? If that's the case, then this alteration to Wine's opengl is of course technically breaking it to work with a bug in the game, which is rather a pity. Either way, I'll be trying this next time I rebuild Wine. |
|
Back to top |
|
|
StratoFish n00b
Joined: 31 Aug 2005 Posts: 4
|
Posted: Wed Aug 31, 2005 11:44 am Post subject: |
|
|
Waywocket, my large HD died recently taking my Windows install with it so I can't confirm that it also happens in OpenGL mode there. I need to take it back for a replacement before I would be able to check on it. It would make sense that the bug is in the game though as there really isn't anything to go wrong in the Wine OpenGL wrapper. So my hack is adapting the system to the bug like you said.
Until Blizzard fix it though, it is a solution that can improve the in-game experience under Linux (that needs confirming works for others). Maybe a bash script that swaps the opengl32.dll.so files before running WoW and back again after would be the best way to ensure that other apps/games don't get effected. _________________ Strato |
|
Back to top |
|
|
legine Guru
Joined: 27 May 2004 Posts: 555 Location: Germany
|
Posted: Wed Aug 31, 2005 12:12 pm Post subject: |
|
|
Do you think that this discovery can be put into a patch with an aim that a wine registry Key sets the offset? That would be Ausum!!! _________________ quote from Spaceballs:
Dark Helmet:[...] we were told to comb the desert, so we're combing it! [puts down bullhorn] Find anything yet?!
Soldier: Nothing yet, sir. |
|
Back to top |
|
|
lameaim n00b
Joined: 29 Jun 2005 Posts: 16
|
Posted: Wed Aug 31, 2005 3:35 pm Post subject: Re: Fix/Hack for target circles |
|
|
Waywocket wrote: | Stratofish: That's very cool - good discovery. One question I have though for people who've played using opengl in Windows: I've heard that the circles don't work there (ie. they only work in D3D). Can you confirm this? If that's the case, then this alteration to Wine's opengl is of course technically breaking it to work with a bug in the game, which is rather a pity. Either way, I'll be trying this next time I rebuild Wine. |
Yes, the targeting circles et al. are missing in Windows OGL mode aswell. |
|
Back to top |
|
|
StratoFish n00b
Joined: 31 Aug 2005 Posts: 4
|
Posted: Wed Aug 31, 2005 4:48 pm Post subject: |
|
|
Well in that case the best way to get it fixed is to ask Blizzard via the tech support or suggestions WoW forums. If anyone can confirm that my fix works for them we will have proven that it is a case of an incorrectly scaled value being passed to the OpenGL system so the devs have no excuse not to look at it and apply the 1 line fix. If I can get my Windows back up and running I will try to compile the fix into one of the open source OpenGL trace wrapper libraries and test it to see if it fixes the Windows OGL version as well as an extra test.
I would post myself but I am on the Euro WoW servers so don't have access to the US forums. Our suggestions+tech forums are there as a token gesture and are not read by anyone that could make that sort of change. A post there would achieve nothing in the way of a proper fix. If I can get confirmation i will post anyway though as it might help fellow Euro Linux users out. _________________ Strato |
|
Back to top |
|
|
Waywocket Tux's lil' helper
Joined: 16 Dec 2003 Posts: 84 Location: York
|
Posted: Wed Aug 31, 2005 4:49 pm Post subject: Re: Fix/Hack for target circles |
|
|
StratoFish wrote: |
Steps -
1. edit the file <winesrc>/dlls/opengl32/opengl_norm.c
2. search for 'glPolygonOffset''
3. a few lines down is the line 'glPolygonOffset( factor, units );'
4. change it to read 'glPolygonOffset( factor, units*250.0f );'
5. save and close the file
6. in the /dlls/opengl32 directory, run 'make'
7. copy opengl32.dll.so to your wine libs install directory (on my system /usr/local/lib/wine/). You will probably have to do this as root.
8. run WoW and check it works
Lower values than 250 make the circle disappear at a higher camera angle. 250 was the lowest I could make it so that the camera could go right to the ground and still see them.
It should work for everyone, so let me know if you try it.
|
I've just had a try with this, and noticed that sometimes you can see footprints in the snow - but not always. After trying a few changes, more-or-less at random, I've noticed that changing 'glPolygonOffset( factor, units );' to 'glPolygonOffset( -factor, units );' (ie. making 'factor' negative) solves the problem entirely, with no noticeable side effects (in WoW at least). It's like it's being drawn on the wrong side of the ground plane or something, but with this change it behaves more-or-less as in Windows using D3D. (I say more-or-less because I've just had a brief look on someone else's Windows machine and mine actually looks *better* at some angles, but I imagine that's because the graphical settings are higher). Still not had the chance to have a look at opengl in Windows.
Edit: Just read the last two posts - it looks to me then that Blizzard have made a simple sign error somewhere in their code. |
|
Back to top |
|
|
ikataii n00b
Joined: 21 Apr 2005 Posts: 59 Location: CA
|
Posted: Wed Aug 31, 2005 6:35 pm Post subject: |
|
|
the -function did it for me. Nothing noticeable as far as detriment yet. Hooray for breaking wine to fix WoW _________________ "War is the Tao of deception." -Sun Tzu |
|
Back to top |
|
|
branana n00b
Joined: 03 Sep 2004 Posts: 29
|
Posted: Thu Sep 01, 2005 1:37 am Post subject: |
|
|
I just would like to thank you Darkness for your guide, and the helpful posts.
I got my WoW to run on Cedega 4.4.1 with OpenGL.
I have AMD64 gentoo, Nvidia 7667 drivers.
Using the "1.5 OpenGL Hotfix" from Transgaming forums
Using the "memory=0x1000000" fix for the mouseover problems.
Now the game runs like a dream, very good FPS.
(only downside is missing the circles when selecting people, but I prefer it this way) |
|
Back to top |
|
|
Septor Apprentice
Joined: 01 Sep 2004 Posts: 150
|
Posted: Thu Sep 01, 2005 6:31 am Post subject: |
|
|
ikataii wrote: | the -function did it for me. Nothing noticeable as far as detriment yet. Hooray for breaking wine to fix WoW |
If this was a registry option, it could be done on a per-application basis, so as not to break other applications whose developers actually know how to program Maybe I'll whip up a patch tonight and push it into wine, along with my registry patch for DX9 video memory registry setting.
Wierd, my previous post is not showing... must have cancelled it. Anyways I was just curious if people could try with glPolygonOffset(factor,-units) instead of -factor... it should be more accurate, if it works. Anybody add a debug statement there to see what sort of values WoW is throwing at glPolygonOffset()? |
|
Back to top |
|
|
Linubie Guru
Joined: 11 Jun 2004 Posts: 365
|
Posted: Thu Sep 01, 2005 7:02 am Post subject: |
|
|
Septor wrote: | ikataii wrote: | the -function did it for me. Nothing noticeable as far as detriment yet. Hooray for breaking wine to fix WoW |
If this was a registry option, it could be done on a per-application basis, so as not to break other applications whose developers actually know how to program Maybe I'll whip up a patch tonight and push it into wine, along with my registry patch for DX9 video memory registry setting.
Wierd, my previous post is not showing... must have cancelled it. Anyways I was just curious if people could try with glPolygonOffset(factor,-units) instead of -factor... it should be more accurate, if it works. Anybody add a debug statement there to see what sort of values WoW is throwing at glPolygonOffset()? |
As I read this, it seems to me you have developing access to wine, is there a way to include this libmemwrapper into wine and make it switchable on/off to make AMD64 users like me happy trying to preload this workaround, wich is not working in AMD64 environment.
Thank you |
|
Back to top |
|
|
artificio Apprentice
Joined: 15 Sep 2004 Posts: 183
|
Posted: Thu Sep 01, 2005 7:03 am Post subject: |
|
|
The wow installer is bitching about my windows version (it's 98 in ~/.wine/config). I searched google and the forums using the exact string it gave me...
Quote: | World of Warcraft requires a newer operating system to run. |
And got nothing. I tried looking through all the wow threads, but I couldn't find anything. Any ideas/links? |
|
Back to top |
|
|
legine Guru
Joined: 27 May 2004 Posts: 555 Location: Germany
|
Posted: Thu Sep 01, 2005 8:56 am Post subject: |
|
|
@artificio
You have entered 98 in wine? If it so try to use winecfg and set it to win 98. Alternat you can try winNT or 2k Maybe that helps. Just use winecfg
@Linubie
Okey Linnubie, the problem is more difficult then just fix the preloader.
The problem is an overoptimzed Memory layout. So the fix cant be enhance because the fix is doing something similar to banging on a broken TV until you get your picture back.
The devs wont include this fix and they said already that they wont include the fix of Cadega. Atm no one has the time of them in looking into it. So you have no other choice then to wait a bit longer (and use Cadega).
Maybe the latest Kernel can do the trick? I think others mentioned that this does not work on 64 bit processors but I am not sure.
@Septor
Great if you could do that
Do you post the patch to the list or directly into cvs? - I never done this so don't know how the submitting a patch works _________________ quote from Spaceballs:
Dark Helmet:[...] we were told to comb the desert, so we're combing it! [puts down bullhorn] Find anything yet?!
Soldier: Nothing yet, sir. |
|
Back to top |
|
|
Septor Apprentice
Joined: 01 Sep 2004 Posts: 150
|
Posted: Thu Sep 01, 2005 9:53 am Post subject: |
|
|
Linubie wrote: |
As I read this, it seems to me you have developing access to wine, is there a way to include this libmemwrapper into wine and make it switchable on/off to make AMD64 users like me happy trying to preload this workaround, wich is not working in AMD64 environment.
|
I only have as much access as the rest of you... this is open source, all contributions are welcome. I do not have wine cvs access, but I have contributed patches in the past. I'll take a look at the libmemwrapper stuff since I am not familiar with it, and see if it is appropriate for inclusion in wine, and make an appropriate patch if it is. If it is just fuging with memory offsets etc I doubt it would get accepted into CVS. Things like registry settings are an easy patch though, and I doubt there are many reasons to reject one, but who knows. |
|
Back to top |
|
|
Waywocket Tux's lil' helper
Joined: 16 Dec 2003 Posts: 84 Location: York
|
Posted: Thu Sep 01, 2005 11:07 am Post subject: |
|
|
The 1.7 patch works fine for me without libmemwrapper (as I mentioned a while back). It would be nice if somebody on AMD64 could try the test server, but I think (hope?) Blizzard have fixed this one at last. |
|
Back to top |
|
|
Waywocket Tux's lil' helper
Joined: 16 Dec 2003 Posts: 84 Location: York
|
Posted: Thu Sep 01, 2005 11:14 am Post subject: |
|
|
Septor wrote: | ikataii wrote: | the -function did it for me. Nothing noticeable as far as detriment yet. Hooray for breaking wine to fix WoW |
Wierd, my previous post is not showing... must have cancelled it. Anyways I was just curious if people could try with glPolygonOffset(factor,-units) instead of -factor... it should be more accurate, if it works. Anybody add a debug statement there to see what sort of values WoW is throwing at glPolygonOffset()? |
No, that doesn't work - it actually makes it so that you can't see them even from overhead. The debug statement is already there; if you don't want to start turning on debug channels, you can always change the TRACE to a FIXME. I can't remember for certain, but I seem to recall it was using 2.3 and 0.3 for factor (depending on what was being drawn - I think the difference was for targetting circles and footprints). I'll get back to you on the rest...
[Edit: spleling]
Edit: No, I remembered that wrong. there are two different pairs of values - one 10 times the other, for some reason - (2.000031, -1.0) and (0.200003, -1.0). The latter appears once when loading the game in Ironforge. They both appear repeatedly when walking around in the snow outside. I really think it looks like Blizzard just made a mistake about the direction of the axis, since making ifactor negative solves the problem so completely. BTW, a description of the function can be found here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/opengl/glfunc03_87g4.asp for people who know what to make of it (personally I think I'm about 50:50 on understanding that description ) |
|
Back to top |
|
|
StratoFish n00b
Joined: 31 Aug 2005 Posts: 4
|
Posted: Thu Sep 01, 2005 10:38 pm Post subject: |
|
|
Nice one for working out that better sign-flipping version. OpenGL and Direct3D use different coordinate system and converting from one to the other involves flipping positive/negative values so it would have been easy for it to be left out in 1 place during the port.
What glPolygonOffset does is a bit off-topic here but a fairly quick version is -
Every time a polygon is drawn to the screen, a per-pixel depth buffer for the screen is checked so that it will be correctly hidden behind polygons that have already been drawn. This causes problems when 2 polygons share exactly the same plane such as a floor with a decal on it as they will be exactly the same depth in the existing depth buffer and the second one to be drawn should not be drawn where they overlap. Rounding errors can make this appear as a flickering, jagged version of what it should be depending on the angle you view the plane from. To get around that problem glPolygonOffset is used so that when a polygon is drawn it has a small amount added or subtracted to it's apparent depth. If it is shifted a bit towards the camera, it will then be drawn on top of the existing polygon, shifted away it will not be drawn as it is behind. This doesn't effect the actual position of the polygon, just the depth buffer check. _________________ Strato |
|
Back to top |
|
|
Waywocket Tux's lil' helper
Joined: 16 Dec 2003 Posts: 84 Location: York
|
Posted: Thu Sep 01, 2005 11:05 pm Post subject: |
|
|
Ah, thanks for that. I think it explains a point I was wondering about: I was kind of expecting that changing these values would leave the circles hovering a little above the ground, and was a little confused as to why that didn't seem to be happening. From what you say, this is because it doesn't actually change the *position* of what's drawn at all. It's nice to understand that now (assuming I've got that right ). |
|
Back to top |
|
|
Septor Apprentice
Joined: 01 Sep 2004 Posts: 150
|
Posted: Fri Sep 02, 2005 12:40 am Post subject: |
|
|
Waywocket wrote: | Ah, thanks for that. I think it explains a point I was wondering about: I was kind of expecting that changing these values would leave the circles hovering a little above the ground, and was a little confused as to why that didn't seem to be happening. From what you say, this is because it doesn't actually change the *position* of what's drawn at all. It's nice to understand that now (assuming I've got that right ). | Yup you got it. glPolygonOffset() only affects the depth check, not the actual values that go into the z-buffer (depthbuffer). It is an easy way to draw coplanar surfaces (such as the ground with footprints) without having to physically adjust the surface coordinates. It's also silly Blizzard hasn't fixed this by now... has anyone reported this into to them? |
|
Back to top |
|
|
legine Guru
Joined: 27 May 2004 Posts: 555 Location: Germany
|
Posted: Fri Sep 02, 2005 6:58 am Post subject: |
|
|
I think not. I'll do this afterbnoon if no one else does it.
I am on europe Servers. So it would be nice if some on the US Forums can report too. Jaust to be sure... _________________ quote from Spaceballs:
Dark Helmet:[...] we were told to comb the desert, so we're combing it! [puts down bullhorn] Find anything yet?!
Soldier: Nothing yet, sir. |
|
Back to top |
|
|
stobbsm Guru
Joined: 23 May 2004 Posts: 452
|
|
Back to top |
|
|
Waywocket Tux's lil' helper
Joined: 16 Dec 2003 Posts: 84 Location: York
|
Posted: Fri Sep 02, 2005 4:20 pm Post subject: |
|
|
I've just made a rather interesting discovery: using a 2.4 kernel (2.4.27 to be precise), the soud in WoW no longer has problems. I don't need to run the game niced, or increase the sound buffer, and there is no skipping or popping, at least using OSS. I've not yet tried getting into combat, but with every 2.6 kernel I've tried the music skips and pops painfully even in the loading screen, but with 2.4.27 it seems to be perfect.
On the downside, Shamus's mouse fix doesn't work with this kernel. I'm about to download the new test client patch, and see if it works there without libmemwrapper (as it did with 2.6.11).
Edit: Yes, it does. |
|
Back to top |
|
|
kmare l33t
Joined: 20 Nov 2004 Posts: 619 Location: Thessaloniki, Greece
|
Posted: Fri Sep 02, 2005 6:49 pm Post subject: |
|
|
actually I believe that the alsa driver is not working that well with wine... and in 2.6 oss is emulated via alsa... |
|
Back to top |
|
|
Waywocket Tux's lil' helper
Joined: 16 Dec 2003 Posts: 84 Location: York
|
Posted: Fri Sep 02, 2005 6:57 pm Post subject: |
|
|
kmare wrote: | actually I believe that the alsa driver is not working that well with wine... and in 2.6 oss is emulated via alsa... |
Good point. That's doubtless the reason. So is it possible to get native OSS sound with 2.6, anybody? I've never seen it mentioned, since ALSA's OSS emulation is as good as perfect for everything but Wine, AFAIK. |
|
Back to top |
|
|
philidias n00b
Joined: 02 Sep 2005 Posts: 6
|
Posted: Fri Sep 02, 2005 11:15 pm Post subject: |
|
|
Sweet world of warcraft looks awesome on linux |
|
Back to top |
|
|
kmare l33t
Joined: 20 Nov 2004 Posts: 619 Location: Thessaloniki, Greece
|
Posted: Sat Sep 03, 2005 2:11 am Post subject: |
|
|
Waywocket wrote: |
Good point. That's doubtless the reason. So is it possible to get native OSS sound with 2.6, anybody? I've never seen it mentioned, since ALSA's OSS emulation is as good as perfect for everything but Wine, AFAIK. |
yes.. you can still enable oss under 2.6 but it has the "deprecated" tag. It could be removed at any time... |
|
Back to top |
|
|
|