Unreal Engine 4.20 & 4.21 and beyond

shkhln said:
I'm a bit of Nvidia fanboy, admittedly, so I don't pay much attention to AMD stuff.
Click to expand...
I myself have just never had any reason to look to other brands since I knew Nvidia had official FreeBSD support. But Vulkan is going to be a dealbreaker for me, so I really hope we can have it from Nvidia as well.
More choice is always better.

I've made a post on this forum to refer to a post I've made on the Nvidia forum, it'd be great if other people could leave something behind there just to indicate people would really like to see this.
 
malavon said:
I've made a post on this forum to refer to a post I've made on the Nvidia forum, it'd be great if other people could leave something behind there just to indicate people would really like to see this.
Click to expand...

Is that even a correct subforum? Unix Graphics is usually the place for these issues. It would likely take a substantially larger amount of complaints to get Nvidia to do something about it, though.

(Which is why it's important to work on improving Wine, Steam integration, controller support and whatever peripheral technologies. We need more people to maintain a proper "complaint presence", so to speak. I can easily count all current FreeBSD Vulkan users on the fingers of one hand. That just doesn't cut it.)
 
shkhln said:
Is that even a correct subforum? Unix Graphics is usually the place for these issues. It would likely take a substantially larger amount of complaints to get Nvidia to do something about it, though.
Click to expand...
Somehow I missed that forum, I've asked a mod to move it (though I don't know if there are active mods on that forum).

shkhln said:
(Which is why it's important to work on improving Wine, Steam integration, controller support and whatever peripheral technologies. We need more people to maintain a proper "complaint presence", so to speak. I can easily count all current FreeBSD Vulkan users on the fingers of one hand. That just doesn't cut it.)
Click to expand...
I agree for sure, but no harm in asking twice :)
 
I've checked compatibility of the 4.23.1 release with FreeBSD 12.1 (and thus Clang/LLVM 8) and have found and fixed a few issues.
On top of those I also found one with the nvcore/nvtt library. Make sure to rebuild all third party libs before trying anything.

The modified code will eventually be released with the official 4.23.2 release. In the meantime, there's a branch 4.23.1 that contains all fixes on top of the 4.23.1 release.
 
I've released 4.24.1 on GitHub. All useful information can now be found there with the release, along with a link to the readme which explains how to build UE4 on FreeBSD.
There's also a release for 4.24.0, but that one contains only basic getting-to-work code since 4.24.1 came only 9 days after Epic's 4.24.0 release. Backporting 4.24.1 (FreeBSD) improvements would have meant too much work with too few gains.

It took me quite a long time, in part because I needed to debug the UnrealBuildTool (a .Net application) but monodevelop no longer worked on FreeBSD 12. So after a quite lengthy detour trying to get that rectified, I finally managed to get something working.
A few other (possible) issues were discovered after release.

One of them were OpenGL shaders, but after a lot of investigations I'm starting to think there was file system corruption that may have have impacted this.
In short, after creating a project from the ShooterGame template, the gun of the game would have the wrong shaders (OpenGL only). I can no longer reproduce this, so I consider it a misfortune for now.

Another issue that I noticed was in the SpatialAudioTemple demo. The violin wouldn't start playing the first time it launched, but would the second time around.
If someone else could verify that the demo is working on his end the very first time it'd be very much appreciated.
There's the earlier one compiled for 4.23, and below there's a 4.24 version.

In the future I most likely won't be keeping the master branch up to date anymore. I've been doing this ever since the beginning, but it hasn't really helped me that much. So I'll be sticking to the release branches more often.
If that's the case, I will remove the master branch from my repository altogether in order to not confuse other people.

Links to a few demos, compiled for 4.24 and FreeBSD 12.1 (amd64):

ArchVizInterior (demo mainly meant to showcase raytracing, which is only supported on DX12)
InfiltratorDemo
ShooterGame
SpatialAudioTemple
 
