StubbinMyToe

It's incredible how arrogant you are. You don't need to be able to write code to observe how **** an engine performs, especially when you have other engines to compare it to. I have already explained IN DETAIL, go read it. I am not arrogant, I just have a low tolerence for people who make statements without having any knowledge about software development. I am done with you, come back when you have a clue. Edit: I finally found out how to ignore this kid.

Wrong, the fastest games were writtten in Assembly language and eventually C, then C++. C# and Java are higher level languages, but they are perfectly capable of producing very fast games, it all depends on the skill and knowledge of the developer! And regarding DirectX, it is as fast as possible to write to a graphics card without creating your own device drivers! Do you know how DirectX functions under the hood? I do! Which ones were written in assembly language? I hope you're not talking about pre 95' engines? I'm dying to see fast engine made by c# or java (or any other application). It doesn't only depend of the skills and knowledge, but garbage collector, JIT and other language related factors. A perfect c/c++ game engine will be much better (and faster) than perfect c#/java engine. The later have larger memory footprint and memory allocation is much faster in C/C++. nVidia claims Linux can achieve 300% more performance in OpenGL than Windows with dx. They were probably thinking about upcoming Vulcan (the new OpenGL, but not exactly). It will give much more power to developers. It will be even possible to control graphic card directly from the engine level;. Plenty of games were made with Unity that perform well, they can be seen here (not all of them are great but many are, again it depends on the developer skills with the engine): http://unity3d.com/showcase/gallery Everything I did in the 80's was in pure Assembly, this was on the C64. When I moved to the Amiga it was Assembly and C, eventually C++. In the 90's it was C/C++ but Assembly was used especially in 32 bit DOS games where I wrote my own bank switching code that sat on top of VESA. All my device drivers were 100% assembler and ran in Ring-0 and included bi-modal IRQ handlers to reflect IRQ's up to higher level protected mode code. For Windows games, we used the GameSDK (this was the pre-cursor to DirectX) so that we did not have to write bank switching code for 8 million different video cards. The games themselves were written in C or C++. In the 2000's we used mainly C++ especially on applications such as Adobe Photoshop, and we had our own custom framework that ran on both Windows and the Mac. I never said the game engines were written in C# or java, but the game logic certainly can be and is done a lot of the time nowadays. DirectX goes directly to the hardware, so it is very fast. OpenGL might be faster under Linux, but that is mainly because Linux is lightweight compared to Windows, meaning Windows has to ship with support for all kinds of hardware, where Linux can be configured to only support what is currently in the hardware leading to much better performance. Unfortunately, there is no real market for games in Linux when the vast majority of gamers use Windows, so the nVidia point is moot. nVidia used to have a big advantage in Windows because they had very good connections to low level developers at Microsoft (I had access to the same developers when I was working on video drivers for video editing hardware). Some of those good developers left Microsoft and moved to AMD about 10 years ago, so AMD device drivers (which were notoriously bad) have become better. You are right that there are options for the developers to query/enumerate the hardware features, then have the code dynamically use that knowledge to boost performance with vertex buffers, texture sizes, shader logic, etc, but very few developers (especially the Indie devs) have the knowledge and skill to do this. And that IMO is why you can have game X perform like crap and game Y perform great even when both are using the same engine. This is even more true on mobile devices where things like texture and vertex management become extremely important. FWIW: I am glad to have had the chance to get into development back in the late 70's. Back then we packed quite the punch on very limited hardware like the Atari consoles and 8 bit computers like the C64 etc. We did that by using mostly assembly code and using various hardware tricks, this is a lost art today. Games and Applications have become bloated crap, and very few people innovate, most use 3rd party SDK's or worse they use code on the internet that they do not understand, especially for AI, pathfinding, and high speed rendering algorithms. Sure, the graphics and sound are much better, but not enough to explain the difference in size/bloat. It's not that programmers don't want to make small and fast code, but today deadlines are short and investors/publishers are more interested in a cash grab than writing some solid code. It is always great to roll your own engine, but very few projects will allow that, and if they do you can count on them to try and release as many games as they can with it, even if the engine becomes old and outdated! That is why 3rd party engines are useful, the developers of Unity, Unreal, Torque, and other engines can focus on optimizing the low level stuff while the game developers can work on the game logic. BUT, they should have a VERY GOOD understanding of how the engine works so that their code does not run like crap with it.

