Unreal Engine 4.20 & 4.21 and beyond

Jose said:
I'm losing interest rapidly.
Click to expand...

Haha. Actually I was wondering myself why the process hasn't been made a little easier now that Microsoft has taken over GitHub. I would have thought they would have turbo charged the "Paid for code access" API the first second they could.

That said, it is certainly worth it. Malavon has done a great job at porting it. It works well and I would say that it is very production ready. If it wasn't for licensing issues (and logistics) it would have been a great addition to the ports in its current state.
 
I'm not going to approach a for-profit company on bended knee and beg them to let me work for them for free. Especially not if the results of my labor are not going to be shared freely. I get compensated handsomely for doing that sort of thing.
 
Jose said:
Especially not if the results of my labor are not going to be shared freely. I get compensated handsomely for doing that sort of thing.
Click to expand...

Yep, I do understand that exactly. You could start an open-source UE4 game and share that with people but the underlying engine looks unlikely to ever be free.

I would say that Epic's UE4 is doing better than (err) Unity's Unity in that when Epic goes bust, you can keep your project going (unlike Unity which will slowly bitrot into legacy platforms only just like Adobe Flash).

But yes, for my own passion projects, I am like you. Stay light and free. Only recently I wrote a shadow baking tool for my own games just to avoid proprietary (or very large) software which unfortunately can be relatively short lived and restricting.

But again... in 30 years, I doubt anyone will be around to sue me for releasing a UE4 based game open-source. If they are, I will simply do it as one last laugh on my death bed! XD
 
Another thing I forgot to mention. Unreal Engine 5 has been set for 2021, no idea what the future for UE4 will be.

Jose said:
I'm not going to approach a for-profit company on bended knee and beg them to let me work for them for free. Especially not if the results of my labor are not going to be shared freely. I get compensated handsomely for doing that sort of thing.
Click to expand...
Not sure what the deal is really, after all it's just registering an account with Epic and linking your GitHub account. But then again I'm quite pragmatic. Also: free games on that Epic account weekly.
If that's the only thing to do to gain access of tens or hundreds millions of $/€ worth of code, I think it's a pretty good trade off. It's even less difficult than signing an NDA, which is the least to be expected in such a situation really.
Working for free is definitely something you don't have to do. If you're referring to what I do, I see it as giving something to the FreeBSD community, not to Epic.
kpedersen said:
But again... in 30 years, I doubt anyone will be around to sue me for releasing a UE4 based game open-source
Click to expand...
You can legally do that today already, you just can't include a copy of the engine. No fee is required if there's no revenue. All code you write remains yours.
 
malavon said:
You can legally do that today already, you just can't include a copy of the engine.
Click to expand...

Yes of course. However imagine in 30 years I did that. The source would be useless to someone without the rest of the (long since obsolete version) engine. It is not like my code will be able to instantly work on the then current version of Unreal Engine 8. If going by UE3 -> 4 then it most certainly won't.
The potential players would need to track down a specific version of the engine which has no guarantee to still be available.

So yes, I quite possibly would release it all together and hope Epic doesn't wake from the care home to sue me haha. That said, I am making a fairly large assumption that UE4 will still be working (or can even be compiled!) on our magical quantum computers of the year 2050 (more like crappy consumer phones connected to expensive subscription grids).

So, if in 2050 you see a tonne of random LEGO games (though none are UE4 based and full of bitrot!) appear on the torrents along with source code... it may or may not be me XD
 
I really appreciate it when people work Freebsd because it's my chosen platform. I'm grateful for what you do even if I'm not likely to ever use it. Thank you for making it possible to work with the UE engine on Freebsd.

Working like this is just not for me. Having to keep private forks of a private repository so that my work is not gratuitously erased upstream because they don't feel like "supporting" it is not something I want to do. The worst part for me is that no one can pick up my work and build on it because it's invisible to most people.
 
kpedersen said:
The potential players would need to track down a specific version of the engine which has no guarantee to still be available.
Click to expand...
That would definitely be an issue. There's always the chance that in the long run - think ten or twenty years - Epic releases UE4 as real free unencumbered open-source. It all depends on how useful they still deem it I guess.
But like you said, the chances that we'd even be able to compile and run might be rather low anyway.
What I did however mean is that if you want to start an open-source game, there's nothing to hold you back legally right now. Feel free to code something and release it to all of us ;)

Jose said:
The worst part for me is that no one can pick up my work and build on it because it's invisible to most people.
Click to expand...
It's not really invisible, is it? It's only invisible to people not interested in the Unreal Engine. The ones who want to download it, eventually still end up with the right instructions anyway.
 
malavon said:
there's nothing to hold you back legally right now. Feel free to code something and release it to all of us ;)
Click to expand...

There should be. It should be illegal for me to make games and subject people to the torture XD

These are two such classics!

Steam Community :: Error

steamcommunity.com steamcommunity.com

Steam Community :: Error

steamcommunity.com steamcommunity.com

My issue is that everything I make in terms of art is painful on the eyes. I accept this, and I revel in it ;)
No matter how advanced and beautiful UE4 gets. There is probably no helping me haha.

So instead I stick to non-gaming / 3D simulation contracts... Safer for everyone.
 
That said, I am fairly excited because I am nearing completion of my raytracing lightmap generator (so I can avoid the scrappyness that is Blender scripting as well as constantly replacing code as functionality is dropped).

My theory is if I make everything helplessly dark, then people won't be able to see my horrible artwork :)
 
  • Like
Reactions: a6h
Are there any tunables I should try tweaking for gaming in freebsd? My workstation locks up quite a bit when i am doing it and I have plenty of free resources.
 
