Unreal Engine 4.20 & 4.21

Beastie7

Well-Known Member

Reaction score: 160
Messages: 401

This is really exciting work. Thanks so much for this. As someone who plans on starting game development on FreeBSD - this is great to hear.

I have question. Can this engine be used for simple 2D games with just a text editor? Also, have you came across anything that's missing in FreeBSD that could make it a better game dev platform? ie Sound servers, graphics libraries etc, etc,

Thanks.
 
OP
OP
M

malavon

Active Member

Reaction score: 77
Messages: 121

Can this engine be used for simple 2D games with just a text editor?
No, not really. Whatever you'd develop in UE4 you'd still need to import your assets, sounds etc using the editor. By my knowledge there are no command line tools for this.
As far as 2D goes, there is a module named Paper2D which apparently is pretty powerful but it's not being developed any longer. It's not deprecated or so, it's put in the hands of the community.
If I were to make a 2D game I'd go fake 3D (fixed orthogonal camera on the side/top) instead of actual 2D. It's more powerful, but takes more resources.
That said, for pure 2D games there might be better options out there aside than UE4.

Also, have you came across anything that's missing in FreeBSD that could make it a better game dev platform? ie Sound servers, graphics libraries etc, etc,
Yes and no. There are quite a few features missing because I don't have compiled the required libraries on FreeBSD yet (most notably and annoying CEF3).
But as far as FreeBSD ports go, there isn't much missing. UE4 is mostly statically linked to libraries compiled (and sometimes modified) specifically for the engine. It's more a question of stuff compiling on FreeBSD
than actually having stuff in FreeBSD, if that makes sense.

From Epic's perspective the FreeBSD port is missing cross-compiling support - mainly because I don't see the value of it. I'm in the 'set up the OS you need in a VM' camp.
 

kpedersen

Daemon

Reaction score: 487
Messages: 1,361

I'm in the 'set up the OS you need in a VM' camp.
This actually follows on quite well from Beastie7's question. UE4 (and Unity) with their editors makes cross compiling in a VM a pain in the butt (in the way that they both require more functionality than a virtualized GPU can provide). Both have "headless / dummy" display modes but sometimes you need to tweak a few settings which is very awkward if the editor is required to do so.

So I guess I am from the "use a ratty computer set up in the corner" camp ;)

Which is why your great work on porting UE4 to FreeBSD is an absolute godsend for me. I can run my labs and lectures on the OS I actually like because VMs were not at all an option!

As a side effect, you have single handedly allowed me to justify removing all traces of the toy known as Unity from my unit :)
 
OP
OP
M

malavon

Active Member

Reaction score: 77
Messages: 121

UE4 (and Unity) with their editors makes cross compiling in a VM a pain in the butt (in the way that they both require more functionality than a virtualized GPU can provide)
I'd personally use the VMs as build server, without any editor at all. So when I'd have to make a change, I'd do it on my local machine, commit/push and then checkout/pull it on the build VM(s).
Certainly, if you'd want to run the editor I wouldn't recommend doing it in a VM. For building (compiling, cooking, staging, deploying) headless - as far as I know - the best tool is UE4's AutomationTool, with a command like this:
mono ~/development/UnrealEngine/Engine/Binaries/DotNET/AutomationTool.exe -ScriptsForProject=~/development/unrealprojects/InfiltratorDemo/InfiltratorDemo.uproject BuildCookRun -project=~/development/unrealprojects/InfiltratorDemo/InfiltratorDemo.uproject -noP4 -clientconfig=Shipping -serverconfig=Shipping -utf8output -platform=FreeBSD -targetplatform=FreeBSD -build -cook -map= -unversionedcookedcontent -compressed -stage -deploy -cmdline= -Messaging -device=FreeBSDNoEditor@limbo -addcmdline=-SessionId=001812BD08D681FB6A61747CE8172C4D -SessionOwner='benny' -SessionName='limbo'

Less resources are consumed this way, because the editor is a bit of a resource hog.
You can get this command line if you run 'UnrealFrontend', let it run for a few seconds/a minute and then copy the command line (with the copy button). Don't close the window till you've pasted it though.
Which is why your great work on porting UE4 to FreeBSD is an absolute godsend for me. I can run my labs and lectures on the OS I actually like because VMs were not at all an option!
Wish I was still in uni, so much more interesting stuff to learn than when I was young.
It's great knowing there's someone out there using this, makes it easier to dedicate time to this port.
 
OP
OP
M

malavon

Active Member

Reaction score: 77
Messages: 121

A few days ago I ported 4.22.0. As always, Epic is frantically fixing bugs and 4.22.1 will probably surface in less than a month.
Not much more to tell at the moment. Tests passed just like they did on 4.21.x, projects still compile and run :)
 

kpedersen

Daemon

Reaction score: 487
Messages: 1,361

Nice work :)

I know there was a big push to get compile times faster by integrating Live++ into the pipeline. Is this just on the Windows build do you know?

Faster compile times (for projects) would be a massive bonus for me; gets a bit awkward during lectures having to wait up to a minute for a compile to demonstrate a small code change. I often have to prepare a slide of "filler" but to keep their minds from wondering XD.

