[Raion]

Impossible? No, but there's always issues to overcome. In particular you need a OpenGL 1.1 back end, all dependencies must be built properly etc. A few issues that are endemic to these endeavors:

Many of the base libraries used for games require 32-bit X, and IRIX uses 8,16 or 24 bit depth. Replacing XSGI with Xorg or Xf86 will result in a significant performance decrease especially for the slower systems.

Glib, gtk, and many other base libs just don't build correctly.

And finally platform support. Sure you might be able to hack something basic together but the chances of upstream support in general are pretty nil, and that can result in a stalled project as soon as your more competent devs move on or die or quit.

[Raion]

Looked through it. A few issues:

C++11 is used. this means MIPSPro won't be able to compile it as that's C++98/03. This also means the last mainline GCC (4.7.4) won't be able to do it either in many cases, not to mention coding issues arising from SDL2 not working completely on IRIX yet, or the fact that it looks like they're using some routines that may not easily be translated to OpenGL's immediate mode, even using vertex arrays (which are in OpenGL 1.1/1.2).

It's not impossible, but the performance is probably going to be ass and it'd require a lot of rewrites.

[Jammaster]

I dream, a day, to see Tim Sweeney let Unreal Engine 1 in nature ! ^^

[jamesgil]

good post!

[CRM114]

Generally as everyone has already pointed out there are concerns at a deep level with how the would be ported- but I wanted to mention calling out BeOS and others is really non sequitur to porting. These are apples and oranges. The SGI machines are running on a 20+ year old silicon. Yes, it is MIPS- but a niche flavor of MIPS that is not widely used these days. Lower level libs and supporting code actually do care about hardware. You can't compile code on a machine without a compiler that can read the code. These machines are turning into more of a museum of how things were- you cannot expect to take code that compiles on CISC wintel machines in 2019 and compile it in a unix environment from 1998.

[Unxmaal]

<snip> you cannot expect to take code that compiles on CISC wintel machines in 2019 and compile it in a unix environment from 1998.

Uh, what?

Taking code from one hardware platform and compiling it on another hardware platform is the definition of porting, and it's done all the time.

I'm a scrub and I've ported dozens of new FOSS packages to IRIX. It's mostly just C. It's not magic.

[Raion]

Easy boys. Both of you have excellent points.

What CRM was saying, and probably failed to get across, is that libraries, and some low level graphics code, often that uses in games like this, is more sensitive than more mundane programs, regardless of language. In particular, I'd expect Endianness issues, and issues with SIMD code and the like. A lot of higher performance software expects SSE2 and may not have a fallback for that.

[Anonymoose]

Any updates to this? Anything change in the last six years? I know nothing about coding and whatnot, but I wouldn't mind pitching in some money to motivate someone...

[Raion]

Before the SGUG staff broke down between us, I discussed it at length with Xav101. There's several issues that make a port unviable at this time:

1. Xash3D's code is not optimized for anything outside of x86.

2. It's got a nasty build system.

3. There's no code for big endian loading of assets, so assets will not load properly.

4. It's inconclusive if it will properly support OpenGL 1.2

Obviously this would only run well on texture memory systems with sufficient CPU. Probably only the top 10% of SGIs.

Xav was unwilling to share the fixes he made with just anyone.

Honestly, it's not super viable, and I think it's a lost cause unless someone really wants to work for free on a project that will end up having people shit on them if it takes too long or doesn't end up working.