Posts Tagged ‘ Linux

Of Epic, Rocket League and Linux

— Part of this article was based on a comment I wrote on Rock, Paper Shotgun, minus various grammatical errors and typos.

Of course “everyone” hates Epic.

As you may have read on Tim Sweeney’s Twitter page, Tim has been killing babies since the new year.

Just kidding. But you wouldn’t know that just by reading the long discussions of people simply angry at Epic Games. There’s a lot of hate, a lot!

For those who don’t know about the story, you can easily pick it up on some long, albeit deceitful, post on a blog somewhere, or an angry video rant from some YouTube “influencer”. Suffice to say that Epic has made its mission to disrupt the current status quo in online game distribution and is paying mucho bucks and a better revenue share to attract big names and upcoming stars to distribute their game to its store. And that, my friends, pisses some people off. A capitalist move in a capitalist world and suddenly, the whole gaming world seems to have turned socialist. Now, I’m not against socialism in any way. I like to think myself as socialist. But I like to confine it to actual important things, like health care or wealth distribution, not whether Rich Gaming Company A can or cannot compete with equally Rich Gaming Company B using ugly capitalistic tactics. Ironically, it’s under the mantra of “better distribution of wealth” that Epic started this whole crisis.

It sounds like a lot of people are not buying this.

It also sounds that a lot people are buying this if you count the number of developers jumping ship and joining the Epic train. Sales of Metro Exodus went really well and Borderlands 3 is poised to be a monstrous hit. So it’s not just those developers who agree, but users (yes, actual gamers !!!) do too. Such much for boycotts and review bombs

So if fortune smiles on Epic despite the hate, it has become customary from haters to find peripheral reasons to hate Epic in a desperate effort to unmask the villain: that Epic is selling player IDs to the Chinese, that Tim Sweeney hates consumers, that programmers weren’t consulted on any of the publisher’s decision to move to the Epic Store (and that is a sin), that the Epic Store doesn’t support their God-given right to vote on a game, etc., etc. All things that, under the critical eye, are either false, misconstrued or totally peripheral to the matter at hand.

I even read someone scolding Sweeney that Epic should have considered the harm it would bring to the reputation of these unwilling developers. That’s strange! I always thought that a developer’s bad reputation was earned by releasing shitty games. If that’s not the case anymore and a Steam offering is all it takes to have a good reputation, then the reputation of Bethesda and Bioware must be stellar. Which wouldn’t surprise me anyways as these entities and their parent companies don’t appear to have used all their good karma as gamers buy again and again their games – and don’t let the current wave of vitriol over Fallout 76 and Anthem fool you; forgiveness is only a GDC or E3 demo away.

So imagine my surprise when I read today that since Psyonix, the company behind Rocket League, has joined Epic, there’s a new reason to hate it now:

Epic hates Linux.

Rocket League has long supported Linux and Linux modding apparently so people are concerned down right angry that Epic will not support Linux. Oh, and apparently Sweeney said something bad about Linux, too.

What a load of crap.

To be fair, there is genuine concern that support for an arguably less popular gaming platform may be axed, especially since the Epic Store is not ported to Linux even though it is based on Electron, a multi-platform framework that should be trivial to port – at least according to its developers.

I’m not necessarily well-informed on all gossip around Epic as I rely on a small set of outlets – although I can myself distinguish genuine concerns and critiques from a bunch of hooplah. But – full surprise disclosure here – as a game programmer who uses Unreal Engine, here are two opinions of my own on the subject (which is, by the way, the core of the title for this article).

1) Unreal Engine, at least since version 3, has Linux support, both on client and server (the latter, I believe, makes a better choice for dedicated servers over Windows as you don’t need as much licences to operate). Now, I’m not totally familiar with UDK, aka Unreal Engine 3, which is used by Rocket League, but the way it works on Unreal Engine 4 (UE4) is that the same code base is used for both client and server. You don’t create a separate code base exclusively for each end and thus creating multiple teams working on potentially different platforms. If your server runs under Linux, a Linux client will most likely work out of the box too. So it’s not like Psyonix would be slashing a Linux team because “Big Ol’ Evil Epic” says so. Linux is part Unreal’s DNA.

