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

Member

Reaction score: 56
Messages: 84

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: 474
Messages: 1,342

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

Member

Reaction score: 56
Messages: 84

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

Member

Reaction score: 56
Messages: 84

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: 474
Messages: 1,342

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

Member

Reaction score: 56
Messages: 84

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: 474
Messages: 1,342

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. :)
 
Top