Version 4.24.2 is on Github since yesterday, of course a few hours later Epic had to release a new version already :)
There's a catch though, my GTX 770 has stopped working and I no longer have a decent platform to test on. Right now I'm on my built-in Intel video, but that won't run UE4 stuff.
On top of that I don't really want to buy a new videocard: I don't know what NVIDIA is going to do with Vulkan, AMD might release cards that support raytracing and Intel is coming to GPU land with discrete GPUs.
I'll keep you posted if something changes.
 
aimeec1995 said:
Could retail UE4 game be made to work on freebsd with this port of the engine?
Click to expand...

Unreal Tournament 4 provides access to the source for the public (after signup) so in theory could be a retail game that is portable to FreeBSD. They could close up the source nearer to beta however.

I think development may have stalled whilst Epic milk Fortnight however ;)
 
aimeec1995 said:
Could retail UE4 game be made to work on freebsd with this port of the engine?
Click to expand...
shkhln said:
No, it's only useful to developers.
Click to expand...
Well, in theory any UE4 game could be compiled by its development team to produce native binaries for FreeBSD. In practice this would require a UE4.19 or higher and there would probably be some bugs to work out as well.
But indeed, an already compiled game wouldn't be able to be ported easily.
kpedersen said:
I think development may have stalled whilst Epic milk Fortnight however ;)
Click to expand...
From what I once gathered though take this with a heap of salt, UT4 was supposed to be the milk cow for Epic with skins, maps, gamemodes etc being sold on the marketplace.
Although never official, this is most likely why UT4 was abandoned after Fortnight took off. Also, the (external) development team was removed from the project.
 
malavon said:
It has been tested on my poor little embedded graphics card (at about 2 fps).
Click to expand...

Haha. I have a Quadro k440 and a GeForce 4 (AGP) that I am probably never going to use if you would like me to send it to you. Still not massively powerful (and as I am sure you already know, they both require a very poor quality driver to be functional).

As always, thanks for your work!

Edit: I think I have a RadeonHD 6xxx too. If you have time to write an ~OpenGL 2.x renderer for UE4? ;)

Edit2: Old shite is kinda my thing so I possibly am not the most useful hardware hoarder for this XD
 
Yeah, I have some old stuff as well but nothing usable or available to use. Doesn't really matter atm though, I'll get a new one somewhere in the future :)
Timing might be wrong for the 4.25 release though, it might be the first range I'll miss.
 
Last edited:
Apparently my 770 decided to come back alive, no idea why it didn't work before (tested in several computers etc).
So if it keeps up, nothing has changed and 4.25 will be ported and tested as well as other versions, barring the usual risks.
 
Again, I would like to thank you once more for the consistent effort you are putting into this port. I am considering moving away from Gentoo on desktop as I am very satisfied with my experiments with ZFS (Linux does support ZFS, but well I liked the easy setup on FreeBSD), and your port is one reason I can easily go back to FreeBSD on the desktop without losing UE4. But, I am considering a longterm decision. So, have you ever considered backporting your changes to upstream?

I know EPIC is painfully slow at accepting pull requests on GitHub. But, I would like to know if it ever happened and they were receptive or not.
 
NuLL3rr0r said:
But, I am considering a longterm decision.
Click to expand...
If I die of a certain virus somewhere in the next few weeks/months/years there will no longer be a FreeBSD UE4 port. The only possible option would be to keep the port up to date yourself.
It's actually surprisingly easy, it just takes quite some time to track down where things have broken compared to the previous version.