2) I bet you dollars for donuts that Psyonix uses a heavily modified version of Unreal 3 just for Rocket League on all platforms it currently supports. So it’s not like their devs are going to rewrite the whole thing from scratch anytime soon – even in UE4 – and any change in the code will be immediately compatible to all their platforms of distribution.

So what’s at stake is the distribution of a Linux client. This is a genuine problem but not due to a coding or porting issue. However, this might be a good opportunity for Psyonix to teach a few things to Epic and praise Linux as a valid gaming platform, if there was any doubt from Epic’s part.

And of course, if the numbers are right …

Which leads to adding a third opinion, the one that puts me in a zen state whenever I see comments on Linux gaming in general. I was, and still am a Linux user. And I’ve use it as a gaming platform every since Quake and even compiled my own version of Doom from Id’s public FTP site.

An early adopter of Linux and modding was Id Software. There are currently a multitude of Doom ports on Linux and Id has released all versions of Quake on Linux. Moreover, Id systematically released the code for these games to the public after their end-of-use, under the Free Software Foundation’s General Public Licence no less.

I don’t know how much of Zenimax’s position went into this but John Carmack, Id’s ex-co-founder and ex-lead programmer isn’t usually a company mouthpiece and went on record, saying: “The conventional wisdom is that native Linux games are not a good market. Id Software tested the conventional wisdom twice, with Quake Arena and Quake Live. The conventional wisdom proved correct. Arguments can be made that neither one was an optimal test case, but they were honest tries.”

Before those comments, Rage, a game released after Quake IV, was never released on Linux.

No matter how you try, the case for a Linux gaming platform is still a tough call to make. If only today my love of Linux would extend to gaming like before. I cheered for Valve’s push for Linux – or SteamOS – and actually ran many Steam games on it but only after carefully curating my computer with relevant drivers and libraries – not necessarily the latest ones as I toiled many times on it while longing for the latest of apt-get updates and upgrades. And Steam Link sucked with two monitors on my gear as if it’s couldn’t display one of each separately on my TV screen. And how many friends rose a red fist in the air – or not – and wanted to make the move to Linux and “end the Windows monopoly” only to return to it less than a month later for <enter relevant reason here>.

Ironically, Tim Sweeney’s ill-labelled article about developers vs consumers may prove to be a balm to worried users: if consumers (aka, the market) have their way, then Carmack is right and Psyonix will probably look at the numbers and decide on them alone; you can’t really blame their move to Epic as a way to readjust and re-evaluate their stance on many topics, including, yes, Linux.

On the other hand, you can pray that Sweeney is right and that developers do make the most important decisions in gaming and that deep down, the Psyonix devs find it in their hearts that all of this is worth it.

More Doom obsession with Ubuntu PowerPC

Continuing with my obsession with Doom – as decribed in my previous post – I tried compiling my modified original source on a PowerPC running both Mac OS X and Ubuntu Linux. Since they both have the X Windows system, it should work. Today’s post will be about Ubuntu.

Relevant libraries

I guess I got ahead of myself last time when I suggested to simply type ‘make’ to compile. In fact, they are a few packages that must be installed on Ubuntu. So install the relevant X developement libraries like so:

sudo apt-get install xlibs-dev x11proto-xext-dev libxext-dev

Compiling linuxdoom will yield a new set of errors that I hadn’t notice the first time around on a Intel x86 PC.

Endianess