.cpp files aren't so bad but headers with the additional ubt / uht processing step can be quite slow.

Tim Sweeny was on reddit looking at interest in a scripting language due to the compile times (and because Blueprint is a bit naff). Obviously all the language buffs kept chiming in with sodding Python but in reality I would very much like to have seen something like Cling (CERN's C++ scripting language based on LLVM) being used. That way faster iteration times and yet release builds can compile into 100% machine code rather than any interpreted parts all whilst keeping with a single homogeneous language (and kill Blueprint / other Kismet replacements ;)).
 
OP
OP
M

malavon

Active Member

Reaction score: 77
Messages: 121

I've been looking into what kpedersen mentioned, took me a while to get back here to report on it but I wanted to be able to give actual information :).

I know there was a big push to get compile times faster by integrating Live++ into the pipeline. Is this just on the Windows build do you know?

Faster compile times (for projects) would be a massive bonus for me; gets a bit awkward during lectures having to wait up to a minute for a compile to demonstrate a small code change. I often have to prepare a slide of "filler" but to keep their minds from wondering XD.

.cpp files aren't so bad but headers with the additional ubt / uht processing step can be quite slow.
To be fair I had seen stuff about compile time improvements during development, but assumed Live++ was Windows only. I now looked into this and I found that Live coding is compiled only on the
Windows version of the editor. So at least right now this isn't supported on any of the other platforms (Mac, Linux and FreeBSD). The code can be found under Engine/Source/Developer/Windows/LiveCoding
which is a dead giveaway.
I am wondering if it would be a lot of trouble to monitor the filesystem and auto-compile when something is changed. Then again, the editor really doesn't like it when something that's compiled
runs into an assert somewhere or any other type of exception. So I'm not sure this would actually be a good thing.

I did get the feeling during development that some things were faster, but I'm not sure about the entire compile process actually being faster as mentioned on the 4.22 release notes. If someone is
able to verify this by compiling 4.21.2 first and then compiling 4.22.0, please let us know in this thread.
Some things like header processing are definitely faster (or at least feel faster), but I didn't do any measurements so can't quantify this.

Tim Sweeny was on reddit looking at interest in a scripting language due to the compile times (and because Blueprint is a bit naff). Obviously all the language buffs kept chiming in with sodding Python but in reality I would very much like to have seen something like Cling (CERN's C++ scripting language based on LLVM) being used. That way faster iteration times and yet release builds can compile into 100% machine code rather than any interpreted parts all whilst keeping with a single homogeneous language (and kill Blueprint / other Kismet replacements ;)).
That would explain all the "NODE_JS NOT FOUND" and "PYTHON NOT FOUND" error messages that the build system has been giving since a few months. Since everything kept working I didn't pay much
attention to these yet. But if this is because of new scripting languages, I'm pretty sure there will be a demo soon to demonstrate some of them. I'll fix this then, but it's good to know it's coming.

Note about blueprints: I'm not exactly a big fan of it but looking over the UE4 forum it would seem a lot of people do use them, especially artists with little to no coding experience.
While scripting languages could be a solution to some people, I'm pretty sure it wouldn't be for most of them (especially not something that looks and behaves like C++).
 

kpedersen

Daemon

Reaction score: 487
Messages: 1,361

Many thanks for looking into that. It is really fantastic that you are able to keep your FreeBSD porting work in sync with upstream.

Oh well, I can deal with the compile times, I just need to be a bit smart about it.
For my own uses, I also need to shake the habit of :!make every couple of lines ;)

No problem with Blueprints; so long as I don't need to use it. I still get a bit shakey using the Material Editor. I wish they would use a transpiler like NVIDIA's Cg rather than force me to use a node based system that will change each year but oh well. :)
 
OP
OP
M

malavon

Active Member

Reaction score: 77
Messages: 121

Told you it wouldn't take long :) 4.22.1 was released a few days ago and I just finished porting.
I am however not making a tag just yet. I had some troubles with the .NET binaries in the project which didn't get rebuilt as I expected they would have been.
Result is that I'm not getting an AutomationTool.exe which I I use in my tests.
There is a branch 4.22.1 if someone would like to give it a try and see if it's only on my setup.

I did some compile time comparisons with 4.21.2 and found the following (first line is output from build system, second output from time):
4.21.2
Total build time: 2625,20 seconds (Local executor: 2552,72 seconds)
20111.056u 884.300s 52:24.31 667.7% 47950+3410k 1963241+492857io 553175pf+35w
4.22.1
Total execution time: 3194,43 seconds
23442.020u 1010.971s 1:03:46.96 638.9% 47816+3396k 2212565+564964io 645849pf+57w

Procedure used:
1. make ARGS=-clean
2. ./Setup.sh (to clean all third party libraries)
3. rebuild all third party libs (see second post in this thread)
4. time make

Not scientifical at all. Take it for what it's worth. I wouldn't exactly call it faster :cool:
 
OP
OP
M

malavon

Active Member

Reaction score: 77
Messages: 121

I was lured back here by that thanks and remembered that I hadn't said what the issue was.
The same as always, I just forgot to run UnrealFrontend to create the AutomationTool.

So the tag has been on the Github repo for 10 days now.
 
Top