Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
Discussions Rules and Guidelines
Report this post
If DirectX is the only thing preventing SE to be recompiled under MacOS and Linux. Vulkan is a must and should be a top priority in the game industry.
PS: I just discovered the Vulkan API and I am really excited about it and it's implication in the game devs and Linux gaming evolution.
The only reason you'd switch to a cross-platform API when it offers no reasonable performance benefits (theoretical benefits aren't worth considering) is if you were planning to go cross-platform with the software as well. That would require moving away from C# first. You could argue that having the interfaces ready before changing the code is beneficial but that's a chicken/egg scenario right there.
Yes, I'm kind-of familiar with Mono, but it's still not finished either. Attempting to port unfinished code through an unfinished compiler using an unfinished API is just asking for trouble.
That being said the hype is that existing hardware will gain a significant boost compared to previous opengl verions and a boost compared to the windows 10 only directx 12. With vulkan you will still in theory be able to get next gen graphics on windows 7 as well as other platforms.
Understandably Vulkan should provide a boost over previous iterations of OpenGL, and probably also DirectX. Provided, of course, that the drivers are up to the task (historically, feature-equivalent OpenGL and DirectX implementations have favoured DirectX simply due to driver effacacy). It's a low-level API, after all, and that's the entire point of it. Given it's based largely on Mantle, however, and DirectX 12 is also based on Mantle it would be questionable as to which is actually a faster implementation until both are "in the wild".
Of course, the other issue is that Macs don't support Vulkan. Not officially, anyway (someone may have hacked it in). They support Metal instead, which is probably much the same but proprietary. Given Macs represnt a larger part of the market than Linux, that would arguably be an issue worth considering.
As such, the major draw for Vulkan would be that it supports Linux and versions of Windows earlier than 10. But for now DX11 is everything newer than XP, so the relative increase in audience isn't that great - plus the hardware and drivers would still need to support it (keeping in mind most non-DX11 cards are considered "legacy" and likely won't ever receive a Vulkan driver).
this being said, I would like to troll about the fact that I never understood why people would use C# as a develloping language. since 2003 I do know this ♥♥♥♥♥♥ language and since 2003 I found no interrest in it. I always prefer C++ over it because C# don't bring anything that deserve attention. By the way I also hated ASP since its birth because PHP is way better (since it is originally inspired from Perl)....
you says "But for now DX11 is everything newer than XP, so the relative increase in audience isn't that great", but the point is also to increase performances for users that don't use windows 10, and SE really need to increase performances a lot. AND most important point for me :) I want it to run on Linux natively without wine ;( 30 millions dollars of incoms over 2 years for a game that don't run on steam OS (linux), I am so sad ;(
PS: I will never, under any circonstances insall windows on my computer, 'cause I work with my computer.
If you're including non-x86 than, sure, I could easily understand Linux having a bigger market share. But it's also a pointless market share for the purposes of this conversation, since ARM lacks the power to even attempt to run SE and consoles won't be running in Linux anyway.
As to why someone's using C#? Who knows? I haven't really done a heck of a lot of programming since Pascal was a thing, and I used it because it's what I had - not because of any real preference to the language. Maybe their initial programmer was fluent in C# due to a misguided tertiary schooling program and they just went with it. Maybe it was just easier when they started. But porting it across to another language (eg C++) would be a massive task at this point.
And, lastly, yes, I'm well aware of the potential performance benefits of Vulkan. My point in bringing up DX11-class hardware was the number of people already being restricted in so much as they cannot use planets because they lack DX11-class hardware. Moving to Vulkan would do precisely nothing for them, and runs the risk of cutting out some DX11-class hardware as well by using features which require DX12-class hardware.
Back to mono, mono has a native binary ide and compilier for x86/x64 for windows, SE probably even uses it since it comes bundled with unity. I'm really not sure where you are getting the bad information about mono.
As for linux vs mac, mac has never really been a target as a game platform and is currently in the same position linux once was in, using wrapper libraries to make things work. I would also hope people aren't running x86 systems anymore, they are way past outdated and if you are running mac OS trust me you are running x86 or x64, apple stopped creating ppc proc many years ago for personal pc users.
I would like to point out that there is pretty much no reason not to have a DX11 or Vulkan compatible (OpenGL ES 3.1 or OpenGL 4.x) at this point, you can go mow a neighbors yard and have enough money to buy a compatible card that can play this game. I have zero sympathy for people who complain about not having hardware newer than 5+ years ago. Since it might come up I do have a complaint mentioned several times in the forums and in a review because of SE and my hardware being incompatible but it seems to be something to do with unity and specific ati cards not because I have massivly old system.
Don't worry, I am just trolling because, in my mind, SE is a geek kind of game, and linux is the geek OS. A lots of player of minecraft of my generation are on linux and I think this is the same market.
About C#, it was from the beginning, an attempts from microsoft to bring a windows-centric language and this was the only point of this language. This is mostly why I don't like it and says that there is no point in using it for developping softwares. I would use it for prototyping, proving concepts (as I did in the past with Perl or Python) but not for commercial products if this magnitude.
You say perhaps they use C# because "initial programmer was fluent in C#" ??? But what the hell are you speaking about, you don't choose language for this reason, you choose a language for it's advantages in solving your specific problems. It is very easy to learn new languages, but it is complicated to switch language in mid-development. For example: before needing to use Python I didn't knew anything about this language, But i did develop a framework in this language for a company that needed to complete its validation tools. I didn't choose this because I like it (in fact I hate it, because its logic is a little broken when you dig a little, and tricky part are not well documented), I choose it because it fit perfectly in the company expectation in terms of cost, integration (in existing tools) and functionnalities.
In the precise case of game development, the memory usage and CPU usage must be controled the best we can, so we need to keep a great control over ressources and C# do not allow that easy (it is difficult to predict how many intruction and how much memory a function will need to perform a task) so it is very difficult to predict the pre-requisit of an heavy software developed in this maner. Hopefully they use a physic engine (HAVOK) that is well developed (in C/C++/ASM) and optimized and use C# for 'lesser' matters (calls to libraries like SharpDX). But it still waste precious ressources (by adding overheads) that will not be used for heavy stuff.
My point here is not to re-write the world, but just to say that before you start somthing big, take you time to think everything very well. It might seems to be a waste of time when you take one or two month without writing a line of code. But in the end you gain a lot because when you start coding everything will go very smoothly and fast when you know exactly where you are going (you can devide task easily and optimize teamwork).
And when you go through a major update of a big software (let say from VRAGE 1.0 to 2.0) you should consider switching language because you should have already seen limits in the first version. You shouldn't count on the hardware evolution, because you will stay limited.
About bringing up DX11-class hardware to people ??? this is exactly what I am saying, Vulkan would not really help ??? maybe it will because it would force to rethink a little about the problems. It is possible to bring planets using DX9 but they refuse to do such an effort because the projet start on wrong bases to begin with and they count on the developing hardware to compensate their lake of pre-vision on those issues. Vulkan would allow to bring planet (if the problem is rethunk) and it could be faster than DX9.
By the way, NVIDIA announced that all their cards from series 400 to 900 will support vulkan (http://on-demand.gputechconf.com/siggraph/2015/presentation/SIG1501-Piers-Daniell.pdf). It can potentially bring new functionnalities provided by openGL ES 3.1 to openGL 4.5 for old hardwares (it will work from windows XP to 10, and linux). But I agree that rewriting the engine for Vulkan would be a major rewritting, but would be beneficient to solve many issues by rethinking them, sometime it is better to restart a project from scratch using the past experiences (it is not a waste of time).
PS: It is true that i like to do some C# bashing from time to time :)
What does Unity have to do with anything...? SE (and ME) run on VRage, which is being developed by Keen themselves. They do license a few things to use within it (eg Havok) but Unity has nothing to do with it. Empyrion is based on Unity, SE is not.
You also seem to be at odds with what an x86 system is. In one sentence you state that you "hope people aren't running x86 systems anymore, they are way past outdated" and then go on to say that "if you are running mac OS trust me you are running x86 or x64". So are you trying to say that people who use a Mac are running outdated hardware, ignoring that it's the dominant architecture for home PCs, or do you simply not know what exactly you're trying to say?
As for older hardware, that's not something which is easily changed. The game entered into early access with DirectX 9 listed as a minimum requirement, and anyone who can only run that would be justified in seeking restitution if that were no longer the case by the time it was released. The more additional features which require a newer API, the more basis they would have to those claims.
Though I'm sure that if you were willing to pay for all of the affected people to update their hardware, you could probably make the mistake go away. It sounds like your neighbours would be happy to provide the capital and then you could make a better pitch for the update.
PS. http://www.mono-project.com/download/#download-win
Note the only listed binary is for 32-bit.
In regards to gglobot:
I'm not exactly sure what you're trying to say directly and what's tongue-in-cheek, so I'm going to pick out a few bits and respond. If it's not good enough... well... yeah.
The "initial programmer" in this case is likely whoever helped make the proof-of-concept for Miner Wars (which used VRage 1). In your own words, C# is useful for making prototypes. But that means there was going to be existing C# code which could either be replaced or built off. Evidently they opted to build off of it, for better or worse.
You're referring to an established company with existing expectations. This is exactly where Keen is now, likely as a result of the work done originally on Miner Wars. The difference is they're expecting C# where Python was expected of you. Prior to Miner Wars there was likely no expectation at all, but someone somewhere evidently made a choice and it's stuck since then.
Though it is, of course, entirely possible that it is not the original choice. It may well have started in a different language again and was switched across to C#.
Because cards prior to DX11 won't have software support for it. You can't just load a new API onto a system and expect it to work without the interface between the API and the hardware. Since anything prior to DX11 is considered "legacy" by both major hardware vendors, it's extremely unlikely they'll ever receive a Vulkan HAL. As such it's as useful to them as DX11 is now.
By the way, why you always say x86 or x64 ? what you call x64 is no more than x86 with a 64bits instruction set. the correct denomination should be x86_64 but since it was introduced by AMD it is often called amd64