I know it's probably not what you wanted to hear, I'm just trying to paint a realistic picture here. One-man efforts can easily stop due to a multitude of factors. If you're really dependent on UE4, you'd be making yourself dependent on me and my porting/programming skills. Also, I have no idea if I could call my port production quality since I don't use it myself except for some tinkering/experiments. On top of that, one day there may be some required closed source library which I can't circument like I did with the FBX importer. At that moment it'll stop because I have no other option.
NuLL3rr0r said:
So, have you ever considered backporting your changes to upstream?
Click to expand...
Yes ? but see below.
NuLL3rr0r said:
I know EPIC is painfully slow at accepting pull requests on GitHub. But, I would like to know if it ever happened and they were receptive or not.
Click to expand...
Well, back in 2014 there seemed to be some interest in this from Epic's side. See https://www.unrealengine.com/en-US/blog/unreal-engine-4-and-linux. This changed later on or was a bit of a marketing thing.
As you may well know I originally based my work on the work done by mdcasey in this GitHub repo sometime in 2016. He had been trying to get FreeBSD support mainlined in a few PR's, but eventually abandoned it when it looked like it wasn't going anywhere.
Unfortunately, we will not be able to maintain FreeBSD support in the engine, but I suggest creating a fork dedicated purely to FreeBSD support and adding the link to it to the public wiki.
Click to expand...

I myself have also contacted this Epic developer privately via e-mail on this back in 2018 and I basically got the same response. Epic isn't interested in having this code in their repository, since they won't be maintaining it themselves. In fact, they've recently begun making changes to eliminate all platforms they no longer want to support from the official repository. One example of this is HTML5 support. Sidenote: this now also makes it impractical for me to support HTML5 on FreeBSD, because I'd have to support two separate ports.
More recently I've also contacted Epic to know if they'd be interested in more or less making FreeBSD official through their dev grant system by basically throwing some money in my direction, but until today I haven't received anything back except a "we're looking into it" type of response. If they were really interested in FreeBSD support, I'm pretty sure they'd jump on the opportunity of having someone do it for far less than the cost of the actual maintenance.

Apparently the UE4 Wiki has been taken offline by Epic. I think there was some more information on there, but don't know for sure anymore.

TL;DR: One-man projects are always a risk and Epic isn't really interested.
 
Thank very much for the detailed clarification and the info. Well, I expected to hear they are not interested (as corporates number one priority is the market and money). But, by following the links you have posted, I noticed they accept smaller pull requests which are good news.

Anyway, I am considering moving back to FreeBSD on Desktop (I use it regularly on servers). I am a gamedev who has been away from game development for almost two years now (I did three games in UDK and UE4 in the past). I guess I'll get an extra SSD/NVME drive and try to experiment with your port to see where it goes before I make the permanent switch. If I am successful with it, who knows, maybe I join you in this effort which will be a good refresher for me.

Thanks again for the response and for keeping this port up to date.
 
malavon said:
One-man projects are always a risk.
Click to expand...

I certainly see what you are saying but I also know of a lot of one-man projects that have outlived commercial support. Commercial companies are like little fat children, they lose interest and ditch their toys XD.

Even though I don't know who you are (other than recognising the name from IWD2), when it comes to technical competency, I actually have less confidence in game development companies haha.

What is fantastic about your work is that when Epic goes bankrupt or makes an Unreal Engine 5 and ultimately ditches UE4, we know that we still have your work on UE4 available to us and we only need to maintain it from breakages from FreeBSD itself :).

If it was withheld source without an official FreeBSD port like Unity (the prosumer toy version of the game engine world), any commitments a developer has made up until that point would have been wasted when the company goes bankrupt. I feel because of your efforts we are in a much better position here.

I am more than happy to use old software (even you first port!), so I just hope you do not feel pressured to keep in sync with upstream.
 