Endianess, for those who might not know, is how computer store numbers in the processor and, corollarily, on other devices in the system. On a big endian system, like a PowerPC, the numbers are stored, byte per byte with the highest values first. On a little endian system, such as the Intel x86 family, it’s stored with the smallest values first. Originally, Doom used a little endian scheme under DOS, so a Linux port that runs on an x86 would have no trouble with it. For big endian, you need to swap the values. Not necessarily all of them but certainly those who affect the devices: video, filesystem, etc. There are many references in linuxdoom to macros called SHORT() or LONG() that wrap certain values for this purpose. So the Doom porters added some extra pre-processor switches where a conversion will happen if you happen to compile on a big endian system. But is this enough … ?

Here’s what you get in m_swap.h:


// Endianess handling.
// WAD files are stored little endian.
#ifdef __BIG_ENDIAN__
short	SwapSHORT(short);
long	SwapLONG(long);
#define SHORT(x)	((short)SwapSHORT((unsigned short) (x)))
#define LONG(x)         ((long)SwapLONG((unsigned long) (x)))
#else
#define SHORT(x)	(x)
#define LONG(x)     (x)
#endif

And here’s what you get in m_swap.c:


// Not needed with big endian.
#ifndef __BIG_ENDIAN__

// Swap 16bit, that is, MSB and LSB byte.
unsigned short SwapSHORT(unsigned short x)
{
    // No masking with 0xFF should be necessary. 
    return (x>>8) | (x<<8);
}

// Swapping 32bit.
unsigned long SwapLONG( unsigned long x)
{
    return
	(x>>24)
	| ((x>>8) & 0xff00)
	| ((x<<8) & 0xff0000)
	| (x<<24);
}


#endif

First, even as #ifdef __BIG_ENDIAN__ in m_swap.h will set prototypes for the swap functions SwapSHORT() and SwapLONG(), it is incompatible with the fact that w_swap.c wraps these functions with #ifndef __BIG_ENDIAN__. We couldn't notice this error under x86 compilation - although the compiler could have warned us that the prototypes were missing - but on a PowerPC, it will fail.

So change the line in m_swap.c from

#ifndef __BIG_ENDIAN__

to

#ifdef __BIG_ENDIAN__

Next, the values between the prototypes and the definitions are all wrong. In the header file, SwapSHORT() and SwapLONG() both take and return signed values, whereas in the .c file, they're all unsigned. Change the signed ones in m_swap.h like so:

unsigned short   SwapSHORT(unsigned short);
unsigned long    SwapLONG(unsigned long);

These changes should make the linuxdoom code compile (with all its usual sets of warnings).

The sound server

What about the sound server ? It does compile and is set up to its right endianness. But the sound comes out all scratchy. It is possible that the conversion process was not complete. For the moment I have no solution for that. You can still compile the main linuxdoom source without the -DSNDSERV flag in the Makefile.

Final words

So, just like the x86 version on my previous post, start a new X session in 8 bit colors, open a console, set the environment variable for DOOM, make sure your Doom IWAD is present (and the sound server if you like scratchy noises) and voilà.

Next stop: Mac OS X.

Running Doom under Linux

[Edit: 2014-03-05: I’m closing this thread now.  Check out the references to chocolate-doom in the comments below as probably our last resort to actually compile Doom from a reasonably corrected source for our modern times.  Beyond that, I’m pretty much as clueless as you are]

I love Doom. Actually, Doom II was the first PC game I ever got in my hands onto. The game was fast-paced, gritty and scary like hell, even with its 8 bit architecture. The sound was ominous, the levels and monsters were darn frikin’ hard to go against … I totally agree with anyone that would put it onto their top list of games since the beginning of that instrustry we call “gaming”.

This post is about compiling Doom on a modern Linux distro.

The source of the Doom engine (which ran Doom, Doom II, and Ultimate Doom) was released in 1997 as a Linux port that used X with a separate sound server. It is still available here.

