Bandwidth estimation based on TFP-friendly rate control (RFC 5348)

Wow, cool ... Wasn't aware we were already that important that a company like Valve would do stuff especially for us :D

View this comment - View article - View full comments

Not sure when the switch to SDL2 happened (at least I think it already did), maybe that's related?

Quoting: GuestWell duh, if nobody tests anything (yes I know that’s an exaggeration), that happens.

Well, to be fair though due to high number of combinations of HW, drivers, libraries, desktop environments and what not for every tester you have for Windows you might need like 10 for Linux. While the userbase on Linux is more like 1/50th of that of Windows. So yeah, it's really hard to argue for doing even more testing on Linux than (hopefully) already done :(

Of course you could try with beta branches and hope the community jumps in on that, as obviously they can easily cover a lot more of those combinations than a dev ever could.

View this comment - View article - View full comments

Being able to fix bugs in a Linux build of a game, directly on Linux, now that's going to be useful I hope.

Thing is ... in our experience bugs on Linux were almost never code related (besides the nasty locale-usage on e.g. float-parsing that only happens on Linux players) but mostly graphics/shader stuff. So unless we get better debug tools for shaders I don't see much of an improvement here besides being able to build a player directly on the platform. But having another PC on the same network is almost the same speed anyway.

This is just about it improving debugging on Linux, of course having an officially supported editor on Linux in general is really nice :)

View this comment - View article - View full comments

Quoting: ElectricPrismor they're working on something else very quietly like a new VR Vulkan 1st class game that will crank some juice & high FPS.

Oh fuck YEAH ... A VR Portal 3, now *that* would be nice and could get me buying a VR device :D

View this comment - View article - View full comments

Quoting: Alm888NO! It is not you who have Linux-specific bugs! It is Unity3D game engine. And if you are using commertial version then Unity3D-devs are obliged to provide you working engine. Go, hit them with something big and heavy! All of the Linux community will be grateful!

lol`ed
Hate to have to say that but paying for a product nowadays is in no way helping you getting support. Made that experience with both Valve and UnityTechnologies. Getting replies at all is hard enough, even more getting actual help. (Tak's a really big exception here but he's "just" responsible for some Linux stuff, not everything ;) )
Not even being able to talk to anyone makes hitting them with something big harder as well.

View this comment - View article - View full comments

I wouldn't just look at the gross sale numbers in this regards. First of all it's always hard to figure who buys for what platform or if someone wouldn't have bought a game if it was/was not available for Linux etc... So real benefit in terms of money is hard to get right imho.

But there's also another point in supporting OSX/Linux: it shows interest in the users demands, often gives positive public reception, sometimes even (indirect) advertisment like in this case.

As Unity and its "just push Linux export" was already mentioned here... It's obviously not that simple yet. But I'd argue it's very close to that. Most of our issues have always been shader/graphics related, as WorthlessBums also said. But unfortunately that's not a minor issue as debugging that stuff is very annoying, even more so with theamount of HW/driver/distribution combinations.

Of course there's other stuff too, like file I/O (can be handled quite easily if you do care about a few things though), locales (the Linux player of Unity is the only one which cares about the system locale, resulting in issues with float/datetime parsing so you have to explicitly use culture invariant parsing), or RNGs behaving different. Nothing taking too much time in my experience.

Native code can also become an issue if you use stuff that's not available for those platforms bjt you can typically avoid that. Since like half a year now even the Steam API can be fully used, including Linux x64 builds (was crashing on some parts before).

But after having all that sorted out ... you still won't get only happy users. There's seemingly random crashes for some (luckily the minority) in the Unity players without any useful feedback for a dev in the logs. That's where working on that platform really gets annoying, even if you really want to get it to work (like myself, been working on the Linux support even before I was part of the company ;) ).

All in all I'd say with an engine like Unity3D supporting Linux/OSX is definitely worth it, as the required work to get it working for the majority of those users is *relatively* low and you get happy (/happier) customers in return.

View this comment - View article - View full comments

I hope developers stick to this, and I hope those who don't have their feature list adjusted if they do not.

Actually I doubt most will as exactly their special API stuff *heavily* sucks for any dev that does not want to *only* support the Steam Controller (or in future the pads supported by Steam's API) as you basically have to implement two completely different sets of input support (e.g. kbd/mouse/controllers vs Steam Input). That's not good for any code design at all :(

View this comment - View article - View full comments

Yay, we finally made it to a positive article :)
Just nitpicking here but English has been in there since the first release ;)

Also recommend trying the GLCore renderer, as that seems to look better / more the way it's meant to be. Just not the default yet as it's not had widespread testing.

View this comment - View article - View full comments

Having it installed on our couch PC too now as I didn't use that PC lately anyway (netflix, amazon, youtube is all done directly on the TV so no need to boot up another PC just for that). Mainly for testing our game's compatibility with that distro as it seems it *is* different in some terms to a "normal" desktop Linux installation (which is running on my notebook anyway).

Thing is: That machine only has an Intel GPU (think second gen Core i) and while it would be good enough in terms of performance, at least for testing purposes, the BPM heavily flickers all the time. Especially while there's any kind of input from any controller. Up to a degree of having like 50% of the time being black. From a short research it seemed that this applies to most Intel GPU users (and does *not* affect game rendering, desktop mode, terminals).

Yes, I know, those GPUs aren't meant for gaming in the first place, but they work just fine as long as you don't play the latest and greatest titles in full HD at max quality settings. And the BPM isn't even a highly demanding game, it's basically just a menu UI. Don't get why they can't get that part to work, even more so as the Intel drivers are typically the most stable ones.

Regards,
Chris

View this comment - View article - View full comments

Wondering about performance though which already seems to be still lacking a bit behind Unity's DX implementation. Would have expected it to be even lower then when "directly" talking to the windowing system (though I actually thought it would more or less talk directly to some OpenGL stuff?) instead of having SDL as an additional layer in between?

View this comment - View article - View full comments