skeletonboss12 said:
Are there any tunables I should try tweaking for gaming in freebsd? My workstation locks up quite a bit when i am doing it and I have plenty of free resources.
Click to expand...
You'll probably be better off making your own topic, only people interested in the UE4 port are in this topic. Also try to be a bit more detailed (which game, emulated or native, what hardware etc).
 
A bit unexpectedly Epic released a new version in the 4.25 branch even though they're working hard on 4.26. 4.25.4 is on GitHub now.
Not sure what they're doing with future versions, the roadmap mentions using the GPU for lightmass calculations. I hope they won't remove the CPU version since we don't have OpenCL/CUDA for NVIDIA cards on FreeBSD.
 
malavon said:
I hope they won't remove the CPU version since we don't have OpenCL/CUDA for NVIDIA cards on FreeBSD.
Click to expand...

Eeek. That would be a shame. Perhaps there are still a number of platforms out there that Epic want to support without CUDA implementations? Mobile / console?

nmcunl said:
Thank you so much kpedersen :) <3
Click to expand...

Ah I missed this. No worries. But the real person to thank here is malavon. He is doing the entire port single handedly. I am just a forum lurker ;)
 
kpedersen said:
Eeek. That would be a shame. Perhaps there are still a number of platforms out there that Epic want to support without CUDA implementations? Mobile / console?
Click to expand...
Well, lightmass runs during the build/bake process, so what matters is the development system (Windows/Linux for Android, MacOS for IOS). I'm pretty sure they can change this without impacting their actual development platforms.
We'll see what happens.

Sidenote, it appears that Chaos is production-ready for 4.26. I hope Epic decide to release their destruction rail demo so it can be compiled for FreeBSD as well.
 
malavon said:
Well, lightmass runs during the build/bake process, so what matters is the development system
Click to expand...

Ah yes; good point!

malavon said:
Sidenote, it appears that Chaos is production-ready for 4.26. I hope Epic decide to release their destruction rail demo so it can be compiled for FreeBSD as well.
Click to expand...

That is looking pretty awesome. It makes me shudder to think how much complexity there is in the engine now!

Do you see any potential work being done to speed up the iterative build times? Any stubs to Cling? Or perhaps even some hint that the Python layer will be within the engine itself rather than just the editor?
 
kpedersen said:
That is looking pretty awesome. It makes me shudder to think how much complexity there is in the engine now!
Click to expand...
I haven't looked into it very much, but since it's encapsulated inside the engine it's probably easier than it used to be with PhysX. Complexity may have gone up, but UE4's modularity helps separating everything nicely.
kpedersen said:
Do you see any potential work being done to speed up the iterative build times? Any stubs to Cling? Or perhaps even some hint that the Python layer will be within the engine itself rather than just the editor?
Click to expand...
Python is still in experimental status, but as far as I see it's possible to use Python (code-wise that is) aside from the editor. I haven't tried it though, so there might actually be issues there. But it's not documented as such.
Note that Python support in FreeBSD is a bit sketchy right now, it requires python 2 instead of the 3 branch.
Any other script-like thingies might be there but I generally only see the parts of the engine that break :) It shouldn't be too hard to implement though, take a look at the ScriptPlugin plugin. It's an example how to add scripting languages.
 
Ok, since there are 2 bugfix releases for the 4.26 branch already and I haven't released any FreeBSD versions yet, a quick look into why that is.
The 4.26 branch is the first where Vulkan is the only option available to Linux users (and thus FreeBSD). So logically I've assumed that that would make my life easier, since there's only one RHI to test anymore. There were a few other things that took some time, but nothing earth shattering. However, what looked like a very simple maintenance release has turned into a nightmare. Vulkan used to work before but I can't get it to work with the 4.26 branch - which uses different initialization code - at all. I assume it does work on Linux (haven't tested it), but it just won't work on FreeBSD. Maybe there's some obscure issue with FreeBSD 12.2 (previous releases were on 12.0 & 12.1), but I highly doubt that.

Each UE4 release I keep hoping that there was an issue that has been resolved. Twice I have been disappointed. I've done everything I can to find out if there's an issue with my system, but all other vulkan software works without issues. When NVIDIA released their beta driver, I hoped that maybe there was a very obscure error in the nvshim that I use for Vulkan support. I tried an entire month to get Vulkan working and failed each and every time.

For the record, I don't know anything about Vulkan programming. I can't just look at the initialization code and spot what's wrong. The only way right now that I think I can try and solve this is by starting the 'random change/delete' method. Just keep deleting code until it works and then figure out why. The other alternative is to reimplement the whole init code with the Vulkan examples and Khronos documentation and then work from there.
Both are however difficult, with code spread over many places inside the engine. Even the vulkan headers are available in three different versions throughout the codebase, which makes debugging even harder.

If someone wants to try and have a stab at it, please do. All releases are on my github in separate branches for each release, without any major modifications to the Vulkan stuff. Everything compiles on FreeBSD and I'm pretty certain it'll work as it is, except for the Vulkan part that is. At the very least this could tell me whether or not there is maybe a local issue that I'm not seeing.

Anyway, I do hope to take another stab at it sometime but I'm really despairing each time I just open up the code. I feel like I'm missing something incredibly obvious as this has happened before (non-vulkan), but it's the first time I'm not having any luck finding it.
Hope to get back to you all one day with better news though. Right now I am however busy with another (commercial) project, of course not UE4 related and I don't expect to find much time for this for several more months.
 
You must log in or register to reply here.
Back
Top