Any plans for the native 64-bit Linux version?
Re: Any plans for the native 64-bit Linux version?
Out of curiousity, could you also post the contents of your myth_log.txt? We have some settings over OpenGL use in Myth - perhaps one of them might help you - but first let's see what its defaulting to on your system.
-
- Posts: 27
- Joined: Mon Jan 16, 2012 3:54 pm
Re: Any plans for the native 64-bit Linux version?
Here's my myth_log.txt:
2012-01-20 22:09:01
Myth II 32-Bit Build 377 running under Linux ----------------------------------------------
Loading poweruser.txt... not found.
Scanning for software devices...
Found 1 to use
Scanning for OpenGL devices...
Found 1 to use
Mesa DRI Intel(R) Sandybridge Mobile | Tungsten Graphics, Inc | OpenGL 2.1
INFO: Loaded OpenAL library 'libopenal.so'
Loading Patch Files...
Patch 1.2
Patch MariusNet
Patch 1.3
Patch 1.4
Patch 1.4 Interface
Patch 1.5
Loading Patch Files Succeeded
Loading saved game "001" ...
Running OpenGL at 1366 x 768 (VSync ON)
Starting mesh "Crow's Bridge" with 1 plugin...
Magma - The Fallen Levels v2
Using 1.7.2 gameplay...
OpenGL: initialized with ErasePreviousFrame=0, Use32BitTextures=1, UseAppleClientStorage=1, UseDepthTest=1, UseShaders=1, UpdateCMapChunked=1
Quitting single player game...
Closing Myth.
It could be that the original SDL.a you guys use plays a role in combination with a build environment, in which case we solved the environment but not the SDL...
NB: I tried running with or without the Magma The Fallen Levels V2 plugin so that has no bearing on the issue.
EDIT: This is probably a long-shot but I just realized I've installed my game from the Total Codex I had bought a long time ago. It's a 3 or 4-CD collection that has both Myth 1 and 2 plus bunch of additional content. Could it be that that installer has somehow differently stored textures that might be the cause of this problem?
2012-01-20 22:09:01
Myth II 32-Bit Build 377 running under Linux ----------------------------------------------
Loading poweruser.txt... not found.
Scanning for software devices...
Found 1 to use
Scanning for OpenGL devices...
Found 1 to use
Mesa DRI Intel(R) Sandybridge Mobile | Tungsten Graphics, Inc | OpenGL 2.1
INFO: Loaded OpenAL library 'libopenal.so'
Loading Patch Files...
Patch 1.2
Patch MariusNet
Patch 1.3
Patch 1.4
Patch 1.4 Interface
Patch 1.5
Loading Patch Files Succeeded
Loading saved game "001" ...
Running OpenGL at 1366 x 768 (VSync ON)
Starting mesh "Crow's Bridge" with 1 plugin...
Magma - The Fallen Levels v2
Using 1.7.2 gameplay...
OpenGL: initialized with ErasePreviousFrame=0, Use32BitTextures=1, UseAppleClientStorage=1, UseDepthTest=1, UseShaders=1, UpdateCMapChunked=1
Quitting single player game...
Closing Myth.
It could be that the original SDL.a you guys use plays a role in combination with a build environment, in which case we solved the environment but not the SDL...
NB: I tried running with or without the Magma The Fallen Levels V2 plugin so that has no bearing on the issue.
EDIT: This is probably a long-shot but I just realized I've installed my game from the Total Codex I had bought a long time ago. It's a 3 or 4-CD collection that has both Myth 1 and 2 plus bunch of additional content. Could it be that that installer has somehow differently stored textures that might be the cause of this problem?
Re: Any plans for the native 64-bit Linux version?
Try this:
Create a file called "poweruser.txt" in your preferences folder with the following contents:
See if that helps.
Create a file called "poweruser.txt" in your preferences folder with the following contents:
Code: Select all
[Renderer.OpenGL]
UseShaders=false
-
- Posts: 27
- Joined: Mon Jan 16, 2012 3:54 pm
Re: Any plans for the native 64-bit Linux version?
OK, tried that as well as every other flag available in the log without luck. So, eventually I ran with everything disabled and still nothing:
2012-01-21 11:58:32
Myth II 32-Bit Build 377 running under Linux ----------------------------------------------
Loading poweruser.txt... OK.
Scanning for software devices...
Found 1 to use
Scanning for OpenGL devices...
Found 1 to use
Mesa DRI Intel(R) Sandybridge Mobile | Tungsten Graphics, Inc | OpenGL 2.1
INFO: Loaded OpenAL library 'libopenal.so'
Loading Patch Files...
Patch 1.2
Patch MariusNet
Patch 1.3
Patch 1.4
Patch 1.4 Interface
Patch 1.5
Loading Patch Files Succeeded
Loading saved game "001" ...
Running OpenGL at 1366 x 768 (VSync ON)
Starting mesh "Crow's Bridge" with 1 plugin...
Magma - The Fallen Levels v2
Using 1.7.2 gameplay...
OpenGL: Forcing UseMipMaps=0 because UseShaders=0
OpenGL: initialized with ErasePreviousFrame=0, Use32BitTextures=0, UseAppleClientStorage=0, UseDepthTest=0, UseShaders=0, UpdateCMapChunked=0
Quitting single player game...
Closing Myth.
(notice all things were disabled in the second OpenGL line towards the end)
2012-01-21 11:58:32
Myth II 32-Bit Build 377 running under Linux ----------------------------------------------
Loading poweruser.txt... OK.
Scanning for software devices...
Found 1 to use
Scanning for OpenGL devices...
Found 1 to use
Mesa DRI Intel(R) Sandybridge Mobile | Tungsten Graphics, Inc | OpenGL 2.1
INFO: Loaded OpenAL library 'libopenal.so'
Loading Patch Files...
Patch 1.2
Patch MariusNet
Patch 1.3
Patch 1.4
Patch 1.4 Interface
Patch 1.5
Loading Patch Files Succeeded
Loading saved game "001" ...
Running OpenGL at 1366 x 768 (VSync ON)
Starting mesh "Crow's Bridge" with 1 plugin...
Magma - The Fallen Levels v2
Using 1.7.2 gameplay...
OpenGL: Forcing UseMipMaps=0 because UseShaders=0
OpenGL: initialized with ErasePreviousFrame=0, Use32BitTextures=0, UseAppleClientStorage=0, UseDepthTest=0, UseShaders=0, UpdateCMapChunked=0
Quitting single player game...
Closing Myth.
(notice all things were disabled in the second OpenGL line towards the end)
Re: Any plans for the native 64-bit Linux version?
It looks like something is going wrong with the sprite texture borders or texture coordinates. I'm assuming it's an issue with the texture itself since we don't see any problems along the polygon diagonal.
Only thing I can think of is premultiplied alpha and border colors not working for some reason (since IIRC 1.7.2 Linux is a branch of the 1.8 rendering path), but if that happens even when you disable shaders (which also disables premultiplied alpha), I'm at a loss.
I assume you're using new video drivers, etc.? I don't really recall what the relationship of "mesa" is to Intel when it comes to drivers. Are these effectively open source driver implementations of the hardware spec? Is there an "official" driver at all or only that?
Only thing I can think of is premultiplied alpha and border colors not working for some reason (since IIRC 1.7.2 Linux is a branch of the 1.8 rendering path), but if that happens even when you disable shaders (which also disables premultiplied alpha), I'm at a loss.
I assume you're using new video drivers, etc.? I don't really recall what the relationship of "mesa" is to Intel when it comes to drivers. Are these effectively open source driver implementations of the hardware spec? Is there an "official" driver at all or only that?
-
- Posts: 27
- Joined: Mon Jan 16, 2012 3:54 pm
Re: Any plans for the native 64-bit Linux version?
Intel drivers are integrated into Xorg and actively maintained with contributions from Intel so that is as official as it gets. That said, there is only open-source driver. I completely agree that something funny is happening with alpha calculation and that could still point to a driver as Sandy Bridge iteration of the hardware is still fairly new. The driver I am running is the latest available (even newer than Oneiric). I did try this with Oneiric driver originally and the artifacts made me try newest driver in hope that would fix problems.
Indeed the problem is only with 2D textures applied inside OpenGL. Texturing (transparent or not) on a 3D object works just fine.
Indeed the problem is only with 2D textures applied inside OpenGL. Texturing (transparent or not) on a 3D object works just fine.
Re: Any plans for the native 64-bit Linux version?
Can you try the following:
-Ensure [Renderer.OpenGL]UseShaders=false is set, as described above.
-Turn on 3D fog in preferences
-Run the second level, "salvation"
(To get to the second level without playing the first, hold shift while clicking new game.)
Tell me if the black rectangles are still visible.
EDIT: Also, have you tried running the 1.7.2 Windows version under Wine? I'm curious if the issue would also show up there.
-Ensure [Renderer.OpenGL]UseShaders=false is set, as described above.
-Turn on 3D fog in preferences
-Run the second level, "salvation"
(To get to the second level without playing the first, hold shift while clicking new game.)
Tell me if the black rectangles are still visible.
EDIT: Also, have you tried running the 1.7.2 Windows version under Wine? I'm curious if the issue would also show up there.
-
- Posts: 27
- Joined: Mon Jan 16, 2012 3:54 pm
Re: Any plans for the native 64-bit Linux version?
Tried the test and still the same...
http://img213.imageshack.us/img213/4469 ... rtifac.png
I will try to install it through Wine and let you know.
EDIT: Oh, the irony... I installed Myth2 (from the Total Codex that I purchased many years ago), and patched it with your 1.72 patch for Windows, and lo and behold no artifacts... So, Wine is fine (OpenGL) but native isn't...
http://img213.imageshack.us/img213/4469 ... rtifac.png
I will try to install it through Wine and let you know.
EDIT: Oh, the irony... I installed Myth2 (from the Total Codex that I purchased many years ago), and patched it with your 1.72 patch for Windows, and lo and behold no artifacts... So, Wine is fine (OpenGL) but native isn't...
Re: Any plans for the native 64-bit Linux version?
Melekor: So it must be something in the (1.8-ish) path that we're using in the 1.7.2 Linux version?
Re: Any plans for the native 64-bit Linux version?
The fog+no shaders test rules out the border pixel blending theory punk suggested.
I'm not sure how to interpret the wine result yet, since it still doesn't explain why we've only seen this issue on a single machine.
I'm not sure how to interpret the wine result yet, since it still doesn't explain why we've only seen this issue on a single machine.
-
- Posts: 27
- Joined: Mon Jan 16, 2012 3:54 pm
Re: Any plans for the native 64-bit Linux version?
What is however curious is that even the Ubuntu Oneiric version you guys compiled for me is throwing out errors suggesting that some globally defined struct or data is redefined and hence it fails when fully dynamically linked. Are you guys using a customized version of SDL?
Another thought is that when the aforesaid version was provided to me, based on correspondence above it appears you used previously compiled SDL rather than the native Ubuntu Oneiric one. Again, is this because there is something you guys have customized inside libSDL.a, or? If not, perhaps trying to compile it with native libSDL.a would make sense to fully eliminate any external variables... After that, knowing that Aquaria problem has been fixed on my machine, my only idea would be something inside the code...
Another thought is that when the aforesaid version was provided to me, based on correspondence above it appears you used previously compiled SDL rather than the native Ubuntu Oneiric one. Again, is this because there is something you guys have customized inside libSDL.a, or? If not, perhaps trying to compile it with native libSDL.a would make sense to fully eliminate any external variables... After that, knowing that Aquaria problem has been fixed on my machine, my only idea would be something inside the code...
Re: Any plans for the native 64-bit Linux version?
If you are referring to this one: "Inconsistency detected by ld.so: dl-close.c: 743: _dl_close: Assertion `map->l_init_called' failed!", I found out that is caused by not calling dl_close on the OpenAL library before the process exits. It's not a real problem since the OS will clean up the resources automatically, but I'll fix it for the next release for the sake of getting rid of the message.flabbergastedpickle wrote:What is however curious is that even the Ubuntu Oneiric version you guys compiled for me is throwing out errors suggesting that some globally defined struct or data is redefined and hence it fails when fully dynamically linked.
Nope. Just a statically linked 1.2.14 which we compiled ourselves as Myrd detailed earlier.Are you guys using a customized version of SDL?
I've attached a version here compiled with the native Oneiric SDL. This build also calls dl_close so that warning message should be gone. I expect this won't solve the problem, but let's see...Another thought is that when the aforesaid version was provided to me, based on correspondence above it appears you used previously compiled SDL rather than the native Ubuntu Oneiric one.
- Attachments
-
- Myth2_1.7.2_oneiric_sdl.7z
- (1.97 MiB) Downloaded 317 times
-
- Posts: 27
- Joined: Mon Jan 16, 2012 3:54 pm
Re: Any plans for the native 64-bit Linux version?
Indeed, no difference unfortunately...
-
- Posts: 27
- Joined: Mon Jan 16, 2012 3:54 pm
Re: Any plans for the native 64-bit Linux version?
That is totally a plausible explanation for what's happening. We indeed use border color (i.e. clamp to border) when using the OpenGL 2.0 shader path to return a premultiplied alpha of "0" at borders and thus interpolate correctly at edges. This is a 1.8-specific improvement to the rendering of sprite edges, but as we discussed, 1.7.2 is a branch from that tree.
But then again, that doesn't explain why it still happened when you disabled shaders, as Melekor noted, so who knows.
Anyways let us know if their fix works for Myth.
[Edit] Actually looking at the code, UseShaders doesn't always equal non-pow-2 textures (which is what currently triggers the clamp to border color code), although it does *default* to it (i.e. if it's the first time you ran the Myth 2 application). Could you try the Salvation/fog test again with both UseShaders=false *and* UseNPO2Textures=false under OpenGL?
But then again, that doesn't explain why it still happened when you disabled shaders, as Melekor noted, so who knows.
Anyways let us know if their fix works for Myth.
[Edit] Actually looking at the code, UseShaders doesn't always equal non-pow-2 textures (which is what currently triggers the clamp to border color code), although it does *default* to it (i.e. if it's the first time you ran the Myth 2 application). Could you try the Salvation/fog test again with both UseShaders=false *and* UseNPO2Textures=false under OpenGL?