NuLL3rr0r said:
I am a gamedev who has been away from game development for almost two years now
Click to expand...
If you'd be interested in getting your most recent project (Reminiscence) running on FreeBSD hit me up. I'll guide you through it as good as I can. Having someone who runs a "real" project on FreeBSD would be great to check if the FreeBSD port doesn't have any more bottlenecks than Linux etc.
kpedersen said:
Even though I don't know who you are (other than recognising the name from IWD2), when it comes to technical competency, I actually have less confidence in game development companies haha.
Click to expand...
Ah, the name. Yes, it's originally from IWD (not 2 though). It's also the name of my first and most precious AD&D2 character, a true neutral necromancer. I don't play anymore though.
As far as technical skills go, I really don't compare to what the (engine dev) guys at Epic are really doing. I couldn't write this whole thing from scratch. The only thing I can say is that if I tried it'd be cleaner and unit tested code at least ;)
kpedersen said:
What is fantastic about your work is that when Epic goes bankrupt or makes an Unreal Engine 5 and ultimately ditches UE4, we know that we still have your work on UE4 available to us and we only need to maintain it from breakages from FreeBSD itself :).
Click to expand...
I'm not entirely sure if the EULA (aka the license) doesn't make it possible for Epic to remove all forks in existence and just retract the license they've given us to maintain them. I skimmed through it and I think they can't do this legally, but who knows.
You are right though, up to now some things have been broken when OpenSSL was updated, Clang versions broke some things etc but nothing really major.
kpedersen said:
I am more than happy to use old software (even you first port!), so I just hope you do not feel pressured to keep in sync with upstream.
Click to expand...
Not really, I still kinda feel like it's fun to get it working. If I don't feel like working on it, I just don't. It's one of the benefits of doing this purely for fun. The novelty has worn off though, I rarely get excited when a new version is released.
In fact I've been awaiting the release of a version which has a non-beta of Chaos because it's something new and shiny, but it would appear this won't be the case for UE4.25. More focus has gone to archviz stuff which I assume is also a huge market for Epic.
 
If you'd be interested in getting your most recent project (Reminiscence) running on FreeBSD hit me up. I'll guide you through it as good as I can. Having someone who runs a "real" project on FreeBSD would be great to check if the FreeBSD port doesn't have any more bottlenecks than Linux etc.
Click to expand...

Sure, I definitely will test it out.

My current hardware is Asus ROG G752VS-XB78K Overclocked Edition. The touchpad (ELANTECH 1200) was a hassle with Linux until 4.19. I even risked and ran this binary to make it work with Linux:


Bug #1643242 “ASUS ROG G752 ELAN1203:00 04F3:301E Touchpad detec...” : Bugs : linux package : Ubuntu

Model: Laptop ASUS ROG G752 VM dual boot with Windows 10; security boot disabled; touchpad activated in uefi Touchpad: Name "ELAN1203:00 04F3:301E Touchpad" (see dmesg.txt) OS: Ubuntu 4.8.0-27.29-generic 4.8.1 (also tried 4.4.0 and some others) Symptoms: - Touchpad seems to be correctly...
bugs.launchpad.net bugs.launchpad.net

Bug #1653456 “ASUS G752VS: Touchpad and Fn keys not working (Ubu...” : Bugs : linux package : Ubuntu

Non-Optimus laptop ASUS G752VS-GC063D-CST256. 17.3" FHD LED 1920x1080, Intel Core i7-6700HQ (3.50Ghz), 16GB DDR4, 256GB M.2 NVMe SSD + 1TB HDD 7200rpm, DVDRW-DL, Nvidia GTX1070 8GB GDDR5, Wifi 802.11ac+Bluetooth 4.1 (Dual band) 2*2, Gb LAN, HDMI, mDP, Intel WiDi, USB3.0 x4, USB3.1-Type C(Gen2)...
bugs.launchpad.net bugs.launchpad.net

So, I decided to download FuryBSD 12.1 to try a LiveCD and see if it works before installing FreeBSD. Well, it didn't work. But, I found a link to a patch file here: https://reviews.freebsd.org/D16698 and unfortunately, it requires approval after signing up. I've been waiting a few days. So, once I get that fixed, I'll try out your port.
 
I've released 4.25.1. There won't be a 4.25.0 release, that one was broken due to UE-92806 (even though the description doesn't really give it away).
Originally I had added ccache to this release, but in the end it seemed that the UE build system didn't profit from it. I might revisit that in the long run again though because I could really use it myself to speed up things.

There isn't much news to share, except that Epic has added something that changed the way the editor works: after creating a new project, the project is not opened in the editor but in the default file browser.
Compilation of the new project needs to be done manually as well first (at least for C++ projects), it's not kicked of by the editor anymore.

I'm going to try and revisit my wine experimentations until next version is released.
 
You must log in or register to reply here.
Back
Top