C4 Engine Drops Linux Support, Calls It "Frankenstein OS"

[yogi_berra]

Do you run games as root?

He probably doesn't run games at all thanks to Steam's deleting everything owned by the user. Well played, Valve.

[Kano]

Most likely he used sh not bash, that causes problems. Everything with "function" or "==" is a bashism, would be simple to fix those. The .sh suffix is irritating and the code itself is not safe. I am sure I reported it somewhere too, just not on github as I don't want to create an account there.

[Mat2]

I am reading https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes and begin to think that this guy is right:

Known issues:
- Automatic install is broken on drives that contain partitions that either do not have an operating system installed (eg. a user data partition like /home on Linux or D: on Windows), or partitions that have Windows 8 installed. Selecting automatic install (or upgrade) on these systems will result in the whole drive being wiped and all existing data will be lost. There are also problems dealing with systems with multiple drives. This bug is present in released media of 14.04 and 14.04.1. If you have a drive with any pre-existing partitions, or multiple drives, then you should use manual partitioning. Ensure you have backups. (1265192)

[...]
Upgrade:

- Automatic upgrade on drives containing user data partitions, including from other operating systems, and all Windows 8 systems, will result in the whole drive being wiped and all existing data will be lost. This bug is present in released media of 14.04 and 14.04.1. If you have a drive with any pre-existing partitions, or multiple drives, then you should use manual partitioning. Ensure you have backups. (1265192)

- Configuration of the package tex-common fails when 12.04 LTS is upgraded to 14.04 LTS (1304972)
- Configuration of flightgear fails during upgrade from 12.04 LTS to 14.04 LTS (1308338)

The worst thing is that this bug is not fixed in 14.04.1. I like the sentence "Ensure you have backups." the most.

That's a LTS release and users will expect it to be more stable then "normal" releases.

[Mat2]

The famous bug in kernel that resulted in several models of Samsung laptops being bricked
https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557
also took an awful lot of time to fix (over a half a year AFAIK).

[sepul]

He is maybe right about linux game dev being harder than win/osx.
But most problems are because of OpenGL (compared to D3D), and mostly closed source stuff like bad official drivers. Not the linux itself.

Maybe he should open-source his engine and let the community help him.

[johnc]

He is maybe right about linux game dev being harder than win/osx.
But most problems are because of OpenGL (compared to D3D), and mostly closed source stuff like bad official drivers. Not the linux itself.

Maybe he should open-source his engine and let the community help him.

I don't mean to bludgeon a dead horse but it's important to reiterate that he says his engine works perfectly fine on Linux, and has no problems developing for the platform. The problems he encountered were related to installing and setting up his OS.

[Kano]

I never saw automated partitioning fully working if there are already partitions on a drive, it was possible with very simple configurations but for Kanotix we removed the automatic a few years ago. It is better to ask in the IRC/forum how to partition the drive for a specific purpose than relying on auto mode. In most automatic installers the last partition on a drive gets resized, 2 partitions added for / and swap (even if there are swap partitions already there), some like Fedora setup a boot partition as well. The last time I tested Fedora (just to use something with rpm again) the installer was pure crap in manual mode, it took some time to figure it out and not to wipe something... For noobs best: get a ssd/hd purely for Linux, disconnect everything else, partition like you wish or try automatic. If you need to access Windows 8 NTFS/FAT partitions: run in as admin inside Windows: "cmd" (ctrl+shift+enter) this: "powercfg -h off". This disables suspend (hibernate) and fast startup (Windows 8+).

[Shoost]

He is maybe right about linux game dev being harder than win/osx.
But most problems are because of OpenGL (compared to D3D), and mostly closed source stuff like bad official drivers. Not the linux itself.

Maybe he should open-source his engine and let the community help him.

C4 uses OpenGL. I'd argue that OpenGL is better than DirectX in most respects but it is a pain to use a bunch of extensions.

As far as performance and drivers go, he has apparently had no issues. This is helped because the engine doesn't have outside dependencies like STL, PhysX, Audio libraries etc. these are all replaced by c4-specific versions. This also reduces the complexity and improves stability for people using the C4 as well.

[maokei]

He is maybe right about linux game dev being harder than win/osx.
But most problems are because of OpenGL (compared to D3D), and mostly closed source stuff like bad official drivers. Not the linux itself.

Maybe he should open-source his engine and let the community help him.

So what do you think OSX uses? it sure isn't DirectX 3D.

[sepul]

C4 uses OpenGL. I'd argue that OpenGL is better than DirectX in most respects but it is a pain to use a bunch of extensions.

Yeah I* know. It sucks because developing under OpenGL* is much harder than D3D* especially if you are a single developer and want to implement some newer graphic features and also maintain portability and speed between different platforms.
And of course, The guy complaining about linux itself, is not right.

So what do you think OSX uses? it sure isn't DirectX 3D.

Yeah I know OSX* uses GL, but doesn't change the fact that D3D* programming is easier than OpenGL. even on OSX.
On linux it's even harder because you have many different drivers, with different features and performances. And the overall quality of all of them are inferior to windows/d3d.

On D3D* you have nice features like unified intermediate shading code where you can compile your shader once and run it on every graphic card that supports the API with no problems (Unlike GL). Another example is that D3D* drivers suffers minimal performance cost from Locking (Mapping) buffers, but still, on GL* there can be abysmal performances with locking buffers, and you have to do all kinds of Sync tricks to even get closer to D3D* performance. Of course there are Extra _New_* extensions that can help you with that, but they are not portable across hardware and can complicate the code design in case of multi-platformness.
So my point is, it's just harder to achieve same speeds with GL* than D3D. Some thing like Unreal4 can pull it off, but for a single developer it's a big thing.

I also don't want to raise another flame war of GL vs D3D. Just wanted to point out that I had very much difficulties developing in OpenGL* compared to D3D, and not the linux and the tools itself. So I think the argument about problems installing linux and using programs is rather stupid - If he didn't mean driver mess or the API* itself.