Bug reports improve quality. Most people appreciate voluntary QA which Linux users often provide. Unless they have no one to review them.
"No one to review them" is a red herring. The problem is, it costs money to review bug reports and take action on them, whether or not there is staff qualified to do so. There has to be a real present return, not an imagined future one, on providing support for a product on multiple OS. It is not laziness or ignorance, it is the need to make a profit and the need not to spend money or effort on what management cannot show will make a profit.
Last edited:
Does Witcher Supports OpenGL?
Does Witcher supports OpenGL. Or Witcher supports only DX?
Sorry for bad english. =)
Does Witcher supports OpenGL. Or Witcher supports only DX?
Sorry for bad english. =)
The Mac port of TW2 uses a DirectX 9 to OpenGL 3 translation layer. You can see this if you log OpenGL calls. This is a common tactic; a lot of games on Steam that have been ported to Mac do the same. So it's natively and structurally still DX9 and only looks like it supports OpenGL.
I don't think there will be such a convenient translation layer for DX11 and OpenGL 4. But since Red Engine 3 is capable of DX11 on PC and going right down to the sand on the consoles, I don't think the technical problems with a native OpenGL port (even if it has warts) are insurmountable. Market considerations (can we sell enough to justify the extra work?) may be the greater hindrance.
I don't think there will be such a convenient translation layer for DX11 and OpenGL 4. But since Red Engine 3 is capable of DX11 on PC and going right down to the sand on the consoles, I don't think the technical problems with a native OpenGL port (even if it has warts) are insurmountable. Market considerations (can we sell enough to justify the extra work?) may be the greater hindrance.
@Guy N'wah: That's what I meant by no one to review them. Not no one capable, but no one available to spend time on it. Others who have more resources appreciate the input, because it does improve quality overall. Those with more limited resources can't handle the load and can't dedicate people for review. So it depends on the situation. If they are flooded with bug reports they can't process - it doesn't worth it, because people waste their time reporting them and developers look bad as if they ignore them.
For example inXile explicitly ask to report bugs to them: http://inxile-entertainment.com/projects/the-bards-tale-linux
I did report a few in the Linux version of the Bard's Tale. And they review them and actually work on the fixes.
I think CDPR are perfectly capable of handling bug reports though. They aren't some one man studio.
For example inXile explicitly ask to report bugs to them: http://inxile-entertainment.com/projects/the-bards-tale-linux
I did report a few in the Linux version of the Bard's Tale. And they review them and actually work on the fixes.
I think CDPR are perfectly capable of handling bug reports though. They aren't some one man studio.
Last edited:
There are many reasons companies may be operating under resource restrictions. They may not have enough capital to staff, or they may not find qualified staff. But the reason I meant to emphasize is that there may be no business case for it. Bug reports are not free quality improvements: handling them costs money. If the cost of doing so does not furnish a profitable return (whether in increased sales, reduced technical effort, fewer returns, or even goodwill, but it must exceed costs by an acceptable rate of return), the right thing to do is not to do it.
Last edited:
I'd say it depends on the attitude as well. Some studios funded by legacy publishes might have more money but still ignore extra quality, as you said to increase profits. Others with less resources can still spend their effort on bug fixes, even though it reduces their pure profit. I don't think we are talking about the case when processing bug reports will negate their profit altogether and will make them work for loss.
Did you actually check that in the OS X release? Because before CDPR developers claimed that they use native OpenGL 3 core profile in TW2 on OS X. Otherwise why couldn't they use Wine for translation, same way they did with TW1 there?
Last edited:
Some people went to the trouble of running OpenGL logging on the game. Sure looks like a translation layer to me. Full post at http://portingteam.com/topic/8289-t...lly-on-mac-50-mac-games-on-gogcom/#entry90302
Code:
[thread 00000001][I]: NSWindow for window 0x4945c380 is 0x48482620
[thread 00000002][I]: Direct3DDevice9::Initialize()
[thread 00000002][I]: pParams: BackBufferWidth: 1680, BackBufferHeight: 1050, BackBufferFormat: D3DFMT_X8R8G8B8, BackBufferCount: 1
MultiSampleType = D3DMULTISAMPLE_NONE, MultiSampleQuality = 0
SwapEffect: D3DSWAPEFFECT_DISCARD, Windowed: false, EnableAutoDepthStencil: false, AutoDepthStencilFormat: D3DFMT_UNKNOWN
Flags: 0, Fullscreen_RefreshRateInHz: 0, PresentationInterval: 1
[thread 00000002][I]: Available video memory: 1073741824
[thread 00000002][I]: Available texture memory: 1021313024
[thread 00000002][I]: Direct3D -> OpenGL context information:
[thread 00000002][I]: renderer: NVIDIA GeForce GTX 285 OpenGL Engine
[thread 00000002][I]: vendor: NVIDIA Corporation
[thread 00000002][I]: version: 3.2 NVIDIA-8.0.61
[thread 00000002][I]: GLSL version: 1.50An interesting find. So they took a shortcut, just a bit more involved than with the first game. It explains why they couldn't just reuse the OpenGL code in the newer REDengine - because they didn't have it 
So to enable OpenGL they need to start from scratch to some degree. I hope when they'll get to it, they'll actually work on native approach, instead of shortcuts with translation. Later they can also reverse it, and use OpenGL even in the Windows version.
So to enable OpenGL they need to start from scratch to some degree. I hope when they'll get to it, they'll actually work on native approach, instead of shortcuts with translation. Later they can also reverse it, and use OpenGL even in the Windows version.
Last edited:
Last edited:
+1 for Linux here!
When i read about Lars Gustavsson said that it would only take one "killer" game for Linux to break into mainstream gaming, The Witcher 3 was the first game that came in my mind. Of cource a exclusive game would be more effective, but a release with a week or two before than Windows would just work right now. I know that releasing a game for Linux have a lot of problems. The best way to support all distros is giving a tar.gz a leaving the player do the dirty job, but this is terrible fom a brad new game! Doing deb/rpm packages needs some practices and knowhow with the autotools.
When i read about Lars Gustavsson said that it would only take one "killer" game for Linux to break into mainstream gaming, The Witcher 3 was the first game that came in my mind. Of cource a exclusive game would be more effective, but a release with a week or two before than Windows would just work right now. I know that releasing a game for Linux have a lot of problems. The best way to support all distros is giving a tar.gz a leaving the player do the dirty job, but this is terrible fom a brad new game! Doing deb/rpm packages needs some practices and knowhow with the autotools.
@Ziuloliveira: Welcome to the forum! It looks like CDPR are already working on the Witcher 2 for Linux. Witcher 3? So far there are no news about it, but let's hope. GOG is rolling out Linux support later this year, so they'll have to figure out how to do it. Knowing GOG I expect it to be something more than simply tarballs. Package manager is something they want to avoid probably. So let's wait and see. It's really a whole pile of exciting Linux gaming news in such a short time.
I agree that Witcher 3 on Linux would be a huge breakthrough. But even Witcher 2 would be a major milestone as well.
I agree that Witcher 3 on Linux would be a huge breakthrough. But even Witcher 2 would be a major milestone as well.
Last edited:
Since I have been doing Linux packaging and showing others how to do it right for a while now, I'm not sure avoiding package management is that good of a way to go. Trying to ship tarballs and provide instructions adds no value and causes a lot of labor in tech writing and tech support. Going outside package management with a proprietary installer is a surefire way to land yourself in shared object hell. But packaging done right allows the product itself to specify what it must have and cannot get along with, it allows the installer to acquire and set up everything seamlessly, and it allows the installed game to keep up with kernel changes and prevent inadvertent updates that would break it. Even Windows installers force you to do things like go out and get stuff like Visual C++ or DirectX or Java or Flash runtimes. RPMs or Debian packages could be made free of those warts.
Last edited:
Shared object mess can be avoided by proper bundling and properly build executable. It has nothing to do with package management really. The downside of package manager is its inflexibilty. I.e. for example you can't specify the target directory and it's susceptible to system changes. Since GOG especially is very concerned with long term support and potentially better cross ditro coverage, they want their deployment to be as isolated from system internals as possible (bundling, independent installation management, potentially using containers for security or something like Docker and etc. are all going in that direction). That seems to be the proposed approach which Valve takes, and it's recommended by Ryan Icculus Gordon for example. The installer doesn't need to be proprietary. There are open source solutions, and it's even strongly advisable for GOG to keep it open, to preserve trust by avoiding any closed code which targets system modification.
Last edited:
Looks like Virtual Programming are working on the Linux version of the Witcher 2. These are the same folks who ported it to OS X (see http://www.vpltd.com/news/. I didn't know before that the port was outsourced).
At least it can be assumed from this log which someone discovered:
http://steamdb.info/app/20920/#section_history
At least it can be assumed from this log which someone discovered:
http://steamdb.info/app/20920/#section_history
Code:
Changed oslist – windows,macos,[color=red]linux[/color]
branches/[color=red]vp_beta[/color]/buildid
Last edited:
@Marcin Momot: Can you please relay this message to the developers who work on the Witcher 2 for Linux? Some recent games which are ported to Linux store their local settings and saved games and etc. in some custom directory in $HOME (for example $HOME/.witcher2 or something of that sort). While such practice was a norm in the past, it clutters $HOME and according to the XDG base directories specification it's not the right way of doing it.
I.e. for example, according to the standard spec, config files should go into $HOME/.config/witcher2, while some other local files (such as saved games and etc.) can go into $HOME/.local/share/witcher2 and so on. Unfortunately, a lot of porters of games aren't familiar with this standard and continue using old method which clutters the home directory. I hope TW2 developers can avoid this, so it's better to inform them in advance, just in case they aren't familiar with this issue.
I.e. for example, according to the standard spec, config files should go into $HOME/.config/witcher2, while some other local files (such as saved games and etc.) can go into $HOME/.local/share/witcher2 and so on. Unfortunately, a lot of porters of games aren't familiar with this standard and continue using old method which clutters the home directory. I hope TW2 developers can avoid this, so it's better to inform them in advance, just in case they aren't familiar with this issue.
Last edited:
@mairon: I doubt even latest mobile GPUs are capable of running demanding high end games like Witcher 3. Witcher 1 on the other hand is more realistic, but all Witcher games interfaces are designed either for keyboard and mouse or for controllers, so unless you want to attach a keyboard or a gamepad to your tablet, it will require rewriting the UI.
I'd be more interested in games for Sailfish, rather than for Android. Android isn't really well suited for multithreading, since bionic libc has various deficiencies by design (it's a pity Android adopted bionic to begin with, but it's a separate story). So all those extra cores are often underused. glibc based mobile Linuxes are more efficient on the same hardware.
That all said, CDPR are working on some mobile games, they already mentioned that in the past.
I'd be more interested in games for Sailfish, rather than for Android. Android isn't really well suited for multithreading, since bionic libc has various deficiencies by design (it's a pity Android adopted bionic to begin with, but it's a separate story). So all those extra cores are often underused. glibc based mobile Linuxes are more efficient on the same hardware.
That all said, CDPR are working on some mobile games, they already mentioned that in the past.
Last edited: