• Content count

  • Joined

  • Last visited

Community Reputation

266 Neutral

About MAnd

  • Rank
  1. My few cents on this debate are the following. If the usage you foresee does not require a lot of programming (i.e. direct manual programming), Unreal is way easier than Unity do to the well crafted blueprint system. If, as any reasonably professional game developer, you plan to do (or to have other people in your team) to do heavy coding, Unity is way easier than Unreal. Not so much because it relies on C# versus C++. What makes coding in Unity easier in comparison to Unreal are three things. First, the online material you can find on how to things in Unity is much bigger. For what I hear, Unity's official community is also often much more inclined to help and give answers to newbies. Second, Unity's documentation is miles better than Unreal's. Third, Unity's code API is way better design. Or, to be direct: Unreal's API is a mess, badly documented, and with some functions with the silliest, cryptic prototypes I have ever seen. going over Unreal's engine source code, I find it to be just as bloated and confused. On the other hand, I never understand this idea that C++ is so much harder than C#. At the beginning? Sure, by all means. However, since it have orders of magnitude more online and academic material, in a long term, advanced project, try finding source code samples of advanced algorithms and in-depth books on C# and you will see what I mean. In the long term, it is my solid believe that if you can learn only one of those languages, C++ will payoff so, so, so much more. Also, Unity's easiness comes with a price. Unreal has way more functionality out of the hat. I mean, Unity included basic features like GPU instancing and 9-sprites only last year, for god sake! The refinement of Uneal's rendering system is certainly also unmatched by Unity. Sure, you can get Unity games looking pretty great, but the cost of time and effort is leaps and bounds more than in Unreal. It is not a surprise that commercial games made in Unity usually look bad, while even a novice prototype made in Unreal often looks great: because Unreal is set up in a way that is far easier to achieve the good-lookingness. However, that comes with a huge cost too. It is absurdly harder to customize the shading pipeline in Unreal than it is in Unity. Not to mention to use custom computer or geometry shaders. It is a few clicks away in Unity. It often is hellish nightmare in Unreal. So, even if Unreal is open source, in practice, the high costs in terms of programming time often make it so that you get much less flexibility in Unreal than in Unity in terms of the look of your game. That is probably why so many online videos and people's prototypes made in Unreal all look great but all have the same artistic look. But talking about open-sourceness, it is plain ridiculous that at this point, with Unreal, CryEngine and Amazon's engine being free to use and open source, Unity is still expensive for any serious indie usage and closed source. The fact that it is closed source creates two basic problems: 1) total lack of flexibility in what regards anything that lays within the engine (in Unity, you can't even merely make a GameObject skip view-frustum culling if you want to!); 2) you are in Unity's hands if there is engine-related bug that is affecting your players. I, for once, would never, ever work by option with an engine over which I do not have access to source code if needed. Never. Ever.   I also think that the business model pursued by Unity is very debatable. Their new pricing options look very bad for most indies. Their new versioning name that will start is still a mess. And they make odd choices, like leaving the dark theme of the editor for only those who pay subscription for their engine - i.e. if you want to use Unity free, you have to endure your eyes being hurt by that terribly looking white-ish UI. Anyways. Talking about money, a great side of Unity is that you can find tons of cool assets in their asset store either for free or very cheap. Good stuff in Unreal marketstore are way more expensive in comparison. However, in Unity's asset store is hard to find production-quality material.
  2. This is the second pretty promising article this author publishes here in a row. Nice. However, it's also the second time that he publishes it focusing in profiling comparisons but... without showing the code used for profilling. I really do think that the author - actually all authors, of all articles here and elsewhere - should be required to show how the performance measurement used. Without that, performance comparison are just words in the wind.
  3. I really like the changes. It is looking much cleaner and professional so far. My only disagreement is minor: the change from developer's journal to developer's blog does not gain anything while loosing a 18 years old characteristic of the site, so there is just not gains and at least a cost. Besides that, pretty exciting to see the site evolve!
  4. This is a great post in many aspects. First, it's rare to find real discussions on the implementation of VF algorithms that use both SSE and multi-threading. Second, it's even harder to find code samples of those things. Although I didn't check the code, I am sure that it might be pretty usefull for people who never tried such techniques. It is a very generous offer by the author and if code is good it will be a gold mine for beginners. Third, I always appreciate when authors take the time to actually compare algorithms. It is of little no value to come here and advocate for an algorithm without performance analyses. This article does not commit such sin.   On the nitpicking side, I think the article misses details about how the performance was measured. Every article that makes performance comparisons should give details about that part since they can completely alter everything. Additionally, I would say that the text is often too rushed. Many parts will leave interested readers at a loss. In particular, rushing over details about SSE, threading and GPU is dangerous. Also, the text really needs to be reviewed. I am not talking about the written English, but about things like: it does not make sense to include "Not all algorithms could be easily rewrited in SSE" in the list of SSE drawbacks that make SSE less performant. Those kind of minor things are all over the article.   However, don't get me wrong. The article is very welcome and pretty useful. Again, I am very happy to see someone actually share actual implementation of actual multi-threaded+SSE VF code. Not to mention a GPU implementation. I would only stress to whoever read this, that the author chose (understandably, given the purposes of this article) to not deal with spatial partitioning. But in my experience, in many cases even a basic implementation of an Octree or KD-tree outperform even SSE+multithreaded non-spatialized solutions (although I never compared against GPU non-spatialized solutions, but if the performance metrics here are correct, these would be outperformed as well). Of course, it dependes heavily on the chracteristics of each game or engine. But anyone needing high performance should also try at least an Octree and then decide in case by case basis.   Anyways, thanks for the article!