I got interested in the source code in 2003 and started taking notes about compilation, PCX and 8bit paletting, and WAD (de)construction. Now, in 2010, I re-read my notes and decided to give it a go again, this time putting those notes public, although there’s nothing really new here for anyone. With so many ports of Doom that have spawned over the years, there are better options today in playing Doom with full screen graphics, perhaps in 3D, and MP3 sound and music instead using 16 bit mono WAVs and on board MIDI.

But I like retro stuff and this is as close as we can get to the original. The SDL version, made by SDL creator Sam Lantinga, is a straightfoward port of the original with sound and can run on 640 x 480 without palletting. It’s a great way to see how SDL works. But before compiling that version, keep reading this post, there is at least one modification you should be aware of.

Fixing errors and compiling

The first thing about Doom, is that its creator, id software, did released the source code but not any of the data files to run it, called IWADs, which contain the images and sounds of the game. You must either have the commercial version of Doom, Doom II or Ultimate Doom, or the shareware version (a copy of the shareware IWAD is available here). Unzip it and put that file somewhere on your system. We’ll need to point to it later on.

Unzipping the file gives you two packages, the source code of DOOM and a separate sound server that Doom will imbed at run time (apparrently, id licenced a copyrighted sound engine at the time, which is why there is no original DOS release: ‘A mistake’ says John Carmack in the README.TXT file.)

Unzip the source code and make the following changes:

In i_video:49, replace

#include <errnos.h>

with

#include <errno.h>

In i_sound.c:166 and i_video.c:669, delete all declarations of

extern int errno;

and include this file somewhere at the top of i_sound.c:

#include <errno.h>

In s_sound.c:367, replace

#ifndef SNDSRV

with

#ifndef SNDSERV

In the Makefile, add the -DSNDSERV define for compilation.

Finally, and this affects both the original and SDLDoom, change d_main.c:587 from

doomuwad = malloc(strlen(doomwaddir)+1+8+1);

to

doomuwad = malloc(strlen(doomwaddir)+1+9+1);

This “off-by-one” error will generate a ASSERT error in malloc.c:3074 once the X display kicks in. The gdb debugger will tell you so, and yet we are very far from any video initialization at this moment. It took me a while to trap this.

Compile by simply calling ‘make’ at the command line. Everything should compile under 30 seconds. Don’t (?) worry about all the warnings you’ll see passing by. They shouldn’t affect the game at this point. Feel free to clean up the code if you like.

Compiling the sound server

Unzip the sound server’s package and change to that directory. Simply call ‘make’ at the command line.

Move the ‘sndserver’ binary located in the ‘linux’ directory to the same directory you put your IWAD, mentionned above.

Switching to 8 bit

Doom runs in 8 bit (256 palettized colors) at a whoppin size of 320 x 200 pixels. It’s better to simply call another X desktop instead of ruining your current setup.

Issue the following on the command line.

sudo startx -- :1 -depth 8 vt8

This starts another desktop at vt8 (i.e. Ctrl-Alt-F8. You can return to your original desktop with Ctrl-Alt-F7 or loggin off from that session). You’ll notice how rough your desktop will look because of the 8 bit palette it’s running on.

Note that you will be running your new desktop with super-user privileges, so be VERY careful.

Open up a console and set an environment variable called DOOMWADDIR like so:

export DOOMWADDIR=<my path>

and replace <my path> with the location of the IWAD and sound server. If you dip into the code, there always a way to set those changes to a permanent location without defining this value or doing it through some parameter.

You can now run the binary located at linux/linuxdoom in the source code directory.

You’ll see your desktop flashing because Doom will set up its palette to it.

Voilà. Enjoy playing Doom on an itsy bitsy scale. 🙂

You can alway resize your desktop to 640 x 480 to see it a little larger. Don’t forget to set it back to its original size. I believe if you don’t, it will screw up your default settings once you run X again from a fresh boot.

If you don’t want to go through all this trouble, make the change I recommend to d_main.c:587 in SDLDoom, compile it and call the -fullscreen parameter to play Doom at a reasonable scale.

return top