405 karma · joined March 16, 2016
Besides the speedup, there is a very interesting feature of OpenSubdiv - local edge creasing. To influence the general creasing or smoothing of a subd mesh, an artist usually has to add more or subtract geometry in an area, respectively - whereas OpenSubdiv gives you the alternative option to assign a crease value to an area of the source mesh which influences the apparent creasing of the resultant mesh in that area without the artist having to add more geo. It works some of the time: not every artist likes using local edge creases but for those that do, it can be a very big help, considering the the occasional difficulty in adding new geometry to a mesh that flows correctly and doesn't accidentally ruin the rest of the mesh.
- Unity is only for games
Who said they were? You can find lots of examples of game engines being used for other applications, such as in Archviz, non-game simulation areas, interactive art, etc.
- You can only do small games with Unity
Again, who said this? If an engine is free and well supported you might find a lot of smaller games on it, but that's not indicative of the engine as a whole. If you're planning on making a large game, the question you'd be asking is not whether you can make a larger game in Unity, but whether it's appropriate for your larger game in particular.
- Unity is worse than Unreal Engine
Now that's a opinion if I've ever heard of one. Also, you don't need to use C++ to use Unreal. UE4 natively supports Blueprint scripting out of the box (I wouldn't recommend making a game completely in a visual programming language to begin with, anyway). Support for interacting with Unreal through other languages (JavaScript, Nim, etc.) has shown significant progress in the community.
- You don’t need programming knowledge to use Unity
Many of the popular free engines nowadays have some form of visual programming feature. You'd be severely hurting yourself trying to accomplish a bigger problem using visual languages only, however.
- All Unity games looks the same
Some gamers enormously conflate a game's art with its engine, which is completely wrong. Bad art will look bad in any environment - any developer would know that.
- Unity has a lot of bugs
That's an incredibly vague statement that you can apply to just about any large software project, not even just game engines.
http://www.peazip.org/ - Zipping/Unzipping utility, better than WinRAR or 7-Zip
http://implbits.com/products/hashtab/ - Shell extension that adds a panel in the file properties window that can compute and compare a hash against many different hash functions
http://mactype.net/ - Shell extension that gives various options to modify Windows' anti-aliasing scheme. Useful if you're not a fan of TrueType's look. Can cause noticeable lag and drawing issues on some less powerful systems, though
http://cmder.net/ - Alternative, more-featured terminal emulator for windows (works with both Cmd/PowerShell)
https://en.wikipedia.org/wiki/S_(programming_language) (Not really sure how you'd search for this language in particular, though...)
Many a student thinks to themselves in a math class: "Man, I'll never use this." When you actually need the math, suddenly you have this "oh shit" moment and you step into gear.
Either way, opening an article that says "Your programming language is probably unproductive" which immediately devotes itself to whining over pedantic syntax bullshit...makes me not want to read it.
To be fair, exploiting games and emulators directly aren't a particularly common attack vector. I've never heard of any wild malware that attempted to exec itself via a (legit) emulator, although IIRC arbitrary code exec on clients had popped up a few times in the wild on older multiplayer games (mostly CoD and various Source multiplayer games). Most of the "malware" stuff related to emulators I've heard of are cheap tricks (e.g. tainted emulator binaries on shady websites, EXE files deceptively labeled as ROMs) and not any fancy exploits.
If you want you can nudge the compiler in the direction you want via the "inline" keyword, although the compiler won't always take this suggestion to heart. MSVC has "__forceinline" but it too will not always comply.
Before the "inline" keyword, macros were the standard way to do this, IIRC
You make a good point, too, that multiple-return being the only way to do errors is more ideal than the language saying "oh, we support that, but we also have exceptions, too!" At least in a language with Go's philosophy, you can expect other people's libraries and your own code to play by the same rules.