Quoting: kf

- Unless running via a .sh (LD_LIBRARY_PATH=./lib:$LD_LIBRARY_PATH DISPLAY=:0 stdbuf -i0 -o0 -e0 ./MainBinary), native extensions (.so) cease to load correctly.

Isn't this standard when you ship games that require specific versions of libraries? I've even seen many steam games do this even with the steam runtime avaliable.

Yes, it's basically the equivalent of how they on Windows have to bundle all their external dependencies and install them in the same folder as the game (and thus users have millions of the same DLL:s on their hard drives).

If only writers of shared libraries would think more about backwards compatibility...

View this comment - View article - View full comments

Quoting: chancho_zombieafter trying with a second visa debit card, over steam, it finally worked!! you are right @Comandante Ñoñardo, debit cards work!! but not all of them.

Are you sure that it's not some geographical security setting on your VISA? On my bank I can select and deselect various geographical regions where my VISA can be used, the default is enabled for my local country only.

View this comment - View article - View full comments

Quoting: MayeulC

Quoting: F.Ultra

Quoting: MayeulCI remember a game that lasted me six months, singleplayer on civ V (biggest map, slow time). But not every game is like this.

Usually, playing with your friends as an ally is less boring, as they can see your troops.

This is also a good candidate as a "mail-chess"-like (see freeciv 2's website).

A bit sad to hear this. Would love to hear the complete technical analysis of what happens here. The function names, actual differences, etc.

Is it floating point related, RNG related, other? Wine doesn't seem to have a problem with this. Wouldn't using some parts of winelib help? (It is LGPL, so definitely linkable against).

Wine does not experience this problem, but it will also not fix it. Because the difference in the floating points are due to the compiler (yes different math libraries can also cause this but there is a basic difference on the compiler level) so one fix would of course be to force all windows devs to compile with gcc, but for some strange reason most windows devs prefer the Visual Studio compiler.

Ooh,that's right :)

Another solution could then be writing a hybrid: separate the game logic/simulation into its own library (or object file), and link it later (might need a DLL loader, but I don't think it's that complicated; and maybe a shim or two if the calling conventions are different).

In any case, I trust Feral to be competent enough to know the right thing to do (and choose whether to spend time on doing it).

Or rather the companies doing these multiplayer protocols should stop using the raw float values since they cannot be trusted (different raw values of a float can produce the same decimal representation which is the problem) and there is nothing that says that a new version of the Visual Studio compiler will produce raw float values that is binary compatible with the current/old ones. Would probably speed up things as well if they changed to something sane like i.e scaled integers.

View this comment - View article - View full comments

Quoting: MayeulCI remember a game that lasted me six months, singleplayer on civ V (biggest map, slow time). But not every game is like this.

Usually, playing with your friends as an ally is less boring, as they can see your troops.

This is also a good candidate as a "mail-chess"-like (see freeciv 2's website).

A bit sad to hear this. Would love to hear the complete technical analysis of what happens here. The function names, actual differences, etc.

Is it floating point related, RNG related, other? Wine doesn't seem to have a problem with this. Wouldn't using some parts of winelib help? (It is LGPL, so definitely linkable against).

Wine does not experience this problem, but it will also not fix it. Because the difference in the floating points are due to the compiler (yes different math libraries can also cause this but there is a basic difference on the compiler level) so one fix would of course be to force all windows devs to compile with gcc, but for some strange reason most windows devs prefer the Visual Studio compiler.

View this comment - View article - View full comments

Quoting: rkfg

Quoting: EhvisI remember one game where the developer had a Unity3D game running within a day, but had dependency problems when starting from the Steam runtime.

STASIS is suffering from this right now. The engine needs newer libstdc++.so.6 than provided in SteamOS so it doesn't start there. So another advice: check your dependencies on older distros if possible and either ship the libs with the game or link them statically if you can.

Actually this is a very specially sad case. SteamOS supplies 6.0.20 but the Steam runtime supplies the 6.0.21 version that STASIS requires so the problem with STATIS is that it doesn't use the Steam runtime but the system one and that Valve somehow messed up their own distribution by supplying an older version for the OS than what they themselves support via their runtime.

For STASIS it should work on SteamOS if they changed their start script to look in the Steam runtime path for libraries before looking at the system path.

View this comment - View article - View full comments

The stock exchange story does not hold water at all. Witcher 2 was released for Linux on 2014-05-22 and the blog post talked about the CDR share plummeting on the Warsaw Stock Exchange in 2014. Well this is the actual closing prices of the CDR share on the Warsaw Stock Exchange from the release to the end of 2014 and as you all can see the price went up, not down (it closed the year at +12.45% as compared with the day the Linux version was released).

| 2014-05-22 |      14.85 |
| 2014-05-23 |      14.66 |
| 2014-05-26 |      14.89 |
| 2014-05-27 |       14.8 |
| 2014-05-28 |       14.8 |
| 2014-05-29 |      14.89 |
| 2014-05-30 |       15.2 |
| 2014-06-02 |       15.4 |
| 2014-06-03 |      15.38 |
| 2014-06-04 |      15.32 |
| 2014-06-05 |      16.15 |
| 2014-06-06 |       16.5 |
| 2014-06-09 |      16.75 |
| 2014-06-10 |      16.58 |
| 2014-06-11 |      16.27 |
| 2014-06-12 |       16.5 |
| 2014-06-13 |       16.1 |
| 2014-06-16 |      16.25 |
| 2014-06-17 |       16.3 |
| 2014-06-18 |       16.7 |
| 2014-06-20 |      16.73 |
| 2014-06-23 |      16.35 |
| 2014-06-24 |      15.88 |
| 2014-06-25 |      15.44 |
| 2014-06-26 |       15.3 |
| 2014-06-27 |         15 |
| 2014-06-30 |      15.24 |
| 2014-07-01 |      15.07 |
| 2014-07-02 |       15.2 |
| 2014-07-03 |         15 |
| 2014-07-04 |      15.07 |
| 2014-07-07 |         15 |
| 2014-07-08 |       15.3 |
| 2014-07-09 |      15.23 |
| 2014-07-10 |      15.08 |
| 2014-07-11 |      14.95 |
| 2014-07-14 |      14.72 |
| 2014-07-15 |      14.85 |
| 2014-07-16 |      14.84 |
| 2014-07-17 |       14.9 |
| 2014-07-18 |      15.25 |
| 2014-07-21 |      15.33 |
| 2014-07-22 |      15.42 |
| 2014-07-23 |       15.6 |
| 2014-07-24 |       15.5 |
| 2014-07-25 |      15.63 |
| 2014-07-28 |       15.5 |
| 2014-07-29 |       15.5 |
| 2014-07-30 |      15.41 |
| 2014-07-31 |       15.3 |
| 2014-08-01 |      15.06 |
| 2014-08-04 |      15.25 |
| 2014-08-05 |       15.4 |
| 2014-08-06 |      15.08 |
| 2014-08-07 |      14.47 |
| 2014-08-08 |       14.5 |
| 2014-08-11 |       14.9 |
| 2014-08-12 |      14.77 |
| 2014-08-13 |         15 |
| 2014-08-14 |       15.3 |
| 2014-08-18 |      15.25 |
| 2014-08-19 |      15.69 |
| 2014-08-20 |      15.85 |
| 2014-08-21 |       16.2 |
| 2014-08-22 |      16.05 |
| 2014-08-25 |       15.8 |
| 2014-08-26 |       15.7 |
| 2014-08-27 |         16 |
| 2014-08-28 |      15.23 |
| 2014-08-29 |       15.5 |
| 2014-09-01 |      15.45 |
| 2014-09-02 |      15.55 |
| 2014-09-03 |      15.85 |
| 2014-09-04 |      15.89 |
| 2014-09-05 |      15.98 |
| 2014-09-08 |         16 |
| 2014-09-09 |       16.6 |
| 2014-09-10 |      16.75 |
| 2014-09-11 |       16.9 |
| 2014-09-12 |      16.61 |
| 2014-09-15 |       16.7 |
| 2014-09-16 |      16.89 |
| 2014-09-17 |         17 |
| 2014-09-18 |      16.74 |
| 2014-09-19 |      16.76 |
| 2014-09-22 |      16.73 |
| 2014-09-23 |      16.61 |
| 2014-09-24 |      16.59 |
| 2014-09-25 |      16.61 |
| 2014-09-26 |      16.59 |
| 2014-09-29 |      16.59 |
| 2014-09-30 |      16.59 |
| 2014-10-01 |      16.59 |
| 2014-10-02 |      16.63 |
| 2014-10-03 |       16.7 |
| 2014-10-06 |      16.95 |
| 2014-10-07 |      16.97 |
| 2014-10-08 |      16.74 |
| 2014-10-09 |      16.86 |
| 2014-10-10 |       16.4 |
| 2014-10-13 |      16.15 |
| 2014-10-14 |       15.7 |
| 2014-10-15 |      15.46 |
| 2014-10-16 |      15.56 |
| 2014-10-17 |      16.15 |
| 2014-10-20 |      16.26 |
| 2014-10-21 |      16.46 |
| 2014-10-22 |      16.42 |
| 2014-10-23 |       16.5 |
| 2014-10-24 |      16.65 |
| 2014-10-27 |       16.7 |
| 2014-10-28 |      16.68 |
| 2014-10-29 |      16.67 |
| 2014-10-30 |      16.65 |
| 2014-10-31 |       16.7 |
| 2014-11-03 |      16.64 |
| 2014-11-04 |      16.84 |
| 2014-11-05 |      16.73 |
| 2014-11-06 |      16.95 |
| 2014-11-07 |      16.57 |
| 2014-11-10 |      16.45 |
| 2014-11-12 |      16.39 |
| 2014-11-13 |      16.28 |
| 2014-11-14 |      16.44 |
| 2014-11-17 |      16.48 |
| 2014-11-18 |       16.9 |
| 2014-11-19 |      17.73 |
| 2014-11-20 |       17.7 |
| 2014-11-21 |      17.95 |
| 2014-11-24 |      17.99 |
| 2014-11-25 |      17.98 |
| 2014-11-26 |      17.85 |
| 2014-11-27 |       17.5 |
| 2014-11-28 |      17.53 |
| 2014-12-01 |      17.42 |
| 2014-12-02 |      17.98 |
| 2014-12-03 |      17.87 |
| 2014-12-04 |      17.39 |
| 2014-12-05 |       17.4 |
| 2014-12-08 |       17.3 |
| 2014-12-09 |      16.58 |
| 2014-12-10 |       16.8 |
| 2014-12-11 |      16.15 |
| 2014-12-12 |         16 |
| 2014-12-15 |      16.22 |
| 2014-12-16 |      16.22 |
| 2014-12-17 |       16.2 |
| 2014-12-18 |      16.54 |
| 2014-12-19 |      16.19 |
| 2014-12-22 |      16.15 |
| 2014-12-23 |      16.37 |
| 2014-12-29 |      16.36 |
| 2014-12-30 |       16.7 |

View this comment - View article - View full comments

Quoting: Greaser

Quoting: Lakorta

Quoting: Guppy

Quoting: razing32

Quoting: Guppy

Quoting: razing322) Germany ? The heck is happening ? I thought only games with Nazi imagery got banned (for obvious reasons)

The obvious reason being a pathetic attempt at hiding their shameful history from public view. Remember nazi in game are always the villans so there is no chance of the game glorifying it :P

Sorry but have to disagree.
I met germans and I think they apologize too much.
What the Nazis did was a horrible atrocity , but I don;t think Germany today is Germany then.
How many horrible things were done in Europe , Africa , Asia since then yet Germany is held up as the example for human wrong doing. Doesn't seem fair in my mind.

I'm not saying blame Germans today for what happened then, I'm saying censoring media because they contain bits of history your not proud of is a dangerous and slippery slope. Instead own up to it, tech that it's bad and *why* it's bad.

They/We do. Germans are taught about Nazi Germany in school. It's just that Nazi symbols are forbidden unless they're for educational purpose.

And this is what I never understood.
For example movies have an educational purpose the same way as a game could have.
The Nazi Symols in movies aren't censored in germany.
But in general they're unconstitutionally and chargeble. So why is that?

Movies that handle the german history serve the art and games aren't subordinated to art yet officially.

Furthermore games are interactive and movies not! Sounds stupid right?

That's the official justification in germany.

Because it will be a long way before society at large will label games as art and the only exception in the German law are for "art or science, research or teaching".

The law itself is a remnant from the Allied occupation after the end of WWII. Of course Germany could remove these laws since the occupation ended decades ago but which politician in their right minds would suggest "we should really allow the nazi symbols again".

View this comment - View article - View full comments

Quoting: razing32Cool if it gets released on Linux , but , is she fighting in high heels ? By the end of that castle , crystal skin will be the last of her problems...

I found the "knees inwards" defensive position far more troublesome to be honest. That looks really, really, cringe worthy.

View this comment - View article - View full comments

Quoting: GuestFrom a programmers perspective if you can manage your own thread priorities, the user can raise the overall process priority appropriately... or some other process manager could.. for example Windows auto boosts the front process's priority.

Moreover, cgroups is Linux specific, and PTHREAD_SCOPE_PROCESS is not. You have more chance of getting it well supported if it works like every other OS does.

Of course, but as I wrote it's not fun if/when there are other processes running on the same machine competing for CPU time with your threads since all the process scope threads in your application is seen as a single item for the global scheduler. Now I have no experience with programming games since I mainly do server stuff, but the problems that you describe sounds more being due to starting more threads than there are cores on the system which makes them compete with each other in the first place.

The Windows auto boost of the interactive thread is perhaps nice for a game but creates havoc for system daemon writers like me (and thankfully it can be user disabled [but only on the system as a whole]) with latencies going completely haywire every time a end user would move a window around and so on.

Quoting: GuestYou are thinking of forked processes, which are copy-on-write. Web servers typically use forked processes for resilience - if a worker sub-process dies, it can be re-spawned and doesn't crash the whole web server. It also provides for process isolation which increases security.

Threads implicitly share their processes memory. Again the confusion here is because threads were originally poorly implemented on Linux as a "hack" on fork().

Yes this particular scenario of a web server such as Apache works this way by forking but it's not mandatory nor is it always desirable. You can avoid heavy overhead IPC:s (and do note that such IPC have a much heavier overhead than the Infinity channel have on a Ryzen type of cpu architecture) and so on by using threads instead of forked processes even when most of the work load is not shared so still, there is no way for the kernel/system to know what to do with threads and a cpu architecture such as Ryzen more than give the developers tools for managing this on their own because it's only them that know if thread A will often share data with thread B but not with thread C and thus pin them so that threads A and B are always running on the same CCX while thread C can roam free wherever there are idle process time.

The problem here is not that the threads have access to a shared memory pool, the problem is that some of these threads actively do work on the same memory locations which if they run on different CCX:es will cause massive amounts of copying over the Infinity channel.

IF this was "solved" by the kernel then the consequences would be that all threads created by a application would be pinned to schedule on the same CCX leaving quite a few cores running completely idle and all this just to handle a particular work load where the threads do heavy work with the same memory.

View this comment - View article - View full comments

Quoting: GuestI'll try to explain PTHREAD_SCOPE better...

As you know, processes on Linux all have a "priority" value, which is how the kernel scheduler picks the next process to be run. Every process has at least one thread, and games often use multiple threads to do things. Each thread in a process also has a priority value, and this influences which thread in a process the scheduler picks to run.

On Windows, OS X and BSD, thread priorities are *relative* to the processes priority. That means when the kernel picks the process to be run, the scheduler can also see which of that processes threads most urgently need attention. The process itself is completely free to set it's threads priorities as appropriate.

However on Linux, there is a bit more of a potted history with threading. Originally the kernel didn't have threads at all, only processes. Threads were later added by creating processes which shared another process's address space. So it's a bit of a bodge really. This is why if you use the right parameters to "ps", you can see threads, and why threads have a pid_t value.

So on Linux, a threads priority isn't relative to it's owning process - its relative to all the other process priorities too. The problem with this is that changing process priority is, quite rightly, a privileged operation... otherwise it'd be easy to starve out more essential system processes by a rogue process setting a high priority. This also means that a process cannot effectively set its own threads priorities. This means a game is unable to hint to the kernel effectively which of its threads should get priority over others. This is often the cause for stuttering in sound for example, because you cant hint that your sound engine thread needs priority over that background IO thread.

On the other hand a process scope is not so much fun if you run other applications at the same time since all the process scope threads in your application will now be seen as a single entity when it competes for CPU time against all the other threads from the other applications. These days the inter thread intra process priority is handled with cgroups but that is not something that I've tried.

Quoting: shirethroneVery interesting read. I like to have background information.
Do developers have to act or the kernel to fix this issue?

This should be a developers fix mainly because what is happening here is that you have a application where several different threads will perform write+read to shared memory, at the same time you have lot's of applications where none of the threads share memory for anyting (like say a web server) so there is no way the kernel might know which of your threads are sharing memory or not so that is not much it can do. So this behaviour should be apparent on any OS as well.

View this comment - View article - View full comments