When games A and B do a similar thing but B has half the framerate while consuming double the memory and CPU/GPU processing power, then it is a simple judgement to say that B is less efficient than A. You don't need to run a profiler, debugger or other monitor to see the results. With PoE's fixed perspective view, valid comparisons can be drawn with earlier games like Temple of Elemental Evil (min spec 700MHz CPU, 128MB RAM, 32MB GPU) or Beyond Divinity (800MHz PIII, 256MB RAM, 64MB GPU). PoE's min spec (2.5GHz Core i3, 4GB RAM, 512MB GPU) is completely out of line. Just none you'd care to name publicly, eh? If it was one game only, you'd have a point but several other Unity-based games have been mentioned in this thread as showing poor performance also. That does fairly put the spotlight on Unity, since it either proves it to be a bottleneck, or so difficult to get good performance out of that nobody bothers. This isn't to say that people should expect good performance of Pillars from the start - as I and others have said, bug-fixing should take priority over speed improvements. However performance tuning can have a huge impact and any experienced developer should know that. As I said before nobody in this thread can see the code, therefore you cannot comment on if the code was written efficiently or not. For example, in some cases managing memory/garbage collection in Unity can be eased by using Object pooling. Given game A & B both being visually identical, one has pooling the other doesn't, the one with pooling will perform better! So no, you cannot use the task manger to profile a game. One example of a game Engine I worked on was Nightmare Ned (3D) for Disney. I also created various other games in the 80's, but I eventually moved away from games to make better money at Adobe. I have also worked on device drivers for non-linear video editing hardware for Sanyo Electronics. This is not really a discussion about my career though (I am retired now, been so since I was 50), it is a discussion where we are trying to determine what factual basis you have when claiming it is Unity causing the game to be slow (which it isn't on all machines). You need to backup your arguments with real knowledge, not armchair development and speculation. If we had the code in front of us, we could see where any bottlenecks might be, but without it we have pure speculation. I can use the Unreal SDK and write a ****ty poor performing game with it, that is easy to do, using it to the best of its capabilities requires knowledge of it and how it manages resources for example. Unity is the same way, one guy can write **** and another can create something amazing, the engine is not the problem here. Also, in many of the performance posts I see people (not saying YOU) are using Intel graphic chips and expecting high performance! LOL... try lowering your settings, especially when running on a machine that does NOT MEET THE MINIMUMS.

Wrong, the fastest games were writtten in Assembly language and eventually C, then C++. C# and Java are higher level languages, but they are perfectly capable of producing very fast games, it all depends on the skill and knowledge of the developer! And regarding DirectX, it is as fast as possible to write to a graphics card without creating your own device drivers! Do you know how DirectX functions under the hood? I do!

PoE works fine, even maxed out on my gaming laptop, perhaps your computer is the issue? Until you are able to see the code, you are just blowing smoke. Unity has MANY successful games, it has for many years, how about you post some reliable counter?

Exactly right, and with deadlines being what they are today, developers do not write as much custom engine code as they used to. Hell, back when I started developing (8 bit computers) we packed a big punch into games by using assembly language, people do not use asm today, they rely on high level languages like C/C++/Java/C# and high level SDK's such as DirectX to access the hardware for them. Now today cross platform is a huge thing, and maintaining your own cross platform engine is a huge undertaking. We did this at Adobe, had our own framework to develop for mac and pc at the same time, but fortunately this was not for games but applications like Photoshop and Illustrator, a game framework is much more difficult, especially when it comes to consoles, pc clones, mac, linux, etc. If you are not a developer, you have zero understanding of this. Looking at a task manager or memory dump is meaningless without knowing the context within the code. For example, one bone head can write sloppy code that uses DirectX, if they have piss poor texture management, poor 3D object optimization, poor culling, etc, someone who is not a developer would claim DirectX is slow. ROFLMAO

You don't need to be a developer to know what framerate you're seeing from a game, or how much system/GPU memory it is taking. And there are several examples of Unity games showing significantly higher memory utilisation and poorer performance compared to those using "native" engines, such as Legends of Aethereus or Dreamfall Chapters. Based on Unity output logs I've received following a crash, Legends of Aethereus had 240MB allocated yet ended up using 2GB. Dreamfall Chapters reported 800-900MB allocated when it took up 2.8GB. Not (yet) seen Pillars use more than 1.6GB, but this is a spectacular amount of memory compared to what Temple of Elemental Evil or Divine Divinity/Beyond Divinity needed for their graphics. Nice try but wrong, looking at frame rates does not tell you anything about the engine because you do not see the code in a profiler to see where the bottle necks are. There are ways to control your memory footprint and other things if you know what you are doing, people do it all the time on mobile devices. Have you developed any native engines? I have, many times over the past 30 years as a developer.

Stop kidding. Divinity: Original Sin is in 3D and its characters have more polygons than PoE. D: OS is running wonderful on high details on my box. PoE slows down from time to time in some locations. i7 3770k 3.5GHz, Geforce 660 GTX Titanium 2GB, 16GB RAM. PoE looks worse than Temple of Elemental Evil (and ToEE had beautiful trees in 3D), but runs much worse. It's messed up Unity engine which is terribly slow. It's also the case in Wasteland 2. He's talking about Unity engine in specific. It handles 3d models horribly. Divinity: Original Sin has nothing to do with it, since Larian used their own in-house engine. So you seem to know a lot about Unity, how many times have you developed anything for it? Do you know the exact specifics regarding the 3D rendering and limitations of models in Unity 3D? Forget Unity for a minute, since you seem to know so much, how many commercial games have you developed with or without Unity 3D? Have you seen the Unity code? Have you seen the PoE code? How about Divinity Code? I thought so... BTW, even on my Laptop I have zero performance issues with PoE.

You just summed up every Unity 4 game. You need to learn a thing or two about Unity and development before making such ignorant statements. There's 3 choices really: - Either Unity is **** and that's why every game developed on it is either some mobile game or an unoptimized pc title; - Or the devs just don't know what the **** they're doing but they just keep using unity because hey it's free lol Unity IS a steaming pile of **** when it comes to using resources efficiently. it is no coincidence that almost every game released on Unity seems to have the same problems. I understand why Obsidian chose Unity, and I'm not even mad. They said they have no experience with Unity, they're still learning, which is ok by me. I'm not gonna die because my game drops to 30 fps. It's just annoying and I'd be glad to see it fixed. I just hope they move to Unity 5 in a sequel. You are once again completely wrong. The developer has full control over how resources are managed and there have been MANY successful games made with it, including games that run on limited embedded systems such as iOS and Droid. In addition, Unity is only free if you make less than $100k. Don't try to blame the engine until you have written code for it and released a commercial title. I get a feeling your machine just sucks. You must be one of those guys who thinks buying a bunch of parts from NewEgg (or wherever) makes you an expert at building a good machine. ROFLMAO

You just summed up every Unity 4 game. You need to learn a thing or two about Unity and development before making such ignorant statements.

Then we would need a kickstarter for the Unity engine. The reason behind the large "hotfixes" and patches (also seen at Wasteland 2) is the Unity engine, which makes it impossible to do small stuff without having to update everything else. so go, tell Unity they need a kickstarter for better patching experience. I doubt they'll listen. ^^ Hate to be "that guy" - But making patches that only change file DIFFERENCES have been around since the days before the floppy disc. If Obsidian can't be bothered to do that, you're getting those filesizes when changing a few simple text files within a much larger archive. Replacing files is simpler since you don't have to have an exact version of a file - But since Unity uses really dumb archive formats, (lazy) developers who just want a patch out NOW - NOW just replace files outright. Both of you are pretty clueless about Unity since you are both wrong.

It does impact everyones play if the developer is wasting time implementing a useless feature. Here is an example of thinking out a battle sort of the way it should be done. If he would have been more careful and gotten off the traps before the fight, it would have been better! If there was a con feature, he probably would not even have tried! Anyway, this is what makes people like CRPG's that don't hand hold, check it out: https://www.youtube.com/watch?v=qFrfcKroZsM&feature=player_detailpage#t=201

DLL's do in fact contain executable code, it is dynamically linked (as opposed to a statically linked .lib file) to applications. When an application that is dependant on the DLL is loaded, so is the DLL, and when the dependant functions are called, they execute code in the DLL that is loaded in the same process address space as the application. In addtion, many applications share the same DLL's, for example the Microsoft C/C++ runtime DLL's. If one was infected with a virus, any application that uses it will be executing the infected code.

Question for the OP.... Why did you need Linux to do that? roflmao

Problem is they have more important things they could do, like fix all the bugs. Adding hand holding features that are not required except by people playing at difficulty levels they are not capable of is just a waste of time. A bit of common sense and reading can avoid most all deaths in this game provided you know what you are doing and not playing beyond your ability.