Unreal Engine 4

[malavon]

In case anyone is interested in some tech demo's/samples for UE4, I've been busy porting the engine and compiling most of the samples. A few are included here.
These are all based on my personal fork of UE4, there is no support for FreeBSD in the official Epic repo.

(edit: see the Unreal Engine 4.20 post if you're looking for demos or games or want to compile the engine yourself)
For people wondering why I'm posting this: it's mostly just to get an idea whether there are people interested in this or if I'm the only one. It makes the difference between keeping my fork to myself and cleaning it up/pushing it to upstream (which will take a very long time of back-and-forth cycles with feedback/small changes/more feedback/...).
I use FreeBSD as my day-to-day OS and hate using a Windows dual boot for stuff like games. I'd like to one day ditch Windows altogether, especially since I will never be installing Windows 10 or any other OS that likes exploiting my privacy like it does.
Everything is still in a very early stage, but I'm really happy how things turned out in the end.
I took it on myself to provide a full port, mainly to see if I could and how it would perform.
(end edit)

These are NOT the demos presented on GDC 2018, but I do expect them to become available in the future.

In case you need to change keymappings (I don't use Qwerty but tried setting them back to original), change in:
<name>/Config/DefaultInput.ini e.g. ABoyandHisKite/Config/DefaultInput.ini

A few notes:
* It seems that audio is mono only unless the game is using positional audio (like the ShooterGame). This is most likely due to a bug I haven't found yet, but this may be resolved in 4.20 anyway with the new multi-platform sound mixer.
* You will need an OpenGL 4.3-capable GPU and driver
* If a demo starts on only part of your screen, try alt+enter twice (once to get out of fullscreen mode, second time to go back in)
* Kite demo is supposed to play a wmv at the end of the demo (ctrl+d, wait, ctrl+c), which doesn't work on FreeBSD (or Linux for that matter)
* Please don't ask for sources or a FreeBSD port (yet). There's more work to be done to get this in a decent shape to be approved upstream and I rebase my gihub repo almost on a daily basis, making it difficult for people to clone it.
* Don't expect Unreal Tournament to work on FreeBSD soon, it uses UE4 4.12 and I do not intend to port that version

 

[ShelLuser]

* Please don't ask for sources or a FreeBSD port (yet). There's more work to be done to get this in a decent shape to be approved upstream and I rebase my gihub repo almost on a daily basis, making it difficult for people to clone it.

In other words: please download this software from these unknown sources, trust my non-existent forum reputation (first message) when I tell you this can be trusted and most of all please don't ask for any sourcecode in order to verify for yourself what this software is doing exactly.

I assume we should also definitely run this software as root because it doesn't work otherwise?

You mentioned a GitHub repository, so why not give us access to that? Your comment that it would be difficult to clone the repository due to daily changes is plain out nonsense, because of that I can't help get the feeling that you're trying to hide something from us here.

No one in their right mind should try to download and run this.

(edit)

I'm aware my message may sound harsh but in this day and age you can never be too careful. I also couldn't help notice that you didn't even mention against which FreeBSD platform these binaries were build. Is this 10.4, 11.1 or maybe CURRENT? Pretty crucial information if you ask me

If you expect people to trust this then you should give them some good reasons for that. This is not the way how to do that, even if you are being sincere about all this. Problem is that there's no way for us to tell, and as I said: no one in their right mind would take this gamble "just because".

 

[kpedersen]

(Yes Posting magnet links to binaries on a *nix forum is slightly odd.)

Nice. There has already been some work on this. You can find the existing project here:
https://github.com/UE4-FreeBSD/UE4-FreeBSD

Also on the Wiki here: https://wiki.unrealengine.com/Compiling_For_FreeBSD

malavon, I don't suppose you are the same guy doing the main port? I tried to contact you using the forums (because GitHub had no contact / author info). https://forums.unrealengine.com/dev...-unreal-engine-4-is-now-available-for-freebsd

In general, it works but there is no "game editor". I personally don't like game editors anyway so UE4 is pretty complete for me haha.

 

[malavon]

(snipped line breaks out of your quote, hope you don't mind)
For the record, it was several hours after midnight when I posted this. I definitely forgot some stuff. Did some edits, but I'll make most changes here.

In other words: please download this software from these unknown sources, trust my non-existent forum reputation (first message) when I tell you this can be trusted and most of all please don't ask for any sourcecode in order to verify for yourself what this software is doing exactly.

I can't fault you there. These are unknown binaries, from someone who never posted on this forum before. You're completely right there. I too wouldn't just go and run these without thinking.
If you would however like to run these and don't thrust them at all, I'd advise you to quickly install a fresh FreeBSD on an old disk you have laying about. A VM probably won't work well, but no harm in trying. Takes about 10 minutes to install and install a graphical frontend.
To be honest though, I've run countless binaries for which I didn't have the sources before. Most of the games I ever played weren't open source and I'm sure there are other binaries I've trusted that I shouldn't have.

I assume we should also definitely run this software as root because it doesn't work otherwise?

I haven't tried, but it should actually not start. At least in the editor there is a check somewhere to refuse running as root.
So if you trust FreeBSD to run things safely as some new user in a jail, you might not even have to install a fresh copy.

You mentioned a GitHub repository, so why not give us access to that? Your comment that it would be difficult to clone the repository due to daily changes is plain out nonsense, because of that I can't help get the feeling that you're trying to hide something from us here.
No one in their right mind should try to download and run this.

Like I said, it was late so I'll try to clear this up. The GitHub repo is private because Epic does not allow any fork of the Unreal Engine to be public. It's their intellectual property and they're in their right mind to do so. I originally, before posting, did add some more info about the repo and how to get access to it (and compile etc) but removed it in the final version because I was writing a way-too-long how to.
Anyway, if you'd like to have access, follow the right path to get access to UE4 and you'll automatically get access to my repo as well. My Github can be found here. Feel free to try and build it, it's difficult because the code right now is simply not meant to be used by people other than me.
Then again, it doesn't matter much, because the tech demo's here are not on my Github. I didn't make any changes to them and I'm not licensed to publicize their code.
Daily changes are rebases, so if you clone it, be prepared to go and fetch/reset often (unless there is some other workflow that I don't know of). I fixup/squash/edit/reword my commits very often.

I'm aware my message may sound harsh but in this day and age you can never be too careful. I also couldn't help notice that you didn't even mention against which FreeBSD platform these binaries were build. Is this 10.4, 11.1 or maybe CURRENT? Pretty crucial information if you ask me

Like I said, I'm not faulting you. Edited the original post to clarify this.

If you expect people to trust this then you should give them some good reasons for that. This is not the way how to do that, even if you are being sincere about all this. Problem is that there's no way for us to tell, and as I said: no one in their right mind would take this gamble "just because".

Story of my life :-D I tend to communicate pretty badly and have to clarify myself afterward a lot.
Anyway, I have no idea how to get binaries trusted more, feel free to help me out here.

 

[malavon]

(Yes Posting magnet links to binaries on a *nix forum is slightly odd.)

Is it? Agreed about the binaries, but magnet links or torrents for that matter are just another way to download stuff. I don't get why people fuzz about it that much, it's a link to data.

Nice. There has already been some work on this. You can find the existing project here:
https://github.com/UE4-FreeBSD/UE4-FreeBSD
Also on the Wiki here: https://wiki.unrealengine.com/Compiling_For_FreeBSD
malavon, I don't suppose you are the same guy doing the main port? I tried to contact you using the forums (because GitHub had no contact / author info). https://forums.unrealengine.com/dev...-unreal-engine-4-is-now-available-for-freebsd
In general, it works but there is no "game editor". I personally don't like game editors anyway so UE4 is pretty complete for me haha.

The port you're referring to here didn't go nearly as far as I did in the end, but I did use it to get started for my first version.
The differences are numerous, but the important ones:
* That port was meant for cross-compiling a game server binary using a windows machine. It didn't provide actual FreeBSD support.
* It was no longer up to date. I've updated to 4.19.1, the latest released version
* Didn't have any support for running the engine or compiling an actual game.

What I've made is a (almost) complete port of UE4. That's why I compiled these binaries: to showcase that the engine runs and can be used to create a game on FreeBSD, not just a dedicated server.
It runs the editor, the networked frontend. It compiles shaders, lighting.

 

[kpedersen]

The GitHub repo is private because Epic does not allow any fork of the Unreal Engine to be public..

Actually that is a very good point. I completely forgot and didn't notice because my logged in Git account is already a "member of Epic".

For anyone else, in order for access to the repo, you will need to go through the steps here:
https://www.unrealengine.com/en-US/ue4-on-github

Otherwise yes, we will all have to run ratty anonymous binaries from magnet links haha!

@malavon, wow nice work. It looks like you have made fantastic progress on this. I will download them and have a try .
As for your original question: Yes, I for one am certainly interested in a FreeBSD port and I remember Epic saying that they would like to support FreeBSD one day.
A link to your github repo would be great. I have access to the UE4 repo so should be able to access yours too.

Edit: Your first 3 download links are a bit broken. Luckily you have directory listing: (http://www.malavon.com/~benny/). here goes...

 

[kpedersen]

Cool, ShooterGame is working well!
Version output: 4.19.1-0+++UE4+Release-4.19 516 0
This is running on NVIDIA Quadro K400.

 

[malavon]

Edit: Your first 3 download links are a bit broken. Luckily you have directory listing: (http://www.malavon.com/~benny/). here goes...

I actually didn't mean to have directory listing on I fixed that on my server.
Links are fixed in my original post though.

A link to your github repo would be great. I have access to the UE4 repo so should be able to access yours too.

It's up there in my answer to ShelLuser.

Funny you mentioned ShooterGame, of all the game demos it's my favourite because it really feels polished. That's why I included it here.
As far as tech demo's go, I like the InfiltratorDemo most, but it's also pretty heavy to run.

If there's interest in more demos let me know, I have compiled a bunch of them but didn't publicize all of them. In fact, I had a lot of trouble making them into torrents and stopped after four, but now that's out of the way it doesn't matter much.
they won't stay up forever though, even compressed they take up a lot of space. Shipping version is a lot smaller (relatively that is) than I expected though, the KiteDemo's project directory (including cooked stuff and binaries) takes up 41Gb.

(edit)

@@malavon, wow nice work. It looks like you have made fantastic progress on this. I will download them and have a try .
As for your original question: Yes, I for one am certainly interested in a FreeBSD port and I remember Epic saying that they would like to support FreeBSD one day.

Yeah, they said so in 2014 but ever since it's been quiet on that front, which is why I stepped in. I'm currently trying to reduce the size of my fork even more - to make it easier to maintain and port to newer versions. In its current version I've had to duplicate code for the Linux version quite often, in many cases without changes. I'd like to revert that and use the Linux sources directly where applicable. Another thing I'd like to do is to make it easier for NetBSD and OpenBSD to step in as well by making a lot of the changes I have as a generic BSD platform, except for compilation and shipping configuration. I'm not sure how I'm going to do so though and didn't get any response for my queries on Discord.

 

[malavon]

kpedersen If you test any of the other demo's, could you let me know if you have the audio issue as well? It'll be interesting to know if this is something that only happens on my machine or if it's a general problem.
Recap: in all demos except the ShooterGame, I hear only mono audio (left channel).

 

[kpedersen]

the KiteDemo's project directory (including cooked stuff and binaries) takes up 41Gb.

heh, tell me about it. I teach a unit at University where the students must use UE4 to make a simple game. They *always* drag in resources from the KiteDemo even if they don't use them all. It inflates their project size and means sometimes I have to leave my computer downloading their projects over the weekend just so that I can mark it. A whole class can easily fill a 500GB HD when they do this

Yeah, they said so in 2014 but ever since it's been quiet on that front, which is why I stepped in. I'm currently trying to reduce the size of my fork even more - to make it easier to maintain and port to newer versions. In its current version I've had to duplicate code for the Linux version quite often, in many cases without changes. I'd like to revert that and use the Linux sources directly where applicable. Another thing I'd like to do is to make it easier for NetBSD and OpenBSD to step in as well by making a lot of the changes I have as a generic BSD platform, except for compilation and shipping configuration. I'm not sure how I'm going to do so though and didn't get any response for my queries on Discord.

I had a quick scan through your repo and yes there are quite a few changes. I guess some of the duplication of Linux code was to to modify quickly to see if you can get it working because you had a lot of changes to cover? It also seems that the way UE4 is organised means that entire groups of source files are duplicated. Perhaps rather than having a "Linux" or "FreeBSD" port it should be a single "POSIX" port with a number of smaller tweaks #ifdefed in?

One big issue of NetBSD or OpenBSD ports is that UE4 (and especially the UE4Editor) requires such a hefty GPU that neither of those platforms can support (i.e no binary blob driver). It is annoying that even though UE4 can support "weak" mobiles devices (1Ghz / OpenGL ES), the development tools still require a fairly top of the range gaming PC

Your work is still really cool though. How long have you spent on this? What are your future plans with it?

Edit:
Unfortunately my main computer doesn't actually have working audio. I work in an office with a fair number of people anyway so I have never looked too much into fixing it. I might just replace the sound card one day :S
My personal laptop(s) have audio but nowhere near the required GPU to run UE4 so sorry but that is one thing that I cannot really test

 

[Nils Beyer]

In case anyone is interested in some tech demo's/samples for UE4, I've been busy porting the engine and compiling most of the samples. A few are included here.
These are all based on my personal fork of UE4, there is no support for FreeBSD in the official Epic repo. (...)

fantatstic work from you. Runs very well here on my Ryzen 1700 + RX560 (11.1-STABLE) - no issues so far. Who says FreeBSD isn't suitable for AAA-gaming?

Thank you very much...

edit: being more specific with what gaming I meant

 

[malavon]

More demo's on the way, stay tuned ;-)
I'll add the links in the original post.

heh, tell me about it. I teach a unit at University where the students must use UE4 to make a simple game. They *always* drag in resources from the KiteDemo even if they don't use them all. It inflates their project size and means sometimes I have to leave my computer downloading their projects over the weekend just so that I can mark it. A whole class can easily fill a 500GB HD when they do this

Well, it might help to tell them that KiteDemo was never supposed nor optimized to be used as a game, it was supposed to showcase - back in 2015 - what the engine could do with open worlds and meant as a GDC demo. The LandscapeMountains demo resources are probably better optimized.
Really cool that you're teaching with UE4 Back in my student days that wasn't an option.

I had a quick scan through your repo and yes there are quite a few changes. I guess some of the duplication of Linux code was to to modify quickly to see if you can get it working because you had a lot of changes to cover? It also seems that the way UE4 is organised means that entire groups of source files are duplicated. Perhaps rather than having a "Linux" or "FreeBSD" port it should be a single "POSIX" port with a number of smaller tweaks #ifdefed in?

The duplication was mainly done to separate things better, sometimes I had to make bigger changes, sometimes only small changes. It allowed me to keep an eye on things, but I'd rather not keep it that way.
I've thought about using the POSIX-name as well, but the thing is that both Darwin and Android are also POSIX and I'm afraid that would cause confusion.
Also, as far as I understand it a platform can have only a single platform directory. Not sure about that though, I'm still looking into it.

One big issue of NetBSD or OpenBSD ports is that UE4 (and especially the UE4Editor) requires such a hefty GPU that neither of those platforms can support (i.e no binary blob driver). It is annoying that even though UE4 can support "weak" mobiles devices (1Ghz / OpenGL ES), the development tools still require a fairly top of the range gaming PC

I didn't think about that. I don't really know much about the other BSDs, but I was hoping that they would also get KMS graphics like FreeBSD. That way they'd have the possibility to at least use the open source Radeon or Intel driver. But not having a decent Nvidia driver will definitely hurt them. Nevertheless, it would still allow server packages for these platforms, if nothing else.

Your work is still really cool though. How long have you spent on this? What are your future plans with it?

More than I wanted to, definitely more than it would have cost me booting into an actually supported OS (edit)I started this on the third of march and worked pretty much full days from morning till night and full weekends.(/edit) But I feel it was worth it, really learnt a lot about shared object loading. Of course, if you look into the git repo, all commits are probably from a single day due to rebasing.

Future plans are to clean it up and get it admitted into the official Epic tree. If that isn't an option, I'll be trying to rebase it onto every new version that comes out until I get bored of it.
To be honest, the biggest issue I see right now is that it might start feeling like work instead of fun and that's a big no-no. Because of medical issues I won't comment on, I'm on a strict no-stress, no-effort (sic) regime. Then again, I wouldn't have had the time to do this port if that hadn't been the case.
Before doing so, I expect that I'll be toying around with the Editor a bit, have some fun with it and maybe try and fix some bugs I saw last time I opened it.

Edit: in the very unlikely event that companies would actually want to release a FreeBSD version of their UE4 game, I would love to provide consultancy work, build systems etc

 

[malavon]

fantatstic work from you. Runs very well here on my Ryzen 1700 + RX560 (11.1-STABLE) - no issues so far. Who says FreeBSD isn't suitable for AAA-gaming?

Thank you very much...

edit: being more specific with what gaming I meant

It definitely is. I was surprised that it runs this well myself to be honest, I expected more graphical and performance related issues. Just wait till I can get Vulkan compiled in again. I had to take it out temporarily, even though it compiled, cooking a project (compiling shaders etc) still failed even though that should be possible without having a Vulkan-ready driver I think.
Once Vulkan lands in general, there's really not much that should block gaming on Linux and FreeBSD systems except for the effort that companies should spend on it. That's probably the biggest issue, doing QA for a small group of people doesn't make sense to many managers and frankly, from a business perspective they're right.

Nils, could you let me know if you have the same sound issue as I do? See a few posts above this when I asked kpedersen.

 

[malavon]

More demo's have been added to the original post. I had some issues with the links again, but they're fixed now

If you'd like to see any specific one or know of anything that would be good to test it on FreeBSD (open source games, movies, or even commercial projects that you're working on), let me know and I'll see what I can do.

 

[malavon]

I've been testing the network play in ShooterGame because it's the only demo that actually has network play, but it crashes. I'll try to hunt down the cause, might take a while since it's an illegal memory write somewhere.
Not the first I've had to track down, but not easy to do.
In case someone knows of a better (or especially faster) way than to use watches in gdb, it'll be most appreciated. I'll try valgrind tomorrow as well.

 

[mgp]

malavon, porting UE4 to FreeBSD is absolutely a fantastic idea! Thank you very much for doing this. I'm very interested in your work and no doubt many others are too!
Do you realise how many games will potentially work on FreeBSD? This is awesome!
I'm using UE4 for some hobby game development and I'd looooove to be able to do that on FreeBSD!
Please keep it up and keep us posted. Also try to reach more people, I'm sure you'll find others that are willing to help.

Cheers!

 

[Nils Beyer]

Nils, could you let me know if you have the same sound issue as I do? See a few posts above this when I asked kpedersen.

yes, I have mono-aural sound (left channel only) as well...

 

[kpedersen]

@malavon,

https://www.phoronix.com/forums/for...-natively-to-freebsd-by-independent-developer

You are famous. Just remember me up there that I was the 2nd person to reply on this forum

Also, all the original demos work fine. The ABoyandHisKite one was quite slow for me (It is for me on Windows too with this GPU) but did not show any signs of timing problems with the physics etc.
I will carry on with your latest demos as I get time today and report if there are any issues.

 

[malavon]

Yay, my five minutes of fame. I didn't expect to generate this heat though, now the pressure is on

Too bad it's not in a state to be actually released. I'd love to see epic announce FreeBSD support officially!
No update on the ShooterGame yet, valgrind has been running all night long and the game hasn't even started

For the record, I do need to point to the fact I've also replied earlier: I did base my work of off someone else's start. I went a lot further, but just pointing out that I'm not the only one to be credited.

 

[Nils Beyer]

PlatformerGame (has an issue at the end, when entering high scores; I recall having an issue on Windows too, if anyone can verify that'd be great)

same here - it hangs somewhat, too - no entry possible, but graphics are still updating. I killed it via CTRL+C.

Thanks alot for the additional samples - also running very well here. "Sequencer" is very nice.

 

[vchan]

I was actually planning on working on this myself. I'm glad someone beat me to it. lol Anyways I would really like to play Unreal Tournament on FreeBSD. That would be great. I'm pretty sure the source is available for it as well.

 

[malavon]

I was actually planning on working on this myself. I'm glad someone beat me to it. lol Anyways I would really like to play Unreal Tournament on FreeBSD. That would be great. I'm pretty sure the source is available for it as well.

Glad to have done so I learnt quite a lot doing this.

As much as I would love to play UT on FreeBSD as well, I'm afraid I'll have to remind you of my initial post:

* Don't expect Unreal Tournament to work on FreeBSD soon, it uses UE4 4.12 and I do not intend to port that version

You could of course try to upgrade UT to UE 4.19.1 ... it shouldn't be impossible and I presume that would be less work than porting the entire engine would have been too. And even if official FreeBSD support for the engine would be some time out, I reckon it'd be very useful to the UT project itself.
Should you actually consider this, I do however advise you to ask about this on Discord first (https://discordapp.com/invite/unrealtournament). It's always possible someone is already working on this.

 

[malavon]

An update on ShooterGame, which had some bugs when compiled for FreeBSD.

1. First off was an issue that corrupted the games memory when connecting to a remote host, but because of issue 2 no one could have noticed anyway
2. Network broadcasting in FreeBSD works differently from Linux. It has something to do with binding a socket to 0.0.0.0 and broadcasting to 255.255.255.255, but FreeBSD requires binding to a broadcast address in order to broadcast to the general address (and IP_ONESBCAST socket option). Fixing this requires refactoring code (LanBeacon.cpp & .h) that's also used on other platforms. I don't see myself doing that in the near future.

The result of (2) is that you can't use the join option in the game, there's no way your client will find the server. To compensate for this I've also uploaded a development version (see first post), which has the console enabled. It's bound to ~ and $.
Using this console it's possible to use following command

Open <ip address of server>

This will connect to the server without needing broadcasting.
The upside is that you can use any UE4 command now (like "stat FPS" to show FPS). The downside is that any player can use any UE4 command now.
There's also more logging and it might be slightly slower.

To compensate for this hiatus in gaming user-friendliness, I have added a few more game demos in the initial post
On top of that, I've fixed an issue with the mouse and this has also fixed PlatformerGame's high-score inputting system.

(edit except for some grammar changes)
This also means that the port functionality-wise is pretty far, I don't think I'll be changing much more. It's basically cleanup-time now, which is going to be pretty boring.
So unless there's a very fancy new demo coming out, I won't be adding more compiled binaries here. The existing ones showcase the port well enough I think.

 

[malavon]

Just another small update:

4.19.2 has been released a few days back and this is also reflected in my fork (4.19 branch and there's a tag as well). The master branch is also pretty much up to date, although like before there's still a lot of temporary stuff/commits going around.
It's been a while since I've done some work on the third party libraries, but I'd wager that most of them compile and work now. There is no real how-to yet though.

As far as partial integration in the Epic branch goes, no progress on that front. It's difficult to get a hold of epic people and even more difficult to have a PR approved (I still have a few open for trivial bugs since about a month).
This means that supporting the fork may become quite a lot of work in the future, but I still have hope this may rectify itself.

 

[aimeec1995]

In other words: please download this software from these unknown sources, trust my non-existent forum reputation (first message) when I tell you this can be trusted and most of all please don't ask for any sourcecode in order to verify for yourself what this software is doing exactly.

I assume we should also definitely run this software as root because it doesn't work otherwise?

You mentioned a GitHub repository, so why not give us access to that? Your comment that it would be difficult to clone the repository due to daily changes is plain out nonsense, because of that I can't help get the feeling that you're trying to hide something from us here.

No one in their right mind should try to download and run this.

(edit)

I'm aware my message may sound harsh but in this day and age you can never be too careful. I also couldn't help notice that you didn't even mention against which FreeBSD platform these binaries were build. Is this 10.4, 11.1 or maybe CURRENT? Pretty crucial information if you ask me

If you expect people to trust this then you should give them some good reasons for that. This is not the way how to do that, even if you are being sincere about all this. Problem is that there's no way for us to tell, and as I said: no one in their right mind would take this gamble "just because".

But who would try to infect freebsd users?