Hard Light Productions Forums
Off-Topic Discussion => Gaming Discussion => Topic started by: Grizzly on March 19, 2014, 12:57:17 pm
-
Which is damn cheap (https://www.unrealengine.com/blog/welcome-to-unreal-engine-4). Although they do want 5% of the revenue should you actually go on and sell the game.
-
Holy ****, and they've even made the source available. How the hell is that going to work legally? Epic automatically owns any code modifications?
-
Holy ****.
-
(http://i.imgur.com/xmFcZZi.gif)
FUKH YEARH!
-
Holy ****, and they've even made the source available. How the hell is that going to work legally? Epic automatically owns any code modifications?
Depends on the terms of the license.
-
www.youtube.com/embed/PD5cRnrMqWw
Here's a trailer showing some of the features in UE4. Also, it's great that someone started this thread and it wasn't me!
-
... But will it SEXP?
-
I work for a game company that doesn’t use Unreal. Am I allowed to use the Unreal Engine on my personal time?
Yes, the EULA is very liberal in this regard. It doesn’t contain a Non-Disclosure Agreement. You’re free to use, learn from, and freely discuss the Unreal Engine even if you’re developing a competing product or technology.
^This sounds very good.
-
Daaaaaaaaaaaaaamn. I'm an eternal pessimist so I keep looking for a cloud behind the silver lining but it really doesn't seem that there is one. It's really the full source? (thinking of FS's issues with the MVE stuff here)
Comments on the gamedev le reddit discussing the subscription model vs. Unity: http://www.reddit.com/r/gamedev/comments/20tnfm/unreal_engine_4_has_been_launched/cg6p4q5 (tldr it's MUCH better than Unity for a much better product).
Epic Games ftw
-
I also got the email. This is great stuff.
-
Here's that cloud behind the silver lining (http://www.cryengine.com/news/crytek-announces-its-cryengine-as-a-service-program).
-
Shots fired in the engine wars then. I wonder whether we'll see similar stuff out of DICE soon.
-
I kind of wish this has started back before Squad started developing KSP... Maybe, just maybe we wouldn't be stuck with that piece of junk Unity is (honestly, that engine can't even grasp the concept of memory paging, and the 64bit version is broken beyond belief).
-
Unity is still a pretty great engine, and Unity 5 will have 64-bit support, multithreading, and all the other goodies.
http://www.androidpolice.com/2014/03/18/gdc-2014-unity-launches-unity-5-graphics-engine-with-prettier-everything/
-
Notice they said nothing about it's ability to page memory. :) This is what KSP could really use, though 64bit support should alleviate this problem for quite a few users. That said, it's not that Unity 5 won't be an important milestone, and maybe it will help with the memory issues 32bit, too.
-
Honestly, I have no idea what you're referring to with "memory paging" in this context, or what the particular issues are that Squad ran into while working on something Unity wasn't really designed for.
I mean, yeah, Unity may not have been particularly suited to the needs of KSP, but there's little indication that UE4 or CryEngine would have been better.
-
I wonder whether we'll see similar stuff out of DICE soon.
We won't. The Frostbite isn't quite the stand-alone package like UE and CE are, it hasn't so far been designed for distribution. Creating games on Frostbite engine requires a variety of other professional (and expensive) sets of software. DICE might want to compete with UE and CE, but does EA? EA might not see the point in allocating resources towards that end and instead prefer to keep Frostbite in-house, where these requirements aren't an issue. Especially now that UE and CE have entered what looks like pricing wars to cater indie developers. I don't think EA cares very much to enter that war for the good of indies.
Additionally DICE and/or EA might even believe that when you don't have to consider distributing the game engine outside the house, they can depend on whatever non-free software the world has to offer and integrate the engine with them however tightly they want.
-
Hell, for 9,90€ per month, I'll definitely grab myself a Cry license.
-
Hell, for 9,90€ per month, I'll definitely grab myself a Cry license.
Yeah it is quite appealing isn't it? Especially considering UE is twice as expensive and apparently has 5% royalty fee while CE has none.
-
To be fair, we don't know the full text of the license yet. But purely in terms of how much it costs, that price point is hard to beat (and the question of how much royalties you have to pay is something to tackle once there are royalties that can be paid).
-
I really suspect that the whole "CE has zero royalties" is just nonsense. Literally true, but with large caveats. I mean, are we supposed to believe that from now on, AAA titles will only pay 9.99 per month to Crytek? Even if you are saying this is only a license per computer, it's still so dirt cheap I am just baffled.
Or perhaps this is a new age of middleware indeed and I hadn't noticed it. Quite contrasts with licenses of stuff like Lumion, which has a licence of 4 thousand bucks and is probably just a CE screen with good UI on top.
-
Notice they said nothing about it's ability to page memory. :) This is what KSP could really use
if you mean what I think you mean (KSP's ability to address more than 4GB of memory), that's a problem inherent in the 32bit version. 64bit will solve it (not for "quite a few users", for all users with more than 4GB of memory). It's actually the main reason everyone is clamoring for 64bit support.
re:Crytek - I've never really played around with that engine like I have with UDK and the UT games, but I'm loving these AAA engines warring over indie developers. Whoever wins, we win!
-
One reason why the CryEngine license is so cheap may be because CE is nowhere near as user-friendly as Unity or Unreal are.
-
There's a stream going on at http://www.twitch.tv/unrealengine for a bit. Currently 2:10 Mountain Daylight Time.
Stream over
-
Notice they said nothing about it's ability to page memory. :) This is what KSP could really use
if you mean what I think you mean (KSP's ability to address more than 4GB of memory), that's a problem inherent in the 32bit version. 64bit will solve it (not for "quite a few users", for all users with more than 4GB of memory). It's actually the main reason everyone is clamoring for 64bit support.
"Quite a few users", by that I meant people who actually have more than 4GB of memory. An increasing number, but let's face it, not everyone has this much.
Also, I didn't mean the fact it can't address more than 4GB of memory. No, I meant memory paging, which is a separate feature entirely, and normally, greatly increases raw memory available, at the cost of slowing the game down, sometimes very noticeably. That's why you can run ArmA III on a 32bit rig with 3GB memory, textures maxed out. It'll probably run incredibly sluggishly, but should not crash unless it bogs down so much it's killed as unresponsive (unless you're short on HD space. Then it may run out of that, and crash).
Paging works by removing some data from memory and storing it on your HD. The game keeps the most necessary stuff in memory, while sending the rest to a special file on HD. This file can grow quite a bit (you can set it's size in the Windows settings), and it's altered all the time due to changes in memory utilization. That's why if you have your "page file" (which is used for this) on an SSD, you get a performance increase at the cost of SSD's lifetime (page file is written to and read from very frequently). Sometimes you might also notice fluctuations in available HD space when playing a memory-intensive game or browsing with a lot of tabs (though other temporary also contribute here). They can be quite large, depending on how big your page file limit.
Now, for some reason, KSP can't do that. You've got 3.5GB, end of the story. And everything is loaded into it at the start. On the other hand, once you do load it all up, notice there's no FPS impact, even if you're just under the threshold. This is another sign of it just stuffing everything into RAM at once, and perhaps the only advantage of this approach (which I'd gladly give up. My HD can keep up with this).
-
Notice they said nothing about it's ability to page memory. :) This is what KSP could really use
if you mean what I think you mean (KSP's ability to address more than 4GB of memory), that's a problem inherent in the 32bit version. 64bit will solve it (not for "quite a few users", for all users with more than 4GB of memory). It's actually the main reason everyone is clamoring for 64bit support.
"Quite a few users", by that I meant people who actually have more than 4GB of memory. An increasing number, but let's face it, not everyone has this much.
Also, I didn't mean the fact it can't address more than 4GB of memory. No, I meant memory paging, which is a separate feature entirely, and normally, greatly increases raw memory available, at the cost of slowing the game down, sometimes very noticeably. That's why you can run ArmA III on a 32bit rig with 3GB memory, textures maxed out. It'll probably run incredibly sluggishly, but should not crash unless it bogs down so much it's killed as unresponsive (unless you're short on HD space. Then it may run out of that, and crash).
Paging works by removing some data from memory and storing it on your HD. The game keeps the most necessary stuff in memory, while sending the rest to a special file on HD. This file can grow quite a bit (you can set it's size in the Windows settings), and it's altered all the time due to changes in memory utilization. That's why if you have your "page file" (which is used for this) on an SSD, you get a performance increase at the cost of SSD's lifetime (page file is written to and read from very frequently). Sometimes you might also notice fluctuations in available HD space when playing a memory-intensive game or browsing with a lot of tabs (though other temporary also contribute here). They can be quite large, depending on how big your page file limit.
Now, for some reason, KSP can't do that. You've got 3.5GB, end of the story. And everything is loaded into it at the start. On the other hand, once you do load it all up, notice there's no FPS impact, even if you're just under the threshold. This is another sign of it just stuffing everything into RAM at once, and perhaps the only advantage of this approach (which I'd gladly give up. My HD can keep up with this).
AFAIK, memory paging is a feature of the operating system and the memory management unit. Neither Unity nor any other engine should mess with that.
Now, beyond paging there's a different issue to consider: Virtual memory and address space. On (pure)32-bit platforms (without PAE or equivalent), you can't even use more than 4 gigs of virtual memory (physical RAM + paged to disk) in a single address space. This is one of the reasons 64-bit programs are often faster than 32-bit (not the most important though, AFAIK). And since PAE and segmentation are a pain, I wouldn't want to support them either (seriously, it's 2014. If you're on x86, chances are you've got a 64-bit machine).
-
You also need a 64bit OS, and while those are available, Windows 64bit were, last time I checked, more expensive than 32bit. Not to mention you might be waiting for Windows 9 with an upgrade, even if do intend to buy a 64bit version. Though if this does allow Unity to use virtual memory on a 32bit system, then it'd be an improvement.
AFAIK, memory paging is a feature of the operating system and the memory management unit. Neither Unity nor any other engine should mess with that.
I though that too, but for some reason, it doesn't work with Unity. Strangely enough, some people reported that it was, in fact, forced to page by the OS when running out of memory, but those were isolated cases, and in most cases I remember, running sub-par rigs with little memory. What I know is that it doesn't work the way it does in every other game, and I suspect it's Unity's fault, because I remember getting a very similar crash on another Unity game (don't remember which one), too. Well, that, and the fact the page file's size doesn't seem to be affected by KSP running.
-
You continue to not understand what paging is. Paging allows you to create a virtual memory space the size of your address space, by shuffling blocks of data between physical memory and the disk. It is useful when you want your program to be able to access more memory than than you have physical RAM; it is also very slow. It is more or less precisely the opposite of the problem with KSP on Windows, which is that the computer has more physical RAM than Unity is able to access. This happens because Unity is, for some bizarre reason, only available on Windows as a 32-bit binary (a 64-bit OS can run 32-bit programs without any trouble, they just can't access any 64-bit resources).
-
i have been running 64-bit hardware and os FOR TEN ****ING YEARS! its sad to see so many 32 bit applications on my system.
as a ksp modder i have to say that their asset management code is a total crapfest. users are pushing so many textures (usually as a result of mods, which always stack against eachother) that the game looses its ability to allocate memory within its virtual address space, resulting in a crash. not to mention the garbage collector for c# is really slow, which just makes the problem worse. the epic load times stem from the fact most of the assets are not pre-optimized. you know how freespace mods mostly use .dds textures that are ready to go when the game needs them. nope, not with ksp, we have to convert them from tga/png to dxt1,5. now i think you can actually use pre-optimized assets, but the textures are wrapped up in an obscure material container format (mbm or something), and most modders dont use them for other reasons (they are anal about being able to edit textures, which you cant because obscure container format). there is actually a mod that is supposed to fix the pre-optimized asset problem, but i think it just ends up making things worse. if only ksp had the scp's texture management code.
oh and i even went as far as using the 64 bit linux version. in that version half the plugins crash the game, so you cant get enough mods to work with it to justify using the linux version to get 64 bit support.
-
oh and i even went as far as using the 64 bit linux version. in that version half the plugins crash the game, so you cant get enough mods to work with it to justify using the linux version to get 64 bit support.
better than the last time that i tried it :p
half a year ago, it was CTD immediately after opening.
as a side note, Dragon, stop thinking that swapping is actually a good thing.
the basic problem with KSP at the time being wrt the load times is the mod authors.
"WHY SHOULD WE BOTHER USING THIS OBSCURE 'DDS' FORMAT!"
that and the fact that the tooling support is crap. or at least was around half a year ago, when was the last time i bothered looking for the parttols or equivalent these days.
also, Nuke, afaik, MBM format is not dxt, its still some uncompressed quasi-format.
-
Ah, I see what you mean now, Dragon. You are, of course, thoroughly mistaken about where paging fits in in the ressource management process.
Basically, paging is something the operating system does to other processes when one process has increasing memory demands. Only under the most dire of circumstances will an OS page stuff out of a currently active process, and if it does, performance goes out the window immediately.
What you are seeing in KSP is an issue of asset management. Whether or not this is implemented well in Unity, or in KSP, is something I cannot say for sure, but I would hazard a guess that it is more a problem of Squad not doing it right, and modders having no idea how to deal with an open system like KSP (the same problem can be seen in Oblivion and Skyrim modding).
Let me repeat this once more: No engine, not Unreal, not Cry, not whatever ArmA is using, implements a manual paging process. What they are doing is managing memory by unloading assets unused in the current scene and loading those that are, the gritty details of whether those assets are stored in Memory or in the pagefile is left up to the OS to decide (because the OS has a better idea of what can be paged than any application programmer has).
-
Applications also just don't get access to the level of memory manipulation required to implement paging. They all get loaded into their own individual virtual address space, which is why KSP can't alter the text of a document you have open in Word.
-
Applications also just don't get access to the level of memory manipulation required to implement paging. They all get loaded into their own individual virtual address space, which is why KSP can't alter the text of a document you have open in Word.
An application-level program can most definitely implement and use its own pager, it just can't force other applications to use it. I can't imagine why the operating system's pager wouldn't be good enough though, but whatever.
-
KSP can't alter the text of a document you have open in Word.
Well, it can; it's just hard. There are a category of programs out there specifically for altering other programs' memory values, after all.
-
I dunno, they generally use all kinds of dirty tricks to open a channel to the target program's memory space from inside. DFHack replaces some of the libraries DF uses with modified versions, for instance.
-
I meant more along the lines of Cheat Engine (http://www.cheatengine.org); generic memory scanners.
-
I meant more along the lines of Cheat Engine (http://www.cheatengine.org); generic memory scanners.
Or, you know, debuggers.
Also, application programs can do something like "paging", at least on POSIX-operating systems, by way of mmap() and munmap(). The problem there is that, again, on 32-bit programs/OS, you end up cluttering your address space. If you mmap()/munmap() often, you won't be able to mmap() a large contiguous allocation at some point. Basically memory fragmentation. Which is why it's beneficial to have a virtual address space significantly larger than the physical memory of your machine. So really, 64 bit is a vast improvement.
-
I meant more along the lines of Cheat Engine (http://www.cheatengine.org); generic memory scanners.
Or, you know, debuggers.
Also, application programs can do something like "paging", at least on POSIX-operating systems, by way of mmap() and munmap(). The problem there is that, again, on 32-bit programs/OS, you end up cluttering your address space. If you mmap()/munmap() often, you won't be able to mmap() a large contiguous allocation at some point. Basically memory fragmentation. Which is why it's beneficial to have a virtual address space significantly larger than the physical memory of your machine. So really, 64 bit is a vast improvement.
Hmm, interesting, I didn't know about this. And it seems I've got this and actual, OS-side pagning mixed up. I suppose this is the program-side "paging" I was really thinking about when I wrote my previous post (is there a proper name for it in English?). Come to think of it, most other engines have proper 64bit already... Well, in that case, I'll wait for Unity 5 and see how it runs.
-
oh and i even went as far as using the 64 bit linux version. in that version half the plugins crash the game, so you cant get enough mods to work with it to justify using the linux version to get 64 bit support.
better than the last time that i tried it :p
half a year ago, it was CTD immediately after opening.
as a side note, Dragon, stop thinking that swapping is actually a good thing.
the basic problem with KSP at the time being wrt the load times is the mod authors.
"WHY SHOULD WE BOTHER USING THIS OBSCURE 'DDS' FORMAT!"
that and the fact that the tooling support is crap. or at least was around half a year ago, when was the last time i bothered looking for the parttols or equivalent these days.
also, Nuke, afaik, MBM format is not dxt, its still some uncompressed quasi-format.
its a container format. by default it just contains raw bitmap data. if you screw with the unity settings you can export dxt* in your mbms (its not obvious how to do this, and i dont think its documented anywhere). i would love it if they just could use dds directly. it would eliminate the confusion amongst the modders.
-
Coming later this month: Unreal Engine 4.1, including the Elemental demo and better linux support, among other things.
https://www.unrealengine.com/blog/41-update-preview
-
http://www.gamingonlinux.com/articles/the-community-has-beaten-epic-at-porting-the-unreal-editor-to-linux.3671
Looks like this whole source code access thing is working out pretty well!